# Въведение в UML 2.5 и Use Case диаграми
Упражнение 1
--## Въведение в UML
При разработване на един софтуер обикновено се преминава през следните няколко
фази:
- Анализ и дефиниция
- Проектиране
- Разработване
- Тестване
- Внедряване
UML (Unified Modeling Language) е език за специфициране, визуализиране,
конструиране и документиране на процеса за разработване на обектно-ориентирани
софтуерни системи. Стандартизиран е през 1997 г. от Object Management Group и
описва поведението и структурата на обектно-ориентирана софтуерна система чрез
диаграми.
--## UML 2.5
UML спецификацията определя два основни вида диаграми:
- Структурни диаграми (structure diagrams)
- Диаграми на поведението (behavior diagrams)
Структурни диаграми
Структурните диаграми показват статичната структура на системата. Техните елементи
показват различни нива на абстракция, тяхното изпълнение и как са свързани помежду
си. Елементите в структурна диаграма представляват смислените понятия на една
система.
Диаграми на поведението
Диаграмите на поведение показват динамичното поведение на обектите в дадена
система, което може да бъде описано като поредица от промени в системата
последователно във времето.
---
## Структура в UML 2.5
Диаграми в UML
--## UML модел
Един UML модел представлява изглед на системата, която предстои да се разработи.
Включва всички UML диаграми и описва в най-големи детайли какво включва
системата и как тя ще работи.
--## Кой може да използва UML модела?
- Клиенти и ръководители на проекти: Използват Use Case диаграмите, за да получат
изглед върху системата и обхвата на проекта.
- Ръководителят на проекта: Използва Use Case диаграмите и документацията, за да
раздели проекта на управляеми части.
- Анализатори и клиенти: Използват Use Case документацията, за да видят каква
функционалност ще предоставя системата.
- Технически екип: Използва Use Case документацията, за да напише ръководство за
потребителя.
- Анализатори и разработчици: Използват Sequence и Communication диаграмите, за
да видят как ще протича логиката на системата, обектите в нея и съобщенията между
тях.
- QA екипът: Използва Use Case документацията, Sequence и Communication
диаграмите, за да получи информация за тестовите случаи.
- Разработчици: Използват Class и State Machine диаграмите, за да получат детайлен
поглед върху частите от системата и как те се свързват.
- Екип за внедряване: Използва Component и Deployment диаграмите, за да разбере
кои компоненти къде ще бъдат разпределени в мрежата.
- Целият екип: Използва модела, за да бъде сигурен, че изискванията проследяват
кода и че от кода могат да се възстановят изискванията.
--# Use Case диаграми
--## 1. Use Case диаграми
Use Case диаграмите се използват при извличане и спецификация на изискванията на
възможните действия в системата. Описват софтуерния продукт, който ще се
разработва, на високо ниво и показват някои от Use Cases (случаи на употреба), някои
от актьорите и връзките между тях.
Клиентът може да види каква функционалност ще предоставя системата, преди още
да е започнало разработването ѝ.
--## Работа с Use Cases
Use Case (Случай на употреба) е част от функционалността, която системата ще
предоставя. Има уникално име! Може да има входни и изходни условия и най-често
съдържа поток от действия (процес).
В UML Use Case се представят със следната нотация:
- Use Case
Use Case моделът предоставя пълно описание на функционалността на системата,
която ще се разработва. Предимството да видите системата в Use Cases е, че можете
да не се замисляте върху изпълнението ѝ на този етап.
--## Работа с актьори
- Актьорът е всяко нещо, което взаимодейства със системата. Той може да бъде
потребител, друга софтуерна система, външен хардуер или интервал от време.
- Актьорът е външен обект за системата, който произвежда или консумира данни.
Нотация на UML за актьор:
- Actor1
--## Връзки между елементите
Връзки между актьор и Use Case
- Association (Двупосочна)
- Directed Association (Еднопосочна)
---
Връзки между два Use Cases
- Include (Включва): Функционалността на един Use Case се включва във
функционалността на друг Use Case.
- Extends (Разширява): Функционалността на един Use Case се разширява с
функционалността на друг Use Case, само при нужда.
---
Generalization (Наследяване)
Това е връзка, която по-често се използва между актьори, за да покаже, че имат
връзка помежду им.
--## Документация на Use Case
Документацията на всеки Use Case включва документиране на потока от събития,
което описание от своя страна е съставено от следните части:
- Кратко описание: Какво ще прави даденият Use Case.
- Предусловия: Условия, които трябва да се изпълнят, за да се стартира Use Case.
- Първоначален поток от събития: Нормалният или основният поток от събития през
Use Case.
- Алтернативен поток от събития: Различните пътища и отклонения от първоначалния
поток, включително възникнали грешки.
- Следусловия: Условия, които трябва да са изпълнени след завършване на Use Case.
--## Описание на Use Case „Теглене на пари“ от АТМ
Първоначален поток от събития:
1. Use Case започва, когато потребителят вкара картата си в АТМ.
2. АТМ представя съобщение за добре дошъл и подканя потребителя да въведе PIN.
3. Потребителят въвежда PIN.
4. АТМ потвърждава, че PIN е валиден. Ако не е валиден, се изпълнява АП А1.
5. АТМ предоставя възможните опции:
- Депозиране на средства
- Теглене на пари
- Трансфер на средства
6. Потребителят избира опцията „Теглене на пари“.
7. АТМ подканя потребителя да избере сумата, която иска да изтегли.
8. Потребителят избира сумата.
9. АТМ пита дали иска разписка.
10. Потребителят прави избор.
11. АТМ проверява дали в сметката има избраната сума. Ако тя е недостатъчна, се
стартира АП А2. Ако възникне грешка, се стартира поток за грешка Е1.
12. АТМ приспада изтеглената сума от сметката.
13. АТМ предоставя на потребителя изисканите пари.
14. Ако потребителят иска бележка, се стартира АП А3.
15. АТМ връща картата на потребителя.
16. Use Case приключва.
Алтернативни потоци:
А1: Въвеждане на грешен PIN
1. АТМ уведомява потребителя, че въведеният PIN е грешен.
2. АТМ връща картата на потребителя.
3. Use Case приключва.
А2: Недостатъчна наличност по сметка
1. АТМ уведомява потребителя, че сумата в сметката е недостатъчна.
2. Връща картата.
3. Use Case приключва.
А3: Искане на бележка
1. АТМ предоставя бележка на потребителя за извършената операция.
2. АТМ връща картата.
3. Use Case приключва.
Поток на грешка Е1: Грешка при проверка на сумата в сметката на
потребителя:
1. АТМ уведомява потребителя, че е възникнала грешка при проверка на сумата и
предоставя на потребителя телефонен номер на поддържащия екип на АТМ.
2. АТМ отбелязва кода на грешката в лог за грешки, както и датата, времето, името на
потребителя и номера на сметката.
3. АТМ връща картата на потребителя.
4. Use Case приключва.
--# Class диаграми
Упражнение 2
--## Class диаграми
Дефиниция
Class диаграмите се използват, за да показват някои от класовете и пакетите на
класовете в системата, която ще разработим. Те дават статична картина на частите в
системата и връзките между тях.
Анотация на UML за клас:
- Class
--## Видове класове
За всеки клас може да се зададе stereotype. Има три основни stereotype в UML:
1. Boundary classes (граничен клас): Форми, репорти, интерфейси към хардуер и др.
2. Entity classes: Класове, които съдържат информация, която ще записвате в база
данни.
3. Control classes: Класове, които отговарят за действията на другите класове в
модела.
*Модификатори за достъп?!?*
--## Работа с атрибути
Атрибутът (член-променлива) е част от информацията, свързана с класа. Един клас
може да има един или повече атрибути.
Спецификация на атрибута:
`Visibility name : data-type-expression = initial value`
- Visibility: Как се вижда даден атрибут от другите класове: `public`, `private`, `protected`
и `package`.
- Name: Името на атрибута.
- Data Type: Типът на данните за този атрибут. Класовете също са типове!
- Initial Value: Стойност по подразбиране, ако има такава.
За всеки атрибут може да се определи как се съдържа в класа – по стойност или по
адрес.
---
## Работа с операции
Операцията (метод) е поведение, свързано с класа. Всяка операция има три части:
име на операцията, параметри на операцията и тип на връщаната стойност от
операцията.
В UML имат следния вид:
`Visibility operationName(argument1: argument1 data type, argument2: argument2 data
type, …): return type`
--## Интерфейс
Интерфейсът е клас, който съдържа само декларации на операции. Класовете, които
го реализират, трябва да предоставят телата на тези операции. Всеки клас може да
реализира множество интерфейси, както и един интерфейс може да се реализира от
множество класове.
Интерфейс
--## Връзки между класове
Разграничаваме четири основни типа връзки между класовете:
- Associations
- Dependencies
- Aggregation
- Generalization
---
Associations връзки (Двупосочна)
Тази връзка показва семантична връзка между класовете. Тя позволява един клас да
знае за `public` операциите и атрибутите на друг клас.
Пример:
- House
- Person
Directed Association връзки (Еднопосочна): Единият клас знае за `public` атрибутите и
операциите на другия клас, но вторият не знае за първия!
---
Dependencies връзки
Dependency е винаги еднопосочна и показва, че един клас зависи от дефиниции в друг
клас.
Пример: Клас Person съдържа в себе си метод, който изцяло зависи от дефиниции от
клас House – `buyHouse()`.
---
Aggregations връзки
Aggregation е строга форма на асоциация. Това е връзка между цяло и негова част.
Пример: EmployeeList (списък с работници) се състои от Employee (работници). Агрегат
наричаме родителския клас, а компоненти наричаме агрегираните класове.
---
Composition връзки
Композицията е агрегация, при която компонентите не могат да съществуват без
агрегата (родителя).
---
Generalizations връзки
Това е връзка за наследяване между два класа. Тя позволява един клас да наследи
`public` и `protected` атрибути и операции на друг клас.
--## Object диаграми
Object диаграмата представлява граф от инстанции, които включват обекти и
информационни стойности. Те показват моментно положение на състоянието на
системата. Използването на тези диаграми е доста ограничено – главно се използват
да показват примери на информационни структури.
--# Interaction диаграми
Упражнение 3
---
## Interaction диаграми
Служат да покажат стъпка по стъпка един от потоците в Use Case.
Има четири типа Interaction диаграми:
1. Sequence диаграми2. Communication диаграми3. Timing диаграми4. Interaction
Overview диаграмиInteraction диаграмите съдържат обекти и съобщения.
- Обекти: Interaction диаграмите могат да използват имена на обекти, на класове или и
на двете.
- Съобщение: Чрез съобщение един обект може да изиска друг обект да изпълни
някаква специфична функция.
--## Sequence диаграми
Sequence диаграмата е Interaction диаграма, която показва сценарий за някои от
процесите в Use Case, обектите, които участват в този сценарий, и съобщенията, които
те си разменят, подредени във времето последователно.
--## Communication диаграми
Както Sequence диаграмите, Communication диаграмите се използват да покажат
специфичен сценарий на Use Case. Те се фокусират повече върху връзките между
обектите.
--## Работа с актьори
Всяка Sequence и Communication диаграма трябва да има актьор като обект. Актьорът
е външен стимул, който казва на системата да стартира някаква функционалност.
Актьорите за Interaction диаграмите ще включват актьори, които си взаимодействат с
Use Case в Use Case диаграмата.
--## Работа с обекти
Sequence и Communication диаграмите показват обектите, които участват в един
сценарий. След като поставите актьорите в диаграмата, следващата стъпка е да
добавите другите обекти. Първо трябва да ги определите кои са те, чрез изучаване на
потока от събития и документацията, която сте написали за всеки един Use Case. След
това ще преминем към поставянето на съобщения между тези обекти.
--## Работа със съобщения
Съобщението е комуникация между обекти. Чрез него един обект иска от друг обект да
направи нещо. Когато се генерира код, съобщенията ще се трансформират в
повикващи функции.
Пример:
- form1
- form2
- 1: display
Всяко съобщение има име. За всяко съобщение може да се определи
синхронизацията му:
- Simple: Съобщението се стартира в единична нишка на контрол. Това е стойността по
подразбиране за съобщението.
- Synchronous: Клиентът чака, докато доставчикът го изпълни.
- Balking: Клиентът го изпраща; ако доставчикът не е готов да го приеме – го отказва.
- Timeout: Клиентът изпраща, чака известно време и ако доставчикът не го приеме – го
отказва.
- Asynchronous: Клиентът изпраща съобщението и продължава работа.
--## Подходи за разработка на Interaction диаграмите
- Първи подход: От гледна точка на анализа се обръща внимание повече на
информация от високо ниво, която засяга клиента. Обектите и съобщенията не са
специфицирани точно.
- Втори подход: Тимът добавя повече детайли към тях. Тук диаграмите специфицират
обектите и съобщенията от гледна точка на проектирането. Така те стават много
полезни за разработчиците, екипа за тестване и др. Обикновено всяка Interaction
диаграма има контролен обект, който отговаря за последователността на сценария.
--# Activity диаграми
Упражнение 4
--## Activity диаграми
Activity диаграмите предоставят един от начините за моделиране на динамичното
поведение на системата. Те показват какво се случва в работния поток, какви дейности
могат да бъдат извършени паралелно и дали има алтернативни пътища през този
работен поток.
--## Представяне на Activity диаграмите в UML
Основно една Activity диаграма трябва да има следните нотации:
- Activity State: Представя действието на стъпка в работния поток.
- Transition: Показва какво Activity State следва след другото.
- Decisions: Използва се за дефиниране на множество от условия. Чрез тях се дава
възможност да покажете алтернативни нишки.
- Synchronization Bars (Fork): Използват се, за да покажат паралелни потоци. Те служат
да покажат конкурентни нишки в работния поток.
В случаи, когато имате сложни примери, може да използвате допълнителни нотации
като:
- Conditional Threads: Използват се, за да показват, че една от множеството
конкурентни нишки е условна.
- Вложени Activity State диаграми: Едно Activity състояние може да съдържа друга
Activity диаграма, която показва вътрешната структура на това състояние.
- Partitions: Съдържанието на Activity диаграмите може да бъде организирано в дялове,
използвайки вертикални или хоризонтални дебели линии. Дяловете нямат формална
семантика, но в бизнес модела често се използват, за да покажат някакъв вид
организация.
--# State Machine диаграми
Упражнение 5
--## State-Machine диаграми
Дефиниция
State-Machine диаграмите показват жизнения цикъл на един обект от момента на
неговото създаване до момента на неговото унищожаване в системата. Показват също
как даден обект реагира на различни събития, като променя своето състояние, а също
така, в зависимост от неговото състояние, той може да реагира по различен начин на
едно и също събитие. Показват динамичното поведение на обектите от класа.
---
## Представяне на State-Machine диаграмите
За всеки клас, който не е абстрактен, може да създадете State-Machine диаграма. Тя
съдържа всички състояния и преходи за класа.
Състояние (State)
Това е едно от възможните условия, при които обектът може да съществува.
- State
#### Entry Action
Поведение, което възниква, когато обектът влиза в дадено състояние, или действие
при вход в състоянието.
- State
- Entry: Action
#### Do: Activity
Вътрешно действие, което обектът изпълнява, докато се намира в дадено състояние.
- State
- Do: Activity
#### Exit Action
Действие при излизане на обекта от дадено състояние.
- State
- Exit: Action
--## Добавяне на Transitions (Преходи)
Transition е предвижване на обекта от едно състояние в друго. Множеството преходи
на диаграмата показват как той се мести от едно състояние в друго.
- State1
- *(Transition)*
- State2
---
## Характеристики на преходите
- Събитие: Нещо, което се случва и предизвиква преход на обекта от едно състояние в
друго.
- Condition: Условие, което контролира кога да се извърши преход и кога не.
- Action: Задължително поведение, което е част от прехода.
Преходите между състоянията се извършват, както следва:
1. Обектът се намира в дадено състояние.
2. Настъпва събитие.
3. Извършва се действие.
4. Обектът влиза в целево състояние.
--## Специални състояния
- Start State (Initial State): Състоянието, в което обектът се намира след създаването си.
- Stop State (Final State): Състоянието, в което обектът се намира, когато се унищожи.