Požadavky Modelování případů užití

Podobné dokumenty
OOT Objektově orientované technologie

OOT Objektově orientované technologie

Use case - management skladu

Nemocnice. Prvotní analýza a plán projektu

7.2 Model použití (jednání) (Use Case)

Systémová analýza a návrh. Zbyněk Ungermann, UNG května 2011

Požadavky Pokročilé modelování případů užití

IS Restaurace. Semestrální práce. Tomáš Rumíšek V Brně dne Peter Ševčík

Model případu užití. Martin Komárek

Obsah. Zpracoval:

1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam.

Use Case Model - Complete Report Grouped by Item Kind, Full Descriptions

SYSTÉM PRO DRAŽBU ZNÁMEK

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev

Dealer Extranet 3. Správa objednávek

7.6 Další diagramy UML

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53

PARTSTORE ONLINE NÁKUP NÁHRADNÍCH DÍLŮ CAT

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

7.6 Další diagramy UML

Evidence požadavků uživatelů bytů a nebytových prostor

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007

PRACUJEME S TSRM. Modul Samoobsluha

Analýza Realizace případů užití

Externí Helpdesk Uživatelská příručka. verze 1.00

Inspirace pro seminární práci předmětu Techniky a CASE nástroje vývoje IS

Návod k používání eshopu Iveco

Databázové a informační systémy Informační systém prodejny nábytku. Jakub Kamrla, KAM087

1 Tabulky Příklad 3 Access 2010

Allegro obchodní doklady

Modelování požadavků

Práce s programem MPVaK

METODICKÝ POKYN PŘIDÁNÍ A PŘEHRÁNÍ VIDEA V PREZENTACI

Testování operačního systému Windows Phone 8

INSTITUT PRO TESTOVÁNÍ A CERTIFIKACI, a. s. NÁVOD NA PŘÍSTUP K SEZNAMŮM VYSTAVENÝCH DOKUMENTŮ

Dealer Extranet 3. Cenové nabídky

Program GazSMS návod k použití

OmniTouch 8400 Instant Communications Suite. Uživatelské rozhraní Touchtone (TUI) Hlavní nabídka. Služby zasílání zpráv

CO JE VODAFONE EPOKLADNA?

Profesis KROK ZA KROKEM 2

[XXX-PUB] Návrh uživatelského rozhraní pro ovládací panel v restauracích The PUB

Lekce 01 Úvod do algoritmizace

PŘÍKAZ K ZADÁNÍ SEPA PLATBY V APLIKACI MULTICASH KB

Základy vytěžování dat

A7B36SI2 - Řízení SW projektů. Smart-Fine. Systém evidence parkovacích lístků pomocí chytrých telefonů. Analýza (v. 3)

Testování mobilní aplikace Servis24. Semestrální práce z předmětu A7B39TUR Autor: Peter Šourek sourepet@fel.cvut.cz

Případy užití (use case) Projektování SW systémů

mbank.cz mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera

Principy UML. Clear View Training 2005 v2.2 1

Pokročilé typové úlohy a scénáře 2006 UOMO 71

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná.

Dell Premier. Návod k nakupování a objednávkám

8.2 Používání a tvorba databází

Průvodce registrací domény CZ

Úvod...1 Instalace...1 Popis funkcí...2 Hlavní obrazovka...2 Menu...3 Práce s aplikací - příklad...5

MODUL MUNI ASPI, a. s muni_manual.indd :57:23

Manuál internetového obchodu ContiTrade Services s.r.o. (verze k )

Word Lekce III. a IV.

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu:

Návod Démos24plus verze 2012

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

1. Pro přihlášení k odběru novinek klikněte na tlačítko Registrace nového uživatele.

PŘÍLOHA C Požadavky na Dokumentaci

Jak vyhledávat. Vyhledávače KAPITOLA 3

Prohlížení a editace externích předmětů

Obsah. Začínáme programovat v Ruby on Rails 9. Úvod Vítejte v Ruby 15. O autorovi 9 Poděkování 9

Roční periodická zpráva projektu

ACTIVATE HERE - FAQ. Zakoupením této položky získáte do 60 minut do požadovaného u aktivační klíče k vybranému produktu.

REGISTRACE UŽIVATELE

Knihovna UMPRUM manuál ke knihovnímu katalogu

Prosím mějte na paměti, že z bezpečnostních důvodů byste měli změnit Internetový přístupový kód každých 60 dní.

ČVUT FEL. Testování nemocničního systému Fonsakord

POSTUP OBJEDNÁNÍ JEDNOTLIVÉ ZKOUŠKY 2014

Ing. Martin Komárek Katedra počítačů ČVUT v Praze, FEL. Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

Algoritmizace. 1. Úvod. Algoritmus

2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML

Objednávkový portál DODÁVKY PROVOZNÍHO MATERIÁLU DO TISKÁREN.

Problémové domény a jejich charakteristiky

MS Word pro administrátory projektů Pokročilí

Nápověda pro online objednávkový systém WEBSHOP

Manuál pro implementaci aplikace Na poštu

Evidenční systém pro reklamace Wooky tabletů reklamace.wooky.cz

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová

Návod na práci s katalogem konstrukcí a materiálů Obsah

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií

Program GazSMS návod k použití

Unifikovaný modelovací jazyk UML

FUNKČNÍ KONCEPT WEBOVÉHO ROZHRANÍ PRO ZPRACOVÁNÍ ENTIT

Použití Office 365 na telefonu s Androidem

SQL - trigger, Databázové modelování

Profesis on-line Obrázky v prezentaci byly upraveny pro potřeby prezentace.

Úvod do softwarového inženýrství IUS 2009/2010 p.1/30

Informační systém sportovního klubu

JLR EPC. Rychlý průvodce. Obsah. Czech Version 2.0. Průvodce krok za krokem Průvodce obrazovkami

C. 3. Vytvoření metodiky práce s implementovaným IS včetně jeho naplnění daty relevantních procesů a způsobů jejich vyhodnocování

Diagram případu užití. Use Case Diagram

cyklus s daným počtem opakování cyklus s podmínkou na začátku (cyklus bez udání počtu opakování)

Softwarové inženýrství

Transkript:

Požadavky Modelování případů užití Požadavky část 2 Clear View Training 2005 v2.2 1

4.2 Modelování případů užití Modelování případů užití je jednou z forem inženýrství požadavků Modelování případů užití se skládá z aktivit: Nalezení hranic systému Vyhledání aktérů / účastníků (actors) Nalezení případů užití Specifikace případů užití Určení alternativních scénářů Umožňuje nám poznat hranice systému, kdo nebo co používá systém a jaké funkce by měl systém nabízet Clear View Training 2005 v2.2 2

4.3 Hledání aktérů a případů užití Hledání aktérů a případů užití workflow Obchodní model [nebo model domény] Systémový analytik Model případů užití [náčrt] Model požadavků Najít aktéry a případy užití Seznam vlastností Slovníček pojmů projektu Clear View Training 2005 v2.2 3

4.3.1 Subjekt (Hranice systému) Dříve než začneme tvořit, musíme znát: Kde se nachází hranice systému Kdo nebo co používá systém Jaké funkce by měl systém uživatelům nabízet Vytvářený model případu užití obsahuje: Subjekt je vyjádřen jako rámeček s popiskem obsahujícím název systému také známý jako hranice systému Aktéři kdo nebo co používá systém Případy užití jsou něco, co aktér od systému očekává Relace vazba mezi aktéry a případy užití subjekt NázevSystému Clear View Training 2005 v2.2 4

4.3.2 Co jsou to aktéři? Aktéři / účastníci jsou vyjádřením rolí v kterých bezprostředně používají daný systém Aktér může vyjadřovat roli uživatele, roli dalšího systému, který se dotýká hranic Vašeho systému Aktéři jsou vůči systému externími entitami Aktér specifikuje roli, kterou určitá externí entita přijímá v okamžiku, kdy začíná daný systém používat Zákazník «actor» Zákazník Clear View Training 2005 v2.2 5

4.3.2.1 Označení aktérů Při hledání aktérů se ptejte: Kdo nebo co používá systém? Jakou roli v této interakci hraje? Kdo instaluje systém? Kdo spouští a vypíná systém? Kdo se stará o jeho údržbu? Jaké další systémy spolupracují se systémem? Kdo systému zadává informace a kdo je používá? Děje se něco v určitou dobu? Čas Clear View Training 2005 v2.2 6

4.3.3 Co jsou to případy užití? Případ užití je něco, co aktér od systému očekává. Je to případ užití systému specifickým aktérem. Případy užití jsou vždy iniciovány aktérem Hlavní aktér spouští případ užití Žádný nebo více vedlejších aktérů jsou v interakci s případem užití po jeho spuštění Případy užití jsou vždy napsány z pohledu aktéra Zadat Objednávku ZjistitStav Objednávky Clear View Training 2005 v2.2 7

4.3.3.1 Definice případů užití Nejprve projděte seznam aktérů a zvažte způsob, jímž bude každý z nich systém používat Při určování případů užití se ptejte: Jaké funkce jednotliví aktéři od systému očekávají? Bude systém poskytovat a uchovávat informace? Pokud ano, jací aktéři budou tyto činnosti aktivovat? Jací aktéři budou upozorněni na změnu stavu systému? Existují nějaké vnější události, které ovlivňují systém? Co upozorní systém na tyto události? Reaguje systém na vnější systémy? Generuje systém zprávy? Clear View Training 2005 v2.2 8

4.3.3.2 Diagram případu užití Diagram případu užití Systém objednávek poštou komunikační relace Systém objednávek poštou Zadat Objednávku název subjektu hranice systému Zákazník Stornovat Objednávku OvěřitStav Objednávky Dodat Produkt dopravce aktér Katalog Požadavků případ užití dispečer Clear View Training 2005 v2.2 9

4.3.4 Slovníček pojmů Slovníček pojmů Term1 Term2 Term3 Definice Synonyma Homonyma Definice Synonyma Homonyma Definice Synonyma Homonyma Každé odvětví má vlastní žargon, jazyk, terminologii. Je důležité zachytit jazyk ve slovníčku pojmů daného projektu. Slovníček pojmů musí kromě definice klíčových termínů řešit otázku všech synonym a homonym. Sestavovaný slovníček pojmů by měl sloužit všem, kteří se na projektu určitým způsobem podílejí Clear View Training 2005 v2.2 10

4.4 Detail případu užití model případu užití [náčrt] osoba odpovědná za specifikaci případu užití model požadavků upřesnit případ užití případ užití [podrobný] slovníček pojmů projektu Clear View Training 2005 v2.2 11

4.5 Specifikace případu užití název případu užití jedinečný identifikátor stručný popis aktéři případu užití stav systému před spuštěním případu užití skutečné kroky případu užití implicitní časový aktér stav systému po ukončení případu užití alternativní scénáře ID: 1 Primární aktéři: Čas Případ užití: PlatitDaňZPřidanéHodnoty Stručný popis: Na konci fiskálního čtvrtletí zaplatit daň finančnímu úřadu. Vedlejší aktéři: Finanční úřad Vstupní podmínky: 1.Je konec fiskálního čtvrtletí? Hlavní scénář: 1. 2. 3. Případ užití začíná, je-li konec fiskálního čtvrtletí. Systém zjistí částku, kterou je třeba zaplatit finančnímu úřadu. Systém odešle elektronickou platbu finančnímu úřadu. Výstupní podmínky: 1. Finanční úřad přijímá daň z přidané hodnoty ve správné výši. Alternativní scénáře: Žádné. Implicitní časový aktér Clear View Training 2005 v2.2 12

4.5.5 Vstupní a výstupní podmínky Vstupní a výstupní podmínky jsou omezením Vstupní podmínky omezují stav systému před spuštěním případu užití Výstupní podmínky omezují stav systému po skončení případu užití Pokud případ užití nemá vstupní ani výstupní podmínky, v příslušném oddíle specifikace případu užití bude žádné ZadatObjednávku Vstupní podmínky: 1. Oprávněný uživatel má záznam v systému Výstupní podmínky: 1. Objednávka byla označena, potvrzena a uložena v systému Clear View Training 2005 v2.2 13

4.5.6 Tok událostí Tok událostí popisuje kroky případu užití Hlavní scénář událostí vždy začíná tím, že aktér určitou činností případ užití zahájí Správná cesta pro zahájení toku událostí je: 1) Případ užití začíná, když <aktér> <funkce> Tok událostí se skládá z posloupnosti krátkých kroků, které jsou: Deklarativní Očíslované Řazeny dle časové posloupnosti Hlavní tok je vždy scénář šťastný den nebo dokonalý svět <číslo> <něco> <určitá akce> Všechno jde dle očekávání a požadavků, nejsou žádné chyby, odchylky, přerušení nebo odbočky Alternativa může být uvedena rozvětvením scénáře nebo výpisem Alternativní scénáře (uvidíme později) Clear View Training 2005 v2.2 14

4.5.6.2 Klíčové slovo KDYŽ: If Klíčové slovo KDYŽ (if) slouží k označení nové větve hlavního scénáře Za if následuje boolenovský výraz Tělo příkazu lze vyznačit odsazením a číslováním řádků Užití else udává, co se stane když podmínka není splněna (uvidíme v příštím slide) ID: 2 Hlavní aktéři: Zákazník Případ užití: SprávaKošíku Stručný popis: Zákazník změní počet položek v košíku. Vedlejší aktéři: Žádní. Vstupní podmínky: 1. Obsah nákupního košíku je viditelný. Hlavní scénář: Případ užití začíná po výběru položky v košíku. 1. 2. 3. KDYŽ Zákazník zadá smazat položku 2.1 Systém odstraní položku z košíku KDYŽ Zákazník zadá nové množství 3.1 Systém aktualizuje počet položek v košíku Výstupní podmínky: Žádné. Alternativní scénáře: Žádné. Clear View Training 2005 v2.2 15

4.5.6.4 Klíčové slovo: For Můžete použít klíčové slovo For pro označení začátku opakování scénáře Všechny řádky za příkazem For se opakují tolikrát, kolikrát je to uvedeno v iteračním výrazu. ID: 3 Případ užití: NajdiProdukt Stručný popis: Systém najde výrobky podle podmínek zadaných Zákazníkem a zobrazí je Zákazníkovi. Hlavní aktéři: Zákazník Vstupní podmínky: Žádné Hlavní scénář 1. Případ užití začíná, až Zákazník vybere najít produkt". 2. Systém požádá Zákazníka o vyhledávací podmínky. 3. Zákazník zadá požadovaná kritéria. 4. Systém vyhledá produkty odpovídající zadaným podmínkám. 5. (If) Pokud systém najde odpovídající produkty, pak: 5.1 (For) Pro každý nalezený produkt: 5.1.1. Systém zobrazí miniaturu produktu. 5.1.2. Systém zobrazí stručné informace o produktu. 5.1.3. Systém zobrazí cenu produktu. 6. (Else) Jinak 6.1. Systém sdělí zákazníkovi, že zadaným podmínkám neodpovídá žádný produkt. Výstupní podmínky: Žádné. Alternativní scénáře: Žádné. Clear View Training 2005 v2.2 16

4.5.6.5 Klíčové slovo: While Klíčovým slovem while označujeme něco, co se opakuje tak dlouho, dokud Booleanovská podmínka není splněna ID: 3 Případ užití: NajdiProdukt Stručný popis: Systém najde výrobky podle podmínek zadaných Zákazníkem a zobrazí je Zákazníkovi. Hlavní aktéři: Zákazník Vstupní podmínky: Žádné Hlavní scénář 1. Případ užití začíná, až Zákazník vybere najít produkt". 2. Systém požádá Zákazníka o vyhledávací podmínky. 3. Zákazník zadá požadovaná kritéria. 4. Systém vyhledá produkty odpovídající zadaným podmínkám. 5. (If) Pokud systém najde odpovídající produkty, pak: 5.1 (For) Pro každý nalezený produkt: 5.1.1. Systém zobrazí miniaturu produktu. 5.1.2. Systém zobrazí stručné informace o produktu. 5.1.3. Systém zobrazí cenu produktu. 6. (Else) Jinak 6.1. Systém sdělí zákazníkovi, že zadaným podmínkám neodpovídá žádný produkt. Výstupní podmínky: Žádné. Alternativní scénáře: Žádné. Clear View Training 2005 v2.2 17

4.5.7 Větvení: Alternativní scénáře Specifikace případů užití může obsahovat jeden nebo více alternativních scénářů : Alternativní scénáře vedou k zachycení chyb, větvení a přerušení hlavního scénáře Alternativní scénáře se obvykle nevracejí zpět k hlavnímu scénáři Případy užití mohou mít mnoho alternativních scénářů! Potřebujete zvládnout toto: Vyberte nejdůležitější alternativní scénáře a dokumentujte je. Tam, kde existují skupiny podobných vedlejších scénářů, dokumentujte jeden člen skupiny jako příklad a doplňte ho o poznámky upřesňující, čím se liší od ostatních členů skupiny. případ užití alternativní scénáře hlavní scénář Dokumentujte nejdůležitější alternativní scénáře! Clear View Training 2005 v2.2 18

4.5.7 Modelování alternativních scénářů Alternativní scénáře můžete připojit na konec případu užití Alternativní scénáře lze najít zkoumáním hlavního scénáře, v němž budete hledat: alternativy chyby přerušení alternativní scénáře ID: 5 Hlavní scénář: Případ užití: VytvořitNovýÚčetZákazníka Stručný popis: Systém vytvoří nový účet zákazníka. Hlavní aktéři: Zákazník Vedlejší aktéři: Žádní. Vstupní podmínky: Žádné. 1. 2. Případ je Zákazníkem spuštěn příkazem vytvořit nový účet zákazníka". Dokud jsou údaje Zákazníka neplatné: 2.1. 2.2 3. Systém vytvoří nový účet Zákazníka. Výstupní podmínky: 1. Pro Zákazníka byl vytvořen nový účet. Alternativní scénáře: NeplatnáAdresa NeplatnéHeslo Storno Systém žádá Zákazníka, aby zadal všechny údaje včetně e-mailové adresy, hesla a potvrzení hesla. Systém ověří údaje Zákazníka. Clear View Training 2005 v2.2 19

4.5.7 Příklad alternativního scénáře Upozornit, jak jsme pojmenovali a očíslovali alternativní scénáře Vždy ukázat začátek alternativního scénáře. V tomto případě začíná krokem 2.2 v hlavního scénáře Alternativní scénář: VytvořitNovýÚčetZákazníka:NeplatnáAdresa ID: 5.1 Stručný popis: Systém informuje zákazníka, že zadal neplatnou e-mailovou adresu Hlavní aktéři: Zákazník Vedlejší aktéři: Žádní. Vstupní podmínky: 1. Zákazník zadal neplatnou e-mailovou adresu Alternativní scénář: 1. Alternativní scénář začíná krokem 2.2. hlavního scénáře. 2. Systém informuje Zákazníka, že zadal neplatnou e-mailovou adresu. Výstupní podmínky: Žádné. Alternativní scénář lze spustit místo hlavního scénáře spustil jej hlavní aktér Alternativní scénář lze spustit po určeném kroku hlavního scénáře - after Alternativní scénář lze spustit kdykoli během vykonávání hlavního scénáře - at any time Clear View Training 2005 v2.2 20

4.6 Sledování požadavků Sledování požadavků propojuje požadavky ve specifikaci systémových požadavků s modelem případu užití Sledování funkčních požadavků k případům užití komplikuje skutečnost, že mezi jednotlivými funkčními požadavky existuje příliš mnoho relací: Jeden případ užití bude pokrývat mnoho jednotlivých funkčních požadavků Jeden funkční požadavek může být vyjádřen v mnoha případech užití Při sledování požadavků se můžeme opřít o nástroj CASE: Pomocí označených hodnot můžeme přiřadit ke každému případu užití seznam identifikátorů požadavků Můžeme propojit jednotlivé požadavky uložené v databázi požadavků se specifickými případy užití a naopak Pokud nepoužíváme žádný nástroj CASE, můžeme vytvořit matici sledovatelnosti požadavků Requirements R1 R2 R3 R4 R5 Use cases U1 U2 U3 U4 Matice sledovatelnosti požadavků Clear View Training 2005 v2.2 21

4.7 Kdy modelovat případy užití Případy užití popisují funkci systému z pohledu jednoho nebo více aktérů. Jsou vhodné v případech: V systémech, v nichž převládají funkční požadavky V systémech s mnoha typy uživatelů, kterým systém poskytuje různé funkce (systém má mnoho aktérů) V systémech s mnoha rozhraními (systém má mnoho aktérů) Případy užití zachycují funkční požadavky. Nejsou vhodné v případě, že: V systému převládají nefunkční požadavky Systém má málo uživatelů Systém má málo rozhraní Clear View Training 2005 v2.2 22

Shrnutí Věnovali jsme se zachycení systémových požadavků modelováním případů užití. Podívali jsme se na: Případy užití Aktéry Větvení pomocí if (KDYŽ) Opakování pomocí for and while Alternativní scénáře Sledování požadavků Clear View Training 2005 v2.2 23