1. Use case diagram (диаграммы сценариев);

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

2. Deployment diagram (диаграммы топологии);

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

3. State diagram (диаграммы состояний);

Диаграммы состояний (State) предназначена для отображения состоя­ний объектов системы, имеющих сложную модель поведения.

4. Activity diagram (диаграммы активности);

Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram не в том, чтобы отра­жать состояния, а в том, чтобы отражать бизнес-процессы объекта.

5. Interaction diagram (диаграммы взаимодействия);

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

6. Sequence diagram (диаграммы последовательностей действий);

Этот тип диаграммы не акцентирует внимание на конкретном взаимо­действии, главный акцент уделяется последовательности приема/передачи сообщений.

7. Collaboration diagram (диаграммы сотрудничества);

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

8. Class diagram (диаграммы классов);

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

Значки диаграммы позволяют отображать сложную структуру систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диа­грамм противоположен по содержанию диаграмме Collaboration, на кото­ром отображаются объекты системы

9. Component diagram (диаграммы компонент).

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

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

16. Основные элементы диаграммы классов. Охарактеризовать каждый из них.

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

Class (класс)

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

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

1 этап: Определение классов.

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

- Перечисление кандидатов в классы, найденных в постановке проблемы.

- Исключение ненужных и некорректных классов.

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

Из списка кандидатов в классы исключаются «плохие классы» согласно следующим критериям:

а) Избыточные классы. Если два класса отражают одну и ту же информацию, то сохраняется наиболее информативное имя.

Совет:

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

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

в) Неясные классы. Класс должен быть характерным, специальным. Некоторые пробные классы могут иметь плохо определенные границы или быть слишком широкими.

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

Совет:

Если независимое существование свойства является важным, или свойство является сложным объектом, то делайте его классом, а не атрибутом.

д) Операции. Если имя описывает операцию, которая применяется к объектам, а не манипулирует ими с собственными правами, то это не класс.

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

2 этап: Определение связей между классами.

Классы редко бывают изолированы, чаще всего они вступают в отноше­ния друг с другом. Эти отношения показываются при помощи различного вида связей. Типы связей влияют на получаемый при генерации на основе диаграмм исходный код.

В диаграмме классов используются следующие виды связей:

• Unidirectional association (однонаправленная ассоциация);

• Dependency (зависимость);

• Association class (ассоциированный класс);

• Generalization (наследование);

• Realization (реализация).

Unidirectional Association

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

Пример ненаправленной связи

Рис. 3.7

Пример связи

Aggregate показывает, что один класс не просто использует, а содер­жит другой.

Рис. 3.8

Пример агрегирования класса

Агрегирование означает физическое включение объектов одного класса в объекты другого класса.

Association Class (ассоциированный класс)

Используйте данный тип связи для отображения свойства ассоциации.

Рис. 3.9

Пример использования Association Class

Dependency or instantiates (зависимость или реализация)

Этот тип связи позволяет показать, что один класс использует объекты другого. Использование может осуществляться при передаче параметров или вызове операций класса. Графически этот вид связи отражается пунк­тирной стрелкой (рис. 3.10).

Рис. 3.10

Пример связи Dependency or instantiates

Generalization

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

Рис. 3.11

Пример связи Generalization

Выделение связей (ассоциаций)

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

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