Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Ответы по ТООМ - файл Ответы на вопросы.doc


Ответы по ТООМ
скачать (773.2 kb.)

Доступные файлы (1):

Ответы на вопросы.doc2054kb.16.05.2008 13:14скачать

содержание
Загрузка...

Ответы на вопросы.doc

Реклама MarketGid:
Загрузка...
1. Предпосылки возникновения объектно-ориентированного подхода [1/2].

По своей природе компьютер может выполнять только простейшие операции, которые можно вводить одну за другой в его память прямо в машинных кодах. Изнурительная монотонность такой работы привела первых программистов к естественному решению создания ассемблеров. Т.е. средств упрощающих написание программ за счет написания машинных кодов в некоторых мнемонических обозначениях с последующим автоматическим переводом. Дальнейшее развитие этих идей привело к созданию первых языков программирования высокого уровня в которых длинные и сложные последовательности машинных кодов были заменены одним обозначающим их словом или оператором. Эти нововведения существенно упростили написание программ. Тем не менее программы написанные сплошным текстом часто содержали запутанные последовательности операторов в которых зачастую было трудно уловить нить логических рассуждений. Эти проблемы были решены с появлением структурного программирования.

Параллельно был введен принцип декомпозиции. Следующим шагом стало появление модульного подхода, когда отдельные части программ стали отдельные самостоятельные структуры или модули.

Появление программирования снизу-вверх и сверху-вниз так же существенно упростило процесс написания программ. Методы основанные на этих подходах имеют общую черту, в них данные и обрабатывающий их код существуют отдельно друг от друга.

В этот период основным показателем сложности разработки программ считали ее размер. На начальных этапах программирование оценивалось значительно ниже реально затрачиваемых усилий, что служило причиной дополнительных расходов и затягивания окончательных сроков готовности программ.

Окружающий нам мир состоит из объектов, поэтому вполне логично было стремление перенести подобный метод представления информации о предметной области в программирование. Стало очевидным, что традиционные методы процедурного программирования не способны справиться ни с растущей сложностью программ и их разработкой ни с необходимостью повышения их надежности. Выходом из этого стало объектно-ориенитрованное программирование (ООП).

*1. Предпосылки возникновения объектно-ориентированного подхода [2/2].

Вместе с развитием ООП стали развиваться и общие объектно-ориентированные методы разработки ПО.

Объектно-ориентированные подход – это подход при котором требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.

С ООП тесно связанно объектно-ориентированное проектирование или моделирование. Если программирование направленно на правильное и эффективное использование контекстных языков, то проектирование направленно на правильное и эффективное структурирование сложных систем.
^ 2. Концептуальная база объектно-ориентированного стиля[1/2].

Каждый стиль программирования имеет свою концептуальную базу. Для объектно-ориентированного (ОО) стиля концептуальная база – это объектная модель, создание которой требует особого ОО мышления.

ОО модель имеет 4 главных св-ва:

1) Абстрагирование – выделение искусственных характеристик некоторого объекта, отличающих его от других видов объектов. Оно включает понятия агрегации и обобщения.

а) Агрегация – это абстракция, которая превращает связь между объектами в некоторый агрегированный объект более высокого уровня.

Осуществляя такую абстракцию, мы можем игнорировать многие детали этой связи.

b) Обобщение – это абстракция, превращающая класс объекта в родовой объект.

2) Инкапсуляция – скрытие внутренней реализации объекта за представляемым этим объектом интерфейсом.

3) Модульность – способность системы быть разложенной на внутренне сильно- или слабосвязанные между собой модули.

4) Иерархия – упорядочение абстракций и разложение их по уровням.

Эти св-ва являются главными и, при отсутствии хотя бы одного их них, модель не будет ОО.

Также существуют 3 дополнительных св-ва:

1) Типизация – создание объектов на основе шаблонов определенного типа.

2) Параллелизм – способность системы обрабатывать несколько сообщений или задачи параллельно.

3) Сохраняемость – способность хранить не только данные, но и объекты в промежутке между отдельными запусками системы.

*2. Концептуальная база объектно-ориентированного стиля[2/2].

Для того чтобы создать ОО программу, необходимо создать некоторый набор объектов с определенным поведением, определить взаимосвязь. В свою очередь для создания объектов необходимо создать их описание, называемое классом.

Важнейшими св-ми класса явл-ся:

1) Наследование – это св-во, в соответствии с которым знания о более общей категории разрешается применять для более узкой категории. Наследование тесно связано с иерархией класса, которая определяет, какие классы следует считать наиболее абстрактными и общими по отношению к другим классам. При этом если некоторый более общий (или родительский) класс обладает фиксированным набором св-в и поведений, то производный от него потомок должен содержать этот же набор св-в и поведений, а также дополнительные, которые будут характеризовать уникальность полученного таким образом класса.

2) Инкапсуляция – это сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. Взаимодействующему с классом субъекту или клиенту нет необходимости знать, каким образом реализован тот или иной метод класса, услугами которого он решил воспользоваться. Конкретная реализация присущих классу методов, которые определяют его поведение, явл-ся собственным делом данного класса. Отдельные св-ва и методы вообще могут быть невидимыми за пределами этого класса.

3) Полиморфизм – это св-во некоторых объектов принимать различные внешние формы в зависимости от обстоятельств. Действия, выполняемые одноименными методами, могут отличаться в зависимости от того, к какому классу относится тот или иной метод.

^ 3.Методология системного анализа и системного моделирования[1/1].
Системный анализ как научное направление появилось раньше, чем ООАП и имеет собственный предмет исследований.

Центральным понятием системного анализа явл-ся понятие системы, под которой понимается совокупность объектов, компонентов или элементов произвольной природы, образующих некоторую целостность.

Определяющей предпосылкой выделения некоторой совокупности как системы, явл-ся возникновение у нее новых св-в, которые не имеют составляющие ее элементы.

Важнейшими характеристиками любой системы явл-ся:

1) Структура – это устойчивая во времени совокупность взаимосвязи между элементами и компонентами системы. Структура системы может отражать самые различные взаимосвязи, в том числе и вложенность элементов одной системы в другую. В этом случае вложенная (более мелкая) система наз-ся подсистемой, а более крупная – метасистемой.

2) Процесс функционирования системы тесно связан с изменением ее св-в или поведения во времени. При этом важной характеристикой системы явл-ся ее состояния, под которым понимается совокупность св-в или признаков, которые в каждый момент времени отражают наиболее существенные особенности поведения системы.

Методология системного анализа служит концептуальной основой системно-ориентированной декомпозиции предметной области. В этом случае исходными компонентами концептуализации явл-ся системы и взаимосвязи между ними.

Результатом системного анализа явл-ся построение некоторой модели системы или предметной области. Применительно к программным системам – это только то понятие модели, которое используется в системном анализе. Т.е. под моделью понимается некоторое представление о системе, отражающее наиболее существенные закономерности ее структуры, процесса функционирования и зафиксированное на некотором языке или в другой форме.

Общим св-ом всех моделей явл-ся их подобие оригинальной системе, а процесс построения и последующего применения модели для получения информации о системе-оригинале наз-ся моделированием.

^ 4. Диаграммы языка UML[1/1].

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций – диаграмм.

В терминах языка UML представлены следующие виды диаграмм:

I. Диаграмма вариантов использования (Use case diagram) (*)

II. Диаграмма классов (Class diagram) (*)

III. Диаграмма поведения (Behavior diagram)

Делится на следующие диаграммы:

1) Диаграмма состояния (Statechart diagram) (*)

2) Диаграмма деятельности (Activity diagram) (*)

3) Диаграмма взаимодействия (Interaction diagram)

Делится на следующие диаграммы:

a) Диаграмма последовательности (Sequence diagram) (*)

b) Диаграмма кооперации (Collaboration diagram) (*)

IV. Диаграмма реализации (Implementation diagram)

Делится на следующие диаграммы:

1) Диаграмма компонентов (Component diagram) (*)

2) Диаграмма развертывания (Deployment diagram) (*)

Из всех видов диаграмм некоторые служат для обозначения двух или более других подвидов диаграмм. При этом в качестве самостоятельных, используются только диаграммы обозначенные (*).

^ 5. Диаграмма вариантов использования[1/2].

Use case diagram – это графическое представление взаимодействия пользователя и компьютерной системы. Каждый use case охватывает очевидную для пользователя функцию системы и решает некоторую дискретную задачу пользователя. Список всех use case’ов фактически определяет функциональные требования к системе, с помощью которых может быть сформулировано техническое задание.

Визуальное моделирование можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной системы к логической, а затем и к физической модели соответствующей программой системы.

Use case diagram явл-ся исходным концептуальным представлением и ее разработка преследует след. цели:

1) Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

2) Сформулировать общие требования к функциональному поведению проектируемой системы.

3) Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.

4) Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Суть Use case diagram состоит в следующем: проектируемая система представляется в виде множества сущностей (актеров), взаимодействующих с системой с помощью так называемых use case’ов.

При этом актером (actor) или действующим лицом наз-ся любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определил сам разработчик. Актеры служат для обозначения согласованного множества ролей, которые могут играть пользователи в процессе взаимодействия с проектируемой системой.

Актеры позволяют узнать:

1) Кто пользуется системой.

2) Кто отвечает за сопровождение системы.

3) Внешнее аппаратное обеспечение, которое использует система.

4) Другие системы, которые должны взаимодействовать с данной системой.

*5. Диаграмма вариантов использования[2/2].

Use case служит для описания сервисов, которые система предоставляет актеру. Каждый use case определяет некоторый набор действий системы при диалоге с актером. При этом ничего не говорится о том, каким образом будет организовано взаимодействие актеров с системой.

Кроме use case и actor элементами данной диаграммы явл-ся интерфейс (Interface) и примечание (Note).

Interface служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры.

Note предназначены для включения в модель произвольной текстовой информации, имеющее непосредственное отношение к контексту разрабатываемого проекта (комментарии или ограничения).

Пример:

Система продажи товаров по каталогу.



Любой из use case может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность.

Рекомендуемое общее кол-во актеров ≤ 20, а use case ≤ 50 иначе модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм. Все сервисы системы должны быть явно определены на диаграмме use case и никаких других сервисов, которые отсутствуют на данной диаграмме, система не может выполнить!

^ 6. Отношения на диаграмме вариантов использования[1/2].

Между компонентами use case могут существовать различные отношения, которые описывают различные взаимодействия актеров друг с другом и с use case.

Два use case, определенные для одной и той же сущности не могут взаимодействовать друг с другом, поскольку каждый из них самостоятельно описывает законченный use case этой сущности.

В языке UML имеется несколько стандартных видов отношений между актерами и use case’ми:

1) Ассоциация (Association relationship)

2) Расширение (Extend relationship)

3) Обобщение (Generalization relationship)

4) Включение (Include relationship)

При этом общие св-ва use case могут быть представлены тремя различными способами с помощью отношений: расширение, обобщение, включение.

^ Association relationship

Это отношение явл-ся одним из центральных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм.

В Use case diagram служит для обозначения специфической роли актера в отдельном use case, т.е. это отношение устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром use case. Обозначается сплошной линией между use case и actor. Может иметь имя и кратность.

^ Extend relationship

Определяет взаимосвязь экземпляров одного use case с более общим use case, св-ва которого определяются на основе способа совместного объединения данных экземпляров. В метамодели отношение расширения явл-ся направленным и указывает, что применительно к отдельным примерам некоторого use case должны быть выполнены некоторые условия определения для расширения данного use case.



*6. Отношения на диаграмме вариантов использования[2/2].

Если имеет место отношение extend от use case А к use case В, то это означает, что св-ва экземпляра use case В могут быть дополнены благодаря наличию св-в у расширенного use case А.

Отношение extend отмечает тот факт, что один из use case подобен другому, но несет большую нагрузку. Удобно использовать такой тип связи при описании обработки аварийной ситуации, возникающей в системе.

^ Generalization relationship

Служит для указания того факта, что некоторый use case А может быть обобщен до use case B. В этом случае use case А будет являться специализацией use case B. При этом В наз-ся предком (родителем) по отношению к А, а use case А наз-ся потомком по отношению к B.



Потомок наследует все св-ва и поведение своего родителя, а также может быть дополнен новыми св-ми и особенностями поведения.

^ Include relationship

Это отношение между двумя use case’ами указывает, что некоторое заданное поведение для одного use case’а включается в качестве составного компонента в поведение другого use case. Отношение включение, направленное от use case A к use case B, указывает, что каждый экземпляр use case A включает в себя функциональные св-ва, заданные для use case B. Эти св-ва специализируют поведение use case A на данной диаграмме.

Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового use case к включаемому use case и помечается стереотипом <<include>>.



Отношения Расширения, Обобщения и Включения могут существовать только между use case’ми, которые определены для одной и той же сущности.

^ 7. Диаграмма классов[1/3].

Class diagram. Процесс разработки диаграммы классов (ДК) занимает центральное место в ООАП сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи зависит не только успех процесса проектирования, но и производительность программы.

ДК принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые зависят или инвариантны времени. ДК используется также для создания исходного кода приложения.

Class в языке UML служит для обозначения множество объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами других классов.

Графически класс изображается в виде прямоугольников.

Обязательным элементом обозначения класса явл-ся его имя. Оно должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм класса. Рекомендуется в качестве имен классов использовать существительные. Имена классов образуют словарь предметной области.

^ Атрибуты класса

Каждому атрибуту класса соответствует отдельная строка текста:

<квантор видимости> <имя атрибута> [кратность] <тип значения атрибута> = <исходное значение> <строка св-ва>.

1) Квантор видимости может принимать одно их трех возможных значений и выражается с помощью специальных символов:

“+” – обозначает атрибут с областью видимости типа public. Атрибут в этой областью видимости доступен и виден из любого другого класса (пакета), в котором определена диаграмма.

“#” – обозначает атрибут с областью видимости protected. Атрибут с этой областью видимости недоступен (не видим) для всех классов за исключением подкласса данного класса.

“–”– обозначает атрибут с областью видимости private. Атрибут с этой областью видимости недоступен (не видим) для всех классов без исключения.

Если квантор видимости отсутствует, считается, что видимость атрибута не указывается.

2) Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и должно быть уникальным в пределах своего класса.

3) Кратность характеризует общее кол-во конкретных атрибутов данного типа, входящих в состав отдельного класса. Если кратность не указана, по умолчанию принимается значение равное 0.

4) Тип значения атрибута представляет собой выражение семантики, которое определяется языком спецификации соответствующей модели.

*7. Диаграмма классов[2/3].

В нотации UML иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели.

Пример.

Цвет: color

Имя сотрудника [1..2]: string

5) Исходное значение служит для задания некоторого начального значения для соответствующего атрибута в момент создания некоторого экземпляра класса.

6) Строка св-ва служит для указания значения св-в, которые могут быть применены к данному элементу.

^ Операции классов

Это некоторый сервис, который предоставляет каждый экземпляр класса по определенному требованию.

Совокупность операций характеризует функциональный аспект поведения классов. Запись операций классов в языке UML стандартизована и подчиняется определенным синтаксическим правилам:

<квантор видимости> <имя операции> (список параметров): <выражение типа возвращаемого значения> {строка св-ва}.

1) Квантор видимости аналогично атрибутам.

2) Имя операции – строка текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальна в пределах данного класса. Имя операции явл-ся единственным обязательным элементом синтаксического обозначения операции.

3) Список параметров разделенных запятой – это перечень формальных параметров, каждый из которых может быть представлен в следующем виде:

<вид параметра> <имя операции> : <выражение типа> = <значение параметра по умолчанию>.

4) Выражение типа возвращаемого значения явл-ся зависимым от языка реализации спецификации типа или типов значений параметров, которые возвращаются объектам после выполнения соответствующих операций.

5) Строка св-ва аналогично атрибутам.

^ Элементы диаграммы классов

1) Интерфейсы могут уточнять классы. Для их изображения используется специальный графический символ: прямоугольник с надписью <<interface>>. При этом секция атрибутов отсутствует, а указывается только секция операций.

2) <<Object>> явл-ся отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретное значение атрибутов. Изображается в виде прямоугольника, как и классы. Отличие лишь в указании имен объектов, которые обязательно подчеркиваются:

<<имя объекта : имя класса>>.

Имя объекта может отсутствовать. В этом случае объект считается анонимным. Может отсутствовать и имя класса, но тогда обязательно указывается имя объекта. Атрибуты объекта принимают конкретные значения.

3) Шаблон (template) предназначен для обозначения такого класса, который имеет один или более нефиксированных параметров. Он определяет целое

*7. Диаграмма классов[3/3].

семейство или множество классов, каждый из которых может быть получен путем связывания этих параметров с действительными значениями.

После разработки ДК процесс ООАП может быть продолжен в двух направлениях:

1) если поведение системы тривиально, то можно приступить к разработке диаграмм кооперации и компонентов.

2) для сложных динамических систем поведение представляет важнейший аспект их функционирования. Детализация поведения при этом осуществляется при разработке диаграмм состояния, деятельности и последовательности.

Пример:




^ 8. Отношения между классами. [1/2]

Кроме внутреннего устройства или структуры класса на соответствующей диаграмме указываются различные отношения между классами. Базовыми отношениями или связями в языке UML являются: отношение зависимости (dependency relationship); отношение ассоциации (association relationship); отношение обобщения (generalization relationship); отношение реализации (realization relationship).

Отношение зависимости. В общем случаи указывается некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которые не являются отношением ассоциации, обобщения и реализации, оно касается только самих элементов модели. Отношение зависимости используется только в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели. На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса клиента к не зависимому классу или классу источнику.

Отношение ассоциации. Это отношение соответствует наличию некоторого отношения между классами. Наиболее простой случай данного отношения это бинарная ассоциация. Она связывает в точности два класса и как исключение может связывать класс с самим собой.



Для бинарной ассоциации на диаграмме может быть указан порядок следования классов с использованием треугольника в форме стрелки и именем данной ассоциации. Направление этой стрелки указывает на порядок класса, один из которых является первым, а другой вторым. Существует так же N-арная ассоциация.



Частным случаем отношения ассоциации является так называемая исключающая ассоциация. Семантика данной ассоциации указывает на тот факт, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. Специальной формой или частным случаем отношения ассоциации является отношение агрегации, которое в свою очередь тоже имеет свою специальную форму, отношение композиции.

^ Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Данное отношение имеет фундаментальное отношение для сложных систем, поскольку применяется для представления системных взаимосвязей типа «часть-целое». Это отношение по своей сути описывает декомпозицию или разбиение сложной системы на более простые части, которые так же могут быть подвергнуты декомпозиции, если в этом возникает необходимость.



*8. Отношения между классами. [2/2]

Деление системы на составные части представляют собой некоторую иерархию ее компонентов, однако данная иерархия принципиально отличается от иерархии порождаемой отношением обобщения. Отличия заключаются в том, что части системы ни как не обязаны наследовать ее свойства и поведение, поскольку являются вполне самостоятельными сущностями. Более того части целого обладают своими собственными атрибутами и операциями, которые отличаются от атрибутов и операций в целом.

^ Отношение композиции служит для выделения специальной формы отношения «часть-целое», при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются все его составные части.



Отношение обобщения. Является обычным таксономическим отношением между более общем элементом, родителем или предком, и более частным или специальным элементом (дочерним или потомком). Применительно к диаграмме классов данное отношение описывает иерархическое строение класса, наследование их свойств и поведения. При этом предполагается, что класс потомок обладает всеми свойствами и поведением класса предка, а так же имеет свои собственные свойства и поведение, которые отсутствуют у класса предка.



Элементами диаграммы класса являются так же интерфейсы, объекты и шаблоны (параметризованные классы).

Интерфейсы могут уточнять классы и для их изображения используется специальный графический символ мо стереотипом <<interface>>. При этом секция атрибутов отсутствует, указывается только секция операции.

Объект является отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. Для графического изображения объекта используется такой же символ, что и для класса, отличия проявляются при указании имен объекта, которые в случае объектов обязательно подчеркиваются (<< имя объекта: имя класса >>). Имя объекта может отсутствовать, в этом случаи предполагается что объект является анонимным. Отсутствовать может и имя класса, в этом случаи обязательно является указание имени объекта. Атрибуты объектов принимают конкретные значения.

Шаблон (template) предназначен для обозначения такого класса, который имеет один или более нефиксированных формальных параметров. Он определяет целое семейство или множество классов, каждый из которых может быть получен связыванием этих параметров с действительными значениями.
^ 9. Диаграмма состояний. [1/4]

Для моделирования поведения на логическом уровне в языке UML могут использоваться сразу несколько канонических диаграмм, каждая из которых фиксирует внимание на отдельном аспекте функционирования системы. В отличии от других диаграмм ДС описывает процесс изменения состояний только одного класса, а точнее одного экземпляра определенного класса, т.е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменении состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или из вне. Главное предназначение этой диаграммы описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течении его жизненного цикла. ДС по существу является графом специального вида, который представляет некоторый автомат. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдо состояний), дуги графа служат для обозначения переходов из состояния в состояние. ДС могут быть вложены друг в друга и основными понятиями, входящими в формализм автомата являются состояние и переход.

Состояние (state). В языке UML под состоянием понимается абстрактный метакласс, используемый для моделирования отдельных ситуаций, в течение которых имеет место выполнения некоторого условия.

Обозначается состояние следующим образом:



Состояние может быть задано в виде набора конкретных значений атрибута класса или объекта, при этом изменение их конкретных значений будет отражать изменение состояния моделируемого класса или объекта. Под действием в языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения. Имя состояния представляет собой строку текста, которая раскрывает содержательный смысл данного состояния. Поскольку состояние системы является составной частью процесса ее функционирования, рекомендуется в качестве имени использовать глаголы в настоящем времени или соответствующее причастие. Имя состояния может отсутствовать, тогда оно считается анонимным. Имена состояний в пределах одной диаграммы не должны совпадать.

Следующая секция содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого объекта в данном состоянии < метка – действия «/» выражение действия >.

Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, которая определена выражением действия. Перечень меток действия имеет фиксированные значения, которые не могут быть использованы в качестве имен событий.

- entry – указывает на действие, специфицированное следующей за ней выражение действия, которое выполняется в момент входа в данное состояние;

- exit – выходное действие;

*9. Диаграмма состояний. [2/4]

- do – специфицирует выполняющуюся деятельность («do activity»), которое выполняется в течение всего времени пока объект находится в данном состоянии и до тех пор пока не закончатся вычисления. При завершении события генерируется соответствующий результат;

- include – используется для обращения к подавтомату, при этом следующая за ней выражение действия содержит имя этого подавтомата.



^ Псевдо состояние – начальное состояние. Оно представляет собой частичный случай состояния, которое не содержит ни каких внутренних действий. В этом состоянии объект находится по умолчанию в начальный момент времени. Оно служит для указания в диаграмме графической области, с которой начинается процесс изменения состояния.

^ Конечное или финальное состояние. В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени.

Все диаграммы состояний начинаются со значка Start State и должны заканчивать значком End State. При этом значок начала работы может быть только один, а значков окончания может быть сколько угодно.

Переход. Простой переход (Simple transition) представляет собой отношение между двумя последовательными состояниями, которые указывают на факт смены одного состояния другим. Переход осуществляется при наступлении некоторого события: окончание выполнения деятельности; получения объектом сообщения или приемом сигнала. На переходе указывается имя события. Кроме того на переходе могут указываться действия, производимые объектом в ответ на внешние событие при переходе из одного состояния в другое. Срабатывание перехода может зависит так же от выполнения определенного условия называемого сторожевым условием. Объект переедет из одного состояния в другое в том случаи если произошло указанное событие и сторожевое условие приняло значение «истина». Переход может быть направлен в то же состояние, из которого он выходит. На диаграмме показывается целевой направленной линией. Имя события идентифицирует в каждый отдельный переход на диаграмме состояния и может содержать строку текста. В этом случаи принято считать переход триггерным. Если рядом со стрелкой перехода не указана ни какая строка текста, то соответствующий переход является не триггерным и в этом случаи из контекста диаграммы состояния должно быть ясно, что после окончания каждой деятельности он срабатывает.

Сторожевое условие (guard condition). Если оно есть, то всегда записывается в прямых скобках после события триггера и представляет собой некоторое булевское выражение. Введение для перехода сторожевого условия позволяет явно специфицировать семантику его срабатывания.

*9. Диаграмма состояний. [3/4]



Выражение действия (action expression). Выполняется только в том и только в одном случае, когда переход срабатывает. Представляет собой атомарную операцию, выполняемую сразу после срабатывания соответствующего перехода до начала каких ни будь действий в целевом состоянии.

Составное состояние. Это такое сложное состояние, которое состоит из других вложенных в него состояний. Последними будут выступать по отношению к первому как подсостояние. Любое из под состояний в свою очередь может являться составным и содержать внутри себя другие вложенные подсостояния.

Количество уровней вложенности составных состояний не фиксировано в языке UML. Последовательные подсостояния используются для моделирования такого поведения объекта во время которого в каждый момент времени объект может находиться в одном и только в одном подсостоянии. Параллельные подсостояния позволяют специфицировать 2 и более подавтомата, которые могут выполняться параллельно внутри составного события.



Допустимо одновременное нахождение объекта в подсостояниях 1,3,4. Выход из составного состояния будет возможен лишь в том случае, когда все подавтоматы будут находиться в своих конечных подсостояний.

Сложные переходы. Рассмотренное выше понятие перехода является вполне достойным для большинства типичных расчетновычислительных задач. В отдельных случаях переход может иметь несколько состояний источника и несколько целевых состояний, это параллельный переход.

*9. Диаграмма состояний. [4/4]

Введение в рассмотрение параллельного перехода обусловлено необходимости синхронизированности и/или разделить определенные подпроцессы на отдельные нити без спецификации дополнительной синхронизации параллельных подканалов.



Если параллельные переход имеет две и более входящих дуг, то его называют соединением. Если же он имеет две или более исходящих дуг, то его называют ветвлением.



По своему названию ДС не является обязательным представлением в модели и как бы присоединяется к тому элементу, который по замыслу разработчика имеет не тривиальное поведение в течение своего жизненного цикла. При выделении состояний и переходов необходимо помнить, что длительность срабатывания отдельных переходов должна быть существенно меньше чем нахождение моделируемого объекта соответствующих состояний. Объект в каждый момент времени может находиться только в единственном состоянии и ни какие 2 перехода из одного состояния не могут сработать одновременно.

^ 10. Диаграмма деятельности. [1/2]

При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояния, но и детализировать особенности алгоритмической и логической реализации выполняемой системы операций. Традиционно для этой цели используют блок схемы или структурные схемы алгоритма. Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похоже на нотацию диаграммы состояний. Отличие заключается в семантики состояний, которая используется для представления не деятельности, а действий и в отсутствии на переходах сигнатур событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии. Графически ДД представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами переходы из одного состояния действия к другому. Таким образом ДД можно считать частным случаем диаграммы состояния. Основным направлением использования ДД является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения.

Состояние действия. Является специальным случаем состояния с некоторым входным действием и по крайне мере одним входящим из состояния переходом. Этот переход не явно предполагает, что входное действие уже завершилось. Рекомендуется в качестве имени простого действия использовать глагол с дополнительными словами или выражениями. Каждая ДД должна иметь единственное начальное и единственное конечное состояние. ДД принято располагать таким образом, чтобы действия следовали сверху вниз.

Переходы. При построении ДД используется только не тригерные переходы, т.е. такие которые срабатывают сразу после завершения деятельности или выполнения соответствующего действия. Если из состояния действия выходит единственный переход, то он может быть ни как не помечаться. Если же таких переходов несколько, то срабатывать сможет только один из них. Именно в этом случаи для каждого из таких переходов должно быть явно записано сторожевое условие. Графически ветвления (разделение деятельности на альтернативные ветви в зависимости от значения некоторого промежуточного результата) обозначаются небольшими ромбами, внутри которых нет ни какого текста (рис а). Для представления параллельных процессов в UML используется графическое представление показанное на рис.б, при этом разделение имеет один входящий переход и несколько выходящих (слияние наоборот).

Плавательные дорожки. ДД отражают происходящие события, однако они не чего не говорят о том кто участвует в реализации того или иного процесса. Один способ решения этой проблемы снабдить состояние меткой класса, которая за него отвечает или использовать плавательные дорожки.

*10. Диаграмма деятельности. [2/2]





^ 11. Диаграмма последовательности. [1/2]

Одной из характерных особенностей систем различной природы и назначения является взаимодействие между собой отдельных элементов из которых образованы эти системы. В языке UML взаимодействия рассматривается в информационном аспекте и коммуникации, т.е. взаимодействующие объекты объединяются между собой некоторой информацией (сообщения). Для моделирования взаимодействия объектов в языке UML используется соответствующие диаграммы взаимодействия. Говоря об этих диаграммах имею в виду два аспекта взаимодействия. Во первых взаимодействие объектов можно рассматривать во времени и тогда для представления временных особенностей передачи/приема сообщений между объектами используется диаграмма последовательности. Во вторых можно рассматривать структурные особенности взаимодействия объектов для представления структурных особенностей передачи и приема сообщений между объектами используется диаграмма кооперации.



На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии. Ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения: 1) слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта участвовавшего во взаимодействии. Крайней слева объект является инициатором взаимодействия; 2) вертикальная временная ось направлена сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействие объектов реализуется по средствам сообщений, которые посылаются одними объектами к другим. Линия жизни служит для обозначения периода времени в течение которого объект существует в системе и следовательно может потенциально участвовать во всех ее взаимодействиях. Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены чтобы освободить занимаемые ими ресурсы.

*11. Диаграмма последовательности. [2/2]

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от

других объектов. Чтобы явно выделить подобную активность объектов в языке UML применяются специальные понятия, получивши название фокуса управления.

Иногда некоторый объект может инициализировать рекурсивное взаимодействие самим собой. Сообщение представляет собой законченный фрагмент информации, который отправляется одним объектом к другому. При этом прием сообщения инициализирует выполнение определенных действий, направленных на решение отдельных задач и тем объектам, к которым это сообщение отправлено.

Для отображения ветвления рисуется 2 или более стрелки, выходящие из одной точки фокуса управления объекта. При этом соответствующие условия должны быть явно указаны рядом с каждой из стрелок в форме сторожевого условия.



^ 12. Диаграмма кооперации. [1/2]

ДК предназначена для спецификации структурных аспектов взаимодействия. В отличии от диаграмм последовательности на ДК изображаются только отношения между объектами, играющие определенные роли во взаимодействии. На этой диаграмме время так же не указывается в виде отдельного измерения, поэтому последовательность взаимодействий и параллельных потоков может быть определено с помощью порядковых номеров. Понятие кооперации служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделировании систем. Цель самой кооперации состоит в том, чтобы специализировать особенности реализации отдельных наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.



Объект является отдельным экземпляром класса, который создается на этапе выполнения программы. Он может иметь свое собственное имя и конкретное значение атрибутов. Существуют мульти объекты, которые представляют собой целое множество объектов на одном из концов ассоциации. Существует составной компонент, который предназначен для представления объекта, имеющего собственную структуру и внутренние потоки управления. Активный объект имеет свою собственную нить управления и может инициировать деятельность по управлению другими объектами. Связь является экземпляром или примером произвольной ассоциации. Связь, как элемент языка UML, может иметь место между двумя и более объектами.

Сообщение на ДК специфицирует коммуникацию между двумя объектами, один из которых передает другому некоторую информацию, при этом первый объект ожидает что после получения сообщения вторым объектом последует выполнение некоторого действия. Таким образом именно сообщение является причиной или стимулом для начала выполнения операции отправки сигналов, создания и уничтожение отдельных объектов. Связь обеспечивает канал для направленной передачи сообщений между объектами от объекта источника к объекту получателя.


*12. Диаграмма кооперации. [2/2]



В Ration Rows существует возможность создания диаграммы кооперации на основе диаграммы Sequance путем нажатия на клавишу F5. Построение диаграммы кооперации можно начинать сразу после построения диаграмм вариантов использования. В этом случаи каждый из вариантов использования может быть специфицирован в виде отдельных диаграмм кооперации. Необходимо следить за использованием только тех объектов для которых определены порождающие их классы и не допускается различный порядок следования сообщений для моделирования одного и того же взаимодействия на диаграмме кооперации и на диаграмме последовательности.

^ 13. Физические диаграммы. [1/2]

Диаграмма размещения. Предназначена для анализа аппаратной части системы. При помощи данной диаграммы проектировщик может произвести анализ необходимой аппаратной конфигурации, на которой будет работать отдельные процессы системы и описать их взаимодействие между собой и другими аппаратными устройствами. Этот тип диаграмм так же позволяет анализировать взаимодействие процессов, работающих на разных компьютерных сетях.

Основные элементы:

1. Процессор (processor) – это устройство способное выполнять программы. Процессор обязательно должен иметь свое имя, которое ни как не связано с другими диаграммами модели по причине того, что процессор обозначает не программное обеспечение, а аппаратуру;

2. Устройство (device) – обозначает устройство не способное выполнять программы;

3. Соединение (connection) – данный инструмент позволяет связать между собой устройства и процессоры. Соединение представляет собой некоторый тип кабельного или другого соединения. В отличии от реального соединения на диаграмме не может быть показано направление перемещения информации по средствам соединения и считается что соединение всегда двунаправленное.


Диаграмма компонентов. Диаграмма компонентов позволяет создать физическое отражение текущей модели, показывает организацию и взаимосвязи программы компонентов, представленных в исходном коде двоичных или выполняемых файлов. Связи в данном типе диаграммы представляют зависимости одного компонента от другого и имею специальное отражение через «значок» зависимости. Так же данный тип диаграмм позволяет получить представление о поведении компонентов по предоставляемому им интерфейсу.

Компоненты представляют собой модуль ПО, такой как исходный код, двоичный код, выполняемый файл, библиотеки и т.д. Компоненты так же могут использоваться для показа взаимосвязей модулей на этапе компиляции или выполнения программы, а так же показывают какие классы используются для создания конкретных компонентов. В связи с тем что система может состоять из модулей различного типа, пользователь может использовать стереотипы для определения этих различий, что часто ведет к изменению графического отображения компонента на диаграмме.

*13. Физические диаграммы. [2/2]



В отличии от других диаграмм при создании элементов диаграмм компонента в модель всегда добавляется один тип элементов компонент, который отличается только стереотипом. Для каждого компонента должен быть задан язык программирования.

- - - - - - - - - - - - > Dependency

Этот тип связи показывает, что классы, содержащиеся в контейнере – клиенте наследуются: содержит элементы, используется каким либо другим образом, зависит от класса, который экспортируется из контейнера сервера.




^ 14. История развития, назначение, общая структура языка UML [1/2].

История развития языка UML начинается с 1994 г, когда Crady Booch и James Rumbadr из Rational Software Corporation начали работу по унификации методов Booch и OMT.

Проект унифицированного метода был подготовлен и опубликован в октябре 1995 г. Осенью того же года к ним присоединился Jvar Jacobson – главный технолог из компании Objectory AB с целью интеграции своего метода OOSE с двумя предыдущими. Начиная работу по унификации своих методов Booch, Rumbandr и Jacobson сформировали следующие требования к языку моделирования:

он должен

  1. позволять моделировать не только ПО, но и более широкие планы систем и бизнес-приложений с использованием объектно-оринетированных понятий;

  2. явным образом обеспечивать взаимосвязь между базовыми понятиями для моделей концептуального и физического уровня

  3. обеспечивать масштабируемость моделей, что является важной особенностью сложных систем;

  4. быть понятен аналитикам и программистам, а так же поддерживаться специальными инструментальными средствами, реализованных на различных платформах.

UML – Unified Modeling Language

UML предназначен для решения следующих задач:

  1. Предоставить в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования.

  2. Снабдить исходное понятие языка UML возможностью расширения и специализации для более точного представления моделей систем конкретной предметной области.

  3. Описание языка UML должно поддерживать такую специализацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств.

  4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей объектно-ориентированного анализа и проектирования.

*14. История развития, назначение, общая структура языка UML [2/2].

  1. Способствует распространению объектных технологий.

  2. Интегрировать себя новейшие и наилучшие достижения практики объектно-ориентированного анализа и проектирования.

Структура языка UML состоит из 2х взаимосвязанных частей:

  1. Семантика языка.

Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

  1. Нотация языка UML.

Представляет собой графическую нотацию для визуального представления семантики языка UML.

^ 15. Исторический обзор развития методологии ООАП [1/1].

Представление различных понятий окружающего нас мира при помощи различной символики уходит корнями в глубокую древность. Важным достоинством той или иной графической нотации является возможность образного закрепления содержательного смысла или семантики отдельных понятий, что существенно упрощает процесс общения между посвященными в соответствующей теории и идеологии.

^ Теория Множеств – язык диаграмм английского логика Джона Венна. Исходным понятием теории множеств является само понятие множество под которым принято понимать некоторую совокупность объектов. Фундаментальным понятием теории множеств является понятие отношения множеств. К сожалению диаграммы Венна не предназначены для иллюстрации отношений в общем случае.

^ Теория графов. Граф можно рассматривать как графическую нотацию для бинарного отношения двух множеств. Хотя основные понятия теории графов получили свое развитие за долго до появления теории множеств, как самостоятельной научной дисциплины. Графы широко применяются для представления различной информации о структуре систем и процессов.

^ Семантические сети получили свое развитие в рамках научного направления связанного с представлением знаний для моделирования рассуждений человека. Эта область научных исследований возникла в рамках общей проблематики искусственного интеллекта и была ориентированна на разработку специальных языков графических средств для представления декларативных статических знаний о предметной области. В общем случае под семантической сетью понимают некоторый граф, в котором множество вершин и множество ребер разделены на отдельные типы обладающие специальной семантикой характерной для той или иной предметной области.

GS=(VS,ES)

VS – множество вершин

ES – множество ребер
^ 16. Диаграммы структурного системного анализа [1/2].

В рамка данного направления программной инженерии принято рассматривать 3-и графических нотации получивших названия:

  1. Диаграмма «Сущность-Связь» (Entity Relation Diagram).

Диаграммы "сущность-связь" (ERD) предназначены для графического представления моделей данных разрабатываемой программной системы и предлагают некоторый набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними, имеющих важное значение для разрабатываемой системы.

Основными понятиями данной нотации являются понятия сущности и связи. При этом под сущностью (entity) понимается произвольное множество реальных или абстрактных объектов, каждый из которых обладает одинаковыми свойствами и характеристиками. Связь (relationship) определяется как отношение или некоторая ассоциация между отдельными сущностями.

Графическая модель данных строится таким образом, чтобы связи между отдельными сущностями отражали не только семантический характер соответствующего отношения, но и дополнительные аспекты обязательности связей, а также кратность участвующих в данных отношениях экземпляров сущностей.

  1. Диаграмма функционального моделирования (Structured Analyses a Design).

В рамках программы ICAM было разработано несколько графических языков моделирования, которые получили следующие названия:

  • Нотация IDEF0 - для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем.

  • Нотация IDEF1 - для документирования информации о производственном окружении систем.

  • Нотация IDEF2 - для документирования поведения системы во времени. 

  • Нотация IDEF3 - специально для моделирования бизнес-процессов.

*16. Диаграммы структурного системного анализа [2/2].

Рассмотрим кратко эти основные понятия методологии IDEF-SADT, которые используются при построении диаграмм функционального моделирования. Деятельность представляет собой некоторое действие или набор действий, которые имеют фиксированную цель и приводят к некоторому конечному результату. Иногда деятельность называют просто процессом. Модели IDEFO отслеживают различные виды деятельности системы, их описание и взаимодействие с другими процессами.

  1. Диаграмма потоков данных (Data Flow Diagram).

Модель системы в контексте DFD представляется в виде некоторой информационной модели, основными компонентами которой являются различные потоки данных, которые переносят информацию от одной подсистемы к другой. Каждая из подсистем выполняет определенные преобразования входного потока данных и передает результаты обработки информации в виде потоков данных для других подсистем.

Основными компонентами диаграмм потоков данных являются:

  • внешние сущности 

  • накопители данных или хранилища 

  • процессы 

  • потоки данных 

  • системы/подсистемы



^ 17. Разработка WEB-приложений с использованием UML [1/1].

Существует несколько подходов к созданию Web-приложений. Основной протокол компонентов системы является http, а основным языком описания html.

С объектной точки зрения основным недостатком протокола http является то, что он не поддерживает соединение между распределенными объектными системами. Так же существуют ограничения на множество функций которые можно реализовать в рамках языка http. Во многих случаях полоса пропускания канала связи с сервером слишком мала для выполнения сложных операций в клиентской части приложений. С помощью расширения WAE – Web Application Extantion унифицированного языка UML можно создавать устойчивые масштабируемые и многоплановые веб-приложения на основе объектно-ориенитрованных технологий.

Основные задачи этого расширения:

  1. Моделирование соответствующих артефактов. Артефакт – любая часть информации получившая участниками процесса при выполнении ими соответствующих видов деятельности.

  2. Моделирование на соответствующем уровне абстракций и детализации.

  3. Возможность взаимодействия специальных веб-элементов модели с остальными элементами системы.

^ 18. Проектирование баз данных с помощью UML [1/1].

Диаграмма БД описывает структуру БД, включая таблицы, столбцы, связи, домены, хранимые процедуры, триггеры и ограничения. Модель проекта БД представляет собой физический проект БД такой, каким он будет реализован в СУБД. Процесс проектирования БД состоит из следующих этапов создания концептуальных моделей:

  • создание логической модели;

  • создание физической модели;

  • тестирование;

  • развертывание.

Таким образом UML позволяет моделировать на одном языке бизнес-процессы приложения, БД и архитектуру системы.


^ 19. Среда описания и анализа бизнес-процессов ARIS [1/1].
Среда описания и анализа бизнес-процессов ARIS включает в себя методологическую основу ARIS (Architecture of Integrated Information System) и ее программную реализацию в виде семейства продуктов ARIS, разработанных германской фирмой IDS Scheer AG.

Методология ARIS рассматривает предприятие, как совокупность 4-х взглядов:

      1. взгляд на организационную структуру;

      2. взгляд на структуру функций;

      3. взгляд на структуру данных;

      4. взгляд на структуру процессов.

При этом каждый из этих взглядов разделяется еще на 3 подуровня:

  1. описание требований;

  2. описание спецификаций;

  3. описание внедрения.

Таким образом ARIS предлагает рассматривать реализацию с позиции 12 аспектов, отражающих разные взгляды на предприятии, а также разную глубину этих взглядов.

ARIS поддерживает 4 типа моделей, отражающих различные аспекты исследуемой системы:

  1. Организационная модель, представляющая структуру системы, т.е. иерархию организационных подразделений, должностей и конкретных лиц.

  2. Функциональная модель. Создает иерархию целей стоящих перед аппаратом управления с совокупностью деревьев функций, необходимых для достижения поставленных целей.

  3. Информационные модели. Отображают структуру информации, необходимой для реализации всей совокупности функций системы.

  4. Модели управления. Представляют комплексный взгляд на реализацию деловых процессов в рамках системы.


^ 20. Объектно-ориентированные базы данных [1/1].
Объектно-ориентированные БД по сравнению с традиционными БД обеспечивают следующие преимущества:

  • данные в них инкапсулированы в объекты;

  • повышают уровень абстракции при работе с данными;

  • упрощают работу со сложно структурированными БД.

При всех достоинствах современных объектных технологий разработки БД имеется несколько препятствий для перехода с реляционной технологии на объектную:

  • значительный объем разработок приходиться на реляционную СУБД;

  • в объектной технологии нет развитого и стандартизованного языка генерации отчетов и анализа данных каким является языка запросов SQL.

Данные проблемы были решены при создании СУБД Cache фирмы “Inter Systems” – обеспечивает не только реализацию основных возможностей объектно-ориентированных технологий, но и позволяет во многом облегчить переход с реляционной технологии на объектную, а также может выступать в роли шлюза к реляционной БД.

Отличительной особенностью СУБД Cache является независимость хранения данных от способа их представления.


Скачать файл (773.2 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации