Analýza. Analýza. Datový model. Dynamický model

Transkript

1 Analýza CO má systém umt Analýza Mla by odpovdt na otázku CO? Musí proto definovat konceptuální model ešeného systému Musí stanovit pedstavu, s jakými daty bude systém pracovat, jaké služby bude systém poskytovat a jak se bude chování systému mnit - jaká bude dynamika systému Musí stanovit podmínky, za jakých je analytická dokumentace akceptovatelná 1 2 Analytický (konceptuální)) model (konceptuální) funkní model Systém má poskytovat njaké služby. V úvodní studii jsme se orientan dohodli, jaké to služby budou, te je teba to íci pesn. (konceptuální) datový model Aby bylo možno služby poskytovat, je poteba pracovat s daty. V úvodní studii jsme se orientan dohodli, jaké to služby budou, te je teba to íci pesn. (konceptuální) dynamický model Systém, nebo jeho prvky asto vykazují dynamiku jejich chování se mní na základ rzných okolností. Te je teba íci pesn jak. Datový model notace konceptuální model tíd nebo ER-model (diagramy + textový popis) další integritní omezení, která nejsou zachycena v diagramech datový slovník 3 4 Funkní model notace model jednání (seznam událostí, píp. scénáe) pokud scéná obsahuje složitjší aktivity, pak dekompozice tchto aktivit na popisy jednodušší mohou to být podrobnjší scénáe, diagramy aktivit, hierarchická sada diagram datových tok (DFD - kontextový diagram + diagramy úrovn 0,1, + popis) minispecifikace elementárních operací datový slovník Dynamický model notace scénáe životních cykl stavové diagramy datový slovník 5 6

2 Postup pi analýze I. Vstup: úvodní studie Výstup: analytická dokumentace Postup: paraleln zpracuj koncept a projekt Postup pi analýze II. Zpracování konceptu: Vstup: deklarace zámru, odbornýlánek, seznam aktér, seznam událostí, kontext, 1.verze datového slovníku (z úvodní studie) Výstup: konceptuální analytický model (datový, funkní a dynamický model, 2.verze datového slovníku) 7 8 Postup pi analýze III. Zpracování projektu: Vstup: seznam úloh, harmonogram (z úvodní studie) Výstup: projektová dokumentace (projektový deník, seznam zdroj, matice zodpovdností, harmonogram, plán test, akceptaní test) Funkn orientovaná analýza Zaínáme seznamem funkcí (modelem jednání) Scénáe jednání (pvodce, událost, akce, participanti, výstupy - reakce), diagramy aktivit, píp. diagramy datových tok (návaznosti funkcí) Popis akcí (minispecifikace základních akcí) Identifikace objekt Identifikace vztah mezi objekty Modelování životních cykl objekt 9 10 Model jednání ECO-skladu Funkní model Diagram pípad užití je pouhá evidence služeb, ty musí být popsány pesnji. Striktneeno - model jednání obsahuje diagram pípad užití a jejich popis

3 Jak lze služby evidované v modelu jednání popsat? Textovým popisem (to je podmínka nutná, nikoli postaující). Minispecifikací (strukturovaným popisem operace) Dekompozicí na služby jednodušší pomocí scénáe pomocí diagramu aktivity pomocí diagramu komunikace pomocí stavového diagramu pomocí diagramu datových tok (DFD) Zákazník prohlíží katalog a vybere si zboží k nákupu 2. Zákazník zvolí nákup 3. Zákazník vyplní dodací informace (adresa, expresní nebo standardní dodávka) 4. Systém zobrazí plnou cenu vetn ceny dodání 5. Zákazník vyplní platební informace (íslo kreditní karty) 6. Systém autorizuje platbu 7. Systém potvrdí prodej 8. Systém zašle potvrzovací zákazníkovi Alternativy: 3a. Uživatel je pravidelným zákazníkem 3a1. Systém zobrazí naposled zapamatované dodací a platební informace 3a2. Uživatel mže potvrdit, nebo zmnit zobrazené informace a scéná pokrauje v kroku 6 6a. Systému se nepovedlo autorizovat platbu 6a1. Zákazník mže opravit platební informace, nebo zrušit nákup Základní princip scénáe Systém bude realizován jako soubor komunikujících objekt V konceptu nejprve pouze volíme metodu sd Piv olání výtahu Pasažér EA 5.1 Unregistered Trial Version EA Panel_v 5.1 Unregistered _pate Trial Version {není v posledním pate } [chce jet nahoru]: nahoru() Pozdji mžm žeme popsat innost podrobnji, využít konstrukce a destrukce EA 5.1 Unregistered Trial Ver sd Pivolání v ýtahu Plánova EA 5.1 Unregistered Trial Ver EA 5.1 Unregistered Trial Version Panel_v_pate EA 5.1 Unregistered Trial Version EA 5.1 Unregistered Trial Ver {není v posledním pate } Pasažér [chce jet nahoru]: nahoru() EA 5.1 Unregistered Trial Ver create Požadavek_na_pivolání EA 5.1 Unregistered Trial Ver bool= registrace(požadavak) EA 5.1 Unregistered Trial Ver EA 5.1 Unregistered Trial Ver zruš 17 18

4 Reakce a návratovn vratové hodnoty Scéná pro pejímku EA 5.1 Unregistered Trial Version sd Pivolání v ýtahu Plánova EA 5.1 Unregistered Trial Version Pasažér EA 5.1 Unregistered Trial Panel_v_pate Version [chce jet nahoru]: nahoru() EA 5.1 Unregistered {není v posledním pate Trial } Version Požadavek_na_pivolání Seznam_požadavk EA 5.1 Unregistered Trial Version EA 5.1 Unregistered bool= registrace(požadavak) Trial Version EA 5.1 Unregistered Trial Version bool= indikace(smr) EA 5.1 Unregistered Trial Version indikace create EA 5.1 Unregistered Trial Version Po uspokojení požadavku jej EA 5.1 Unregistered Trial Version zruš plánova zruší. EA 5.1 Unregistered Trial Version Scéná je pouze dekompozice, jeho složky musí být popsány pesnji scéná, dekompozice, minispecifikace Popis akce (operace, funkce) Operation: název Description: textový popis Reads: jaká data jente Changes: jaká data mní nebo vytváí Sends: jaké reakce vyvolává (jaké zprávy posílá) Assumes: co pedpokládá Results: co zajišuje (zaruuje) Popis pro prázdná plošina ina Operation: prázdná plošina Description: informuje systém, že nakládací plošina je prázdná Reads: Changes: plošina Sends: Assumes: Results: vyprázdní v modelu nakládací plošinu uvolní identifikátory barel, které jsou na plošin Popis pro dodací list Popis pro barel k zaazen azení Operation: dodací list Description: zahájí pejímku a uloží informace z dodacího listu Reads: supplied dodací_list Changes: zadaný_dodací_list Sends: Assumes: Results: vnitní objekt zadaný_dodací_list je inicializován hodnotami z fyzického dodacího_listu 23 Operation: barel k zaazení Description: každý vyložený barel je jednoznan identifikován Reads: supplied typ_chemikálie Changes: plošina, new b: Barel Sends: operátor:{id barelu} Assumes: Results: nakládací plošina obsahuje barel b operátor dostane identifikaci ID barelu atribut b.typ je nastaven na typ_chemikálie atribut b.id je nastaven na identifikaci ID barelu 24

5 Popis pro konec pejímky Operation: konec pejímky Description: informuje systém, že již byly vyloženy všechny barely Reads: plošina, zadaný_dodací_list Changes: budovy ve skladu Sends: operátor:{rozdíly v pejímce, nelze uložit}, skladník:{píkaz pro skladníka} Assumes: sklad je bezpený Popis pro konec pejímky (pokr.) Results: pro všechny barely, které lze do skladu umístit, pesune v modelu jejich umístní do vhodné budovy a vytvoí príkaz pro skladníka(kam: alokaní seznam) pokud existují rozdíly mezi zadaným_dodacím_listem a skutenou dodávkou, vytvoí se rozdíly v pejímce(navíc, chybí: seznam barel) pro všechny barely, které nelze do skladu umístit vytvoí nelze uložit(co: seznam barel) sklad je bezpený Diagramy datových tok (DFD Data Flow Diagrams) (zachycení vazeb funkcí a tok dat, dokumentace dekompozice) Notace DFD (Yourdon) Komponenty: funkce (procesy, akce) datové toky (data flows) - orientované hrany vyznaující toky dat datové pamti (data stores) - místa, kde si potebujeme nco pamatovat aktéi (terminátory) - uživatelské role nebo spolupracující systémy Kontextový diagram pro Výtah DFD pro výtah (úrove 0) (urení hranice systému) SPINAC PATRA PASAZER stisk tlacitka signalizace spinace patra indikace System pro rizeni vytahu signalizace pretizeni SENZOR PRETIZENI tlacitko ON/OFF ridici povel OPERATOR RIZENI MOTORU 29 30

6 DFD v UML diagram aktivity Popis diagramem aktivity ad DFD_jako_aktivita Požadavek EA 5.1 Unregistered Trial Version EA 5.1 Unregistered požadavek Trial Version Registrace požadavk «object system» Seznam požadavk Plánova «use» «artifact» Nesplené požadavky Stisk tlaítka pro pivolání výtahu ekání na píjezd výtahu píjezd a otevení výtahu Nástup do výtahové klece Došlo k petížení klece? Popis pípadu použití, kdy pasažér pivolává výtah Výstup z klece klec se peplnila Datov orientovaná analýza Seznam událostí, kontext, datový slovník Identifikace dat, která s událostmi souvisí (identifikace základních objekt) Identifikace vztah mezi objekty Scénáe jednání (pvodce, událost, akce, participanti, výstupy - reakce) Modelování životních cykl objekt Popis akcí (minispecifikace základních akcí) Datový model Datový model (konceptu( konceptuální) (zachycení analýzy dat) Komponenty: typy objekt (entity) - entita = rozlišitelný identifikovatelný objekt vztahy (relationships) - množiny instancí reprezentujících vztahy mezi (2 a více) objekty indikace pidružených objekt - pro vztahy o nichž si potebujeme nco pamatovat indikace vztah nadtyp-podtyp, celek-ást (gen-spec, wholepart) - vyjádení vztahu spolený - speciální (ddinost) Datov orientovaná analýza Vychází z pedstavy, že základem IS jsou data. Služby IS slouží pro poízení a exploraci dat. Doporuuje proto nejprve analyzovat požadavky a definovat konceptuální datový model ešeného systému. Konceptuální datový model musí postihovat data picházející pes hranici systému jako vstupní data související s událostmi, dále data, která se v systému ukládají a nakonec rovnž data, která systém produkuje na výstupu. Teprve pozdji doplníme model o dalšíásti

7 Postup datovd atov orient. analýzy 1. Seznam událostí, kontext, datový slovník 2. Identifikace dat, která s událostí souvisí (základních objekt) 3. Identifikace vztah mezi objekty 4. Scénáe jednání (pvodce, událost, akce, participanti, výstupy - reakce) 5. Modelování životních cykl objekt 6. Popis akcí (minispecifikace základních akcí) Jak hledat data? Doporuení.1: Analyzujeme odborný lánek, vybereme všechna podstatná jména. Roztídíme je do skupin: kandidáti na typy objekt (entity), kandidáti na vlastnosti objekt (atributy), ostatní (kandidáti na aktéry, smetí) Píklad: Odborný lánek pro Výtah Systém Výtah slouží pro logickéízení obsluhy výtahu s jednou i více šachtami (pedpokládají se 4 šachty a 40 úrovní). Systém zajišuje efektivní plánování sbru a odvozu pasažér mezi obsluhovanými patry podle požadavk (požadavek na pivolání výtahu pro jízdu smrem nahoru nebo dol, požadavek na dopravení do uritého patra). Smr jízdy se nemní, dokud výtah nesplní objednávky v daném smru (výtah neví o pasažérech neexistuje indikace prázdnosti klece). Peplnný výtah nereaguje na výzvy (existuje indikace petížení). Pro každou šachtu existuje samostatný motor ovládaný signály (povely UP, DOWN a STOP). Povel STOP zpsobí zastavení výtahu v nejbližším pate v daném smru a otevení dveí výtahu (dvee se dají otevít až v pate). Uvnit klece je panel s tlaítky pater, indikace aktuální polohy a tlaítko STOP. Tlaítko STOP zabrání zavení dveí (jde mimo systém). Rovnž otevírání a zavírání dveí jde mimo systém (kvli bezpenosti). Píkazy pro systém jsou akceptovány až po zavení dveí. Operátor výtahu má k dispozici tlaítko ON/OFF, kterým zadává požadavek na zastavení pohybu výtah. 39 Zpracovaný lánek systém Výtah logickéízení šachta úrove pasažér patro požadavek požadavek na pivolání výtahu pro jízdu smrem nahoru požadavek na pivolání výtahu pro jízdu smrem dol požadavek na dopravení do patra smr jízdy objednávka indikace prázdnosti klece výzva indikace petížení motor signál povel UP povel DOWN povel STOP dvee výtahu klec panel s tlaítky pater indikace aktuální polohy tlaítko STOP píkaz pro systém operátor výtahu tlaítko ON/OFF požadavek na zastavení pohybu 40 Kandidáti na aktéry pasažér indikace petížení motor indikace aktuální polohy (patra) tlaítko STOP operátor výtahu tlaítko ON/OFF Kandidáti na typy dat šachta (atribut klece) úrove alias patro požadavek alias objednávka alias píkaz pro systém alias výzva požadavek na pivolání výtahu pro jízdu smrem nahoru požadavek na pivolání výtahu pro jízdu smrem dol požadavek na dopravení do patra smr jízdy (atribut) indikace prázdnosti klece (neexistuje) indikace petížení signál alias povel (pro motor) povel UP povel DOWN povel STOP klec panel s tlaítky pater indikace aktuální polohy tlaítko STOP (jde mimo systém) tlaítko ON/OFF alias požadavek na zastavení pohybu 41 42

8 Nco diagramem vyjádit nelze V píkladu systému Výtah je to nap.: Tlaítko pro pivolání pro jízdu smrem nahoru na panelu v posledním pate, tj. když patro má hodnotu getpocetpater() neexistuje. Tlaítko pro pivolání pro jízdu smrem dol na panelu v prvním pate neexistuje Jak hledat data? Doporuení.2: Analyzujeme seznam událostí, rozpoznáváme data, která s událostmi souvisí. Roztídíme je do skupin: kandidáti na typy objekt (entity), kandidáti na vlastnosti objekt (atributy). Píklad: Události pro ECO sklad Operátor zahájil pejímku Operátor zahájil dodávku Manažer se ptá na stav skladu Manažer se ptá na bezpenost skladu Scéná pro pejp ejímku Kandidáti na typy dat dodací list barel typ chemikálie rozdíly v pejímce nelze uložit píkaz pro skladníka 47 48

9 Datový model pro ECO-sklad Další postup Z datového modelu se snažíme odvodit funkce: Vytvoíme matici CRUD (Create, Read, Update, Delete) Zkoumáme, zda pro každý typ dat existuje odpovídající funkce Z datového modelu se snažíme odvodit dynamiku: Pro každý typ dat zkoumáme, zda objekty nevykazují zmny stavu Matice CRUD ádky odpovídají typm objekt. Sloupce odpovídají funkcím. V prseíku je zapsáno zda funkce C,R,U a/nebo D odpovídající data. V každém ádku by mlo nkde být vše (nkterá funkce musí objekt vytváet, jiná využívat, i rušit). Matice CRUD pro ECO sklad Prázdná plošina Zadej dodací list Zaa barel Konec pejímky Dodávka Zahájení práce systému ECO sklad Plošina U U U C D Ukonení práce systému ECO sklad Sklad U U C,Get D,Save Monitor U,Print U,Print C D Barel Dodací list C C R,D Píkaz C,Print C,Print Co jsme zjistili? Potebujeme ješt v rámci njaké funkce reprezentaci barelu zrušit. Mohla by to udlat funkce dodávka, nebo po vyskladnní barelu jeho životní cyklus koní. Doplníme tedy do popisu funkce dodávka požadavek pokud v rámci dodávky využijeme nkterý barel, vymažeme jeho reprezentaci z obsahu skladu a zrušíme ji. Do matice CRUD pidáme odpovídající D. Dynamický model 53 54

10 Stavové diagramy Slouží k popisu dynamiky systému Stavový diagram definuje možné stavy, možné pechody mezi stavy, události, které pechody iniciují, podmínky pechod a akce, které s pechody souvisí Stavový diagram lze použít pro popis dynamiky objektu (pokud má rozpoznatelné stavy), pro popis metody (pokud známe algoritmus), i pro popis protokolu (vetn protokolu o styku uživatele se systémem) Životní cyklus skuteného barelu Zaa barel / ID idi vykládá barel na plošinu / zarad_barel Je na plošin neoznaen Je na plošin oznaen Je na plošin oznaen Píkaz / Skladník odváží barel do skladu Je ve skladu Píkaz / Skladník odváží barel na plošinu idi nakládá barel z plošiny / smazat ID Životní cyklus entity barel zarad_barel / ID Je v kontejneru Plošina oznaen Je v kontejneru Sklad konec_prejimky / prikaz pro uskladneni Popis ídicích ch proces pomocí stavových diagram Vstupy ídicího procesu lze modelovat pomocí událostí stavového diagramu. Výstupy ídicího procesu lze modelovat pomocí akcí stavového diagramu. Pak lze ídicí procesy modelovat stavovými diagramy. dodavka / píkaz pro vyskladneni stídav spouštíme P1 a P2 P1 P2 y/a a x b y ídicí proces /a Pracuje P1 Pracuje P2 x/b Životní cyklus systému Vyjádení souhrné dynamiky systému, která je zachycena ve scénáích Definuje povolené návaznosti akcí a reakcí Pedstavuje hrubou uživatelskou píruku pro systém Definice systému jako koneného automatu 59 60

11 Životní cyklus jako regulárn rní výraz <Životní cyklus> = Lifecycle <jméno objektu> : <regulární výraz> <regulární výraz> = <akce> #<reakce> <regulární výraz>. <regulární výraz> sekvence [ <regulární výraz> ] voliteln <regulární výraz>* iterace (<regulární výraz> <regulární výraz>) selekce (<regulární výraz> <regulární výraz>) paraleln <akce> = jméno události <reakce> = jméno reakce Životní cyklus entity barel Lifecycle BAREL: zarad_barel. #ID barelu. #píkaz pro uskladnní. dodávka. #píkaz pro vyskladnní Životní cyklus ECO-skladu Lifecycle ECO-sklad: (dodávka pejímka)* (dotaz na stav je bezpený?)* pejímka = prázdná plošina. dodací list. (barel k zaazení. #ID barelu)*. konec pejímky. [#rozdíly v pejímce]. #píkaz pro skladníka. [#nelze uložit] dodávka = prázdná plošina.požadovaná dodávka. #skutená dodávka. #píkaz pro skladníka dotaz na stav = je bezpený? =... Životní cyklus pro Výtah Lifecycle Výtah: (požadavek)* (ON/OFF)* požadavek = [požadavek na pivolání požadavek na patro] požadavek na pivolání = [ požadavek na jízdu dol požadavek na jízdu nahoru ] požadavek na jízdu dol = tlaítko pro jízdu dol. #indikace požadavek na jízdu nahoru = tlaítko pro jízdu nahoru. #indikace požadavek na patro = tlaítko patra. #indikace Kontroly analytických model Výstup analýzy Konceptuální model: datový model popisuje entity, atributy, vztahy, integritní omezení, funkní model popisuje služby, které systém poskytuje pro záznam, údržbu a využití dat, dynamický model popisuje možné stavy dat a jejich zmny

12 Kontrola výstup analýzy kontrola jednotlivých model (pohled) kontrola vzájemné konzistence model Kontrola datového modelu je datový model úplný? existuje entita pro každý typ objektu? nejsou zde nadbytené entity (entity tvoené pouze identifikací, entity s jedinou instancí, apod.)? jsou zde zaneseny všechny vztahy (vetn generalizací a agregací)? nejsou zde odvoditelné vztahy? je model v normální form? jsou zanesena všechna integritní omezení? Existuje entita pro každý typ objektu? Nadbytené entity entity tvoené pouze identifikací entity s jedinou instancí entity s vazbou typy 1:1 apod. Dobrou technikou je pedstavit si píklady entit a objekt? Normalizace datového modelu Pedpoklad: všechny entity jsou jednoznan identifikovatelné oznaenou kombinací atribut a/nebo vztah 1.normální forma: entity neobsahují násobné atributy ani komponované atributy 2.normální forma (navíc): neklíové atributy závisí pouze na celém klíi 3.normální forma (navíc): neklíové atributy nejsou závislé na neklíových položkách Píklad návrhu n reprezentace dat datový model pro leteckou dopravu (LET) 71 72

13 1. verze analytického modelu Nenormalizovaný model Entita: LET íslo letu Spolenost Letišt Obvyklý typ letadla Kapacita Jméno lena posádky Role lena - klíová položka, - nepovinná položka, - povinná položka normáln lní forma 1.normální forma: entity neobsahují násobné atributy, ani komponované atributy pokud existuje atribut nebo skupina atribut, které mohou nabývat více hodnot, vytvoíme novou entitu popsanou tmito atributy a identifikovanou njakou vhodnou kombinací tchto atribut - souasn pidáme vztah 1:N pokud existuje atribut, který obsahuje více hodnot, rozložíme jej na nkolik atribut, které reprezentují vždy jedinou vlastnost Smrem k 1.NF Josef Novák, kapitán Karel Polák, 2.pilot Jana Nováková, letuška normáln lní forma 2.normáln lní forma 2.normální forma (navíc): neklíové atributy závisí pouze na celém klíi pokud existuje atribut nebo skupina atribut, které závisí pouze na ásti jednoznaného klíe, vytvoíme novou entitu obsahující tento atribut a píslušnou ást klíe - souasn pidáme vztah 1:N 77 78

14 2.normáln lní forma 3.normáln lní forma 3.normální forma (navíc): neklíové atributy nejsou závislé na neklíových atributech pokud existuje atribut nebo skupina atribut, které závisí na neklíovém atributu, vytvoíme novou entitu obsahující tento atribut a píslušný atribut jako klí - souasn pidáme vztah 1:N normáln lní forma Návrh reprezentace pomocí RDBMS (patí až do návrhu) n CREATE TABLE "LETY"( "datum_a_cas" DATE NOT NULL, "ID_POSADKY" NUMBER(1) NOT NULL, "cislo_linky" NUMBER(3) NOT NULL, CONSTRAINT "PK_LETY" PRIMARY KEY ("datum_a_cas","cislo_linky") ); CREATE TABLE "POSADKY"( "ID_POSADKY" NUMBER(1) NOT NULL, "role" VARCHAR2(20), CONSTRAINT "PK_POSADKY" PRIMARY KEY ("ID_POSADKY") ); Jsou zaneseny všechny v vztahy? Nelze doplnit generalizace? Nelze doplnit agregace? Nelze model vylepšit? Píklad: Pro entitu dodací list lze vymyslet pružnjší model, který usnadní pípadné úpravy v budoucnosti Nejsou zde odvoditelné vztahy? Zákazník si objednává zboží Zákazníkovi je vystavena faktura. Odebrané zboží je pedmtem fakturace.? Nejsou zde odvoditelné vztahy? Pozn.: Odvoditelné vztahy mohou v modelu být, ale musí být jako odvoditelné pedznaeny znakem / a doplnny zpsobem odvození (formulí, popisem v OCL)

15 Jsou zanesena všechna v integritní omezení? adu vlastností dat nelze do diagramu zanést: Šéf musí mít vtší plat než jeho podízení. V jednom skladu nelze umístit chemikálie typu 1 a 2. context s:sklad inv : forall(barel x,y s.obsahuje(x) and s.obsahuje(y) implies x.typ!= 1 or y.typ!= 2) Vyvážen ení datového modelu datový model versus datový slovník každá entita, atribut a vztah v DD datový model versus funkní dekompozice každá pam a datový tok obsahuje entitu, atribut nebo vztah (nebo jejich kombinaci) datový model versus minispecifikace nco musí entity a vztahy vytváet/rušit, íst/modifikovat (matice CRUD) Matice CRUD pro ECO sklad Prázdná plošina Zadej dodací list Zaa barel Konec pejímky Dodávka Zahájení práce systému ECO sklad Plošina U U U C D Ukonení práce systému ECO sklad Sklad U U C,Get D,Save Monitor U,Print U,Print C D Barel C Kontrola funkního modelu je funkní model úplný? existuje funkce/metoda pro každou událost? každá funkce/metoda musí být popsána dekompozicí, nebo mít minispecifikaci (vstupy a výstupy musí odpovídat) nejsou zde nadbytené funkce/metody? Dodací list C R,D Píkaz C,Print C,Print Vyvážen ení funkního modelu funkní model versus datový slovník každá pam a datový tok v DD každý prvek DD se nkde vyskytuje (jinak je zbytený) funkní model versus datový model každá data zmínná ve funkce/metod musí být popsána v datovém modelu funkní model versus dynamický model každý ídicí proces má dynamický model (vstupy = podmínky, výstupy = akce) stídav spouštíme P1 a P2 P1 P2 y/a a x b y ídicí proces /a Pracuje P1 Pracuje P2 x/b 89 90

16 Kontrola dynamického modelu je dynamický model úplný? existuje model pro každou entitu, která mže mít rzné stavy? existuje model pro každý ídicí proces? existuje popis životního cyklu systému? The End 91 92