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

Transkript

1 Úvod do softwarového inženýrství IUS 2009/ přednáška Ing. Radek Kočí, Ph.D. Ing. Bohuslav Křena, Ph.D. Vytvořeno na základě přednášky doc. Ing. Jaroslava Zendulky, CSc. Úvod do softwarového inženýrství IUS 2009/2010 p.1/30

2 Téma přednášky Strukturovaná analýza a návrh Entity Relationship Diagrams (ERD) State-Transition Diagrams (STD) Úvod do softwarového inženýrství IUS 2009/2010 p.2/30

3 Nejpoužívanější přístupy k analýze a návrhu Strukturovaná analýza a návrh chápe systém jako kolekci funkcí (procesů) operujících nad daty. Objektově orientovaná analýza a návrh chápe systém jako kolekci vzájemně komunikujicích objektů. Úvod do softwarového inženýrství IUS 2009/2010 p.3/30

4 Základní modely strukturované analýzy Funkční (procesní) modelování základní model strukturované analýzy ukazuje funkce systému, toky dat mezi systémem a okolím a mezi funkcemi, data ukládaná v systému diagram datových toků (Data Flow Diagram DFD) Minispecifikace popis funkcí (procesů) co dělají Datové modelování ukazuje entity aplikační domény zpracovávané systémem a statické vztahy mezi nimi (typicky perzistentní data ukládaná v databázi) důležitý model datově intenzivních aplikací zásadní význam pro návrh databáze diagram entit a vztahů (Entity Relationship Diagram ERD) Úvod do softwarového inženýrství IUS 2009/2010 p.4/30

5 Základní modely strukturované analýzy Datový slovník obsahuje specifikace prvků modelů notace pro specifikaci informačního obsahu prvků DFD a ERD Modelování dynamického chování zachycuje stavy systému, události v systému a prováděné akce v závislosti na stavu a události stavový diagram Úvod do softwarového inženýrství IUS 2009/2010 p.5/30

6 Datové modelování ER model Slouží k modelování dat aplikační domény a jejich vztahů "v klidu". podstatné v datově intenzivních aplikacích Která data potřebujeme v systému uchovávat? Jaké jsou mezi nimi vztahy? Úvod do softwarového inženýrství IUS 2009/2010 p.6/30

7 Datové modelování základní pojmy Entita "věc" reálného světa (objekt) rozlišitelný od jiných objektů. Např. klient banky s identifikačním číslem K999, účet číslo U100 Entitní množina množina entit téhož typu, které sdílí tytéž vlastnosti (atributy). Např. Klient, Účet Atribut vlastnost entity, která nás v kontextu daného problému zajímá. Např. Klient: čísloklienta, jméno, příjmení, adresa,... Vztah asociace mezi několika entitami. Např. klient s číslem klienta K999 vlastní účet s číslem účtu U100. Vztahová množina množina vztahů téhož typu, které sdílí tytéž vlastnosti. Např. Klient vlastní Účet pro vztah mezi entitami typu Klient a Účet Úvod do softwarového inženýrství IUS 2009/2010 p.7/30

8 Tvorba ER diagramu Úvod do softwarového inženýrství IUS 2009/2010 p.8/30

9 Typy atributů jednoduché (simple) a složené (composite) atributy Úvod do softwarového inženýrství IUS 2009/2010 p.9/30

10 Typy atributů jednohodnotové (single-valued) a vícehodnotové (double-valued) atributy např. telefon může být více čísel lze omezit minimální a maximální počet hodnot prázdné (NULL) atributy mohou nabývat speciální hodnoty NULL může zastupovat chybějící hodnotu existuje, ale neznáme ji může zastupovat naznámou hodnotu nevíme, zda existuje odvozené atributy hodnotu lze odvodit od jiných atributů nebo entit např. datumnarození věk Úvod do softwarového inženýrství IUS 2009/2010 p.10/30

11 Parametry vztahů Jméno vztahové množiny i jméno role vyjadřuje význam vztahu. Úvod do softwarového inženýrství IUS 2009/2010 p.11/30

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

13 Kardinalita Kardinalita (cardinality) je maximální počet vztahů daného typu (vztahové množiny), ve kterých může participovat jedna entita. Typické hodnoty: 1,M, případně přesněji Úvod do softwarového inženýrství IUS 2009/2010 p.13/30

14 Členství / účast Členství (membership) / účast (participation) je minimální počet vztahů daného typu (vztahové množiny), ve kterých musí participovat jedna entita. Typické hodnoty: 0 volitelné, 1 povinné Úvod do softwarového inženýrství IUS 2009/2010 p.14/30

15 Atributy vztahu Použijeme tehdy, když atribut nelze přiřadit ani jedné z entit. Jedná se o vztah povýšený na entitu. Úvod do softwarového inženýrství IUS 2009/2010 p.15/30

16 Alternativní notace ERD Jakou notaci jsme používali doposud? Úvod do softwarového inženýrství IUS 2009/2010 p.16/30

17 Doporučení pro tvorbu ERD (1.) Jména Musí být srozumitelná a musí vyjadřovat význam entitních a vztahových množin. entitní množiny: podstatná jména vztahové množiny: slovesa, předložky Je-li jméno vztahové množiny jasné ze jmen entitních množin, není nutné uvádět. Mezi stejnými entitními množinami může být několik vztahových množin. Úvod do softwarového inženýrství IUS 2009/2010 p.17/30

18 Doporučení pro tvorbu ERD (2.) Identifikátor (klíč, primární klíč) Entity a vztahy musí být identifikovatelné. Hodnota identifikátoru musí být unikátní (a minimální). Identifikátorem je jednoduchý nebo složený atribut. Unikátnost hodnoty jen v rámci vyvíjeného systému (ne celého vesmíru). Celkový systém by neměl být zahrnut do ERD. Úvod do softwarového inženýrství IUS 2009/2010 p.18/30

19 Doporučení pro tvorbu ERD (3.) Použít entitní množinu nebo atribut? Pravidlo: Je-li hodnota atributu důležitá, i když neexistuje žádná entita s touto hodnotou jako vlastností, pak bychom ji měli modelovat jako entitu. Úvod do softwarového inženýrství IUS 2009/2010 p.19/30

20 Doporučení pro tvorbu ERD (4.) Atributy a vztahy 1:M Bude záležet na tom, zda budeme chtít uchovávat i historii registrací. Úvod do softwarového inženýrství IUS 2009/2010 p.20/30

21 Doporučení pro tvorbu ERD (5.) Náhrada vztahů M:M vazební entitní množinou Úvod do softwarového inženýrství IUS 2009/2010 p.21/30

22 Slabé (weak) entitní množiny Silná (strong) entitní množina má identifikátor tvořený vlastními atributy. Slabá entitní množina nemá identifikátor tvořený vlastními atributy. Úvod do softwarového inženýrství IUS 2009/2010 p.22/30

23 Identifikace slabé entitní množiny Rysy slabé entitní množiny: identifikátor = identifikátor_dominantní + diskriminátor existenční závislost slabé na identifikující Slabá nebo silná entitní množina? 1. Jako slabou modelovat tehdy, kdy entita kompletně zmizí při odstranění odpovídající identifikující entity. Příklad: Objednávka - PoložkaObjednávky 2. Cokoliv s atributem, který je jednoznačný, by nemělo být modelováno jako slabá entitní množina. 3. Jsme-li na pochybách, modelujeme jako silnou entitní množinu. Úvod do softwarového inženýrství IUS 2009/2010 p.23/30

24 Cvičení systém správy účtů Provádíme analýzu systému správy účtů banky. Každý účet má jednoznačné číslo, dále je potřeba znát jméno a adresu majitele účtu. Kromě majitele mohou s účtem disponovat i další jím určené osoby. O těch je třeba znát stejné údaje jako o majiteli. Každá z disponujících osob může mít stanoven limit pro výběr z daného účtu. S účty manipuluje úředník banky na základě příkazu osoby oprávněné s účtem disponovat. Na účet lze provádět vklad, z účtu lze provádět výběr a lze převádět částky na jiné účty v téže nebo jiné bance. Musí být k dispozici informace, kdo příkaz zadal a který úředník ho provedl. Systém musí poskytovat prostředky pro správu informací o klientech banky, musí umožňovat vytvářet a rušit účty, zadávat příkazy, importovat příkazy pro převody z jiných bank a naopak exportovat příkazy pro převody na účty v jiných bankách. Systém musí být schopen tisknout měsíční výpisy z účtů a řadu dalších tiskových sestav. Úvod do softwarového inženýrství IUS 2009/2010 p.24/30

25 Cvičení systém správy účtů Úvod do softwarového inženýrství IUS 2009/2010 p.25/30

26 Stavový diagram (State-Transition Diagram) Dosud známé diagramy DFD modelování funkcí, které systém vykonává ERD modelování uložených dat, která si systém musí pamatovat STD zachycuje chování systému v závislosti na čase zachycuje stavy, ve kterých se systém může vyskytovat zachycuje přechody mezi stavy (změny stavů) Stav systému je reprezentován boxem (elipsou) stav množina okolností nebo atributů charakterizující entitu v daném čase Úvod do softwarového inženýrství IUS 2009/2010 p.26/30

27 Stavový diagram (State-Transition Diagram) IDLE WAITING FOR CALL RECORDING MESSAGE REWINDING PLAYING MESSAGES ANSWERING CALL Úvod do softwarového inženýrství IUS 2009/2010 p.27/30

28 Stavový diagram (State-Transition Diagram) Koncové a počáteční stavy systém má pouze jeden počáteční stav systém může mít více koncových stavů koncové stavy jsou vzájemně vyloučeny (může nastat pouze jeden z nich) Podmínky každá změna může být podmíněna většinou události z okolního prostředí Akce s každou změnou lze vykonat akce akce zaslané okolnímu prostředí výpočet, jehož výsledky si má systém pamatovat Úvod do softwarového inženýrství IUS 2009/2010 p.28/30

29 Stavový diagram (State-Transition Diagram) IDLE "re s e t" p u s h e d "s ta rt" p u s h e d d is p la y "in s e rt ca rd " WAITING FOR CARD ca rd in s e rte d d is p la y "e n te r p a s s word " WAITING FOR PWD... Úvod do softwarového inženýrství IUS 2009/2010 p.29/30

30 Studijní koutek Studentská Unie FIT SU FIT zastupuje studenty při jednání s fakultou. SU FIT pomáhá fakultě s organizací různých akcí. Oficiální informace o SU FIT najdete na URL Každá přednášková skupina má alespoň jednoho voleného zástupce v Zastupitelstvu SU FIT. Studenti mají své zástupce (4 + 1) v akademickém senátu FIT. Studenti mají své zástupce na kolegiu děkana FIT. Studenti mají svého zástupce v akademickém senátu VUT. Studenti mají svého zástupce v oborových radách. Úvod do softwarového inženýrství IUS 2009/2010 p.30/30