1

Дисциплина „Програмни Спецификации”

Упражнение 10. Диаграма на последователностите (sequence diagram) в UML

Цел: Запознаване с предназначението и процеса на построяване на UML sequencе диаграми.

Теоретична част

След като вече са определени случаите на употреба и са моделирани обектите в системата чрез

диаграми на класове, може да се разработи динамичното поведение на системата.

Случаите на употреба описват взаимодействието между потребителите и системата.

Диаграмите на взаимодействие описват начина по който групи от обекти взаимодействат и

съвместно моделират поведение, на единствен случай на употреба.

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

между тях. Диаграмите на последователност и на кооперации (еволюирали в диаграми на

комуникации в UML 2.0) са диаграми на взаимодействие в UML: те са предназначени да покажат

особеностите на взаимодействие на елементите на моделираната система, с цел пълно или

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

времето отсъства. Тъй като временният аспект на поведение има съществено значение при

моделирането на синхронни процеси описващи взаимодействието на обектите, в UML са

въведени диаграмите на последователностите.

И така: има два вида взаимо-допълващи се UML диаграми на взаимодействия, за които Star UML

предлага конвертиране от един в друг вид:

диаграма на последователностите (sequence diagram) – диаграма на взаимодействията, в

която основен акцент се постява върху реда на обмяната на съобщения във времето.

диаграма на кооперациите - диаграма на взаимодействията, в която основен акцент се

поставя върху структурната организация на обектите, които изпращат и получават

съобщения.

Забележка: В UML 2.0 е въведена още една диаграма на взаимодействие: временна диаграма (timing

diagram).

Графични елементи на диаграмите на последователностите

Диаграма последователности (sequence diagram) - диаграма, на която са показани взаимодействията

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

са инстанции на класовете и съобщения (наричани „стимули”) между тях.

Тази диаграма има като че ли 2 измерения:

Едното – от ляво надясно във вид на вертикални линии, всяка от които изобразява линията на

живот на отделен обект, участващ във взаимодействието.

Второто измерение - вертикалната временна ос, насочена отгоре надолу.

Забележка:

За съжаление, както чувате често по време на този курс, в UML няма еднозначност. Някои източници

разграничават «диаграма на последователностите с роли» (sequence role diagram), базирана на

класове с роли и «диаграма на последователностите» (sequence diagram) – базирана, на обекти. Казва

се, че обектите изпращат „стимули” един на друг, докато ролите изпращат «съобщения». Има пет

вида съобщения/стимули: Call, Send, Return, Create и Destroy.

Примерите, които ще показване и разработваме ще са основно базирани на обекти, тъй като това е

преобладаващото изполване на тези диаграми.

Всеки обект графически се изобразява като правоъгълник и се разполага в горната част на своята

линия на живот (рис. 8.1, фигура 1). Вътре в правоъгълника се записва името на обекта с малка

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

което е отличителен признак на обектите: instanceName: datatype

Име на инстанцията може и да не се зададе („анонимен” обект), задължително обаче в този случай

трябва да се зададе името на класа (datatype). Ако не се укаже името на класа, тогава задължително

се указва името на обекта (обект „сирак”). Роля на класовете в тези диаграми по правило не се

указва.

2

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

употреба.

Обикновено най-ляво е обекта, инициатор на моделирания процес на взаимодействие

(обект „a” на фигура 1). Следва – обекта, който непосредствено взаимодейства с инициатора, тоест

подредбата на обектите е също важна, от съображение за удобство при визуализацията на

взаимодействията между обектите.

Фигура 1. Графични елементи на диаграмите

на последователностите

Фигура 2. Актьор, рефлексивно съобщение и

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

На началния момент време съответства най-горната част на диаграмата. Процесът на

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

Съобщенията се изобразяват във вид на хоризонтални стрелки, като тези, които са по-горе в

диаграмата се предават по-рано от тези, които са по-ниско. При това, мащаб на оста на времето не се

указва, моделира се само подредба във времето, от вида „по-рано – по-късно”.

Линия на живот на обекта (object lifeline): това е вертикалната пунктирана линия на диаграмата на

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

време (обект 1 и обект a тип „Клас” на фигура 1 съществуват през цялото време).

За обозначаване на момента на унищожаване на обект се използва симво "X". На фигура 1, този

символ се използва за унищожаване на анонимния обект, от тип Клас 2.

Правоъгълникът върху линията на живот на обекта обозначава „активно” състояние на обекта. Този

правоъгълник се нарича фокус на управление (focus of control) – указва периода време, в течение на

който обектът изпълнява някакво действие, тоест периода време, в течение на който обектът се

намира в активно състояние.

В отделни случаи, инициатор на взаимодействието може да е актьор или външен потребител, тогава

той се изобразява като първи обект в диаграмата, със свой фокус на управление (фигура 2).

В отделни случаи, обектът може да изпраща съобщения на себе си (рефлексивни съобщения) – вижте

съобщение на обект а:Клас1 във фигура 2. Подобни ситуации възникват, например, при обработка на

натиснат клавиш на клавиатурата, при въвеждане на текст в редатируем документ и др.

Ако в процеса на рефлексивно съобщение се създаде нов подпроцес или нишка на управление, то се

говори за рекурсивен или вложен фокус на управление. На диаграмата на последователност,

рекурсията се обозначава като не-голям правоъгълник, свързан с дясната страна на фокуса на

управление на този обект, за който се изобразява рекурсивното взаимодействие (анонимен обект на

Клас 2 на фигура 2).

Съобщения

Както казахме, има пет вида съобщения: Call, Send, Return, Create, и Destroy. Съобщенията най-често

представляват извиквания (Call) на операции на викания обект. Това са „синхронни” съобщения. При

завършването на операцията, извиканият обект връща обратно съобщение към инстанцията, която е

инициирала извикването.

Фигура 3. Графично изображение на съобщения

3

Синхронно съобщение (обозначено е на фигура 3.а): извикване на процедура, изпълнение на

операция или обозначение на отделни вложени потоци за управление. При такова съобщение

получателят може да получи фокуса на управление.

Асинхронно съобщение (обозначено е на фигура 3.б): предава се в произволен момент от време;

обикновено при такова съобщение получателят не получава фокуса на управление.

Връщане от извикване на процедура (фигура 3.в).

Пример 1: Диаграма на последователностите за случай на употреба „Потребител се логва в

системата”.

Случаят на употреба се описва със следните стъпки:

1. Показва се диалога за логване

2. Потребителят въвежда потребителско име и парола

3. Потребителят натиска бутона OK или клавиша enter

4. Потребителското име и парола се проверяват и потвърждават

5. Потребителя се допуска до системата

Алтернатива: Logon Failed – ако на стъпка 4 не са потвърдени потребителското име и парола,

допуска се потребителя да опита отново.

Класове в системата:

Класът LogonDialog има public методи

за показване и скриване на прозорец и

private метод, който се извиква, когато

потребителя натисне бутона OK или

клавиша enter.

Клас LogonManager включва метод,

който връща true, ако логването е

успешно и false, ако не е.

Клас DatabaseAccess ще позволи да се

изпълни заявка към базата данни.

След като са моделирани класовете,

може да се пристъпи към диаграмите

на взаимодействието, в конкретния

случай - диаграма на

последователност (за случай на

употреба: Потребител се логва в

системата):

Задача 1: Реализирайте показаната

sequence диаграма в пример 1,

използвайки StarUML.

4

Пример 2: Диаграма на последователностите, свързана с често разглежданата система

„Телефонна служба за приемане на заявки” и услугата „Обслужване на клиенти по телефонни

заявки”:

Дадената диаграма се фокусира върху действията на оператора на клиентското ПО. Първо, на нея

явно се изобразява, че двете събития – звънене на оператора по телефона и появяване на диалогов

прозорец на дисплея на оператора, за внасяне на информация за това звънене се появяват

едновременно, тоест трябва да станат едновременно (синхронни съобщения). Това изискване

„едновременно” по нататък означава много тестове при реализацията на системата – за да бъде

наистина факт в реалната система. Много е възможно на практика да се окаже, че звъненето

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

Следователно, създаването на диаграмата на последователността помага да се обърне внимание на

тези неща, така че в етапа на проектиране по-нататък това изискване да не се забравя. Тоест

фиксирайки вниманието върху този детайл, диаграмата помага да се предотвратят грешки, които

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

На диаграмата на последователностите, така също както и на диаграмата на комуникация се показва

една и съща информация, но в различен вид. На диаграмите на последователностите тя се показва от

гледна точка на времето (временен аспект), а на диаграмите на комуникация – от гледна точка на

отношенията между взаимодействащите си части (тоест там има по-ясно изразен структурен аспект).

Може да се мисли за диаграмата на последователностите като за двойник на диаграмата на

комуникациите.

Описание на смисъла на тази диаграма: инстанцията на Тел.апарат изпраща звън към инстанцията

на Оператор. Едновременно с това на дисплея на оператора се появява диалогова форма за заявка.

Инстанцията на Тел.апарат казва причината за звъненето на Оператор. Операторът протоколира тази

причина в компютъра си. Инстанцията на Тел.апарат задава въпроси на Оператор. Операторът

отговаря на инстанцията на Тел.апарат. Операторът протоколира резултатите в компютъра.

Задача 2: Реализирайте показаната диаграма в пример 2, използвайки StarUML.

Пример 3. Нека е дадена Use case диаграма за полагане на изпити в web-базирана система. Да се

състави диаграма на последователностите на база на вашия опит, която да съответства на нея.

5

Примерно решение:

Задача 3: Реализирайте и анализирайте показаната диаграма в пример 3, използвайки StarUML.

Задача 4: Анализирайте показаната по-долу диаграма на последователности на Фаулър („Покупка

на стока в електронен Магазин”), опишете смисъла на диаграмата подробно и я реализирайте,

използвайки StarUML.

6

Какъв е смисъла на тази диаграма?

Инстанция на Order_Entry въвежда поръчка Order, за множество артикули, прави се запис Order_Line

на всеки артикул от поръчката, (итерационно, запис по запис), след което нещата стават малко по-

сложни, ако стоката липсва и т.н. Тоест: има условие [needsReorder], което индикира кога

съобщението е изпратено. Съобщението е изпратено само, ако условието е true. ...

Задача 5: Дадена е sequence diagram за резервация в хотел. Анализирайте показаната диаграма,

опишете смисъла на диаграмата подробно и реализирайте диаграмата, използвайки StarUML.

Какъв е смисъла на тази диаграма?

7

Обектът, инициатор на последователността от съобщения е Reservation window:

Reservation window изпраща makeReservation() message към HotelChain.

HotelChain изпраща makeReservation() message към един Hotel.

Ако Hotel има налични стаи, то той прави Reservation и Confirmation. Всяка вертикална пунктирана

линия е lifeline, представя времето на съществуване на един обект. Всяка стрелка е message call от

sender към receiver's lifeline. Времето на изпълнение на едно съобщение се представя чрез activation

bar.

Задача 5. Да се представи с диаграма на последователностите процесът на плащане на закупена

стока, ако цената и е под 100лв., заплащането става с налични средства на касата, ако е между 100 и

1000лв, заплащането да бъде през POS терминал, а ако надхвърли 1000лв – чрез кредит от банката.

Задача 6. Да се добави в решението на задача 1 ситуация, в която на купувача на стока с цена над

1000лв. е отказан кредит.

Задача 7. Да се състави диаграма на последователностите, описваща on-line система за регистрация

за посещения в лекарски кабинет. В системата може да се „логват” както потенциални пациенти, така

и лекарят, който ще извършва прегледите. След логването потребителят на системата въвежда дата.

За въведената дата се проверява дали и кога лекарят е свободен от прегледи. Ако лекарят е свободен

в заявеното време, то се резеврвира и се връща е-мейл на потребителя.

Задача 8. За да се добие представа за целия процес, да се анализира показаната UML- диаграма

на прецедентите след подзадачите. Предположете какъв е представения процес, кои са актьорите и

техните характеристики. На база на информацията за цялостната програмна система, решете

следните подзадачи:

8.1.Разгледайте показаната част от тази UML-диаграма на

прецедентите. Коя част от процеса представя? Какво трябва да изведе

системата? Какво поведение трябва да има при регистриран потребител и

при нерегистриран потребител? Да се състави диаграма на

последователностите за администратора на база на вашия опит, която да

съответства на нея. Нека обектите бъдат: administrator,

boundary:ServiceInterface, Controller:AdministratorSpace, Entity:Login,

LoginDBServer. Нека стимулите бъдат: EnterCredentials, ModifyProducts(),

DoLogin(), Validatelogin(), returnvalidatelogin(), performcheck,

successfeedback, failurefeedback, outputallowlogin.

8.2. Разгледайте другата показаната част от цялата UML-диаграма на

прецедентите. Да се състави диаграма на последователностите за

потребителя на база на вашия опит, която да съответства на нея. Нека

обектите бъдат: customer, boundary:ServiceInterface,

Controller:CustomerSpace, Entity:Calculator, LoadfromDB. Нека стимулите

бъдат:PutRequirements, Makeoffer(), calculate(), loadproducts(),

returnloadproducts(), calculatewithproducts, returncalculate, returnresults,

outputresults.

8

8.3. Разгледайте часттта от тази UML-диаграма на прецедентите, свързана

със създаването/изтриването на акаунти на нови администратори от страна на

boss. Да се състави диаграма на последователностите за boss на база на вашия

опит, която да съответства на нея. Нека обектите бъдат: boss,

boundary:ServiceInterface, Controller:BossSpace, Entity:AddNewAdministrator,

DBServer. Нека стимулите бъдат: inputsinfo, addnewadministrator(), savetoDB(),

returnsavetoDB(), successFeedback, outputsuccess.

8.4. Разгледайте другата показаната част от цялата UML-диаграма

на прецедентите. Да се състави диаграма на последователностите за

администратора на база на вашия опит, която да съответства на нея.

Нека обектите бъдат: administrator, boundary:ServiceInterface,

Controller:AdministratorSpace, Entity:ModifyProduct, DBServer. Нека

стимулите бъдат:InputChanges, ModifyProducts(), SavetoDB(),

returntoDB(), suceessFeedback, outputSuccess.

Временни диаграми (timing diagrams)

Тези диаграми са разновидност на диаграмите на последователностите и са предназначени за

нагледно изобразяване на потока на изменение на състоянието на няколко роли (класове,

компоненти). Последните (класове, компоненти) не се изобразяват вертикално, а хоризонтално, и

основния акцент е върху нагледното изобразяване на състоянието им, по точно на това как те се

променят във времето. Тази възможност е особено полезна при моделиране на вградени системи.

Фигура. 3. Пример за временна диаграма

На фигура 3 е показан фрагмент от работата на система AccessControl, която управлява

отваря/блокира вратата в помещение по въведен от човека електронен ключ. На рисунката са

показани три компонента на тази система (panel, access_processor, door). Първият, panel, се явява

устройство в което има само дисплей за изобразяване на текущото състояние на цялата система и

устройство за прочитане на електронен ключ. Исходно panel се намира в състояние locked

9

(съответния надпис излиза на дисплея). След като човека прилага електронния ключ и устройството

прочита информацията, panel изпраща тази информация във вид на съобщение verify на втория

компонент - процесор (access_processor ) - и преминава във състояние waiting. До получаване на

съобщение verify процесор се намира в състояние idle, а след получаване преминава в състояние

verifying. След успешно преминаване на проверката на данните от електронния ключ процесор

изпраща на компоненти panel и door съобщение unlock и преминава в състояние enable. Компонента

panel минава в състояние open. Третата компонента door (обикновено, самата врата), до сега е била в

състояние locked и, получавайки съобщение unlock, се отваря (преминава в състояние unlock ).

Отворена остава само 5 секунди, след което процесорът и изпраща команда lock и тя се затваря –

отново преминава в състояние locked. Едновременно процесор изпраща команда lock и на компонент

panel, който минава в своето изходно състояние locked и изобразява тази дума "locked" на дисплея.

Видно е, че на временните диаграми, така както и на диаграмите на последователностите и

комуникациите, се показват само главните клонове на алгоритмите, а разклоненията отсъстват.

Компонентите и техните състояния се наслагват по осите на ординатата, а времето - по абсцисата.

Времето се градуира в някаква скала на измерване. В дадения пример всяко деление съответства на 2

секунди.

Диаграмната област на всеки компонент – това е правоъгълник, отделен от другия съседен

(представляващ друг компонент), с права линия, паралелна на оста на абсцисата. Компонентите

могат да обменят съобщения , с помощта на които става синхронизация на тяхното поведение.

Съобщенията се изобразяват с вертикални линии със стрелки (отгоре надолу).

Задача 9: Реализирайте показаната диаграма, използвайки StarUML.

Въпроси:

1. Каква е основната разлика между клас диаграмите и диаграмите на взаимодействие?

2. По какво са подобни и по какво различни диаграмите на последователност и комуникация?

Кои според вас са по-близо до структурните, и кои - до поведенческите?

3. Кога според вас е целесъобразно да се използват временни диаграми. Кое е това, което те

имат и което липсва в други поведенчески диаграми на UML?

4. Дайте примери за ситуации в разработката на софтуер, когато е полезно да се използват

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

Литература: 1. http://staruml.sourceforge.net/docs/user-guide%28en%29/ch04.html

2. http://staruml.sourceforge.net/docs/user-guide%28en%29/ch05_3.html

3. http://www.youtube.com/watch?v=kApq-E2mtn0

Приложение: Построяване на диаграма на последователностите със StarUML.

Създаването на обект със StarUML е в следните стъпки:

Избира се [Toolbox] -> [Sequence] -> [Object]. Посочва се позицията, в която ще се разположи

обекта в [main window] и се въвежда името му. Ако трябва да бъде активен обект, се присвоява на

[IsActive] стойност „true”(вдясно). Ако не е присвоена, резултатът е показан вдясно.

Мулти обект(multi object) се представя така. За да се превърне обекта в мулти обект(multi object) се

установява [IsMultiInstance] в „true”.

10

Създаването на обект от клас става от [model explorer] с drag and drop в полето [main window].

Ако не е присвоен клас към обекта, се избира името на обекта и с двоен клик се активира диалог за

въвеждане на име на класа. Така се създава нов клас и се присвоява на обекта, а ако трябва да се

присвои съществуващ клас, се посочва и се избира от диалог [Select a model element] точния клас.

За да се създаде изходящ стимул от избрания обект към друг обект, се „кликва” два пъти върху

изходния обект и в диалоговия прозорец се въвежда името на стимула след "->" низ ("<-" низ за

входящо и "<->" за изходящи с отиване и връщане. След натискане на [Enter] от избрания обект за

целта се създава обект от изходящия стимул и се поставя последен.

За да се създаде стимул, се избира от [Toolbox] -> [Sequence] -> [Stimulus], след което се изтегля

обекта в [main window] от единия до другия обект.Отваря се диалогов прозорец и се въвежда името

му.

За да се използва операция от клас като стимул. Ако трябва да се присвои операция за

стимулиране,се избира , след което от диалоговата кутия [Select an operation] се избира

операцията с [OK].

11

Може да се добави и втора операция. За да се създаде операция на клас като стимул , се избира за

диалог и се въвежда име на операцията. Тя се появява и в [model explorer].

При създаване на текущия стимул от предишен стимул, се използва контекстното създаване -

„кликва” се два пъти върху стимул, или се избира стимул и се натиска [Enter]. Така са създадени нов

обект и стимули и са разположени над избрания стимул.

При създаване на подстимул се избира стимул и се натиска [Enter]. В диалоговата кутия се

въвежда име на обекта и подстимула след "->" низ("<-" за входящи стимули). След [Enter] се създава

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

Ако трябва да се свърже стимула с друг обект, се кликва в края на стимула и се изтегля с Drag and

drop до другия обект.

Промяна на [ActionKind] на стимула.

ActionKind Shape

CALL

SEND

RETURN

CREATE

DESTROY

12

За да се създаде автостимул: [Toolbox] -> [Sequence] -> [SelfStimulus]. Посочва се обекта или

линията, излизаща от него в [main window]. В диалоговата кутия се записва името.

За да се създаде комбиниран фрагмент (combined fragment): [Toolbox] -> [Sequence] -> [Combined

Fragment] и се посочва къде ще се разположи в [main window].