UML diagramy – Případy užití A7B36SIN - Softwarové inženýrství, A7B36USI - Úvod do SW inženýrství, AD7B36SIN - Softwarové inženýrství(dálkaři), AD7B36USI - Úvod do SW inženýrství(dálkaři), Y36SIN-Úvod do softwarového inženýrství Ing. Martin Komárek Katedra počítačů ČVUT v Praze, FEL
Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti
UML- Případy užití https://sites.google.com/a/fel.cvut.cz/uml---pripady-uziti/
Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti
SOFTWAROVÉ INŽENÝRSTVÍ
Požadavky a jejich modelování pomocí případů užití Martin Komárek Vzniklo primárně pro potřeby studijního programu Softwarové technologie a management za podpory:
Diagram případů užití
Model případů užití
USE CASE MODEL Modelování případů užití, je způsob zachycení funkčních požadavků Vyjadřuje ,kdo bude jakým způsobem používat systém Cíle modelování:
Najít hranice systému (co je součástí, co je vně systém) Najít aktéry (kdo bude systém přímo používat/ovlivňovat) Vytvořit vlastní use case
Účastníci (=aktéři) Jednotlivý účastník:
je vůči systému externími entitou, která systém využívá nebo ho ovlivňuje. většinou účastníkem reálná osoba(uživatel), nebo častěji spíše role, kterých konkrétní osoby nabývají (př. obchodní zástupce, lékař, hlavní účetní, …..) účastníkem ale může být například i "čas" (spouštění záloh atd..) účastníkem dále může být i jiný systém
Identifikace účastníků/aktérů pomocí seznamu otázek Ne všechny aktéry odvodíme s business procesů a proto se ptáme:
Kdo používá systém Kdo instaluje systém? Kdo vypíná a zapíná systém? Kdo udržuje? Jaké další systémy používá řešený systém? Kdo získává a poskytuje informace systému? Děje se něco v systému pravidelně resp. V určitém čase?
Generalizace účastníků
Případy použití systému (USE CASE) “případ použití"~"případ užití"~"užitná činnost“~”use case”
James Rumbaugh: „Případ užití můžeme definovat jako specifikaci posloupnosti činností, včetně proměnných posloupností a chybových posloupností, které systém může vykonat prostřednictvím interakce s aktéry.“
Měl by popisovat jednu rutinní akci jednoho účastníka v jednu chvíli
Je vždy iniciován účastníkem
USE CASE diagram znázorňuje funkce systému z pohledu účastníků
Název USE CASE má vždy slovesnou vazbu!!!
Př. : Zadat objednávku, Zjistit stav objednávky, ……
Use case diagram – Co je špatně? Mail Order System use case diagram
Mail Order System communication relationship
subject name
system boundary Place Order
Cancel Order
Ship Product ShippingCompany
Customer
actor
Check Order Status Send Catalogue
use case Dispatcher 8
Název USE CASE vždy slovesnou vazbou!
Specifikace případu užití
Struktura specifikace není definována standardem UML. UC musí být definován alespoň:
Netriviální UC obvykle bývá doplněn o:
Názvem Stručným popisem Hlavní scénář (Main/Basic/Happy flow) Vedlejší scénář (Alternative flow) Výjimečný scénář (Exceptional flow)
Další možná upřesnění UC:
Jedinečným identifikátorem Vstupními podmínkami Výstupním podmínkami Aktéry zapojenými do případu užití …
Scénář případu užití = tok událostí
Hlavní scénář popisuje kroky případu užití, pokud vše jde jak má. Odchylky od ideálního (=hlavního) scénáře zachycujeme v alternativních scénářích. Výjimky (cancel atd.) ošetřujeme v Exception path. Pozor dříve nebylo podporováno nástrojem EA, takže se používaly alternativní scénáře.
Většinou popisuje textově, ale někdy názornější diagramem aktivit (popis algoritmů výpočtu, složitá větvení toků, atd).
Scénář případu užití
Stejně jako v divadelním či filmovém scénáři se obvykle střídají role. V našem případě Uživatel a Systém.
UC 112 – Přihlášení uživatele 1.
2. 3.
4. 5.
Systém zobrazí přihlašovací formulář (FRM. 26_Login frame) včetně CAPTCHA. Uživatel vyplní požadované údaje a potvrdí je. Systém ověří správnost vyplněných údajů a zobrazí všechny role, které má uživatel v systému na výběr. Uživatel vybere jednu z nabízených rolí. Systém…
Příklad případu užití Upravit záznam Umožňuje upravit jednotlivé položky u vybraného záznamu v katalogu. Seznam položek jednotlivých záznamů v katalogu je uveden v popisu tohoto balíčku. Tok událostí: Basic Path
Upravení záznamu v katalogu 1. Případ užití začíná, když chce lékař upravit některý ze záznamů v katalogu. 2. INCLUDE ( Vybrat katalog ) 3. Systém požádá lékaře o výběr záznamu z katalogu, který chce upravovat. 4. INCLUDE ( Zobrazit položky katalogu). 5. Systém zobrazí formulář umožňující upravit veškeré položky u vybraného záznamu. 6. Lékař upraví požadované údaje. 7. Systém uloží do záznamu všechny změny provedené lékařem.
Exception
Zrušení provedených úprav 1. Lékař může veškeré provedené změny odvolat stisknutím tlačítka Storno.
(Ne)Používání uživatelských rolí ve scénařích Upravit záznam Umožňuje upravit jednotlivé položky u vybraného záznamu v katalogu. Seznam položek jednotlivých záznamů v katalogu je uveden v popisu tohoto balíčku. Tok událostí: Basic Path Upravení záznamu v katalogu 1. Případ užití začíná, když chce lékař upravit některý ze záznamů v katalogu. 2. INCLUDE ( Vybrat katalog ) 3. Systém požádá lékaře o výběr záznamu z katalogu, který chce upravovat. 4. INCLUDE ( Zobrazit položky katalogu). 5. Systém zobrazí formulář umožňující upravit veškeré položky u vybraného záznamu. 6. Lékař upraví požadované údaje. 7. Systém uloží do záznamu všechny změny provedené lékařem. Exception Zrušení provedených úprav Lékař může veškeré provedené změny odvolat stisknutím tlačítka Storno.
Doporučuji nepoužívat uživatelské role ve scénařích Upravit záznam Umožňuje upravit jednotlivé položky u vybraného záznamu v katalogu. Seznam položek jednotlivých záznamů v katalogu je uveden v popisu tohoto balíčku. Tok událostí: Basic Path Upravení záznamu v katalogu 1. Případ užití začíná, když chce uživatel upravit některý ze záznamů v katalogu. 2. INCLUDE ( Vybrat katalog ) 3. Systém požádá uživatele o výběr záznamu z katalogu, který chce upravovat. 4. INCLUDE ( Zobrazit položky katalogu). 5. Systém zobrazí formulář umožňující upravit veškeré položky u vybraného záznamu. 6. Uživatel upraví požadované údaje. 7. Systém uloží do záznamu všechny změny provedené lékařem. Alternate Zrušení provedených úprav Uživatel může veškeré provedené změny odvolat stisknutím tlačítka Storno.
Doporučuji systémové role spíše nepoužívat, protože případ užití může být později přidělen k jiné uživatelské roli nebo více různým uživatelským rolím. Další možností je použití systémových rolí.
Postup tvorby use case 1.
2. 3.
4.
5.
6.
Nalezení a vodné pojmenovaní hlavních use case (pojmenování slovesnou vazbou!) Stručný popis jednotlivých UC. Stačí pár vět. (Prvotní odhad složitosti realizace UC. Pro potřebu odhadu rozpočtu.) U netriviálních UC napsání prvotních scénářů (přehledově) „Refactoring“ use case- odvození pomocných use case Přepracování a zjemnění scénářů 1. 2.
Nejprve píšeme hlavní toky Pak doplňujeme alternativní (viz dále)
Specifikace Use Case dle Arlowa Use case: PaySalesTax
use case name use case identifier
ID: 1
brief description
Brief description: Pay Sales Tax to the Tax Authority at the end of the business quarter.
the actors involved in the use case
Primary actors: Time Secondary actors: TaxAuthority
the system state before the use case can begin
Preconditions: 1. It is the end of the business quarter.
the actual steps of the use case
1. The use case starts when it is the end of the business quarter. 2. The system determines the amount of Sales Tax owed to the Tax Authority. 3. The system sends an electronic payment to the Tax Authority. Postconditions: 1. The Tax Authority receives the correct amount of Sales Tax.
the system state when the use case has finished alternative flows
Main flow:
Alternative flows: None.
implicit time actor
17
Pre a postconditions dle Arlowa
Place Order
Preconditions obsahují stav systému před spuštěním UC (co musí platit, aby šel UC spustit) Postconditions obsahují stav systému po spuštění UC (efekt UC)
Preconditions: 1. A valid user has logged on to the system
Nutné?
Postconditions: 1. The order has been marked confirmed and is saved by the system 18
Hlavní scénář (Happy scenario) dle Arlowa
<číslo>
Posloupnost akcí Vždy začíná akcí aktéra
Dle M. Komárka není vždy nutné, protože akce začíná většinou rozhodnutím aktéra akci spustit.
Např: 1) Use Case začíná když
Odpovídá situaci, kdy vše jde bez problémů a aktér dosáhne svého cíle Alternativy je možné vyjádřit větvením nebo alternativními scénáři 19
Větvení pomocí If Use case: ManageBasket ID: 2 Brief description: The Customer changes the quantity of an item in the basket. Primary actors: Customer Secondary actors: None. Preconditions: 1. The shopping basket contents are visible. Main flow: 1. The use case starts when the Customer selects an item in the basket. 2. If the Customer selects "delete item" 2.1 The system removes the item from the basket. 3. If the Customer types in a new quantity 3.1 The system updates the quantity of the item in the basket. Postconditions: None. Alternative flows: None.
20
Opakování pomocí For Use case: FindProduct ID: 3 Brief description: The system finds some products based on Customer search criteria and displays them to the Customer. Actors: Customer Preconditions: None. Main flow: 1. The use case starts when the Customer selects "find product". 2. The system asks the Customer for search criteria. 3. The Customer enters the requested criteria. 4. The system searches for products that match the Customer's criteria. 5. If the system finds some matching products then 5.1 For each product found 5.1.1. The system displays a thumbnail sketch of the product. 5.1.2. The system displays a summary of the product details. 5.1.3. The system displays the product price. 6. Else 6.1. The system tells the Customer that no matching products could be found.
Postconditions: None. Alternative flows: None.
Alternativní scénáře
Alternativní scénaře odpovídají chybám, vyímkám v hlavním scénaři
Use case
Teoreticky může existovat veliká řada alternativních scénářů
Vyber jen ty nejdůležitější Pro skupinu analogických vyber je jednu alternativu
alternative flows
main flow
22
Odkazovat na alter. scénáře Use case: CreateNewCustomerAccount ID: 5 Brief description: The system creates a new account for the Customer. Primary actors: Customer Secondary actors: None. Preconditions: None. Main flow: 1. The use case begins when the Customer selects "create new customer account". 2. While the Customer details are invalid 2.1. The system asks the Customer to enter his or her details comprising email address, password and password again for confirmation. 2.2 The system validates the Customer details. 3. The system creates a new account for the Customer.
Postconditions: 1. A new account has been created for the Customer.
alterna tive flows
Alternative flows: InvalidEmailAddress InvalidPassword Cancel
Alternativní scénář Alternative flow: CreateNewCustomerAccount:InvalidEmailAddress
ID: 5.1 Brief description: The system informs the Customer that they have entered an invalid email address. Primary actors: Customer Secondary actors: None. Preconditions: 1. The Customer has entered an invalid email address
Alternativní tok začíná v nějakém kroku hlavního scénáře
Alternative flow: 1. The alternative flow begins after step 2.2. of the main 2. flow. The system informs the Customer that he or she entered an invalid email address. Postconditions: None.
Alternativní tok může nastat místo hlavního toku Alternativní tok může nastat za jistým krokem hlavního scénaře Alternativní tok může nastat kdykoliv během hlavního toku 24
Vztahy mezi případy použití
<<extend>> - pokud nějaký případ rozšiřuje chování (je zde možnost volby)
<> - pokud jeden případ zahrnuje případ jiný (např. přepočet ceny prodávaného zboží po změně kurzu EURO) - „vytknutí části scénáře před závorku“
ud Katalogy IS pro praktické lékaře
Přidat nov ý záznam do katalogu
«include» Uprav it záznam «include» Lékař (from IS pro praktické lékaře)
«include»
Zobrazit záznamy v katalogu «include»
«include»
Odstranit záznam z katalogu
Vybrat katalog
ud Správa dekurzu vyúčtování IS pro praktické lékaře
Upravit záznam o průběhu návštěvy
Přidat frázi pro dekurz
«extend» ( upravit záznam )
Lékař
«include»
(from IS pro praktické lékaře) «extend» ( upravit záznam )
«extend» ( upravit záznam )
Zobrazit fráze pro dekurz
«extend» ( upravit záznam ) (from Správa frází k dekurzu)
Přidat záznam o vydání ZP
Přidat záznam o provedeném výkonu
«include»
«include»
Přidat záznam o diagnóze
«include»
Prohlížet číselník
(from Modul správa číselníků)
Include versus extend
Příklad na tabuli na použití vazeb v balíčku Správa zákazníků
Případy použití – nejčastější chyby
Model zachycuje navigaci v systému.
Model obsahuje aktéra Systém místo aktéra Čas.
Nesprávně používaný směr vazeb <> a <<extend>>.
Případy použití – nejčastější chyby
Model zachycuje navigaci v systému.
Model obsahuje aktéra Systém místo aktéra Čas.
Nesprávně používaný směr vazeb <> a <<extend>>.
Matice požadavků a UC
Sledovatelnost / Tracebility požadavků. Ukázka v EA.
7 důvodů proč modelovat UC Dle Ilji Kravala. Články 57 až 60 na http://www.objects.cz/clanky/clanky.php 1. Velmi vhodné zadání algoritmů chodu aplikace již z analýzy až do programování 2. Výrazné zamezení efektu bobtnání projektu
3. Možné odhady pracnosti na projektu a jeho řízení 4. Efektivnější a snadnější tvorba uživatelské dokumentace 5. Vynikající podklady pro funkcionální testování 6. Podklady pro marketingové materiály a obchodní prezentace 7. Efektivní tvorba dokumentu funkční specifikace produktu jako přílohy smlouvy mezi odběratelem a dodavatelem SW
