Файл: Практическое задание № 2 Создание диаграммы классов и диаграмм взаимодействия.pdf

Практикум по 

объектно-ориентированному 

моделированию с помощью UML 

Практическое задание №2

6 

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

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

Рисунок 1.5 – Обозначение граничных классов 

Управляющий класс отвечает за координацию действий других классов. 

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

<<control>> либо специальной пиктограммой (рисунок 1.6). 

Рисунок 1.6 – Обозначение управляющих классов 

Управляющие классы можно представить, как «исполняющие»  прецедент, 

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

Управляющий  класс  делегирует  ответственности  другим  классам.  Сам  он 

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

Практикум по 

объектно-ориентированному 

моделированию с помощью UML 

Практическое задание №2

7 

1.3. 

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

После  того,  как  класс  создан,  информацию  о  нем  необходимо 

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

Если  в  нашей  модели  присутствует  класс  Сотрудник,  то  хорошим 

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

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

и  так  описана  с  помощью  атрибутов.  Например,  плохое  описание  класса 
Сотрудник: «Имя, телефон, адрес, должность, зарплата». 

В StarUML документирование классов выполняется также, как и описанное 

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

1.4. 

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

Диаграммы  классов  относятся  к  логическому  представлению  системы 

Logical  View.  На  диаграмме  Main  представления  Logical  View  обычно 
размещают  главную  диаграмму  пакетов,  а  диаграммы  классов  помещают  на 
другие листы этого представления.  

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

щелкнуть  правой  кнопкой  мыши  по  папке  представления  Logical  View  в 
навигаторе модели,  в  контекстном  меню  выбрать пункт  Add  Diagram,  в  списке 
выбрать диаграмму классов Class Diagram (рисунок 1.7). 

Рисунок 1.7 – Добавление диаграммы классов 

Практикум по 

объектно-ориентированному 

моделированию с помощью UML 

Практическое задание №2

8 

Будет  создана  новая  диаграмма  классов  со  стандартным  именем 

ClassDiagram1,  которое  можно  изменить  в  редакторе  свойств  диаграммы 

(рисунок 1.8). 

Рисунок 1.8 – Редактор свойств диаграммы классов (свойство Name) 

Пример.  Рассмотрим  сценарий  Оформление  заказа,  который  является 

внутренним потоком для прецедента Заказ  товара. Опишем его классы. 

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

оплатить его с использованием банковской карты. 

Давайте представим, как выполняется этот сценарий, еще раз. Покупатель, 

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

Построим  диаграмму  классов  для  сценария  Оформление  заказа  в 

StarUML.  Создайте  в  пакете  Logical  View  диаграмму  классов  описанным  выше 
способом. Переименуйте ClassDiagram1 в Оформление Заказа (Place Order). 

Выбор граничных классов 

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

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

прецедентом 

Оформить 

заказ. 

Назовем 

его 

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

Практикум по 

объектно-ориентированному 

моделированию с помощью UML 

Практическое задание №2

9 

ВводЛичныхДанных  (EnterPersonalInformation).  После  того,  как  выбраны 
товары  и  введена  личная  информация  покупателя,  остается  только  проверить 
детали заказа и согласиться с ними или нет  – для этого действия введем класс 
ПроверкаДеталейЗаказа  (ConfirmOrder).  Наконец,  когда  покупатель 
завершит  оформление  заказа,  то  на  экране  он  видит  номер  заказа  и 
подтверждение  заказа  отправляется  покупателю  на  электронный  адрес,  для 
выполнения  этих  обязанностей  создадим  еще  один  граничный  класс 
ПодтверждениеЗаказа (OrderConfirmation). 

Выбор управляющих классов 

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

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

(PlaceOrderManager). 

Выбор классов-сущностей 

В сценарии Оформление заказа речь идет о покупателе, заказе и товарах. 

Создадим  классы-сущности  Покупатель  (Customer),  Заказ  (Order),  Товар 

(Item). 

Возможно,  что  в  ходе  дальнейшего  проектирования  какие-то  новые 

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

Создадим  новый  класс  Покупатель  (Customer).  Щелкните  правой 

кнопкой  мыши  по  Logical  View  в  навигаторе  модели,  в  контекстном  меню 
выберите  пункт  Add  (Добавить),  затем  выберите  пункт  Class  (Класс).  Новый 
класс  будет  создан  и  отобразится  в  навигаторе  модели.  На  вкладке  Properties 
(Свойства) измените имя класса на  Покупатель (Customer). Заметим, что при 
таком  способе  создания  класса,  StarUML  создает  новый  элемент  в  навигаторе 
модели.  Теперь  перетащите  этот  класс  из  навигатора  модели  на  рабочий  лист 
диаграммы Оформление Заказа (Place Order) (рисунок 1.9). 

Рисунок 1.9 – Создание класса «Покупатель» 

Практикум по 

объектно-ориентированному 

моделированию с помощью UML 

Практическое задание №2

10 

Для  того  чтобы  создать  класс  ОформлениеЗаказа  (PlaceOrder),  можно 

использовать другой метод. Слева на панели инструментов (Toolbox) щелкните 
изображение  класса  (Class),  затем  щелкните  на  листе  диаграммы  Оформление 
Заказа  в  том  месте,  куда  необходимо  поместить  класс,  при  этом  стандартное 
имя  класса  станет  активным,  давая  возможность  его  изменить.  Измените  имя 
класса на ОформлениеЗаказа (PlaceOrder) (рисунок 1.10). 

Рисунок 1.10 – Создание класса «ОформлениеЗаказа» 

Создайте  все  остальные  классы,  в результате  итоговая диаграмма  классов 

будет иметь вид, представленный на рисунке 1.11. 

Рисунок 1.11 – Диаграмма классов сценария «Оформление заказа» 

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

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