Основные элементы языка UML

2.1. Пакеты

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

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

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

Графическое представление пакетов приведено на рис. 2.1.

Рис. 2.1. Графическое изображение пакетов в языке UML

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

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

Отношение между пакетами:

Отношение вложенности (включения)

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

ü размещением одного пакета-прямоугольника внутри другого пакета-прямоугольника (рис. 2.2). В данном примере пакет с именем Пакет_1 содержит в себе два подпакета: Пакет_2 и Пакет_3.

ü с помощью дерева (рис. 2.3). Наиболее общий пакет или контейнер изображается в верхней части рисунка, а его подпакеты – уровнем ниже. В примере Пакет_1 содержит только два подпакета Пакет_2 и Пакет_3, и, никаких других.

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

Рис. 2.3. Альтернативный вариант изображения вложенности

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

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

Подсистема является группировкой элементов модели, которые специфицируют простейшее поведение физической системы. Элементы подсистемы делятся на две части – спецификацию поведения и его реализацию. Графическое представление подсистемы приведено на рис. 2.5.

Рис. 2.4. Изображение общей модели системы

Рис. 2.5. Графическое изображение подсистемы в языке UML

Рекомендации по использованию пакетов языка UML

ü Используя пакеты в UML, помните, что они нужны только для организации элементов вашей модели.

ü Пакет должен быть внутренне согласован и очерчивать четкую границу вокруг группы родственных элементов;

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

ü Вложенность пакетов не должна быть слишком большой;

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

Контрольные вопросы

1. Дайте определение пакета. Для чего они используются?

2. Какой вид отношения определен между пакетами?

3. Разрешена ли в UML вложенность пакетов друг в друга?

2.2. Канонические диаграммы языка UML

Диаграмма (diagram) — графическое представление совокупности элементов модели в форме связного графа, вершинам и ребрам (дугам) которого приписывается определенная семантика.

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

ü Диаграмма вариантов использования (Use Case Diagram)

ü Диаграмма классов (Class Diagram)

ü Диаграмма кооперации (сотрудничества) (Collaboration Diagram)

ü Диаграмма последовательности (Sequence Diagram)

ü Диаграмма состояний (Statechart Diagram)

ü Диаграмма деятельности (Activity Diagram)

ü Диаграмма компонентов (Component Diagram)

ü Диаграмма размещения (Deployment Diagram)

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

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

ü Диаграмма классов является логической моделью, отражающей статические аспекты структурного построения системы.

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

ü Диаграммы схем состояний и деятельности предназначены для моделирования поведения системы.

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

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

Механизмы расширения

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

ü Стереотип (stereotype) — новый тип элемента модели, который расширяет семантику (но не структуру) уже описанных типов или классов метамодели. Существуют предопределенные в языке и описываемые пользователем стереотипы. На диаграммах изображаются в форме текста, заключенного в угловые кавычки. Например, <<extend>>.

ü Теговая величина (tagged value) — явное определение свойства как пары "имя тега – значение". Теговые величины на диаграммах изображаются в форме строки текста, заключенного в фигурные скобки и имеющего формат записи: имя тега = значение. Определение тегов не является строгим, поэтому теги могут быть указаны самим разработчиком. Например, {кол-во процессоров = 4, оперативная память = 2Гб}.

ü Ограничение (constraint) — некоторое логическое условие, ограничивающее семантику выбранного элемента модели. На диаграммах изображаются в форме строки текста, заключенного в фигурные скобки. Как правило, специфицируются разработчиком. Для формальной записи ограничений предназначен специальный язык объектных ограничений (Object Constraint Language, OCL), который является составной частью языка UML. Примеры ограничений: {XOR}, {величина кратна $5}.

Рекомендации по графическому изображению диаграмм языка UML

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

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

ü Все сущности на диаграмме модели должны быть одного уровня представления.

ü На диаграммах явно должна быть представлена вся информация о сущностях.

ü Диаграммы не должны содержать противоречивой информации.

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

ü Количество типов диаграмм для конкретной модели приложения строго не фиксировано.

ü Любая модель системы должна содержать только те элементы, которые определены в нотации языка UML.

Контрольные вопросы

1. Дайте определение понятия диаграмма.

2. Какие диаграммы UML входят в число канонических?

3. Дайте краткую характеристику каждой из канонических диаграмм UML.

4. Какие механизмы расширения предусмотрены в UML?

2.3. Диаграмма вариантов использования (Use Case Diagram)

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

Диаграмма вариантов использования (USE CASEдиаграммa) (Use Case Diagram) описывает то, что система должна делать в процессе своего функционирования. На данной диаграмме изображаются отношения между актерами и вариантами использования.

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

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

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

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

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

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

Базовыми элементами диаграммы вариантов использования являются:

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

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

ü Отношения между объектами диаграммы.

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

Варианты использования

Вариант использования (use case) — описание последовательности действий, которые система может выполнять в процессе взаимодействия с актерами.

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

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

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

Вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме существительного или глагола с пояснительными словами (рис. 2.6).

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

Рис. 2.6.Графическое обозначение варианта использования

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

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

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

Актеры

Актер (actor) — роль, которую играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.

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

Графическое обозначение актера приведено на рис. 2.7.

Рис. 2.7. Графическое обозначение актера

В некоторых случаях актер может обозначаться в виде прямоугольника класса со стереотипом <<actor>>.

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

В качестве актеров могут выступать другие системы, в том числе подсистемы проектируемой системы или ее отдельные классы.

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

Актеры взаимодействуют с системой посредством передачи и приема сообщений от вариантов использования.

Сообщение представляет собой запрос актером сервиса от системы и получение этого сервиса.

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

Отношение ( relationship ) — семантическая связь между отдельными элементами модели.

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

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

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

ü ассоциации (association);

ü включения (include);

ü расширения (extend);

ü обобщения (generalization).

Отношение ассоциации

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

ü обозначается сплошной линией между актером и вариантом использования (рис. 2.8). Эта линия может иметь некоторые дополнительные обозначения, например, мощность.

Рис. 2.8. Отношение ассоциации между актером и вариантом использования

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

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

Отношение включения

Включение (include) является разновидностью отношения зависимости между базовым вариантом использования и его специальным случаем.

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

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

ü графически обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом линия помечается стереотипом <<include>> (рис. 2.9).

Рис. 2.9. Отношение включения между вариантами использования

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

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

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

Отношение расширения

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

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

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

Обычно используется для моделирования:

ü вариантных частей вариантов использования;

ü сложных и редко выполняемых альтернативных последовательностей;

ü подчиненных последовательностей, которые выполняются только в определенных случаях;

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

Решение о выборе, подключении вариантов использования принимается вне базового варианта использования.

Отношение расширения обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом <<extend>> (рис. 2.10).

Рис. 2.10. Отношение расширения между вариантами использования

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

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

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

Базовый вариант использования не зависит от своих расширений.

Отношение обобщения

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

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

Рис. 2.11. Отношение обобщения между актерами

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

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

Рис. 2.12. Отношение обобщения между вариантами использования

В примере на рис. 2.12 отношение обобщения указывает на то, что вариант использования "Предоставление кредита корпоративным клиентам" является специализацией варианта использования "Предоставление кредита клиентам банка".

Дополнительные обозначения UML для бизнес-моделирования

Язык UML включает дополнительные графические обозначения, которые используются для моделирования бизнес-систем и могут быть изображены на диаграммах вариантов использования: бизнес-актер, сотрудник и бизнес-вариант использования.

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

Примеры бизнес-актеров: клиенты, покупатели, поставщики, партнеры.

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

Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы (рис. 2.13, б).

Примеры сотрудников: менеджеры, администраторы, кассиры, инженеры.

Общее свойство сотрудников: они являются субъектами и входят в состав моделируемой системы.

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

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

Рис. 2.13. Бизнес-актер (а), бизнес-сотрудник (б) и бизнес-вариант использования (в)

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

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

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

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

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

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

Рис. 2.14. Диаграмма вариантов использования для системы продажи товаров

Спецификация требований и рекомендации по написанию эффективных вариантов использования

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

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

Требование (requirement) – желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации.

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

ü функциональные требования (Functionality);

ü требования удобства использования (Usability);

ü требования надежности (Reliability);

ü требования производительности (Performance);

ü требования возможности сопровождения (Supportability).

При этом символом "+" обозначены дополнительные условия, к которым относятся:

ü проектные ограничения;

ü требования управления системой;

ü требования к графическому интерфейсу пользователя;

ü физические требования;

ü юридические требования.

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

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

Сценарий (scenario) – определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста.

Предлагаются различные способы представления или написания подобных сценариев.

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

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

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

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

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

Рис. 2.15. Диаграмма вариантов использования для модели банкомата

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

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

Таблица 1. Главный раздел сценария.

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

Таблица 2. Раздел Типичный ход событий сценария.

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

Таблица 3. Раздел Исключения сценария.

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

Отдельные небольшие по своему объему сценарии могут быть размещены на диаграмме в форме примечаний.

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

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

Рис. 2.16. Примеры примечаний на диаграммах вариантов использования

Рекомендации по разработке диаграмм вариантов использования

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

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

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

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

Рекомендуется, чтобы общее количество актеров в модели не превышало 20, а вариантов использования 50. В противном случае модель теряет свою наглядность.

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

ü Определить главных или первичных и второстепенных актеров;

ü Определить цели главных актеров по отношению к системе;

ü Сформулировать основные варианты использования, которые представляют функциональные требования к системе;

ü Упорядочить варианты использования по степени убывания риска их реализации;

ü Выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования;

ü Написать успешный сценарий реализации выбранного варианта использования;

ü Определить исключения или неуспех в выполнении сценария варианта использования;

ü Написать сценарии для всех исключений;

ü Выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом <<include>>;

ü Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом <<extend>>;

ü Проверить диаграмму на отсутствие дублирования вариантов использования и актеров;

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

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

ü Важная информация и внутренняя структура проекта обеспечивается за счет сравнительно небольших усилий;

ü Включает рискованные, сложные или срочные функции;

ü Требует дополнительного исследования или применения новой и ненадежной технологии;

ü Представляет основной экономический процесс;

ü Напрямую обеспечивает повышение эффективности и снижение стоимости.

Контрольные вопросы

1. Для чего предназначена диаграмма вариантов использования?

2. Назовите базовые элементы диаграммы вариантов использования.

3. Что такое вариант использования? Приведите примеры вариантов использования для конкретной предметной области.

4. Для чего используются сценарии?

5. Что собой представляет актер?

6. Как актер взаимодействует с системой?

7. Какие отношения разрешены между элементами диаграммы вариантов использования?

8. Чем отличаются отношения включения и расширения друг от друга с точки зрения управления?

9. Между какими элементами разрешена связь обобщения?

10. Какие существуют дополнительные обозначения для бизнес-моделирования?

11. Для чего необходимо создавать спецификации требований?

12. Какие требования к программным системам необходимо учитывать?

13. Что такое сценарий? Из каких разделов он обычно состоит?

14. Для чего используются примечания?

15. Какая последовательность действий рекомендуется при создании диаграмм вариантов использования?

2.4. Диаграмма классов (Class Diagram)

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

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

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

Классы

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

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

Рис. 2.17. Варианты графического изображения класса на диаграмме классов

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

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

Рис. 2.18. Примеры графического изображения конкретных классов

Класс может иметь или не иметь экземпляров или объектов. В зависимости от этого в языке UML различают конкретные и абстрактные классы:

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

ü Абстрактный класс (abstract class) — класс, который не имеет экземпляров или объектов. В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом.

Имя класса

Имя класса:

ü должно быть уникальным в пределах пакета, который может содержать одну или несколько диаграмм классов.

ü указывается в самой верхней секции прямоугольника – секции имени.

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

ü Имя абстрактного класса записывается наклонным шрифтом (курсивом).

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

ü можно явно указать, к какому пакету относится тот или иной класс. Синтаксис строки имени класса в этом случае будет следующий: <Имя пакета>::<Имя класса>. Например, Банк::Счет.

В секции имени класса могут также находиться:

ü стереотипы или ссылки на стандартные шаблоны, от которых образован данный класс и, соответственно, от которых он наследует атрибуты и операции;

ü информация о разработчике данного класса;

ü статус состояния разработки;

ü другие общие свойства этого класса, имеющие отношение к другим классам диаграммы или стандартным элементам языка UML.

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

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

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

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

Каждому атрибуту класса соответствует отдельная строка текста, имеющая определенный формат.

Общий формат записи атрибута класса имеет вид:

<видимость> <имя атрибута> [ кратность ]:

<тип атрибута> = <начальное значение> { характеристики }

Единственным обязательным элементом является <имя атрибута>.

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

Уровни видимости:

Часть <видимость> может быть опущена.

Вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private, package.

Имя атрибута – идентификатор соответствующего атрибута.

ü должно быть уникальным в пределах данного класса.

ü является обязательным элементом.

ü должно начинаться со строчной буквы и не должно содержать пробелов.

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

Кратность характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса.

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

[ нижняя граница .. верхняя граница ],

где нижняя граница и верхняя граница – положительные целые числа.

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

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

Соответствующие нижние и верхние границы интервалов включаются в значение кратности.

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

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

Если кратность атрибута не указана, то по умолчанию в языке UML принимается ее значение равное [1..1], т. е. в точности 1.

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

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

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

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

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

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

При задании атрибутов могут быть использованы дополнительные синтаксические конструкции:

ü подчеркивание строки атрибута – означает, что соответствующий атрибут общий для всех объектов данного класса, т.е. его значение у всех создаваемых объектов одинаковое (аналогично ключевому слову static в некоторых языках программирования).

ü пояснительный текст в фигурных скобках {характеристики} – может означать две различные конструкции:

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

o отсутствие части {характеристики} по умолчанию трактуется так, что значение соответствующего атрибута может быть изменено в программе.

ü символ «/» перед именем атрибута указывает на то, что данный атрибут является производным от некоторого другого атрибута этого же класса.

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

Операции класса

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

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

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

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

Общий формат записи операции класса имеет вид:

<видимость> <имя операции> ( список параметров ):

<тип_возвращаемого_значения> { характеристики }

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

Значение видимости для операции может быть опущено.

Имя операции – строка текста, используемая в качестве идентификатора соответствующей операции.

ü должно быть уникальным в пределах данного класса.

ü является обязательным элементом синтаксического обозначения операции.

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

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

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

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

<направление параметра> <имя параметра>:

<тип параметра> = <значение параметра по умолчанию>

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

Параметр (parameter) – спецификация переменной операции, которая может быть изменена, передана или возвращена.

<направление параметра> – одно из ключевых слов in, out или inout. Если вид параметра не указывается, то по умолчанию предполагается значение in.

<имя параметра> – идентификатор соответствующего формального параметра.

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

<значение по умолчанию> – конкретное значение для этого формального параметра.

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

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

Пример описания класса на языке программирования Java приведен ниже.

class Account { private float balance=0; public float limit; protected int id; int databaseId;   public void deposit(float amount){...} private void withdraw(float amount) {...} protected int getId(){...} int getDatabaseId(){...} }

Расширение языка UML для построения моделей ПО и бизнес-систем

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

Язык UML содержит два специальных расширения:

ü профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes);

ü профиль для бизнес-моделирования (The UML Profile for Business Modelling).

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

ü Управляющий класс (control class) — класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс, контролирующий последовательность выполнения действий. Данный класс является активным и инициирует рассылку множества сообщений другим классам модели. (рис. 2.19, а).

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

ü Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. (рис. 2.19, в).

Рис. 2.19. Изображение классов для моделирования программного обеспечения

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

ü Сотрудник (business worker) — класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. (рис. 2.20, а).

ü Сотрудник для связи с окружением (caseworker) – класс, служащий для представления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса. (рис. 2.20, б).

ü Бизнес-сущность (business entity) — специальный случай класса-сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. (рис. 2.20, в).

Рис. 2.20. Графическое изображение классов для моделирования бизнес-систем

Интерфейс

Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели.

ü Является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты.

ü Графически изображается в виде окружности или прямоугольника класса со стереотипом <<interface>> (рис. 2.21).

Имя интерфейса, как и имена других классов, рекомендуется записывать на английском и начинать с заглавной буквы I, например, ITemperatureSensor, IsecureInformation (рис. 2.21, в).

Рис. 2.21. Примеры изображения интерфейсов на диаграммах классов

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

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

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

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

Отношения на диаграмме классов

Базовые отношения, изображаемые на диаграммах классов:

ü Отношение ассоциации (association relationship);

ü Отношение обобщения (generalization relationship);

ü Отношение зависимости (dependency relationship);

ü Отношение реализации (realization relationship);

ü Отношение агрегации (aggregation relationship);

ü Отношение композиции (composition relationship).

Отношение ассоциации

Ассоциация (association) – произвольное семантическое отношение (взаимосвязь) между двумя и более классами.

Данное отношение обозначается сплошной линией со стрелкой или без нее и может содержать необязательные дополнительные символы:

ü имя ассоциации;

ü символ навигации;

ü имена и кратность классов-ролей ассоциации.

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

Бинарная ассоциация (binary association) служит для представления произвольного отношения между двумя классами.

Бинарная ассоциация может быть:

ü ненаправленная (симметричная) – изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения классов с использованием значка в форме треугольника рядом с именем данной ассоциации (рис. 2.22).

ü направленная – изображается сплошной линией с простой стрелкой на одной из ее концевых точек. Направление этой стрелки указывает на то, какой класс является первым, а какой – вторым (рис. 2.23). Эти объекты классов образуют кортеж элементов, например, <клиент, счет_1, счет_2,…, счет_n>.

Рис. 2.22. Ненаправленная бинарная ассоциация между классами

Рис. 2.23. Направленная бинарная ассоциация между классами

Фрагменты программного кода на языке Java для ненаправленной и направленной ассоциаций приведены ниже.

Ненаправленная ассоциация	Направленная ассоциация
House.java: public class House { public Person m_Person; House(){ } } Person.java: public class Person { public House m_House; Person(){ } }	House.java: public class House { House(){ } } Person.java: public class Person { public House m_House; Person(){ } }

Рефлексивная ассоциация – частный случай бинарной, связывает класс с самим собой.

Исключающая ассоциация (XOR-association) – частный случай ассоциации. Семантика данной ассоциации указывает на то, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме изображается пунктирной линией, соединяющей две и более ассоциации (рис. 2.24), рядом с которой записывается ограничение {XOR}.

Рис. 2.24. Исключающая ассоциация между тремя классами

n-арная ассоциация (n-ary association) – ассоциация между тремя и большим числом классов. Графически обозначается ромбом, от которого ведут сплошные линии к символам классов данной ассоциации.

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

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

Рис. 2.25. Изображение тернарной ассоциации между тремя классами

Ассоциация класс (association class) – элемент, который одновременно является ассоциацией и классом. Он может рассматриваться как ассоциация, которая обладает свойствами класса, или как класс, имеющий также свойства ассоциации.

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

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

Конец ассоциации (association end) – концевая точка ассоциации, которая связывает ассоциацию с классификатором, графически соответствует точке соединения линии ассоциации с отдельным классом.

Конец ассоциации – часть ассоциации, но не класса. Каждая ассоциация может иметь два или больше концов ассоциации.

Роль (role) – имеющее имя специфическое поведение некоторой сущности, рассматриваемой в определенном контексте. Роль может быть статической или динамической.

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

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