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

ВУЗ: Не указан

Категория: Методичка

Дисциплина: Программирование

Добавлен: 15.11.2018

Просмотров: 2911

Скачиваний: 37

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

Практикум по 

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

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

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

 

16 

 

Группировка классов в пакеты 

Созданные ранее классы диаграммы Оформление заказа сгруппируем по 

пакетам.  Перетащите  в  навигаторе  модели  класс  Customer  (Покупатель)  в 
пакет  Классы-сущности.  Аналогично  классы  Item  (Товар)  и  Order  (Заказ) 
разместим также в пакете Классы-сущности.  

Классы 

ОформлениеЗаказа 

(PlaceOrder), 

ВводЛичныхДанных 

(EnterPersonalInformation), 

ПроверкаДеталейЗаказа  (ConfirmOrder)  и 

ПодтверждениеЗаказа  (OrderConfirmation)  разместим  в  пакете  Граничные 
классы.  

Класс  МенеджерОформленияЗаказа  (PlaceOrderManager)  –  в  пакете 

Управляющие классы. Результат группировки классов по пакетам представлен 
на рисунке 2.5. 

 

Рисунок 2.5 – Результат перемещения классов в пакеты

 

Обратите  внимание,  что  при  этом  внешний  вид  диаграммы  классов 

Оформление заказа (Place Order) и диаграммы пакетов не изменится. 

 

 


background image

Практикум по 

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

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

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

 

17 

 

3. 

Построение диаграмм взаимодействия

 

Диаграммы  взаимодействия  отображают  один  из  процессов  обработки 

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

Основной  элемент  диаграмм  взаимодействия  –  это  объект.  Объектом 

описывают  нечто  содержащее  в  себе  данные  и  поведение.  Это  термин, 
описывающий  реальные,  конкретные  предметы  или  абстрактные  сущности. 
Объекты 

изображаются 

в 

виде 

прямоугольников, 

имена 

объектов 

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

Объекты, помещаемые на диаграммы взаимодействия, скорее всего, будут 

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

Если  перед  тем,  как  строить  диаграммы  взаимодействия  мы  построили 

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

Существует два типа диаграмм взаимодействия: 

  диаграммы последовательности действий (Sequence Diagram); 
  диаграммы кооперации (Communication/Collaboration Diagram).  

Первые  отображают  обмен  сообщениями  между  объектами  во  времени,  а 

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


background image

Практикум по 

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

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

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

 

18 

 

3.1. 

Диаграммы последовательности. Элементы нотации 

Как  правило,  поток  событий  описывает  не  одну  последовательность 

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

Сценарий  (Scenario)  –  это  некоторая  последовательность  действий, 

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

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

последовательность  сообщений,  которыми  обмениваются  объекты  в  ходе 
выполнения сценария (рисунок 3.1). 

   

 

Рисунок 3.1 – Примеры диаграмм последовательности

 

На диаграмме последовательностей могут также изображаться экземпляры 

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


background image

Практикум по 

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

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

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

 

19 

 

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

его  в  навигаторе  модели  справа  и  перетащить  на  поле  рабочее  диаграммы 
последовательностей. 

Каждый объект или действующее лицо на диаграмме последовательностей 

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

Линия  жизни  объекта  (object  lifeline)  –  вертикальная  пунктирная  линия 

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

Фокус управления (активность, focus of control) – специальный символ 

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

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

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

Сообщение  (message)  –  спецификация  передачи  информации  от  одного 

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

Для  сообщений  на  диаграммах  последовательностей,  как  и  для  других 

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

Во-первых, у каждого сообщения должно быть имя, соответствующее его 

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

Объект  не  может  вызвать  произвольную  операцию:  она  должна  быть 

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

В-третьих,  мы  можем  для  каждого  сообщения  установить  тип 

синхронизации. Каждому типу соответствует его обозначение. 

 

 


background image

Практикум по 

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

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

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

 

20 

 

Вызов  операции  (процедуры)  вызывает  операцию  того  объекта,  к 

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

Синхронное  (Message)  сообщение  обозначается  стрелкой  с  закрашенным 

наконечником (рисунок 3.2).  

Асинхронное  сообщение  (Async  Message)  посылает  объекту  сигнал.  При 

этом  источник  не  ждет  отклика  приемника  или  подтверждения  получения,  а 
продолжает свою работу. Обозначается нежирной стрелкой (рисунок 3.2). 

 

Рисунок 3.2 – Синхронное и асинхронное сообщение 

Ответное сообщение (Replay Message) возвращает значение из процедуры 

тому  объекту,  к  которому  направлено.  Обозначается  пунктирной  стрелкой 
(рисунок 3.3). 

 

Рисунок 3.3 – Ответное сообщение 

Создание объекта (Create Message) – создает новый объект. Обозначается 

стрелкой со стереотипом <<create>> (рисунок 3.4). 

 

 

Рисунок 3.4 – Создание объекта 

Удаление  объекта  (Delete  Message)  –  удаляет  объект.  Объект  может 

уничтожить сам себя. Обозначается стрелкой со стереотипом <<destroy>>. При 
уничтожении  объекта  на  его  линии  жизни  появляется  символ  разрушения, 
который обозначается крестом (рисунок 3.5). 

 

Рисунок 3.5 – Уничтожение объекта