Výstupem analýzy:

konceptuální model: - popisuje problém bez ohledu na platformu, implementaci, je na analytické úrovni

• datový (např. doménový model)

• popisuje entity, atributy (něco charakteristické), vztahy mezi nimi a integritní omezení (něco co je ještě potřeba říct)

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

• úplnost datového modelu, např.:

• Musí existovat entita pro každý objekt

• Vyloučit nadbytečné entity

• Zanést všechny vztahy

• Vyloučit odvoditelné vztahy

• Udržet model v normální formě

• Zanést všechny integritní omezení

• funkční model – co má systém dělat

• popisuje služby, které systém poskytuje (pro záznam, údržbu a využití dat)

• use cases, DFD (data flow diagram)

• úplnost funkčního modelu, např.:

• Úplnost datového modelu (metoda pro každou událost, každá funkce/metoda musí být popsána)

• Vyloučit nadbytečné funkce a metody

• dynamický model – popisuje se stavovým diagramem

• popisuje možné stavy dat a jejich změny

• diagram aktivit, stavy systému, události a reakce na ně

• úplnost dynamického modelu:

• Úplnost dynamického modelu (model pro každou entitu, i včetně různých vztahů)

• Existence modelu pro každý řídící proces

• Existence popisu životního cyklu systému

Kontrola výstupů analýzy - verifikace

• Kontrola jednotlivých modulů

• Kontrola vzájemné konzistence modulů

2. Co je smyslem modelem řízeného vývoje (mda, resp. Mdd)?

MDA – Model driven architecture – oddělené analytického pohledu od pohledu návrhu a implementace, založena na XML, UML, ...

MDD - Model Driven Development - využívá jako vyjadřovací prostředek UML modelů, jelikož celý systém je vytvářen na základě modelování. Modely MDD jsou zpočátku obecné a postupem vývoje jsou upřesňovány. Konečný produkt je složením přesně specifikovaných a již implementovaných modelů. Díky průběžnému návrhu a stálému upřesňování, lze velmi jednoduše vytvářet k danému produktu dokumentaci.

Konsorcium Object Management Group si je vědomo úskalí použití UML různými rolemi ve vývojových týmech a nabízí pohled na tvorbu softwarových systémů trochu z jiného úhlu, a to ve formě specifikace Model Driven Architecture.

Co to je MDA?  Model Driven Architecture vidí modely aplikací ve čtyřech úrovních:

• CIM – model nezávislý na počítačovém zpracování

• PIM – platformově nezávislý model řešení

• PSM – platformově specifický model řešení

• Code – kód aplikace, tj. výsledná realizace řešení

CIM – Computation Independent Model  Model nezávislý na počítačovém zpracování je de facto modelem vlastního "businessu". Jedná se především o model procesů. Jeho notace však není v UML standardizována (ani v chystané verzi UML 2.0), nicméně se dá pro tyto účely "přiohnout" diagram aktivit. Dále je to slovník pojmů problémové oblasti, který se dá u složitějších oblastí vyjádřit pomocí konceptuálního modelu tříd. Tento model vytvářejí buď sami uživatelé nebo business analytici.

PIM – Platform Independent Model  Platformově nezávislý model reprezentuje koncepci řešení dané problémové oblasti na základě konkrétních požadavků. Jeho hodnota je především ve vyřešení koncepčních otázek, jako jsou třeba algoritmy zaskladňování a vyskladňování v případě skladů, nebo způsob párování saldokontních položek v účetnictví. Tento model však neobsahuje informace spojené s konkrétní technologií realizace a vytvářejí ho IT analytici.

PSM – Platform Specific Model  Model řešení na dané platformě (např. J2EE nebo C# a ASP.NET) je podkladem pro vlastní implementaci. Důležité je to, že PSM má stejnou strukturu jako kód aplikace. Tento model vytvářejí návrháři.

Code  Z hlediska MDA je zdrojový kód chápán také jako model konkrétní realizace na dané platformě. Konec konců určitě každý zná ze svého okolí aplikace, kde jedině tento model skutečně odpovídá realitě toho, co aplikace dělá.

Co je v MDA objevného?  Z uvedeného výčtu by se mohlo zdát, že OMG "vymyslelo kolo", neboť to, že je potřeba vytvářet analytický model (PIM) a návrhový model (PSM), víme již dávno. Nicméně síla MDA není ani tak v členění modelů, jako v tom, že definuje způsob a postup transformace modelů. Opět se nejedná o žádnou magii, ale o aplikaci osvědčených praktik, především zkušeností z použití návrhových vzorů (Design Patterns). Nejzajímavější je otázka transformace platformově nezávislého modelu (PIM) do platformově specifického modelu (PSM).

Transformace PIM -> PSM  Postup transformace dle MDA je zhruba následující:

1. PIM model je doplněn mapovacími značkami, které definují, jaká obecná transformační pravidla budou použita.

2. Pro PIM model (resp. jeho části) je zvolena implementační platforma.

3. Na základě mapovacích značek jsou provedeny odpovídající transformace již s ohledem na zvolenou platformu.

Tento postup je schematicky znázorněn na následujícím obrázku spolu se snímkem "značkování" PIM modelu.

MDA mapovací značkou je obecně definováno, jakým způsobem bude realizována asociace, kterou vytvořil analytik. Jedná se v podstatě o přiřazení obecnějšího návrhového vzoru příslušnému modelovému elementu. Konkrétní způsob realizace pak může být pro různé platformy jiný, takže z jednoho "značkovaného" modelu PIM je možné odvodit různé PSM modely.

Při tvorbě PSM modelu pro zvolenou platformu je pak rozvinut aplikovaný návrhový vzor, čímž dojde k doplnění příslušných implementačních atributů, operací nebo i celých tříd a tím vznikne základ platformově specifického modelu. Důležité je to, že přidané implementační prvky jsou označeny jako modelově závislé (MDA doporučuje používat značku řecké pí) a ve výsledném PSM modelu je tak dobře vidět, co jsou prvky převzaté z analýzy a které prvky byly přidány až v návrhu.

Kde je flexibilita?  Přínos koncepce Model Driven Architecture je tedy především v tom, že jasně definuje, co je analytický model, co je návrhový model a jak provádět jejich transformaci. Cílem je, aby aplikace byla popsána na různých úrovních abstrakce a tím pádem je značně usnadněno konzistentní promítání změn v aplikaci. Další pozitivní důsledek je standardizace návrhu, která umožňuje zvýšit kvalitu aplikací. A co je důsledkem toho všeho? Především snížení nákladů na údržbu aplikací, tedy peníze, o které jde jako obvykle až v první řadě.