Лабораторна робота №5

Діаграма послідовності (Sequence Diagram) 

Мета роботи: для заданої предметної області побудувати діаграму послідовності.

Теоретичні відомості

Для моделювання взаємодії об'єктів у мові UML використовуються відповідні діаграми взаємодії. Говорячи про ці діаграми, мають на увазі два аспекти взаємодії. По-перше, взаємодії об'єктів можна розглядати в часі, і тоді для подання тимчасових особливостей передавання і приймання повідомлень між об'єктами використовується діаграма послідовності.

1. Об’єкти на діаграмі послідовностей

На діаграмі послідовності зображуються винятково ті об'єкти, які безпосередньо беруть участь у взаємодії і не показуються можливі статичні асоціації з іншими об'єктами. Для діаграми послідовності ключовим моментом є саме динаміка взаємодії об'єктів у часі. При цьому діаграма послідовності має як би два виміри. Один – зліва направо у вигляді вертикальних ліній, кожна з яких зображає лінію життя окремого об'єкту, що бере участь у взаємодії. Графічно кожний об'єкт зображується прямокутником і розташовується у верхній частині своєї лінії життя (рис. 5.1). Всередині прямокутника записуються ім'я об'єкту й ім'я класу, розділені двокрапкою. При цьому весь запис підкреслюється, що є ознакою об'єкту, який, як відомо, є екземпляром класу.

Крайнім ліворуч на діаграмі зображується об'єкт, що є ініціатором взаємодії. Правіше зображується інший об'єкт, що безпосередньо взаємодіє з першим. Таким чином всі об'єкти на діаграмі послідовності утворять деякий порядок, обумовлений ступенем активності цих об'єктів під час взаємодії один з одним. 

Рис. 5.1. Різні графічні примітиви діаграми послідовності.

Другий вимір діаграми послідовності – вертикальна тимчасова вісь, спрямована зверху вниз. Початковому моменту часу відповідає найвища частина діаграми. При цьому взаємодії об'єктів реалізуються за допомогою повідомлень, які посилають одні об'єкти іншим. Повідомлення зображуються у вигляді горизонтальних стрілок з іменем повідомлення і також утворять порядок відповідно до часу свого виникнення. Інакше кажучи, повідомлення, розташовані на діаграмі послідовності вище, ініціюються раніше від тих, які розташовані нижче. При цьому масштаб на осі часу не вказується, оскільки діаграма послідовності моделює лише тимчасову впорядкованість взаємодій типу «пізніше».

Лінія життя об'єкту (object lifeline) зображається пунктирною вертикальною лінією, що асоціюється з єдиним об'єктом на діаграмі послідовності. Лінія життя служить для позначення періоду часу, протягом якого об'єкт існує в системі й, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт існує в системі постійно, то і лінії його життя повинні зображатися на всій площині діаграми послідовності від найвищої її частини до найнижчої.

Фокус керування зображається у формі витягнутого вузького прямокутника, верхня сторона якого позначає початок отримання фокусу керування об'єкту (початок активності), а її нижня сторона – закінчення фокусу керування (закінчення активності). Цей прямокутник розташовується нижче позначення відповідного об'єкту й може замінювати його лінію життя, якщо він є активним протягом всього свого життя.

2. Повідомлення

Як було відзначено вище, ціль взаємодії в контексті мови UML полягає в тому, щоб специфікувати комунікацію між множиною об'єктів, які взаємодіють. Кожна взаємодія описується сукупністю повідомлень, якими об'єкти обмінюються між собою. У цьому сенсі повідомлення (message) є закінченим фрагментом інформації, що відсилається одним об'єктом іншому. При цьому приймання повідомлення ініціює виконання певних дій, спрямованих на рішення окремого завдання тим об'єктом, якому це повідомлення відіслане.

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

У такому контексті кожне повідомлення має напрямок від об'єкту, що ініціює і відсилає повідомлення, до об'єкту, що його одержує. Іноді відправника повідомлення називають клієнтом, а одержувача – сервером. При цьому повідомлення від клієнта має форму запиту деякого сервісу, а реакція сервера на запит після одержання повідомлення може бути пов'язана з виконанням певних дій або передавання клієнтові необхідної інформації теж у формі повідомлення.

3. Стереотипи повідомлень

У мові UML передбачені деякі стандартні дії, що виконуються у відповідь на одержання певного повідомлення. Вони можуть бути явно зазначені на діаграмі послідовності у формі стереотипу поруч із повідомленням, до якого вони відносяться. У цьому випадку вони записуються в лапках. Використовуються такі позначення для моделювання дій:

• "call" (викликати) – повідомлення, що викликає операції або процедури об'єкту, який приймає; якщо повідомлення із цим стереотипом рефлексивне, то воно ініціює локальний виклик операції в самого об'єкту, що послав це повідомлення;

• "return" (повернути) – повідомлення, що повертає значення виконаної операції або процедури об'єкту, якщо її викликав; значення результату може ініціювати розгалуження потоку керування;

• "create" (створити) – повідомлення, що вимагає створення іншого об'єкту для виконання певних дій; створений об'єкт може одержати фокус керування, а може й не одержати його;

• "destroy" (знищити) – повідомлення з явною вимогою знищити відповідний об'єкт; посилається в тому випадку, коли необхідно припинити небажані дії з боку наявного в системі об'єкту, або коли об'єкт більше не потрібний і повинен звільнити задіяні ним системні ресурси;

• "send" (послати) – позначає посилання іншому об'єкту деякого сигналу, що асинхронно ініціюється одним об'єктом і приймається (перехоплюється) іншим; відмінність сиґналу від повідомлення полягає в тому, що сиґнал має бути явно описаний у тому класі, об'єкт якого ініціює його передавання.

Хід роботи

1. Ознайомитися з теоретичними відомостями.

2. Побудувати відповідну діаграму за допомогою UML згідно до своєї предметної області (варіанти предметних областей наведені у додатку).

3. Оформити звіт за результатами лабораторної роботи.

Зміст звіту

1. Мета роботи

2. Короткі теоретичні відомості.

3. Хід роботи.

4. Висновки. 

Література

1. Кальянов  Г.Н. Case -  технологии.  Консалтинг  при  автоматизации бизнес-процессов. - 15.е изд. М.: Горячая линия – Телеком, 2002. - 320 с.

2. Кирстен В. Объектно-ориентированная разработка приложений в среде постреляционной СКБД CACHE / Кирстен В., Ирингер М., Шульте П  - СП-б: АОЗТ “СП. АРМ”,  2000.

3. Пасічник В.В. Організація баз даних та знань / В.В.Пасічник, В.А.Резніченко. – Київ: BHV „ПИТЕР”, 2006. – 460с.

4. Крэг Ларман Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. — 3-е изд. — М.: «Вильямс», 2006. — 736 с. — ISBN 0-13-148906-2

5. Джозеф Шмуллер Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. — М.: «Вильямс», 2005. — 416 с. — ISBN 0-672-32640-X

6. Грейди Буч. Язык UML. Руководство пользователя = The Unified Modeling Language user guide / Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. — 2. — М., СПб.: «ДМК Пресс», «Питер», 2004. — 432 с. — ISBN 5-94074-260-2

7. Буч Г. UML. Классика CS. 2-е изд. / Буч Г., Якобсон А., Рамбо Дж. / Пер. с англ.; Под общей редакцией проф. С. Орлова — СПб.: Питер, 2006. — 736 с.

8. Нікольський Ю.В. Дискретна математика / Ю.В.Нікольський, В.В.Пасічник, Ю.М.Щербина – Львів: Магнолія Плюс, 2007. – 608 с.

9. Шаховська Н.Б. Сховища даних / Шаховська Н.Б., Пасічник В.В. – Львів: «Магнолія-2006», 2008. – 485 с.

З повагою ІЦ "KURSOVIKS"!