Диаграммы классов (Class Diagram). Назначение, основные элементы (Class, Association, Dependency, Aggregation, Generalization). Атрибуты и операции, множественность (multiplicity) и роли

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

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

Конкретный класс (concrete class) — класс, на основе которого могут быть непосредственно созданы экземпляры или объекты.

Абстрактный класс (abstract class)— класс, который не имеет экземпляров или объектов.

Базовые отношения, изображаемые на

диаграммах классов:Отношение ассоциации (association relationship); Отношение обобщения (generalization relationship) ;Отношение агрегации (aggregation relationship); Отношение композиции (composition relationship)

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

Generalize– отношение между общим (родителем) и частным (предком). Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения.

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

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

Операция (operation) -- это сервис, предоставляемый каждым экземпляром или объектом класса по требованию своих клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса. На практике клиент обычно совершает над объектами операции пяти видов. Из них наиболее распространены следующие три вида операции. • Модификатор: операция, изменяющая состояние объекта. • Селектор: операция, имеющая доступ к состоянию объекта, но не изменяющая его. • Итератор: операция, обеспечивающая доступ ко всем частям объекта в строго определенном порядке. Два остальных вида операций носят общий характер. Они образуют инфраструктуру, необходимую для создания и уничтожения экземпляров класса. • Конструктор: операция, создающая объект и/или инициализирующая его состояние. • Деструктор: операция, стирающая состояние объекта и/или уничтожающая сам объект.

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

Видимость (visibility) — качественная характеристика описания элементов класса, характеризующая

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

поведения данного класса.

Кратность (Multiplicity)-- означает потенциальное число отдельных экземпляров класса, которые могут иметь место, когда остальные экземпляры или объекты классов фиксированы.

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

29. Назначение диаграммы вариантов использования (Use Case Diagram)

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

Отношения на диаграммах вариантов использования Цели при создании диаграмм вариантов использования получить деньги показать остаток счета Клиент закрыть сессию Ассоциация (association relationship) – единственное возможное отношение между актером и прецедентом. Каждая ассоциация подразумевает наличие взаимодействия и соответственно канала связи и интерфейса (граничного объекта, boundary) между актером и программной системой. Ассоциация бывает двунаправленной (сообщение посылается от актера к системе и от системы к актеру), а также однонаправленной (изображается линией со стрелкой). В случае, если стрелка направлена в сторону варианта использования, то это означает, что актер инициирует исполнение данного прецедента. Если стрелка направлена к актеру, то это показывает, что он получает от системы справочную информацию. Ассоциация может иметь некоторые дополнительные обозначения, например, имя и кратность Один актер, используя несколько ассоциаций, может взаимодействовать с несколькими вариантами использования. В этом случае этот актер обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими актерами, предоставляя для всех них свой сервис. Отношения между вариантами использования Варианты использования, определенные в рамках одной моделируемой системы, могут также взаимодействовать между собой. Однако, характер этого взаимодействия отличается от взаимодействия с актерами и наличия граничного объекта при этом не подразумевается. Включение (include relationship ) -- каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового варианта использования к включаемому варианту использования.

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

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

30. Диаграммы вариантов использования для моделирования предметной области. Назначение, основные элементы (Business Actor, Business Use Case, Association).

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

Цели при создании диаграмм вариантов использования

• определение общих границ моделируемой предметной области;

• документирование общих требований к функциональному поведению системы;

• определение круга пользователей системы и их связей с системой;

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

Отношения на диаграммах вариантов использования

Ассоциация (association relationship) – единственное возможное отношение между актером и прецедентом. Каждая ассоциация подразумевает наличие взаимодействия и соответственно канала связи и интерфейса (граничного объекта, boundary) между актером и программной системой. Ассоциация бывает двунаправленной (сообщение посылается от актера к системе и от системы к актеру), а также однонаправленной (изображается линией со стрелкой). В случае, если стрелка направлена в сторону варианта использования, то это означает, что актер инициирует исполнение данного прецедента. Если стрелка направлена к актеру, то это показывает, что он получает от системы справочную информацию. Ассоциация может иметь некоторые дополнительные обозначения, например, имя и кратность

Включение (include relationship ) --каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового варианта использования к включаемому варианту использования, которая помечается стереотипом <<include>>. Расширение (extend relationship) -- определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий. Графически обозначается в форме пунктирной линии со стрелкой, направленной от расширяющего прецедента к базовому варианту использования и помеченой стереотипом <<extend>>

Отношения на диаграммах вариантов использования (продолжение)

Семантика отношения расширения (extend relationship) определяется следующим образом. Если базовый вариант использования выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого варианта использования, которая является первой из всех точек расширения у базового варианта, то проверяется логическое условие данного отношения. Если это условие выполняется, исходная последовательность действий расширяется посредством включения действий другого варианта использования. Следует заметить, что условие отношения расширения проверяется лишь один раз — при первой ссылке на точку расширения, и если оно выполняется, то все расширяющие варианты использования вставляются в базовый вариант.

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

Стереотипы для моделирования бизнес-актеров и бизнес-функцийМоделированием функционеров предметной области (бизнес-актеров), их функциональных обязанностей, а также бизнес-процессов выделяется в отдельный раздел аналитики – бизнес-анализ. В представлении use-case view в соответствии с USDP создается папка business use-case, а для моделирования предметной области используются следующие стереотипы: Бизнес-актер (business actor) – индивидуум (штатная должность), группа, организация или система, которые взаимодействуют с моделируемой бизнес-системой, но не являются ее частью. Примерами бизнес-актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы. Сотрудник (business worker) – индивидуум (штатная должность), группа, организация или система, которые действуют внутри моделируемой бизнес-системы, взаимодействуют с другими сотрудниками и являются участниками бизнес-процесса моделируемой системы. Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы.

Бизнес-вариант использования (business use case) – определяет последовательность действий моделируемой системы, направленную на выполнение отдельного бизнес-процесса.