# Въведение в 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): Състоянието, в което обектът се намира, когато се унищожи.
0
You can add this document to your study collection(s)
Sign in Available only to authorized usersYou can add this document to your saved list
Sign in Available only to authorized users(For complaints, use another form )