1 

 

Дисциплина: Програмни Спецификации Упражнения 2 - 3. Какво е Use Case? Използване на StarUML за създаване на UML Use Cases. Използване на use case диаграми в „Спецификацията на Изискванията” към софтуера (SRS) Цел: Запознаване с предназначението и процеса на построяване на UML Use Case диаграми.

1. Какво е Use Case “Use cases” е техника за определяне на функционалните изисквания на една система.  “Use case” (Случай на употреба, Случай на използване, Вариант на използване, Прецедент и др.) е независима част от функционалността на моделираната система, притежаваща резултантна ценност за своите изпълнители (актьори).

• "Независимост" - ако един случай за използване винаги се изпълнява заедно с някой друг, то по всяка вероятност той трябва да бъде включен в другия.

• "Резултантна ценност" на случая за използване означава, че той трябва да носи за актьора някакъв завършен, ценен от гледна точка на бизнеса резултат, тоест да стане по-ефективен, по призводителен бизнеса на актьора.

Множество от „случаи на използване” описва особеностите на поведението на моделираната система, без да се разглежда нейната вътрешна структура. Един “Use case” се изобразява като елипса, в която е поставено наименование, започващо с главна буква: във вид на съществително (а) или глагол (б) с пояснителни думи. Когато говорим за случай на употреба, не може да не говорим и за сценарий на случая на употреба. Един “Use case” е набор от сценарии, свързани помежду си от обща потребителска цел. Сценарият (scenario) представлява серия от стъпки, описващи взаимодействието между потребител и система. Сценариите биват два вида: • основен сценарии на успех (main success scenario) и • разширен сценарий (extensions scenario).

2. Какво е актьор? Актьорът (actor) е роля, която един потребител изпълнява по отношение на системата. Всеки use case има основен актьор, който изисква от системата предоставяне на услуга. Основният актьор е актьорът с целта, която use case предписанието трябва да задоволи, и обикновено, но не винаги, е инициатор на use case. Може да има и други актьори, с които системата комуникира в рамките на use case. Актьорите изпълняват случаи на употреба. Когато един актьор изпълнява даден случай на употреба, то между актьора и случая на употреба има връзка от тип „Асоциация” („Аssociation”), която графично (в диаграмите на потребителските случаи) се представя чрез плътна връзка без стрелка, най-често по следния начин:

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

2 

 

Връзката между актьор и случай на употреба може да е от тип «Насочена асоциация» (т.е. със стрелка). Стрелката е към този, от когото се очаква да извърши услугата. Един актьор може да изпълнява много случаи на употреба. Също – един случай на употреба може да се изпълнява от много актьори, но няма случай на употреба без актьор. Някои автори считат, че терминът актьор не е правилен, а трябва вместо него - да се използва роля. Всяка стъпка от сценария, наречена още use case предписание, е елемент на взаимодействие между актьора и системата. Единствената връзка между актьори е „обобщаване” (Generalization), което на практика означава, че актьорите могат да се наследяват един друг. При наследяването, потомъкът получава в наследство всички случаи на използване на своите предци, но има и собствени. Обозначава се с куха стрелка. Има четири типа връзки между случаите на използване: • включва (<<include>>) - когато един use case задължително

използва функционалността на друг use case. Стрелката сочи включвания use case. Вие може да включите такава връзка във вашия модел за да покажете следните ситуации:

- Поведението на включения use case е общо за 2 или повече use cases.

- Резултатът от поведението на включения use case, а не поведението му, е важен за базовия use case.

• разширява (<<extend>>) - вие можете да използвате extend relationship за да специфицирате, че един use case (т.е extension use case) може (но не е задължително) да разшири поведението на друг use case (base use case). Тази връзка показва, че изпълнението на разширението (т.е на extension use case) зависи от това, което се случва, когато базовия use case се изпълнява, тоест разширението не е задължително да се изпълни, то е опционално и зависи от изпълнението на базовия клас. Вие може да специфицирате няколко разширения ("Extension points:") на един единствен базов use case. Стрелката сочи базовия use case.

• обобщава (Generalization) – Използвайте генерализация, когато описвате вариации на нормалното поведение, а нормалното поведение е - в базовия случай на употреба. Връзка от този тип се визуализира със плътна линия и куха стрелка, като линията тръгва от вариацията и сочи към базовия на употреба.

• зависи (Dependency): връзка, при която единият use case (да го наречем „клиент”), използва или зависи от друг елемент („доставчик”). Ако доставчикът бъде променен, тогава и клиентът може (но не е задължително) да бъде засегнат, но обратното не е в сила. Обикновено тези връзки нямат имена и се представят с пунктирана отворена стрелка.

„Клиент” зависи от „Доставчик”

3 

 

Текстово описание на случая на употреба Пример 1. Разгледайте следния класически пример за видове сценарии, описан от М.Фаулър (UML основи). Да си представим един типичен on-line магазин. Бихме могли да имаме следната последователност от стъпки, тоест следния сценарий (основен) за “Покупка на продукт”: • Клиентът преглежда каталога и добавя желания арикул в кошницата за покупки. Когато пожелае да

плати, клиентът предоставя информация за доставката (адрес и др.) и кредитната си карта и потвърждава продажбата; Системата проверява оторизацията на клиентската кредитна карта, потвърждава в продажбата в браузъра на клиента и изпраща потвърждаващ e-mail на клиента.

Този сценарий описва едно от нещата, които могат да се случат по време използване на on-line магазина, това е един възможен сценарий - за успех. Но ако оторизацията е неуспешна (например картата е неразпозната), това би бил отделен сценарий – това е един неуспешен сценарий. Освен това, има и трети сценарий – за редовни клиенти да не се изисква оторизация на кредитната карта. Вижда се, че имаме 3 различни сценария, сходни единствено по целта: клиентът иска да купи стока. Тази потребителска цел е ключът към случаите на употреба: случаят на употреба е набор от сценарии, свързани помежду си с потребителска цел. !!!Не съществува стандартен начин за текстово описание на съдържанието (т.е на всички сценарии) на един случай на употреба. В различни случаи са приложими различни формати (стилове).

Текстово описание на случая на употреба „ПОКУПКА НА ПРОДУКТ” Примерно съдържание - формат 1 (М.Фаулър “UML основи”)

Основен сценарий за успех: 1. Клиентът преглежда каталога и избира артикул за покупка 2. Клиентът преминава към потвърждаване на покупката 3. Клиентът предоставя информация за доставката (адрес; спешна доставка или в 3 дневен срок) 4. Системата представя пълна информация за цената, включително на доставката 5. Клиентът попълва данни от кредитната си карта 6. Системата оторизира покупката 7. Системата потвърждава незабавно продажбата 8. Системата изпраща потвърждаващ e-mail на клиента. Разширения: Ако клиентът е «редовен клиент» .1 Системата показва текущата информация за доставка, цена и разплащане .2 Клиентът може да приеме тези подразбиращи се стойности или да дефинира нови; Следва връщане към основния сценарий на успех в стъпка 6. 6.а. системата не успява да оторизира покупката с кредитна карта 1: Клиентът може да въведе отново данните или да анулира покупката. Забележка: Една сложна стъпка в даден случай на употреба може да се окаже сама по себе си „случай на употреба”, тогава казваме, че даденият случай на употреба включва втория. Така например стъпка 1: „Клиентът преглежда каталога и избира артикул за покупка” на практика включва в себе си случая на употреба „преглед на каталог„ и „избор на артикул”. При стъпките в сценариите, можете да добавите и друга обща информация за случаите на употреба: - Предусловие (pre-condition) – описва какво условие системата трябва да провери преди да позволи

изпълнението на случая на употреба.

4 

 

- Гаранция (guarantee) или Постусловие – описва какво състояние системата трябва да осигури в края на случая на употреба.

- Тригер (trigger) – определя събитието, което стартира случая на употреба.

Текстово описание на случай на употреба Примерно съдържание - формат 2

Това е друг подход за текстово описание на всеки случай на употреба. Използва се следния примерен шаблон за описание:

Име: Актьори: Описание (Description): Приоритет: (high, medium, low) Риск: (high, medium, low) Сценарии (Scenarios):

• Сценарий 1: това е обикновено основният сценарий (main scenario) • Сценарий 2: алтернативен сценарий • Сценарий 3: алтернативен сценарий

Име: Трябва да бъде назначено уникално име, например „Transfer Funds” Актьори: Да се определят асоциираните със случая на употреба главни и второстепенни участници (потребители, бази от данни, клиенти и сървъри, платформи, устройства). Главните актьори обикновено инициират един use case (това се показва със стрелка излизаща от актьора). Второстепенните отговарят на случаите на използване. Описание: Едно или две изречения, описващи функцията или целта Приоритет: висок, среден или нисък; Приоритетът зависи от значимостта на функцията: high, medium, and low. Висок приоритет означава, че функцията трябва да бъде налична още във първата версия, иначе системата ще бъде безполезна. Среден – функцията трябва да се разработи, колкото е възможно по бързо. Малък – хубаво е да я има в някакъв момент. Риск: висок, среден или нисък; Рискът комбинира 2 оценки в един фактор, наречен индикатор на величината на риска (risk magnitude indicator):

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

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

Понякога, се включват 5 нива на риск: висок, значителен, умерен, слаб и нисък. Балансирането на приоритет и риск може да е трудно. Общото правило е - рискът, трябва да бъде в началото на проекта. Ако проектът не успее, добре е това да стане преди да са направени големи разходи на време и пари. Следва описването на сценариите: описват възможни взаимодействия между актьора и use case. Основното при разработката на всеки случай на употреба – това е описанието на сценариите: основния сценарий и алтернативните (наричани „разширения” във формат 1) сценарии. Следва още един от шаблон за текстово описание на случаи на употреба:

5 

 

Текстово описание на случай на употреба Примерно съдържание - формат 3

Таблица 4.1. Шаблон за написване на сценарий на отделен вариант на използване

Главен раздел Раздел "Типичен ход на събитията"

Раздел "Изключения"

Раздел "Забележки"

Име на варианта на използване Типичен ход на събитията, водещ към успешно изпълнение на варианта на използване

Изключение № 1 Забележки № 1 Актьори Изключение № 2 Забележки № 2 Цел ... ... Кратко описание Тип Връзка (Указване) към други варианти на използване

Изключение № N Забележки № N

Диаграми на случаите на употреба Диаграмите на случаите на употреба са начин за визуализация на случаите на употреба в UML. Това са поведенчески диаграми. Всеки случай на употреба (use case) e описание на отделен аспект от поведението на системата. Разработката на UML Use Case диаграми – това е първият етап от процеса на инженеринг на изискванията, който има за цел - да се извлече набор от функционални изисквания за поведението на проектирана система. Получените в резултат диаграми са средство за комуникация между експерти, потребители и изпълнители и основни артефакти на Спецификацията на изискванията към софтуера (SRS). Спецификацията на изискванията към бъдещата система под формата на диаграми на варианти на използване (на различни нива на абстракция, започвайки от концептуално ниво) и допълнителни сценарии може да бъде един самостоятелен модел на ПС, който в езика UML получи название <<useCaseModel>> („Модел на Случаи на Използване”). Фаулър представя следната, станала „класическа” use case диаграма, за „Система за търговия на стоковата борса”.

6 

 

Use case диаграма, за „Система за търговия на стоковата борса” Задача 1: Използвайки StarUml, отворете нов проект и създайте use case диаграмата на „Система за търговия на стоковата борса”.

a. Стартира се StarUML b. Създайте нов проект: изберете Rational Approach като “Default Approach”. c. Отворете “Main” Use Case Diagram – Новият проект автоматично прави подразбираща се

use case diagram-а под “Use Case View”-“Main” в Model Explorer. d. Разработете модела (Model) – Използвайте елементите от toolbox-а с цел да създадете

желания модел. Въведете описание (descriptions) на актьорите на случаите на използване, чрез щракане върху елемента и писане на текста в полето за документация.

Задача 2: Използвайки StarUml, отворете нов проект и създайте следната use case диаграма, демонстрираща работата с текстов редактор:

Задача 3:Да се върнем отново на примерния проект ”monopoly.uml” (за играта Monopoly), който разхгледахме обобщено в предното упражнение. Разширете Monopoly use case model в следните направления:

1. Добавете следните use case елементи (овали) към подходящите диаграми за следните случаи на употреба:

o Login – Израчът (player) трябва да се логне (login) преди да започне да играе monopoly или ра разглежда статистиката.

o Trade Properties (Търговия с имоти) – В началото, когато е на ред, играчът може да поиска друг играч да търгува с имоти и/или пари.

7 

 

o Go to Jail (Отиване в затвора) - Играч, който се попада на "go to Jail" пространството или получава "go to Jail" карта трябва да се премести в пространството на затвора.

o Buy Property (Купуване на имоти) - В края на своя ред (страна), играчът може да избере да купи имота, който току що се е появил.

2. Напишете пълният text use case за един use case, който сте добавили към диаграмата. Не забравяйте да напишете главния сценарий като сценарий за успех и да добавите други условия като разширения. Не забравяйте, че един имот би могъл да бъде собственост на банката или на друг играч.

За да изпълните задачата:

1. Отваряте “Main” use case diagram – Вие може да я намерите в “Model Explorer” панел, горе в дясно под “Monopoly”-“Use Case View”-“Main”. Тя показва случая на използване на най-високо ниво на примерната система.

Обърнете внимание на следните функции в главния прозорец на StarUML:

• "Tool Box" в ляво - осигурява елементите, на диаграмата на случая на използване (на use case model diagram).

• На "Model View" в горния десен ъгъл, се показват всички диаграми и диаграмни елементи, създадени досега.

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

2. Разгледайте текстовото описание на случаи на използване (use cases) “Play Monopoly” и “View Statistics”. Вие можете да ги намерите по следния начин:

a. Кликнете върху use case в “Use Case View” b. Отворете панел “Documentation” долу в дясно. Ако “Properties” панела е показан там,

изберете “Display” раздел най-долу. Представени са текстовите описания („text use case”) на следните use cases: “Play Monopoly” и “View Statistics”.

3. Отворете „Play” use case диаграма, намираща се в Model Explorer под "Monopoly"-"Use Case View:

8 

 

Това е по-детайлизиран модел на случая на употреба "Play Monopoly", който видяхте в модела на най-високо ниво („Main”). Той се фокусира върху действителната игра на Monopoly. Изяснете си следните неща:

• Text use case (Текстово описание на случая на употреба). Прочетете текстовото описание на случай на употреба за покупка на къщата "Buy House". Обърнете внимание на съдържанието и формата, който е използван.

• Отговорете на следните въпроси: 1. Какво означава: "Pass GO" use case разширява (extend) "Make Move" use case? 2. Какво означава: "Make Move" и "Pay Rent" use cases включат (include) "Roll Dice" use case?

Имайте предвид, че са моделирани хитрости в правилата на Монополи, които не всеки използва.

3. Какъв е редът на изпълнение на случаите на употреба, които се извършват от "Player" (т.е., "Make Move", "Pay Rent", "Buy House", "Draw Card")?

Пример 3. Постъпково реализиране на Use case диаграма Нека постъпково да реализираме и анализираме Use case диаграма за управление на „Система за електронно обучение”. В случая нашата основна цел е да определим различни нива на достъп до системата на електронно обучение. Последователност на създаване на диаграмата на прецедентите : • да бъдат анализирани потенциалните актьори в системата, които всъщност са участници в

системата • да се определят Use case, т.е. задачите които трябва да бъдат изпълнени, за реализацията на

потребителската цел. • да се определи кои актьори, какви Use cases изпълняват • текстово описание на всеки Use case 1. Идентифициране на потенциалните елементи на системата.

9 

 

И така нека да определим потенциалните актьори на системата. Важно е да се разбере, че под актьори имаме предвид различните участници в системата, като не е задължително това да са хора. Възможна е ситуация, в която един човек изпълнява две различни роли за системата, както и друга – актьорът е система, която взаимодейства с разработваната система. На пръв поглед се различават следните основни елементи (обекти) на разработваната система: • Курсове (т.е учебни дисциплини) и Теми, които представляват елементи на курса; • Лектор, който води курса; • Администратор на системата, който може да редактира курса, да създава нов курс и да го управлява; • Календарен график на курса; • Студенти, които ръководят календарния график на курса, в който участват. 2. Идентифициране на актьорите в системата за електронно обучение. Сега трябва да определим от горе описания списък само значещите актьори. Те са: - Администратор на системата; - Лектор; - Студент. Главният актьор за нашата диаграма е администраторът на системата, а лекторът и студентът са допълнителни актьори. 3. Идентифициране на Use case. Тук трябва да се опитаме да определим потенциалните бизнес процеси, т.е. процесите, които трябва системата да изпълнява за да може да реализира различните нива на достъп до нея, т.е. да удовлетвори поставената цел. И така основните задачи за системата са: - Управление на курс; - Управление на назначение на курс. Като анализираме по-нататъшното развитие на системата, може да определим някои подпроцеси, без които основните процеси не могат да съществуват. За актьор – „Администратор на системата”: за да управлява един курс, той трябва да може да разгледа съществуващите вече курсове, както и съдържаната в тях информация, лекторите, които ги ръководят, както и тяхната продължителност. Освен това„Администратор на системата” трябва да има възможността да редактира информацията, съдържаща се в даден курс, да може да създава курс и да назначава лектор за курса. Също така, той трябва да може да редактира служебната информация за самите лектори, както и да проверява дали вече някой лектор е въведен в системата, и ако не е въведен, да може да направи това. Ако някой от лекторите вече не води никой от курсовете, то тогава - да може да изтрива профила му от системата. И така след тези разсъждения достигнахме до следните use case: - Преглед на курсовете; - Управление на тематичното съдържание в курса; - Управление на информацията за курса; - Преглед на календарния график на курса; - Управление на информацията за лекторите; - Назначаване на преподаватели към даден курс. Ако сега се направи анализ на морфологичния състав на горе изложените изречения, много лесно подлогът може да се възприеме като актьор, а сказуемите и техните описателни допълнения да се разглеждат като use case. Често това е едно добро начало за разработване на use case диаграми. Добра практика е оформянето на таблица с 2 колони: 1-та - use case, а във 2-та - актьорите, участващи в него.

10 

 

use case Актьори Преглед на курсовете Администратор на системата Управление на тематичното съдържание в курса

Администратор на системата

Управление на информацията за курса

Администратор на системата

Преглед на календарния график на курса

Администратор на системата, Лектор, Студент

Управление на информацията за лекторите

Администратор на системата, Лектор

Назначаване на преподаватели към даден курс.

Администратор на системата

Въз основа на таблицата лесно се създава диаграмата. Ето и как ще изглежда нашата use case диаграма:

Задача 4: Направете текстово описание на избрани от вас use cases, свързани с пример 3.

11 

 

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

Решение: use case Актьори Поставяне на меню Секретарка Запознаване с меню Секретарката, Служителите, Офис-

мениджърът Правят заявка Секретарката, Служителите, Офис-

мениджърът Обобщаване на заявките

Офис-мениджърът

Заплащане Офис-мениджърът Правоъгълникът обозначава граница на системата (или на подсистема). В случая – може да се пропусне, т.к. се подразбира интуитивно. Актьорите са представени без техните атрибути, които при програмирането ще бъдат обособени в клас. Връзките между актьори и прецеденти винаги са от тип 1:1, но 1 актьор може да се свърже с няколко прецедента с отделни връзки. Пример 5. „Обслужване на клиенти по телефонни заявки” В качеството на пример при разглеждане на различните UML диаграми по време на лекции, често ще бъде използван един пример: система "Обслужване на клиенти по телефонни заявки" Възложител на дадената система - това е компания, владееща мрежа от продуктови магазини. Възложителят изисква да се разработи система, предоставяща услугата „обслужване на клиенти по телефонни заявки” (ОКТЗ). Всеки клиент трябва да може да се регистрира в компанията, след което да може по телефона, в удобно за себе си време да прави поръчка на стоки, които да му се носят у дома, където той ще се разплаща. За тази цел, в компанията ще се организира локален телефонен център, състоящ се от многоканална АТЦ, щатни оператори и съответното ПО (което е обект на възлагане). При това, компанията вече разполага с информационна система за Системата за Обработка на Заявките (СОЗ) и новата поръчкова система (ОКТЗ) трябва да бъде интегрирана с нея. Преди да се захване с реализация на описаната по-горе задача, всяка сериозна софтуерна компания се заема с уточняване на изискванията. Резултатът е - Спецификацията на Изискванията” към софтуера (SRS). Дейността по анализ на изискванита включва опит за преценка какво точно потребителите очакват от разработения софтуер и какво самите разработчици трябва да направят. Тук може да се използват Use Cases, които да опишат на най-високо ниво целите на потребителите на системата, цели, които разработваната система трябва да реализира. Тези цели не е необходимо да са задачи или действия, а могат да са по общи изисквания към функционалността на системата. За конкретния пример, функционалните изисквания на ПС могат да се опишат със следната UML диаграма на случаи на използване:

12 

 

Пример на диаграма на случаи на използване

На тази диаграма са обозначени следните видове потребители: оператор, мениджър и представители на техническата поддръжка. Системата трябва също да поддържа външен интерфейс със Системата за Обработка на Заявките (СОЗ). Това е - четвърти потребител. Има и още един потребител на системата, а именно Петров А.Б. - директор на департамента за продажба на стоки, който желае периодично да следи дейността на телефонната служба за приемане на заявки. За него е създадено специално работно място с екранни форми и статистики. Използвайки StarUml, създайте горната диаграма. Задача 6. Разгледайте показаната UML-диаграма на прецедентите. Коя част от процеса представя? Какво трябва да изведе системата? Какво поведение трябва да има при регистриран потребител и при нерегистриран потребител? Какви механизми за сигурност при валидация бихте използвали? Опишете сценария с таблица с две колони: действие на актьора, реакция на системата. Опитайте да опишете процеса с максимална детайлизация. Задача 7. Да се анализира показаната UML- диаграма на прецедентите. Предположете какъв е представения процес, кои са актьорите и техните характеристики. Какви са прецедентите? Има ли грешки или пропуски в представянето? Същият процес може ли да се престави по друг начин?

13 

 

Задача 8. Да се построи UML-диаграма на прецедентите за процеса на купуване на стока в магазин за строителни материали. Нека процесът изглежда така: Продавачът изписва на клиента ордер, в който пише код на стоката,наименование и количество. Клиентът плаща на касата стойността на стоката. Касиерът намира в БД стоката по кода и изчислява стойността. Клиентът получава касов бон и разписка за получаване на стоката от склада и отива с нея в склада. Там той дава разписката на служителя, който отписва от счетоводната книга посоченото количество от стоката по кода (получава се какво количество остава в наличност в склада) и го дава на клиента. Задача 9. Да се построи UML-диаграма на прецедентите за процеса на обучение на студент по един предмет. Нека процесът изглежда така: Студентът изучава материала като: слуша лекции, наблюдава презентации, чете препоръчаната литература, посещава упражнения, изпълнява заданията в час, изпълнява домашните задания, преминава текущите проверки чрез тестове и задачи. Студентът получава консултации от лектора в посочените часове и зала, от асистента в посочените часове и зала, по имейл от лектора, по имейл от асистента. Студентът се явява на изпит и получава оценка. Задача 10. Ще се разработва софтуер за създаване на игра на бесеница. Правилата са следните: Компютърът избира дума, която потребителят ще познава и показва само първа и последна буква, както и броя на неразкритите букви. Потребителят предлага буква и ако тя се съдържа в думата, се извежда на съответното място, ако не, един опит изгаря от общо 9 опита. Играта приключва с победа за потребителя, ако той познае думата преди да привършат опитите му или със загуба, ако използва всички свои опити без да познае думата. Каква UML диаграма би била полезна в този случай? Защо? Съставете я с помощта на StarUML. Препоръки при разработка на use case диаграмите Както беше отбелязано по-горе, едно от основните предназначения на тази диаграма е за определяне и формализация на функционалните изисквания на системата. Тази диаграма може да служи като основа за съгласуване на функционалните изисквания на системата с клиента, при ранните етапи на проектиране на системата. Всеки use case на даден етап на разработка може да бъде подложен на декомпозиция при следващите етапи. Препоръчително е, общия брой актьори да не превишава 20, а броят на случаите на използване - да не надвишава 50. В противен случай моделът губи своята яснота. За разработка на use case диаграми се препоръчва следната последователност от действия:

• Да се определят главните или първичните и второстепенни актьори • Да се определят целите на главните актьори по отношение на системата • Да се формират основни варианти на използване, които специфицират функционалните

изисквания към системата

14 

 

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

вариант на използване • Да се напише успешния сценарий за реализация на избрания вариант за използване • Да се определят «Изключения» или «неуспех» при изпълнение на сценария на варианта на

използване • Да се напише сценарий за изпълнение на всички изключения • Да се определят общите варианти на използване и да се изобразят техните взаимовръзки с

базовите варианти (със стереотип <<include>>) • Да се определят варианти на използване, свързани с изключенията и да се изобразят тяхните

взаимовръзки с базовите, като стереотип <<extend>> • Да се провери диаграмата за отсъствие на дублиране на варианти на използване и актьори

Кога да използваме случаи на употреба? • Те са ценен инструмент за разбиране функционалните изисквания на системата. • Те са външен изглед на поведението на системата, така че не очаквайте корелация между тях и

класовете на системата. • Те са основен инструмент за „уточняване” на изискванията при планирането и контролирането на

итеративно разработвани софтуерни проекти. „Улавянето” на случаите на употреба е една от основните задачи през фазата на уточняване и специфициране на изискванията към софтуера.

• Повечето от случаите на използване ще се генерират по време на тази фаза на проекта, но някои ще бъдат открити и по късно, през следващите фази на разработка на проекта. Така, че: мислете за тях, през цялото време, т.е през целия жизнен цикъл на ПО. Всеки случай на използване е едно потенциално изискване, и докато не сте „разбрали изискването”, не можете да планирате да се справите с него. Обсъждането с потребителите е от голяма полза за тяйното уточняване!

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

Въпроси: 1. Какво представляват нефункционалните изисквания ? 2. Какво представляват функционалните изисквания ? 3. Как се изобразяват нефункционалните изисквания на диаграмата на прецедентите? 4. Как се изобразяват нефункционалните изисквания на диаграмата на прецедентите? 5. Какво е Use Case? 6. Какво е useCaseModel? 7. Как се изобразяват актьорите в UML use case диаграмите? 8. Какво е актьор? Какви типове актьори има? В какви отношения могат да бъдат актьорите? 9. В какви отношения могат да бъдат случаите на използване? 10. Какъв е смисълът на отношението <<include>>? 11. Какъв е смисълът на отношението <<extend>>? 12. От какъв тип са връзките между актьорите и случаите на използване? 13. Какво означава текстово описание на случая на употреба? Дайте пример. 14. Какво е предназначението на Use case diagrams? 15. Кога да използваме случаи на употреба? Използвана Литература: Мартин Фаулър „UML основи” http://staruml.sourceforge.net/docs/user-guide(en)/toc.html http://194.141.86.222/lecture/rkraleva/LetenSem/SoftTech/Ypr_SoftTech/st10.htm http://cs.calvin.edu/curriculum/cs/262/kvlinden/04analysis/lab.html http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML