28. Vysvětlete pojem datové modelování, jaké datové modely znáte?

Datové modelování představuje jednu ze základních součástí analýzy každého softwarového projektu.

Vytváříme konceptuální datový model

• popisuje entity (typy objektů), atributy, modely, vztahy mezi nimi a integritní omezení

• model tříd popisuje i operace, často se však k modelu připojí až v návrhu

Vztahy mezi entitami jsou nejčastěji: 1:1, 1:N, M:N.

Používáme – ER diagramy, relační modely, UML Class diagram

Při tvorbě datového modelu si nejprve klademe otázku, které údaje musí být uchovány v systému.

Objekty, které jsou charakterizovány skupinou k sobě náležících údajů se nazývají datové entity.

E-R diagramy (entity-relationship, ERD) se nejčastěji používají pro grafické vyjádření datového modelu. Znázorňují datové objekty – entity a jejich vzájemné vztahy.

Příklad ERD : Studenti si volí jednotlivé předměty, tyto předměty vyučují učitelé.

Entity: Student, Předmět, Učitel

Vztahy (relace) mezi entitami: Učitel přednáší předmět, Učitel vede laboratoře v předmětu, Student studuje předmět.

Kontrola datového modelu

• je datový model úplný?

• existuje entita pro každý typ objektu?

• Nejsou zde nadbytečné entity (entity tvořené pouze identifikací, entity s jedinou instancí, apod.)?

• Jsou zde zaneseny všechny vztahy (včetně generalizací a agregací)?

• Nejsou zde odvoditelné vztahy?

• Je model v normální formě?

• Jsou zanesena všechna integritní omezení?

Příklad datového modelu je doménový model.

Diagram tříd

Diagram spolupráce

Diagram komponent

Diagram nasazení

29. Vysvětlete pojem funkční (procesní) modelování, jaké modely znáte?

Procesní modelování je nedílnou součástí analýzy, která slouží k detailní identifikaci a specifikaci procesů, jejich struktury, vlastníků, vstupů, výstupů, omezení apod. Procesní model poskytuje grafickou prezentaci, která zásadním způsobem usnadňuje spolupráci všech, kteří se procesní analýzy účastní nebo pouze využívají její výsledky.

Funkční (procesní) model

• popisuje služby, které systém poskytuje

• model jednání, scénáře, použití, popisy funkcí (minispecifikace – podle toho programátor pracuje)

• diagramy aktivit, funkční hierarchie (DFD – data flow diagram)

• notace

• pokud scénář obsahuje složitější aktivity, pak dekompozice těchto aktivit na jednodušší (scénáře, diagramy aktivit, hierarchická sada DFD - kontextový diagram + diagramy úrovně 0,1, ... + popis)

• d atový slovník

Model jednání, případy použití (use cases)

• vyjadřuje vztahy mezi Actors vně systému a Use Case uvnitř systému

• dokumentují možné případy použití systému – události na které musí systém reagovat

Tato část UML nejméně rozpracovaná část celé metodiky, lze v ní snad nalézt určitou analogii s DFD nejvyšší úrovně.

Diagramy datových toků (DFD), datové toky a datové paměti

• používají se pro zachycení vazeb funkcí a toků dat

Komponenty:

• funkce

• datové toky – orientované hrany vyznačující toky dat

• datové paměti – místa, kde si potřebujeme něco pamatovat

• aktéři – uživatelské role nebo spolupracující systémy

Scénáře činností (Sequence Diagrams)

• popisují scénáře průběhu určité činnosti v systému

• dokumentují spolupráci participantů na scénáři činnosti

• kladou důraz na časový aspekt komunikace

• dokumentují objekty a zprávy, které si objekty posílají při řešení scénáře

• jsou vhodné pro popis scénáře při komunikaci s uživateli

Diagramy aktivit (Activity Diagrams)

• p opisují průběh aktivit procesu či činnosti

• kromě stavů používáme aktivity

• nachází-li se systém v nějakém stavu, je přechod do jiného stavu iniciován nějakou vnější událostí

• u aktivity je, na rozdíl od stavu, přechod iniciován ukončením aktivity, přechody jsou vyvolány dokončením akce (jsou synchronní).

• používají se pro dokumentaci tříd, metod, nebo případů použití (jako „workflow“).

• nahrazují do určité míry v UML neexistující diagramy datových toků.

• mohou obsahovat symbol „rozhodnutí“.

Diagram spolupráce

Chceme-li v jednom diagramu znázornit jak strukturu objektů (například skládání objektů) tak i jejich dynamické chování, použijeme s výhodou diagramů spolupráce, které jsou vedle sekvenčních diagramů dalším prostředkem, jehož těžiště tkví v modelování dynamiky. Na rozdíl od sekvenčních diagramů je však znatelně obtížnější vysledovat návaznost jednotlivých posílaných zpráv zajišťujících samotnou funkcionalitu systému. Zatímco v sekvenčních diagramech je tato návaznost zřejmá z vertikálního uspořádání celého diagramu, v diagramech spolupráce je následnost zobrazena pořadovým číslem, kterým jsou zprávy uvozeny.

Tvorba diagramu spolupráce by měla být v souladu s diagramem tříd. Pro zachování vzájemné konzistence modelů je nezbytné dodržovat základní pravidla, která mezi těmito modely platí. Komunikace mezi objekty musí být například podmíněna existencí odpovídající vazby mezi jejich třídami, o existenci patřičných tříd nemluvě. Nemusíme asi ani zdůrazňovat, jak nevděčnou prací je "ruční" kontrolování obdobných pravidel. Je jasné, že zde mohou opět pomoci CASE nástroje. Docela seriózně lze prohlásit, že právě zde existuje hranice mezi skutečnými CASE systémy