Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

4.4.2008 1 Klasické metody objektové analýzy a návrhu.

Podobné prezentace


Prezentace na téma: "4.4.2008 1 Klasické metody objektové analýzy a návrhu."— Transkript prezentace:

1 4.4.2008 1 Klasické metody objektové analýzy a návrhu

2 4.4.2008 2 Historie 1966 – první objektový jazyk Simula 80.léta – první metody OO analýzy 1991 – Object Oriented Design 1991 – Object Modeling Technique 1992 – Object Oriented Software Ingineering 1994 – Unified Method 1995 – Unified Method Language

3 4.4.2008 3 Vývoj

4 4.4.2008 4 Vlastnosti objektů (1)‏ Třída – podle G.Boocha je třída množina objektů, které sdílejí společnou strukturu a chování Objekt – objekt je instancí třídy Zapouzdření – odlišuje vnější chování od vnitřní organizace Dědičnost (generalizace a specializace)‏ Vazba – spojení mezi třídami (asociace) nebo objekty (link)‏ Polymorfismus – „mnohotvarost“, instance různých tříd reagují na stejný podnět různě

5 4.4.2008 5 Vlastnosti objektů (2)‏ Synergie – integrace dat a metod v jeden celek je účinější než jednoduché seskupení Znovuvyužitelnost Abstrakce

6 4.4.2008 6 Objektově orientovaný návrh Object-Oriented Design (OOD)‏ 1991 vyvinul Grady Booch 1994 popsána v knize Object-Oriented Design with Application analýza: chování systému, role a zodpovědnost objektů návrh: existence tříd a jejich propojení, spolupráce objektů, deklarace tříd a objektů

7 4.4.2008 7 Rozdělení (1) (OOD)‏ Rozdělení do 2 dimenzí: logický a fyzický pohled statický a dynamický pohled Každý pohled obsahuje několik diagramů, které musí být mezi sebou konzistentní.

8 4.4.2008 8 Rozdělení (2) (OOD)‏

9 4.4.2008 9 Rozdělení (3) (OOD)‏ Logický model: diagram tříd (Class Diagram)‏ objektový diagram (Object Diagram)‏ Fyzický model: diagram modulů (Module Diagram)‏ diagram procesů (Process Diagram)‏ Dynamický model stavový diagram (State Transition Diagram)‏ diagram interakcí (Interaction Diagram)‏

10 4.4.2008 10 Rozdělení (4) (OOD)‏ Metoda popisuje 2 druhy procesů popisující vývoj systému: makroproces: shrnuje nutné kroky, určuje základní požadavky, vytváří model požadovaného chování a architekturu systému mikroproces: zachycuje obecně uznávané a nutné kroky pro vytvoření diagramu tříd a objektů, určují se třídy a objekt, jejich vztahy, rozhraní a implementace

11 4.4.2008 11 Logický model (OOD)‏ popis existence základních mechanismů a abstrakcí statická struktura Obsahuje: diagram tříd objektový diagram

12 4.4.2008 12 Diagram tříd (OOD)‏ poukazuje na existenci tříd a jejich vztahů analýza: diagramy representují role a odpovědnost návrh: diagramy representují strukturu tříd třída je znázorněna jako mrak, má unikátní jméno a jednoznačné atributy třída je s jinou třídou je spojena vazbou

13 4.4.2008 13 Rozšíření základní notace (OOD)‏ skupina tříd (Class Category): shluky tříd, které spolupracují a jsou volně vázané s ostatními shluky nebo třídami. Objevují se v nejvyšších vrstvách systému. parametrizovaná třída (Parametrized Class): je šablonou pro jiné třídy. Obsahuje formální parametry. Při jejich určení vzniká konkrétní instance a to je instanční třída. metatřída (Metaclass): její instance jsou třídy, definuje chování a svých tříd a jejich instancí. obslužná třída (Class Utility): označuje kolekci logicky spojených podprogramů (ty jsou ale samostatné).

14 4.4.2008 14 Vazby (OOD)‏ 6 typů vazeb: asociace: sémantická vazba, označuje se násobností dědění:označuje generalizaci nebo specializaci, násobné dědění, neobsahuje násobnost agregace: vztah typu „má“ „používá“: vztah klient-poskytovatel kontretizace: vztah mezi parametrizovanou a instanční třídou vztah metatříd: vztah mezi metatřídou a její třídou Násobnost (kardinalita) vztahů: Omezení v počtu druhé entity Např. 1.. 1 1.. N N.. N

15 4.4.2008 15 Třídy (OOD)‏

16 4.4.2008 16 Vazby (OOD)‏

17 4.4.2008 17 Objektový diagram (OOD)‏ poukazuje na existenci objektů a jejich vztahů vychází z diagramu tříd analýza: popisuje chování systému návrh: popisuje sémantiku mechanismů objekty jsou znázorněny jako mrak, nemusí mít unikátní jméno (stejný název objektu v diagramu značí stejný objekt)‏ s jiným objektem je propojen pomocí linku

18 4.4.2008 18 Link (1) (OOD)‏ link je možný pouze pokud existuje asociace mezi odpovídajícími třídami objekt vyvolávající operace je klient objekt poskytující operace je poskytovatel odesílatel zprávy zná příjemce, naopak ne zprávy jsou číslované od jedné (podle pořadí provádění)‏ nečíslované zprávy prochází diagramem kdykoliv bez určeného pořadí vykonání

19 4.4.2008 19 Link (2) (OOD)‏ Objekt vystupuje v linku v jedné ze 3 rolí: aktor: operuje nad jinými objekty, ale jiné objekty neoperují nad ním, bývá označován i jako aktivní objekt server: jiné objekty operují nad ním, ale ne naopak agent: operuje nad jinými objekty a naopak Při posílání zprávy se musí objekty zesynchronizovat. Jsou 3 druhy synchronizace. sekvenční: v jeden okamžik je aktivní pouze jeden objekt hlídaná: aktivní objekty spolupracují, aby se dohodly na střídání synchronní: poskytovatel garantuje vzájemné střídání

20 4.4.2008 20 Objekt a link (OOD)‏

21 4.4.2008 21 Fyzický model (OOD)‏ popisuje softwarové a hardwarové požadavky na systém a implementaci statická struktura Obsahuje: diagram modulů diagram procesů

22 4.4.2008 22 Diagram Modulů (OOD)‏ zachycuje rozmístění tříd a objektů do modulů zachycuje vlastní programovou strukturu základní prvky jsou moduly a jejich vztahy každý modul musí mít název

23 4.4.2008 23 Moduly a vztahy (OOD)‏ zachycuje rozmístění tříd a objektů do modulů vztah mezi moduly se nazývá kompilační závislost moduly je možné rozmístit do podsystémů pro popis souborů se používají 3 notace: specifikace (hlavička)‏ - obsahuje specifikace a definice entit tělo – obsahuje specifikace a definice entit hlavní program – obsahuje jádro systému

24 4.4.2008 24 Moduly a vztah (OOD)‏

25 4.4.2008 25 Diagram procesů (OOD)‏ znázorňuje rozmístění procesů na procesory ukazuje pohled na strukturní proces systému základní prvky jsou: procesor: část HW, která vykonává procesy zařízení: část HW, která nevykonává procesy vztahy: jsou mezi procesory, zařízeními a mezi procesorem a zařízením. Často představuje skutečné, HW spojení.

26 4.4.2008 26 Procesy a vztah (OOD)‏

27 4.4.2008 27 Dynamický model (OOD)‏ popisuje dynamické chování objektů a tříd Obsahuje: stavový diagram (State Transition Diagram)‏ diagram interakcí (Interaction Diagram

28 4.4.2008 28 Stavový diagram (OOD)‏ popisuje dynamiku tříd základní jednotky jsou stav a přechod stavu zachycuje stavy objektu, kterými prochází/může procházet během svého životního cyklu ke změně stavu dojde pod podmínkou (událost nebo čas)‏ během změny se uskuteční nějaká akce má pouze jeden počáteční a žádný, jeden nebo více koncových stavů

29 4.4.2008 29 Stavy a přechody (OOD)‏

30 4.4.2008 30 Diagram interakcí (OOD)‏ popisuje dynamiku instancí zachycuje posloupnost interakcí mezi objekty vychází z objektového diagramu zaměřuje se na události (ne na operace)‏ zobrazuje se v tabulkové formě: objekty jsou zobrazeny nahoře vedle sebe od objektu vede čára směrem dolu (plynoucí čas)‏ na čárách jsou obdélníky vyjadřující čas činnosti objektu po odeslání zprávy zprávy se značí šipkou

31 4.4.2008 31 Diagram interakcí (OOD)‏

32 4.4.2008 32 Zhodnocení (OOD)‏ metoda je silná v oblasti vlastního návrhu a realizace velký důraz klade na návrh neomezuje se pouze na popis nástrojů a diagramů zahrnuje popis postupu návrhu a tvorby informačního systému

33 4.4.2008 33 Objektová modelovací technika Object Modeling Technique (OMT)‏ 1991 vyvinul James Rumbaugh 1991 popsáno v knize Object Oriented Technique and Design vychází z datového modelování Význam: testování fyzických entit před jejich vytvořením komunikace se zákazníkem znázornění modelu

34 4.4.2008 34 Rozdělení (OMT)‏ Fáze analýzy: objektový model (OM – Object Model)‏ dynamický model (DM – Dynamic Model)‏ funkční model (FM – Functional Model)‏ Fáze návrhu: systémový návrh (SD – System Design)‏ objektový návrh (OD – Object Design)‏ Implementace

35 4.4.2008 35 Analýza (OMT)‏ OM popisuje objektovou strukturu DM provádí akce, které způsobují změny hodnot objektů a vyvolávají funkce FM popisuje funkce vyvolané operacemi v OM a akcemi v DM Výsledkem je dokument analýzy (Analysis Document), který obsahuje seznam požadavků, OM, DM a FM

36 4.4.2008 36 Seznam požadavků (OMT)‏ Problem Statement vypracováno ve spolupráci se zadavateli a uživateli popisuje, co je potřeba, ne jak to má být implemetováno může být nekompletní, chybový a nejednoznačný

37 4.4.2008 37 Objektový model (OMT)‏ popisuje statickou strukturu systému organizuje systém do funkčních částí zachycuje strukturu objektů v systému, jejich identitu, vztahy, atributy a metody OM je prezentován jako objektový diagram výsledkem je diagram objektového modelu a datový slovník

38 4.4.2008 38 Kroky tvorby OM (1) (OMT)‏ 1.Vytvoření kontextového diagramu popisuje vztah systému ke svému okolí na nejvyšší úrovni 2.Identifikace objektů a tříd základní třídy se odvodí z kontextového diagramu a ze seznamu požadavků doplní se třídy mající význam entitty, které se dále nerozkládají, se stávají stributy eliminace nepravých tříd

39 4.4.2008 39 Kroky tvorby OM (2) (OMT)‏ 3.Tvorba datového slovníku Přesný popis všech tříd dvojice jméno třídy: popis udržuje konzistenci dat seznam všech datových objektů, prvků s jejich vztahy 4.Identifikace vztahů tvorba na základě seznamu požadavků a znalostí reálného světa pomocí datového slovníku se slovně popíší vztahy mezi třídami vyjímky: implementační, odvozené a omezené relace

40 4.4.2008 40 Kroky tvorby OM (3) (OMT)‏ 5.Identifikace atributů zastupují vlastnosti objektů 6.Uspořádání a zjednodušení objektů a tříd dědičnost se zjednodušuje na generalizaci a abstrakci 7.Zjemňování kontrola tříd, atributů a vztahů 8.Seskupování tříd do modulů seskupování do modulů na základě blízkých vazeb a podobných funkcí

41 4.4.2008 41 Třída a objekt (OMT)‏

42 4.4.2008 42 Vazby (OMT)‏

43 4.4.2008 43 Vztahy (OMT)‏

44 4.4.2008 44 Dynamický model (OMT)‏ popisuje dynamické chování objektů a jejich stavů chování objektů v čase, tok zpráv a kontroly mezi objekty výsledkem jsou stavové diagramy a diagram událostí Obsahuje: stavový diagram (State Transition Diagram)‏ mapa událostí (Event Trace Diagram)‏ diagram událostí (Event Schema nebo Event-flow Diagram)‏

45 4.4.2008 45 Kroky tvorby DM (1) (OMT)‏ 1.Scénář typických dialogů mezi objekty nebo třídami dialog mezi uživatelem a systémem zachycuje očekávané chování systému scénář zachycuje hlavní interakce a výměnu informací popisuje komunikaci mezi třídami 2.Identifikace událostí mezi objekty pomocí scénáře se identifikují všechny externí události vytváří se mapa událostí zobrazuje všechny události, které třídy zpracovávají nebo vysílají

46 4.4.2008 46 Kroky tvorby DM (2) (OMT)‏ 3.Spojení scénáře a události vytváří se diagram událostí činnosti jsou popsány jako reakce na vstupy je to síť událostí a aktivit, události se mohou větvit nebo slévat nerespektují se hranice systému cesty ukazují možné řídící toky jeden vstup a jeden výstup

47 4.4.2008 47 Kroky tvorby DM (3) (OMT)‏ 4.Vytvoření stavových diagramů STD je graf stavů a přechodů mezi stavy přechod je reakce objektu na obdrženou událost stavy jsou statické, přechody dynamické zapisují se podmínky přechodu 5.Kontrola úplnosti a konzistence kontrola na systémové úrovni každé odesílené události z STD musí odpovídat přechod v příslušném diagramu

48 4.4.2008 48 Stavy a přechody (1) (OMT)‏

49 4.4.2008 49 Stavy a přechody (2) (OMT)‏

50 4.4.2008 50 Funkční model (OMT)‏ popisuje funkční závislosti systému ukazuje jak jsou hodnoty počítány výsledkem je DFD a omezení

51 4.4.2008 51 Kroky tvorby FM (1) (OMT)‏ 1.Určení vstupů a výstupů doplnění kontextového diagramu o příčiny událostí událost může být vyvolána: F (Flow oriented): datová událost spuštěná vstupem do systému T (Temporar): časová událost spuštěná časovým okamžikem C (Control): řídící událost spuštěná povelem

52 4.4.2008 52 Kroky tvorby FM (2) (OMT)‏ 2.Tvorba diagramu datových toků navazuje na kontextový diagram zobrazuje vnitřní fukncionalitu systému na základě toků dat uvnitř i s okolím popisuje datová úložistě neobsahuje časování a řídící informace 3.Popis funkcí popsány pomocí minispecifikace, která definuje logiku procesů vytvořena pro každý proces na nejnižší úrovni popisuje postupy a pravidla při přeměně datových toků na výstupní

53 4.4.2008 53 Kroky tvorby FM (3) (OMT)‏ 4.Omezení doplnění textových informací do modelu jsou to funkční závislosti mezi objekty 5.Optimalizace kontrola, zda lze model zjenodušit nebo vylepšit

54 4.4.2008 54 Proces a toky (OMT)‏

55 4.4.2008 55 Data store (OMT)‏

56 4.4.2008 56 Toky (OMT)

57 4.4.2008 57 Doplnění (OMT)‏ opakování, ověřování a zjemnění všech tří modelů přidání klíčových operací (objeveny během přípravy z FM na OM)‏ ověření konzistence a kompletnosti na vybraných úrovních, porovnání se seznamem požadavků opakování předchozích kroků

58 4.4.2008 58 Systémový návrh (OMT)‏ rozložení na podsystémy rozhoduje se, jak bude problém řešen výsledkem je dokument systémového návrhu (System Design Document), což je základní struktura architektury pro systém a rozhodnutí o celkové strategii a postupu řešení

59 4.4.2008 59 Kroky tvorby SD (1) (OMT)‏ 1.Rozdělení na podsystémy rozdělení na základě objektového modelu podsystém: kolekce tříd, vztahů, operací... uspořádání do sekcí nebo vtrstev vztahy podsystémů: klient-server peer- to-peer 2.Určení paralelnosti určí se současně aktivní objekty pomocí DFD rozložení zátěže na více procesorech 3.Alokace systému procesům a úlohám odhad požadavků na HW zdroje kompromisy mezi SW a HW

60 4.4.2008 60 Kroky tvorby SD (2) (OMT)‏ 4.Vybrání strategie pro datastore 5.Identifikace globálních zdrojů a řízení přístupu k nim na základě způsobu obsluhy vnějších a vnitřních událostí 6.Volba implementace řízení v programu varianty externího řízení: sekvenční řízení kódem: vstupy jsou realizovány na základě naprogramované žádosti sekvenční řízení událostmi: pomocí monitoru událostí interní události se obsluhují pomocí procedur

61 4.4.2008 61 Kroky tvorby SD (3) (OMT)‏ 7.Ošetření okolních podmínek v systému pomocí iniciace, ukončení a chybových stavů 8.Určení priorit zpracování přijmutí kompromisních řešení

62 4.4.2008 62 Objektový návrh (OMT)‏ modely z analýzy se transformují do fyzického návrhu tříd spojení objektového a stavového modelu návrh potřebných algoritmů výsledkem je dokument návrhu, který obsahuje podrobný OM, podrobný FM a podrobný DM

63 4.4.2008 63 Kroky tvorby OD (1) (OMT)‏ 1.Získávání operací pro objektový model z ostatních modelů přenesení operací z DM a Fm do OM pro implementaci do objektového diagramu se z FM definují pro každou událost operace vyplývající z DM 2.Návrh algoritmů každá operace specifikovaná v FM musí být formulovaná jako algoritmus algoritmy se dělí na volání a jednodušší operace použití algoritmů, které minimalizují náklady podle potřeby se definují nové třídy a operace operacím se přiřazuje odpovědnost

64 4.4.2008 64 Kroky tvorby OD (2) (OMT)‏ 3.Optimalizace přístupu k datům opětovné uspořádání výpočtů pro zvýšení efektivnosti: přidání redundantních vztahů:minimalizace, přístupové ceny a maximálního pohodlí uchování odvozených atributů: např. zachování výsledku při dlouhém výpočtu přizpůsobení objetové hierarchie: podobné operace mohou být posunuty o úroveň výš

65 4.4.2008 65 Kroky tvorby OD (3) (OMT)‏ 4.Implementace řízení zdokonalení strategie pro implementaci 5.Návrh implementace vztahů podle způsobu použití se dělí na: jednocestné: implementována jako pointer dvoucestné: dva pointery a atribut, který obsahuje objektové reference 6.Rozdělení tříd do modulů rozdělení popisu tříd na veřejné a soukromé části doplnění inicializačních funkcí úprava typu atributů

66 4.4.2008 66 Implementace (OMT)‏ použití programovacích jazyků a relačních databází

67 4.4.2008 67 Zhodnocení (OMT)‏ metoda je silná v oblasti analýzy systému s rozsáhlou datovou základnou velmi oblíbená metodika analýzy a návrhu vychází z ní např. Select Perspective

68 4.4.2008 68 Objektově orientované softwarové inženýrství Object-Oriented Software Engineering (OOSE)‏ 1992 vyvinul Ivar Jacobson používá use case Zdroj metody: OO programování konceptuální modelování blokový design všechny modely používají objekty

69 4.4.2008 69 Rozdělení (OOSE)‏ Analýza: model požadavků (Requirements Model)‏ model analýzy (Analysis Model)‏ Konstrukce: model návrhu (Design Model)‏ implementační model (Implementation Model)‏ Testování model testování (Test Model)‏

70 4.4.2008 70 Postup metody (OOSE)

71 4.4.2008 71 Analýza (OOSE)‏ vytváří se konceptuální obrázek systému cílem je analyzovat, specifikovat a definovat systém, jak bude postaven spojení mezi třídami: dědičnost a rozšíření spojení mezi objekty: spojení, acquaintance (statické spojení, objekty si nemohou měnit informace), agregace a komunikační spojení (přijímá a vysílá stimuli) stimul: zpráva/informace posílaná mezi objekty Rozdělení: model požadavků model analýzy

72 4.4.2008 72 Model požadavků (OOSE)‏ zachycuje funkcionální požadavky Skládá se z: use case model popis rozhraní: zachycuje uživatelův logický pohled používají se nákresy toho, co uvidí uživatel na obrazovce model problémových oblastí: identifikuje objekty definuje a ilustruje obsah, se kterým pracuje systém

73 4.4.2008 73 Use case (OOSE)‏ používá aktory a use case zachycuej interakci mezi aktory a systémem uživatel: používá systém vykonává sekvence transakcí v dialogu se systémem aktor: vnějšek systému, nepopisuje se, instance uživatele instance v use case existují pouze po dobu pracování use case obsahuje rozšíření (extends), což je alternativní průběh události, spustí se pouze pokud se splní podmínka

74 4.4.2008 74 Analýza požadavků (OOSE)‏

75 4.4.2008 75 Use case (OOSE)

76 4.4.2008 76 Model analýzy (1) (OOSE)‏ vytvořen na základě modelu požadavků logická struktura systému systém se rozděluje na podsystémy, určují se mezi nimi rozhraní Prostor modelu zachycují 3 rozměry: rozměr informací: specifikuje informace držené v systému popis vnitřního stavu systému rozměr chování: popisuje chování, které přijal systém stanovuje se kdy a jak se mění stav systému rozměr prezentace: poskytuje informace pro představení systému okolí

77 4.4.2008 77 Model analýzy (2) (OOSE)‏ postaven na specifických objektech objekt označuje jak třídu tak její instanci objekty obsahují chování, informace a presentaci Objektové typy: entitní objekty objekty rozhraní kontrolní objekty

78 4.4.2008 78 Objektové typy (1) (OOSE)‏ entitní objekty: drží informace dlouhou dobu v systému, pouze pokud je use case kompletní typické operace: vytvoření a smazání entitního objektu, skladování s posílání informací objekty rozhraní: pomocí nich komunikují aktoři se systémem každý aktor má alespoň jeden objekt rozhraní mění vstupy od aktorů na události systému a naopak jednotlivé objekty rozhraní o sobě musí vědět, vztah mezi nimi se jmenuje acquaintance acquaintance

79 4.4.2008 79 Objektové typy (2) (OOSE)‏ kontrolní objekty: vykonávají specifické úkoly use case spojuje ostatní objekty nemusí se v use case objevit při složitém chování se může funkcionalita rozdělit do několika kontrolních objektů typické vlastnosti: transakce provádějící chování, kontrolní sekvence a funkcionalita oddělující entitní objekty od objektů rozhraní

80 4.4.2008 80 Typy objektů, prostor (OOSE)‏

81 4.4.2008 81 Konstrukce (OOSE)‏ navazuje na modely vyvinutých během analýzy proces rozvinutí komponent: vyvíjí a udržuje komponenty, které se požívají během konstrukce komponenty jsou implementované kódy Rozdělení: model návrhu implementační model

82 4.4.2008 82 Proces konstrukce (OOSE)‏

83 4.4.2008 83 Model návrhu (1) (OOSE)‏ pomocí modelu analýzy a modelu požadavků se navrhuje systém určuje se rozhraní každého bloku a popisuje se očekávané chování (objekty, subsystémy)‏ rozměr modelu se rozšíří o implementaci prostředí používá se bloková struktura stanovuje se rozhraní každého objektu rozhoduje se jaký programovací jazyk a databáze se použijí

84 4.4.2008 84 Model návrhu (2) (OOSE)‏ Blok je to jeden objekt, implementace do zdrojového kódu začíná pokud se stabilizuje rozhraní bloku mohou se seskupovat v moduli komunikují pomocí stimulů k popsání stimul se používá diagram interakcí Diagram interakcí: popisuje všechny sekvence toků vytvořen pro každý use case struktura: větvení (centralizovaná), schodová (decentralizovaná)

85 4.4.2008 85 Model návrhu (3) (OOSE)‏ chování objektů se popisuje pomocí stavově přechodového grafu, popisuje kdy byly stimuly poslány, které mohou být přijaty a co mohou způsobit

86 4.4.2008 86 Blok, rozměry modelu (OOSE)‏

87 4.4.2008 87 Diagram interakcí (OOSE)‏

88 4.4.2008 88 Stavově přechodový graf (OOSE)‏

89 4.4.2008 89 Implementační model (OOSE)‏ cíl: implementovat model skládá se z okomentovaných zdrojových kódů objektů jednoduché bloky se přepíší na jednu třídu v imlementačním jazyce složité bloky se přepisují do 1 až 5 tříd překládají se pojmy v návrhu do pojmů a vlastností programovacího jazyka

90 4.4.2008 90 Testování (OOSE)‏ integruje systém ověřuje implementašní systém Rozdělení: model testování

91 4.4.2008 91 Proces testování (OOSE)‏

92 4.4.2008 92 Model testování (OOSE)‏ popisuje výsledky testování testování začíná od nejnižších úrovní první se testují objekty a bloky poslední se testuje celý systém výsledky testů se zachovávají v rozhodovací tabulce, ke 1 značí uspěl a 0 neuspěl celkový test může být měřen podle důležitosti nebo porovnán s limit (pokud výsledky převýší limit, pak test prošel) pokud test selže, je selhání analyzováno, testy se opakují dokud systém neprojde

93 4.4.2008 93 Zhodnocení (OOSE)‏ metoda je silná v úvodní fázi analýzy v analýze požadavků jako první začala používat use case podpora celého životního cyklu vývoje sw produktu předpoklad, že je možné pomocí use case vyjádřit všechny sekvence a operace, což je u komplexních a expertních systémů nemožné převody mezi modely mohou být matoucí

94 4.4.2008 94 Příklad: Volejbalový tým tým se skládá z trenéra a hráčů. trenér i hráči mají přidělené login a heslo Trenér: přidává a odebírá tréninky a zápasy, přidává a odebírá hráče do/ze soupisky. Hráč: přihlašuje a odhlašuje se na/z tréninků a zápasů pro přihlášení na zápas musí být hráč zapsán v soupisce hráč se vyskytuje pouze na jedné soupisce v daný čas soupiska obsahuje seznam hráčů, kteří se mohou účastnit zápasů

95 4.4.2008 95 Příklad: OOD seznam požadavků, vize diagram tříd objektový diagram stavový diagram diagram interakcí

96 4.4.2008 96 Seznam požadavků, vize (1) (Příklad: OOD)‏ pouze dva druhy uživatelů – hráči a trenér Trenér: –má přidělen login a heslo –vypisuje a ruší tréninky –vypisuje a ruší zápasy –přidává a odebírá hráče na/ze soupisky Soupiska: –seznam hráčů, kteří se mohou účastnit zápasů

97 4.4.2008 97 Seznam požadavků, vize (2) (Příklad: OOD)‏ Hráč: –má přidělen login a heslo –přihlašuje a odhlašuje se na/z tréninků –pokud je uveden na soupisce, tak se přihlašuje a odhlašuje na/ze zápasů

98 4.4.2008 98 Diagram tříd (Příklad: OOD)‏ značí abstraktní třídu

99 4.4.2008 99 Objektový diagram (Příklad: OOD)‏

100 4.4.2008 100 Stavový diagram (Příklad: OOD)‏

101 4.4.2008 101 Diagram interakcí (Příklad: OOD)‏

102 4.4.2008 102 Příklad: OMT seznam požadavků (viz OOD)‏ kontextový diagram diagram tříd datový slovník scénář typických dialogů mapa událostí diagram událostí stavový diagram

103 4.4.2008 103 Kontextový diagram (Příklad: OMT)‏

104 4.4.2008 104 Diagram tříd (Příklad: OMT)‏

105 4.4.2008 105 Datový slovník (1) (Příklad: OMT)‏ Trenér: osoba, která trénuje hráče, účastní se tréninků a zápasů, vypisuje a ruší termíny tréninků a zápasů, edituje soupisku. Atributy jsou jméno, přijmení, bydliště, telefon, mail a licence. Hráč: osoba, která trénuje pod vedením trenéra, účastní se tréninků, pokud je osoba vedena na soupisce pak se může účastnit i zápasů, vyskytuje se pouze na jedné soupisce v daný okamžik. Atributy jsou jméno, příjmení, bydliště, telefon, mail, číslo registračky, platnost registračky, seznam předchozích klubů a post.

106 4.4.2008 106 Datový slovník (2) (Příklad: OMT)‏ Trénink: aktivita vykonávaná v určitém čase a na určitém místě. Vypisuje a ruší ji trenér. Hráči se na/z ní přihlašují a odhlašují. Atributy jsou datum, místo konání a počet lidí. Metody jsou přidat_trénink, odebrat_trénink, přidat_hráče, odebrat_hráče. Zápas: aktivita vykonávaná v určitém čase a na určitém místě. Vypisuje a ruší ji trenér. Hráči, kteří jsou vedeni na soupisce, se na/z ní přihlašují a odhlašují. Atributy jsou datum, místo konání a počet lidí. Metody jsou přidat_zápas, odebrat_zápas, přidat_hráče, odebrat_hráče. Soupiska: seznam hráčů, kteří se mohou účastnit zápasů. Atributy jsou název týmu a úroveň. Metody jsou přidat_hráče, odebrat_hráče.

107 4.4.2008 107 Scénář typických dialogů (1) (Příklad: OMT)‏‏ Trenér vloží požadavek na přidání zápasu do systému Systém požaduje heslo Trenér vloží heslo Systém ověří heslo, heslo ověřeno, OK Systém vloží termín zápasu

108 4.4.2008 108 Scénář typických dialogů (2) (Příklad: OMT)‏‏ Hráč vloží požadavek na přihlášení se na zápas Systém požaduje heslo Hráč vloží heslo Systém ověří heslo, heslo ověřeno, OK Hráč vloží požadavek na přihlášení se na zápas Systém ověří, zda je hráč na soupisce Soupiska ověřena, OK Systém potvrdí přihlášení

109 4.4.2008 109 Scénář typických dialogů (3) (Příklad: OMT)‏‏ s výjimkami: Trenér vloží požadavek na přidání zápasu do systému Systém požaduje heslo Trenér vloží heslo Systém ověří heslo, špatné heslo Systém nabídne znovu zadat login a heslo, heslo ověřeno, OK Systém vloží termín zápasu

110 4.4.2008 110 Scénář typických dialogů (4) (Příklad: OMT)‏‏ s výjimkami: Hráč vloží požadavek na přihlášení se na zápas Systém požaduje heslo Hráč vloží heslo Systém ověří heslo, špatné heslo Systém nabídne znovu zadat login a heslo, heslo ověřeno, OK Systém ověří, zda je hráč na soupisce Soupiska ověřena, jméno není na soupisce Systém požadavek zamítl

111 4.4.2008 111 Mapa událostí (Příklad: OMT)‏

112 4.4.2008 112 Diagram událostí (Příklad: OMT)‏

113 4.4.2008 113 Stavové diagramy (Příklad: OMT)‏

114 4.4.2008 114 Příklad: OOSE seznam požadavků (viz OOD)‏ use case model popis rozhraní model problémových oblastí model analýzy model návrhu diagram interakcí

115 4.4.2008 115 Use case (Příklad: OOSE)‏

116 4.4.2008 116 Popis rozhraní (Příklad: OOSE)‏

117 4.4.2008 117 Model problémových oblastí (Příklad: OOSE)‏‏

118 4.4.2008 118 Model analýzy (Příklad: OOSE)‏

119 4.4.2008 119 Model analýzy (2) (Příklad: OOSE)‏

120 4.4.2008 120 Model návrhu (1) (Příklad: OOSE)‏ Chování A rozšiřuje chování B. Je to implementováno tak, že stimul je posílán od B k A.

121 4.4.2008 121 Model návrhu (2) (Příklad: OOSE)‏

122 4.4.2008 122 Diagram interakcí (Příklad: OOSE)‏

123 4.4.2008 123 Vlastnosti správného diagramu (Příklad)‏ je normalizovaný umožňuje flexibilitu umožňuje znovupoužitelnost

124 4.4.2008 124 Shrnutí metody se samy o sobě výrazně neprosadily žádná z metod nebyla dostatečně silná ve všech fázích (analýza, návrh, implementace, testování)‏ největší význam metod je, že se spojily a vzniklo UML

125 4.4.2008 125 OOD diagram (Shrnutí)‏

126 4.4.2008 126 OMT diagram (Shrnutí)‏

127 4.4.2008 127 OOSE diagram (Shrnutí)‏

128 4.4.2008 128 Porovnání metod (Shrnutí)‏

129 4.4.2008 129 Vývoj k UML (1) (Shrnutí)‏

130 4.4.2008 130 Vývoj k UML (2) (Shrnutí)‏

131 4.4.2008 131 Vývoj k UML (3) (Shrnutí)‏


Stáhnout ppt "4.4.2008 1 Klasické metody objektové analýzy a návrhu."

Podobné prezentace


Reklamy Google