Создание кооперативной диаграммы

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

Рис. 2.12. Диаграмма кооперации для системы АТМ

2.3.Диаграмма классов

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений [1], [8], [10], [11].

Диаграммы классов используются:

• в ходе анализа ― для указания ролей и обязанностей сущностей, которые обеспечивают поведение системы;

• в ходе проектирования ― для фиксирования структуры классов, которые формируют системную архитектуру.

Диаграмма классов ― это граф, вершинами которого являются классы, а дугами (ребрами) ― отношения между ними.

Обозначение класса (class) показано на рис. 2.13.

Рис. 2.13. Обозначение класса

Пиктограмма класса включает три секции (для имени, для свойств и для операций). Имя класса указывается всегда, свойства и операции ― выборочно. Пустота секции не означает, что у класса отсутствуют свойства или операции, просто в данный момент они не показываются.

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

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

Общий синтаксис представления свойства (атрибута) имеет вид:

Видимость Имя [Множественность]:Тип = НачальнЗначение {Характеристики}

В языке UML определены три уровня видимости:

• public ― любой клиент класса может использовать свойство (операцию), обозначается символом «+»;

• protected ― любой наследник класса может использовать свойство (операцию), обозначается символом «#»;

• private ― свойство (операция) может использоваться только самим классом, обозначается символом «-».

Если видимость не указана, то считают, что свойство объявлено с видимостью public.

Определены три характеристики свойств:

• changeable ― нет ограничений на модификацию значения свойства;

• addOnly ― дополнительные значения могут быть добавлены, но после создания значение не может удаляться или изменяться (для свойств с множественностью, большей 1);

• frozen ― после инициализации объекта значение свойства не изменяется.

Если характеристика не указана, считают, что свойство объявлено с характеристикой changeable.

Иногда бывает необходимо ограничить количество экземпляров класса:

• задать ноль экземпляров (в этом случае класс превращается в утилиту, которая предлагает свои свойства и операции);

• задать один экземпляр (класс-singleton);

• задать конкретное количество экземпляров;

• не ограничивать количество экземпляров (это случай, предполагаемый по умолчанию).

Количество экземпляров класса называется его множественностью (multiplicity). Выражение множественности записывается в правом верхнем углу значка класса (см. рис. 2.14).

Множественность применима не только к классам, но и к свойствам. Множественность свойства задается выражением в квадратных скобках, записанным после его имени (см. рис. 2.14).

Рис. 2.14. Обозначение множественности

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

Видимость Имя (СписокПараметров) : ВозвращаемыйТип {Характеристики}

В сигнатуре операции можно указать ноль или более параметров. Форма представления параметра имеет следующий синтаксис:

Направление Имя : Тип = ЗначениеПоУмолчанию

Элемент Направление может принимать одно из следующих значений:

• in ― входной параметр, не может модифицироваться (значение по умолчанию);

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

• inout ― входной параметр, может модифицироваться.

Допустимо применение следующих характеристик операций:

• leaf ― конечная операция, операция не может быть полиморфной и не может переопределяться (в цепочке наследования);

• isQuery (запрос) ― выполнение операции не изменяет состояние объекта;

• sequential (последовательная) ― в каждый момент времени в объект поступает только один вызов операций и выполняется только одна операция объекта;

• guarded (охраняемая) ― допускается одновременное поступление в объект нескольких вызовов, но в каждый момент времени обрабатывается только один вызов охраняемой операции;

• concurrent (параллельная) ― в объект поступает несколько потоков вызовов операций, разрешается параллельное и множественное выполнение операции.

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

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

Ассоциации отображают структурные отношения между экземплярами классов, то есть соединения между объектами. Каждая ассоциация может иметь метку ― имя, которое описывает природу отношения. Имени можно придать направление ― достаточно добавить треугольник направления для чтения имени (см. рис. 2.16).

Рис. 2.16. Имя и направление ассоциации

Когда класс участвует в ассоциации, он играет в этом отношении определенную роль. Роль (role) определяет, каким представляется класс на одном конце ассоциации для класса на противоположном конце ассоциации (см. рис. 2.17).

Рис. 2.17. Роли ассоциации и их мощность

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

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

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

Рис. 2.18. Использование квалификатора

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

• по умолчанию для роли задается видимость public (+);

• видимость private (-) указывает, что объекты на данном конце недоступны любым объектам вне ассоциации;

• видимость protected (#) указывает, что объекты на данном конце недоступны любым объектам вне ассоциации, за исключением потомков того класса, который указан на противоположном конце ассоциации.

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

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

Рис. 2.19. Отношение зависимости на диаграмме классов

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

Рис. 2.20. Отношение обобщения на диаграмме классов

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

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

Иногда полезно отметить корневой класс, который не может иметь родителей. Такой класс помечается теговой величиной {root}, записываемой за именем класса.

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

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

Реализация ― семантическое отношение между классами, в котором класс-приемник выполняет реализацию операций интерфейса класса-источника (см. рис. 2.21).

Рис. 2.21. Реализация интерфейса

Шаблон (template) или параметризованный класс (parametrized class) предна­значен для обозначения такого класса, который имеет один (или более) не­фиксированный формальный параметр. Он определяет целое семейство или множество классов, каждый из которых может быть получен связыванием этих параметров с действительными значениями. Обычно параметрами шаб­лонов служат типы атрибутов классов, такие как целые числа, перечисление, массив строк и др. В более сложном случае формальные параметры могут представлять и операции класса.

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

Рис. 2.22. Шаблон на диаграмме классов

Шаблон не может быть непосредственно использован в качестве класса, по­скольку содержит неопределенные параметры. Чаще всего в качестве шаб­лона выступает некоторый суперкласс, параметры которого уточняются в его классах-потомках. Очевидно, в этом случае между ними существует от­ношение зависимости с ключевым словом <<bind>>, когда класс-клиент может использовать некоторый шаблон для своей последующей параметризации. В более частном случае между шаблоном и формируемым от него клас­сом имеет место отношение обобщения с наследованием свойств шаблона.

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

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

На диаграмме показаны связи между классами, реализующими вариант использования Снять деньги со счета. В этом процессе задействованы четыре класса: CardReader (Устройство чтения), ATMScreen (Экран АТМ), Account (Счёт) и CashDispenser (Касса). Каждый класс на рассматриваемой диа­грамме изображается в виде прямоугольника, разделенного на три части. В первой части ука­зывается имя класса, во второй — его атрибуты. Атрибут — это некоторая информация, характеризующая класс. Например, класс Account (Счёт) имеет три атрибута: AccountNumber (Номер счета), PIN (Идентификационный номер) и Balance (Баланс). В последней части содержатся опера­ции класса, отражающие его поведение (действия, выполняемые классом). Для класса Account (Счёт) определены пять операций: Open (Открытие счёта), VerifyNumber (Проверка регистрационного номера), WithdrawFunds (Снятие денег со счета), VerifyFunds (Проверка суммы), DeductFunds (Вычет снятой суммы со счета).

Связывающие классы линии показывают взаимодействие между классами. Так, класс ATMScreen (Экран АТМ) связан с классом Account (Счёт), потому что они непосредственно взаимодействуют друг с другом. Класс CardReader (Устройство чтения) не связан с классом CashDispenser (Касса), поскольку они не общаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыта (private). Доступ к закрытым атрибутам или опе­рациям возможен только из содержащего их класса. AccountNumber (Номер счета), PIN (Идентификационный номер) и Balance (Баланс) — закрытые атри­буты класса Account (Счёт). Кроме того, закрытыми являются операции VerifyFunds (Проверка суммы) и DeductFunds (Вычет снятой суммы со счета).

Разработчики используют диаграммы классов для реального создания классов. Такие инструмен­ты, как Rational Rose, генерируют основу кода классов, которую программисты заполняют деталями на вы­бранном ими языке. С помощью этих диаграмм аналитики могут показать элементы системы, а архитекторы — понять ее проект. Если, например, какой-либо класс несет слишком большую функци­ональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. С помощью рассматриваемой диаграммы можно также выявить случаи, когда между сообщаю­щимися классами не определено никаких связей. Диаграммы классов следует создавать, чтобы пока­зать взаимодействующие классы в каждом варианте использования. Можно строить также более общие диаграммы, охватывающие все системы или подсистемы.

Упражнение

Постройте диаграмму классов для пред­ставления всех классов варианта использования Снять деньги со счета системы АТМ.

Этапы выполнения упражнения

Настройка

1. В меню модели выберите пункт Tools > Options (Инструменты > Параметры). Перейдите на вкладку Diagram (Диаграмма).

2. Убедитесь, что установлены флажки: Show visibility (Показать видимость), Show stereotypes (Показать стереотипы), Show operation signatures (Показать сигнатуры операций), Show All Attributes (Показать все атрибуты) и Show All Operations (Показать все операции).

3. Убедитесь, что сброшены флажки Suppress Attributes (Подавить вывод атрибутов) и Suppress Operations (Подавить вывод операций).

Создание диаграммы классов для сценария «Снять деньги со счета» с отображением всех классов

1. Щелкните правой кнопкой мыши на логическом представлении (Logical View) браузера. В открывшемся меню выберите пункт New > Class Diagram (Создать > Диаграмма классов). Назовите новую диаграмму классов Withdraw funds (Снятие денег со счета).

2. Дважды щелкнув мышью на этой диаграмме в браузере, откройте ее. Перетащите на нее из браузера все классы (CardReader, ATMScreen, Account и CashDispenser).

Полученная диаграмма классов представлена на рис. 2.23.

Рис. 2.23. Диаграмма классов Withdraw funds

Добавление стереотипов к классам

1. Щелкните правой кнопкой мыши на классе CardReader диаграммы. В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). В раскрывающемся списке поля стереотипов выберите слово boundary (граница). Нажмите на кнопку ОК.

2. Повторив п.1, свяжите классы ATMScreen и CashDispenser со стереотипом boundary, а класс Account — со стереотипом entity (сущность).

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

Рис. 2.24. Диаграмма классов Withdraw funds со стереотипами классов

Добавление атрибутов

1. Щелкните правой кнопкой мыши на классе Account. В открывшемся меню выберите пункт New Attribute (Создать атрибут). Введите новый атрибут AccountNumber : integer

2. Нажмите клавишу Enter. Введите следующий атрибут PIN : integer

3. Повторив п.2, добавьте атрибут Balance : float

4. Щелкните правой кнопкой мыши на классе CardReader. В открывшемся меню выберите пункт New Attribute (Создать атрибут). Введите новый атрибут CardNumber : integer

5. Щелкните правой кнопкой мыши на классе CashDispenser. В открывшемся меню выберите пункт New Attribute (Создать атрибут). Введите новый атрибут CashBalance : float

Подробное описание операций с помощью диаграммы классов

1. Щелкнув мышью на классе CardReader, выделите его. Щелкните на этом классе еще раз, чтобы переместить курсор внутрь.

2. Отредактируйте операцию AcceptCard(), чтобы она выглядела следующим образом: AcceptCard() : boolean

3. Отредактируйте операцию ReadCard(), чтобы она выглядела следующим образом: ReadCard(CardNum : integer) : boolean

4. Отредактируйте операцию EjectCard(), чтобы она выглядела следующим образом: EjectCard() : boolean

5. Используя диаграмму классов, введите следующие сигнатуры операций класса ATMScreen:

InitializateScreen() : boolean, InputNumber(CustomerID : integer) : boolean, Prompt() : string, InputSum(Sum : float) : boolean

6. Используя диаграмму классов, введите следующие сигнатуры операций класса Account:

Open(CardNum : integer) : boolean, VerifyNumber(CustomerID : integer) : boolean,

WithdrawFunds(Sum : float) : boolean, VerifyFunds(Sum : float) : boolean,

DeductFunds(Sum : float) : boolean

7. Используя диаграмму классов, введите следующие сигнатуры операций класса CashDispenser:

ProvideCash(Sum : float) : boolean, ProvideReceipt() : boolean

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

Настройка

1. Проверьте, имеется ли на панели инструментов диаграммы кнопка Unidirectional Association (Однонаправленная ассоциация). Если ее нет, продолжите настройку, выполняя п.2. Если есть, то приступайте к добавлению ассоциаций.

2. Щелкните правой кнопкой мыши на панели инструментов диаграммы и в открывшемся меню выберите пункт Customize (Настроить). Добавьте на панель кнопку Creates a unidirectional association (Создать однонаправленную ассоциацию).

Рис. 2.25. Диаграмма классов Withdraw funds

с атрибутами и сигнатурами операций классов

Добавление ассоциаций

1. Нажмите кнопку Unidirectional Association панели инструментов. Проведите ассоциацию от класса CardReader к классу ATMScreen.

2. Повторив п.1, создайте остальные ассоциации (см. рис. 2.26).

3. Щелкните правой кнопкой мыши на однонаправленной ассоциации между классами CardReader и ATMScreen со стороны класса CardReader. В открывшемся меню выберите пункт Multiplicity > Zero or One (Множественность > Нуль или один). Щелкните правой кнопкой мыши на другом конце однонаправленной ассоциации. В открывшемся меню выберите пункт Multiplicity > Zero or One (Множественность > Нуль или один).

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

Рис. 2.26. Ассоциации сценария Снять деньги со счета