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

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

Osnova Základní principy tvorby SW Fáze tvorby SW v předmětu UOMO Analýza požadavků Modelování typových úloh 2006 UOMO 54

Tvorba SW Dříve umění vyvolených dnes podnikatelské průmyslové odvětví Nezahrnuje pouze programování SW krize nedodržené časové harmonogramy, překročené rozpočty, nesplnění požadavků, nedokončené projekty, vývoj není řízen (nebo jen omezeně) neexistují (nebo se nedodržují) systematické, zavedené (praxí ověřené) postupy SW krize ústí do zavádění různých pravidel a principů a vytváření metodických postupů tvorby SW -> vzniká obor tzv. softwarové inženýrství 2006 UOMO 55

Objektový vývoj SW Objektový přístup (způsob myšlení, uchopení problému) se prolíná do celé řady postupů (metod) využívaných při vývoji SW Ucelený souhrn metod pokrývající celý proces vývoje SW se označuje jako metodika V předmětu UOMO se využívá výběr základních principů a postupů metodiky UP (Unified Process) 2006 UOMO 56

Postup v předmětu UOMO Založen na postupném zpřesňování a zpodrobňování jednotlivých modelů -> iterativní přístup Fáze 1. Analýza požadavků (externí pohled) use case diagramy 2. Analýza požadavků (interní pohled) Scénáře 3. Analytický model tříd diagramy tříd 4. Analytické objektové interakce sekvenční diagram 5. Návrhový model tříd - diagramy tříd 6. Zavedení prezentační logiky diagram balíčků; diagram tříd 7. Objektové interakce sekvenční diagram 2006 UOMO 57

Specifikace požadavků na systém Specifikace požadavků zákazníka (SPZ) je první fází návrhu informačního systému SPZ je nástrojem poznání potřeb budoucího uživatele systému Cílem je vymezit systém z hlediska požadavků na funkcionalitu, technologie, bezpečnost atd. SPZ je základ pro veškeré další práce na projektu IS 2006 UOMO 58

Získávání požadavků Základem jsou interview s pověřenými zástupci zadavatele (budoucího uživatele) předem si připravit seznam otázek vše pečlivě poznamenat nedělat výběr nechat si podepsat výsledek jednání Studium podnikových norem zákazníka Studium standardů problémové domény Vlastní zkušenosti projektanta SPZ musí mít ve výsledku podobu formálního (oboustranně schváleného) dokumentu 2006 UOMO 59

Rozdělení požadavků Funkční požadavky definují CO má budoucí systém nabízet uživatelům za služby, jeho chování mohou mít podobu výčtu požadovaných funkcí nebo cílů, kterých chce zadavatel prostřednictvím IS dosáhnout Non-funkční požadavky požadavky na kvalitu (např. rychlost odezvy) požadavky na použité technologie požadavky na organizaci projektu požadavky na formu a obsah dokumentace... 2006 UOMO 60

Modelování non-funkčních požadavků Non-funkční požadavek má podobu pouze katalogového záznamu CASE nástroje umožňují požadavky zaznamenat, dát je do vzájemných vztahů (závislostí) a zobrazit následný způsob jejich realizace 2006 UOMO 61

Modelování typových úloh ang. Use Case Modeling Je základním nástrojem specifikace funkčních požadavků Smyslem je popis základní funkcionality požadovaného (nového) informačního systému Navazuje na poznání firemního prostředí (BPM) a definuje na jeho základě požadavky na nový informační systém 2006 UOMO 62

Modelování typových úloh Modelování je založeno na pojmu Use Case (česky typová úloha, někdy výstižněji případ užití ) V roce 1994 Ivar Jacobson popsal typovou úlohu jako:...provázané sekvence interakcí, dovolující uživateli vést s IS dialog. Typové úlohy jsou předem definované scénáře, které popisují způsob interakce (komunikace) uživatele se systémem. Definují k čemu uživatel systém používá Slouží jako komunikační nástroj se zákazníkem nebo uživatelem 2006 UOMO 63

Modely typových úloh V souladu s filosofií vnějšího a vnitřního pohledu na systém můžeme rozlišit Externí model - popisuje IS z pohledu relevantního okolí, tedy z pohledu aktéra a základním konstruktem je typová úloha Interní model - popisuje vnitřní stavbu typové úlohy, která je neviditelná pro aktéra. Jejím základním konstruktem je třída objektů Model typových úloh neslouží k zachycení každého detailu jak bude systém fungovat ale ke zkoumání a vymezení co by měl systém dělat. Ke grafickému vyjádření externího modelu se používá Diagram typových úloh 2006 UOMO 64

Diagram typových úloh ang. Use Case Diagram (UCD) speciální typ diagramu tříd omezený na elementy aktéra a typovou úlohu je externím modelem typových úloh popisuje (znázorňuje) služby systému (typové úlohy) a jejich vzájemné vztahy vyjadřuje provázanost (interakci) typových úloh s aktérem jaké služby aktér využívá 2006 UOMO 65

Příklad diagramu typových úloh Výběr hotov osti Klient banky Zadání trv alého příkazu «include» «include» «extend» Ověření identifkačních údaj ů aktéra Pracovník banky «include» «include» Zadání příkazu k úhradě «extend» Zrušení bankov ního účtu 2006 UOMO 66

Aktér typové úlohy Aktér Reprezentuje určitou roli, ve které vystupuje uživatel, tedy někdo kdo komunikuje se systémem. Aktér je vlastně zákazník, kterému IS poskytuje služby. Aktér je relevantní zástupce okolí, který určuje smysl existence IS. Aktér je třída uživatelů (zákazník, ředitel, kuchař), daný uživatel je konkrétní výskyt (pan Novák, paní Krátká) > aktér není konkrétní osoba. Jedna (konkrétní) osoba může zastávat několik rolí tj. vystupovat jako několik aktérů Aktérem může být člověk, jiný systém, nebo čas Aktér stojí mimo kontrolu systému 2006 UOMO 67

Co nás na aktérech zajímá? Aktér stojí mimo modelovaný systém a sám o sobě není předmětem modelování*, stejně tak jako komunikace mezi aktéry. Pro účely modelování požadavků však může být důležité následující: Jak často aktér resp. uživatel v dané roli systém využívá? Jaký je počet uživatelů v dané roli? Jaký je případně celkový počet uživatelů nebo jaký počet bude využívat systém v určitém období? Jaký je počet současně pracujících uživatelů v dané roli? atd. Jaké je postavení takového aktéra resp. jakou důležitost má daná role pro využívání systému? Jaká jsou případná omezení daného aktéra? *Určitým způsobem se ale v dalších modelech objeví 2006 UOMO 68

Typová úloha Use Case (Type) Představuje základní funkční jednotku aplikace Je to způsob užití systému tj. popisuje k čemu bude uživatel IS používat. Je to vlastně cíl uživatele, kterého chce dosáhnout prostřednictvím IS (např. zadat objednávku, nebo dát příkaz k úhradě,...) Typová úloha musí přinášet určitou měřitelnou hodnotu pro konkrétního uživatele (aktéra) Výbě r hotov osti 2006 UOMO 69

Typová úloha Popisuje požadované chování z hlediska uživatele Typová úloha je charakterizována: sekvencí transakcí/dialogů aktéra se systémem je vždy iniciována aktérem vyjadřuje co, (ne jak - technologicky) systém nabídne aktérovi je provázána s firemními procesy. Typové úlohy mohou mít vztahy i mezi sebou. Typové úlohy slouží jako komunikační nástroj vývojářů s uživateli budoucího systému Popis všech modelovaných typových úloh tedy musí nakonec zahrnovat veškerou požadovanou funkcionalitu budoucího IS. 2006 UOMO 70