Opakování

1. UOMO Ing. Monika Šimková monika.simkova@uhk.cz Opakování

2. Cvičení 4 – Typové úlohy • Cvičení 5 - Scénáře • Cvičení 6 – Analytický model tříd • Cvičení 7 – Sekvenční diagram • Cvičení 8 – Návrhový model tříd Konzultace

3. Cvičení 4 – Typové úlohy • Specifikace požadavků systému se provádí ve fázích Zahájení a Rozpracování • Jedná se o přehled množiny, která zahrnuje co má systém dělat. • Požadavky vyplývají z kontextu systému: • (přímí uživatelé, ostatní osoby (manažeři, správci), další systémy, hardwarová zařízení, právní omezení, obchodní cíle). • Rozlišujeme funčknía nefukunčnípožadavky: Modelování požadavků – CV4

4. Funkční : • - definují funkce systému (požadavek CO má systém dělat – ne JAK!, tzv. „případ užití“ = „use case“, - - modelují se pomocí Use Case diagramu • - např. (1) Systém bude ověřovat validitu uživatele). • Non-funkční: • – definují omezení kladená na systém, mají podobu katalogového záznamu • - např. software bude napsán v jazyce Java, systém bude reagovat na ___ do 3 sekund, atd.) FunkčníXNon-funkční

5. Vyhledání aktérů a případů užití (= Use Case) • Detail případu užití (=scénář) • Struktura modelu případů užití (=Use Case Diagram) • Případy užití se modelují proto, abychom pochopili požadované chování systému – ne proto, abychom vytvořili kompletní model případů užití USE CASE DIAGRAM

6. Aktér • - role, kterou entita přijímá při používání systému (nezaměňovat s konkrétními osobami; osoba může mít více rolí) • - je vůči systému externí entitou • - komunikují se systémem • - Aktéry mohou být konkrétní osoby, systém či čas AKTÉR

7. Aktéři toho mají hodně společného, a tak nám generalizace umožní vyčlenit toto společné chování zjednodušit tak i náš model.

8. - Popisuje funkce systému, akci • - Nemodelují non-funkční požadavky • - Je vždy iniciován aktérem • - Je vždy popsán z pohledu aktéra • - Pojmenovávat slovesnou vazbou (při popisu užívejte tzv. CamelCase!) • o NalezeniProduktu, RozeslaniNotifikace, VytvoreniUdalostiVKalendari • - Vytváření, čtení, aktualizaci a mazání nemodelovat jako typové úlohy, ale jako kroky scénáře Případ užití

9. Relace use, include, extend • <<include>> vyčleňuje kroky společné několika případům užití do samostatného případu užití • <<extend>> umožňuje do existujícího případu užití vložit nové, volitelné chování Relace use, include, extend

10. Scénáře – Cvičení 5

11. Diagram tříd (Class Diagram) • • Je základním strukturálním diagramem • • Jeho smyslem je popsat stavební prvky • systému (třídy) a jejich vzájemné vztahy • • Vychází z požadované funkcionality, • definované v Use-Case diagramu • • Využívá se pro modelování struktury • více úrovní informačního systému Cvičení 6 – Analytické třídy

12. • Základem diagramu tříd jsou: • – třídy objektů - objektem může být jakákoliv • existence, která ovlivňuje život firmy, nebo • jej zobrazuje, např. Člen, zápůjčka, titul. • – atributy - definují vlastnosti tříd, jako např. • jméno člena, adresa • – metody (operace, funkce) - vytvářejí • chování objektu a realizují požadovanou • funkcionalitu systému • – asociace - definují vztahy na další objekty • (např. vazba mezi členem a členským • účtem) Diagram tříd

13. Tvorba diagramu tříd • • Diagram se vytváří ve dvou fázích • – Identifikace analytických tříd – definuje • základní logické celky a jejich vztahy, bez • implementačních detailů. Převážnou část • modelu tvoří tzv. doménové třídy (objekty). • – Identifikace návrhových tříd – • rozpracovávají analytické třídy do • implementační podoby. Doplňují se třídy • rozhraní, řídící a podpůrné třídy. AnalytickýxNávrhový

14. Identifikace tříd – datový přístup • Kroky identifikace analytických tříd • 1. Analýza scénářů typových úloh, pojmů problémové • domény a dalších zdrojů informací a identifikace • podstatných jmen resp. entit jako kandidátů na objekty • 2. Určení entit schopných samostatné existence jako • objektů a seskupení do tříd (nepodstatné se eliminuje) • 3. Entity, které nemohou samostatně existovat představují • atributy tříd (např. výška, cena, atd.) • 4. Doplnění dalších informací, které entity vyžadují nebo • produkují • 5. Identifikace sloves jako činností resp. operací, které by • měl systém vykonávat a přiřazení k třídám • 6. Doplnění dalších metod pracujících nad množinou • atributů dané třídy • 7. Doplnění vztahů a závislostí mezi třídami Kroky identifikace analytických tříd – datový přístup

15. Kroky identifikace analytických tříd • 1. Analýza scénářů typových úloh, pojmů problémové • domény a dalších zdrojů informací tj. hledání činností, • které musí provádět systém, aby realizoval vybrané • kroky scénářů typových úloh • 2. Navržení metod zodpovídajících za identifikované • činnosti • 3. Rozmístění metod do analytických rozhraní dle • hlediska soudržnosti (metody pracují s jednou skupinou • dat, se stejnou mírou podrobnosti, minimalizace vztahů • a závislostí) • 4. Navržení analytických tříd, realizujících analytická • rozhraní – třídy musí být obrazem entit reality s jasným • významem a zodpovědností • 5. Doplnění atributů a dalších metod do tříd - identifikace • na základě reálných vlastností entit (primární a • vypočtené atributy, podpůrné metody). • 6. Doplnění vztahů a závislostí mezi třídami Kroky identifikace analytických tříd – funkční přístup

16. • Špatné názvy tříd – názvy analytických tříd • odpovídají názvům používaným v dané • oblasti (Zakazka, Faktura, Objednavka, ….); • – Technické názvy tříd - v analytickém modelu je • vhodné se vyhnout třídám jako Database, Data, • Udaje, System, … • – Názvy tříd jako aktivity – Nacteni, Otevreni, • Ulozeni – nejsou vhodné názvy pro třídy • • Špatné názvy metod – např. zpracujUdaje – • není jasné jaké údaje a jak mají být • zpracovány -> není možné vhodně přiřadit ke • třídě Nejčastější chyby

17. • Je prostředníkem mezi rozhraním a daty, • realizátorem služeb systému • • Skládáse z řídících a pomocných tříd • • Třídy se identifikují z požadovaného chování • a služeb (v rámci typových úloh) • • Odrážejí firemní pravidla (business rules) • • Zajišťují i nízkoúrovňové operace – • komunikace, podpůrné služby, atd. • • Velká znovupoužitelnost (využití knihoven) Model aplikační logiky

18. Sekvenční diagram – interakce objektů v čase v rámci plnění určitého scénáře typové úlohy; není určen k zobrazení relací jednotlivých objektů Sekvenční diagram Cvičení 7

19. Modelování objektových interakcí je nástrojem • realizacepřípadůužití (use case) – tzn. pro • popis, JAK budou jednotlivé typové úlohy • realizovány (implementovány) • • Modelování objektových interakcí slouží k • popisu spolupráce instancí tříd pro dosažení • požadovaného chování systému • • Modelování objektových interakcí popisuje • jakým způsobem objekty realizují jednotlivé • typové úlohy pomocí své spolupráce • (interakce) Modelování objektových interakcí

21. Návaznost na předchozí modely • • Diagram typových úloh definuje třídy uživatelů • (aktérů) a požadovanou funkčnost systému. • • Diagram tříd definuje vnitřní strukturu systému • a jednotlivých objektů, ale neříká nic o tom, • jak budou vzájemně spolupracovat v typových • úlohách prostřednictvím operací (zpráv) • • Objektové interakce demonstrují dynamické • chování, které se vyskytuje mezi objekty za • účelem realizace jednotlivých typových úloh Návaznost

22. • ObjectInteraction Modeling (OIM) je možno • použít: • – V analýze systému – k ověření úplnosti modelu • typových úloh i jednotlivých scénářů typových úloh. • Mnohdy i ke grafickému popisu vnitřního průběhu • typových úloh namísto (textových) scénářů. • Pomáhá pochopit problém a potvrdit třídy a • operace • – V návrhu systému – k detailnímu popisu vnitřního • chování systému pomocí modelování zasílání • zpráv mezi objekty. Zatímco v diagramu tříd přísně • rozlišujeme úrovně objektů (interface, business a • storage), zde modelujeme průnik mezi úrovněmi • uživatelského rozhraní, firemních objektů a objektů • uložení Interakce

23. Interakce – popisuje dynamickou interakci • mezi instancemi. Popisuje zprávy, které si • instance navzájem předávají. Dříve, než • mohou instance spolupracovat, musí • navzájem navázat příslušnou relaci (musí o • sobě vědět). K interakci může tedy dojít • pouze v kontextu spolupráce (pouze mezi • asociací provázanými instancemi tříd). Interakce

24. Sekvenční diagram • • Slouží k zobrazení interakcí ve vztahu k času • • Jeho účelem je přehledně, v časové ose, • modelovat zasílání zpráv mezi objekty, za • účelem naplnění (realizace) jednotlivých kroků • interakce mezi uživatelem a systémem • (scénáře typové úlohy) • – Časová osa diagramu běží shora dolů (vertikálně) • • Diagram je mapován (přiřazen) k jedné typové • úloze • • K tomu, abychom mohli definovat interakce • mezi objekty musíme rozšířit model typových • úloh o podrobné popisy kroků interakce mezi • systémem a aktérem (podrobné scénáře) Interakce

25. • Model návrhových tříd rozpracovává • analytické třídy do takové podrobnosti, že je • lze implementovat • • Na rozdíl od modelu analytických tříd je již • implementačnězávislý (je určen pro konkrétní • jazyk) • • Návrhové třídy vznikají • – Postupným upřesňováním analytických tříd (z • analytické třídy může vzniknout několik • návrhových) • – Doplňováním tříd rozhraní, řídících a podpůrných • tříd (daných např. technologiemi a architekturou) • – Ze znovupoužitelných komponent (knihovny apod.) Cvičení 8 - Návrhové třídy

26. • doplnění datových typů atributů • • určení návratových hodnot metod • • doplnění parametrů metod • • doplnění přístupových metod • • doplnění výchozích hodnot atributů event. • parametrů • • doplnění konstruktorů a destruktorů • • určení viditelnosti atributů a metod • • zavedení pomocných tříd u atributů s vnitřní • strukturou (např. Adresa) • • využití tříd v knihovnách implementačního • prostředí (např. Date, Time, …) • • zpřesnění relací • • zavedení vztahu dědičnosti Rozpracování návrhových tříd

27. • konstruktory – zajišťují vytvoření instance z dané třídy • (alokace paměti, nastavení výchozích hodnot atributů, …); • v jazyce JAVA a C# se název konstruktoru shoduje s • názvem třídy (case senzitivně); • • destruktory – provádí rušení instance (uvolňují paměť) • • selektory – slouží pro čtení hodnot atributu resp. pro • zjišťování stavu nikoliv pro změnu stavu (označovány jako • tzv. metody get) • • modifikátory – slouží pro nastavení hodnot atributů, • provádí činnosti spojené se zajištěním konzistence objektu • i po nastavení dané hodnoty (např. ověření zda hodnota • odpovídá omezením) – označovány jako tzv. metody set • • výkonné metody – zajišťují požadované chování objektu; • provádí vlastní zpracování dat; vycházejí z analytických • operací v analytickém modelu tříd • – hlavní – tvoří součást rozhraní třídy; využívají vedlejších • metod pro lepší strukturování kódu; bývají veřejné • – vedlejší – slouží pro lepší strukturování kódu; provádí • určitou část daného úkolu; většinou jsou privátní Typy metod

28. • Určuje, kdo může využívat jednotlivé členy • třídy • • Možnosti • – public (+) – členy jsou přístupné pro všechny • ostatní třídy (objekty) • – private(-) – členy třídy jsou přístupné jen v rámci • dané třídy • – protected(#) – členy jsou přístupné pro třídu • samotnou a třídy, které jsou ve vztahu gen.spec. • – package(~) – členy jsou viditelné pro třídy v • daném balíčku • • Atributytřídy by mělybýt private; Viditelnost členů třídy

29. Základní datové typy (JAVA – obdoba je i v jiných • jazycích) • – int - celá čísla (1;2;10;254) • – double – čísla s desetinnou čárkou (12,5;24,369;…) • – char – jeden znak (‘*’) • – String–řetězec znaků („Ahoj“) • • Výchozí hodnota – je dobrým zvykem pro každý atribut • doplnit výchozí hodnotu; výchozí hodnota je většinou • neutrální hodnotou v daném oboru; • – 0 –pro číselné hodnoty • – ““ – pro řetězcové hodnoty - prázdný řetězec (dvoje uvozovky bez • mezery) • – null – pro atributy neprimitivních atributů • – newNazevTridy() – inicializace neprimitivních atributů novou instancí • ze třídy NazevTridy; např „newDate()“ Datové typy

30. • určení typu asociace (rozlišení agregace a • kompozice – určení odpovědnosti za • vytváření instancí) • • určení viditelnosti vazby (viz viditelnost členů • třídy) • • zavedení kolekcí • • určení řiditelnosti – určení jakým směrem lze • zasílat zprávy (určení že zdrojový objekt • ponese odkaz na cílový objekt) • • odstranění asociativních tříd – asociativní • třídy nejsou v prog. jazycích podporovány Zpřesnění relací

31. Užitková třída

32. Asociace 1:1

33. Použití kolekceAsociace 1:N

34. Použití kolekce1:N