Model driven architecture: Porovnání verzí

Z Wikipedie, otevřené encyklopedie
Smazaný obsah Přidaný obsah
Přesměrování na Model driven architecture
Vytvoření stránky
Řádek 1: Řádek 1:
'''MDA''', '''Model Driven Architecture''' (Modelem řízená [[architektura]]) je [[specifikace]] konsorcia [[OMG]] <ref name="OMG">OMG: „MDA Guide Version 1.0.1“,
#REDIRECT [[Model driven architecture]]
el. zdroj: http://www.omg.org/docs/omg/03-06-01.pdf, June 2007</ref> založená na pevně stanovených standardech této skupiny. Tento [[koncept]] přináší „nový“ přístup v oblasti vývoje a především údržby informačních systémů, který je založen na klasickém [[OOP]]. Hlavní myšlenkou MDA je oddělit business a aplikační logiku od technologické platformy. Tato myšlenka není nikterak nová, potřeba vytvářet analytický a návrhový [[model]] tu existuje poměrně dlouho. To, co MDA přináší nového, jsou postupy a způsoby, jak tyto modely správně transformovat. Primárními cíly tohoto přístupu jsou zajištění přenosnosti, interoperability (součinnosti) a znuvupoužitelnosti díky oddělené architektury.

;MDA poskytuje obecný přístup jak:
*Specifikovat systém nezávisle na platformě na které je systém vystavěn<br />
*Specifikovat [[platformy]]<br />
*Vybrat konkrétní platformu <br />
*Transformovat systém podle zvolené platformy<br />

;MDA člení architekturu na čtyři úrovně:
*Model nezávislý na počítačovém zpracování ([[CIM]])<br />
*Model nezávislý na platformě ([[PIM]])<br />
*Model specifický na konkrétní platformě ([[PSM]])<br />
*[[Zdrojový kód]] [[aplikace]] (výsledná implementace)<br /><br />

== Computation Independent Model (CIM) ==
Model, též známý jako [[doménový model]], se zaměřuje výhradně na prostředí a obecné požadavky systému a jeho detailní struktura a konkrétní zpracování jsou v této fázi skryté nebo dosud neurčené. Tento model reflektuje „business“ požadavky zákazníka a pomáhá přesně popsat to, co se od systému očekává. Proto musí být nezávislý na technickém zpracování a popisovat systém čistě věcně a logicky. Předpokládá se, že uživatel těchto modelů je člověk, který není obeznámen s modely nebo konstrukcemi užívaných k vyjádření funkčnosti těch požadavků, které jsou právě specifikované v CIM. Nejčastějšími uživateli tohoto typu modelů jsou „business“ analytici případně sami uživatelé systému. Tento druh zobrazení neslouží pouze jako prostředek k pochopení problémů a vymezení problémové oblasti, ale také jako jakýsi sdílený zdroj pojmů (slovník problémové oblasti), které se používají v jiných modelech (úrovních MDA) nebo pro další [[modelovaní]] na stejné úrovni. Ve skutečnosti mohou být tyto modely např. procesní modely, [[Use case]] diagramy případně diagramy činností.

== Platform Independent Model (PIM) ==
Tento model se zabývá tou částí kompletní specifikace systému, která se nemění podle konkrétního druhu zvolené platformy. PIM totiž zprostředkovává určitou míru nezávislosti konkrétního řešení dané problémové oblasti tak, aby se hodila na různé platformy podobného typu. Popisuje chování (algoritmy) a strukturu aplikace opravdu jen v těch mezích, které zajistí jeho přenositelnost mezi různými technologickými řešeními. Oproti předcházejícímu modelu je doplněn o ty informace (algoritmy, principy, pravidla, omezení…), které jsou nezbytně důležité k řešení dané problémové oblasti prostřednictvím informačních technologií. Ovšem je důležité poznamenat, že tento model přesně nevychází z CIM, nýbrž si z něho obvykle [[IT]] analytik vybere pouze to podstatné, co se považuje za smysluplné pro potřeby počítačového zpracování konkrétní problémové oblasti. Transformace z modelu CIM do PIM obvykle neprobíhá automaticky, je to dáno především odlišným charakterem těchto modelů, kde PIM je model struktury (objektový model), kdežto CIM je spíše procesní model. Tento přechod probíhá skrze Use Case scénáře, které přiblíží procesní model k objektovému. Velkou výhodou PIM modelu je jeho znovupoužitelnost a proto může posloužit jako výchozí bod pro různá zadání.

== Platform Specific Model (PSM) ==
Poslední model (pokud se nebere v úvahu zdrojový kód) specifikace MDA, který je již závislý na cílové platformě, kombinuje PIM s konkrétním technologickým řešením (např. [[.NET]], [[J2EE]], [[Corba]]). Tento model věrně odráží strukturu kódu a proto je již dostatečným podkladem pro implementaci, de facto se jedná o vizualizaci kódu na stejné úrovni abstrakce. Vyskytují se v něm objekty, které úzce souvisí se zvoleným technologickým prostředím (např. operace pro přístup k atributům, konstruktory a destruktory tříd,…). Příkladem jsou třídy specifické pro danou platformu, které dovolují komunikovat s balíkem objektů běžně dodávaných s vývojovou platformou. [[Databázový model]] (model [[relační databáze]]) lze považovat také za PSM.

== Transformace modelu PIM do PSM ==
Jedná se o proces aplikace konkrétních transformačních pravidel na model nezávislý na platformě, jenž vyústí v PSM. Otázkou je, jaká transformační pravidla mají být použita u konkrétních elementů z PSM. MDA specifikace popisuje hned několik způsobů, jak vytvořit (mapovat) tyto vazby (v čemž spočívá asi jeho největší přínos).
Jednou z možností je mapovat přes meta-modely, kdy jednotlivé typy elementů jak v PIM tak v PSM, jsou specifikovány ve dvou odlišných tzv. [[MOF]] („Meta Object Facility“) meta-modelech. V tomto případě jsou určena jasná mapovací pravidla (algoritmy) určující protějšky ke konkrétním typům v meta-modelu PIM z meta-modelu PSM. Jedná se vlastně o překlad z meta jazyka uřčeného pro modelování v PIM do meta jazyka sloužícího k vyjádření typově různých elementů závislých na dané platformě (viz. následující obr.).
[[Soubor:transformation_PIM2PSM.jpg|none|PIM transformace do PSM]]
Dalším přístupem je mapování prostřednictvím tzv. značek. Těmito značkami se označí jednotlivé elementy a tím se určuje, jakým způsobem budou transformovány. Slouží tedy jako identifikátory pro transformační pravidla. Jednoduchým příkladem značky by mohla být „Entita“, která může být aplikována na nějakou třídu nebo jiný objekt z PIM. Složitější ukázkou je případ, kdy je více elementů modelu osázeno značkami, které dohromady tvoří identifikovatelnou sadu. K této sadě je jasně definována transformační šablona např. v podobě [[návrhového vzoru]]. A aby to nebylo jednoduché, je také možno jednomu elementu přiřadit více značek. To indikuje, že tento prvek hraje roli ve více než jednom mapování a proto také bude podle každého z nich transformován. Ve výsledku se to může projevit jak dodatečnou vlastností stejně tak jako novým elementem v PSM.
[[Soubor:transformation_PIM2PSM_nextway.jpg|none|PIM transformace do PSM]]
V reálu se k transformaci používá obvykle kombinace obou výše uvedených přístupů. Mapování pomocí meta-modelu totiž v sobě skrývá omezení, které nedovoluje více instancím jedno typu z PIM přiřadit různé protějšky z PSM. Tato neschopnost, dodatečně přidat potřebné informace, dělá tento způsob silně deterministickým. Proto některé charakteristické typy s PIM musejí být opatřeny značkou za účelem detailnějšího specifikování. Na druhou stranu každá transformace jednotlivých elementů v sobě přepokládá určitá typová omezení, kterých bych se každý návrhář měl držet, aby výsledná transformace měla vůbec nějaký smysl. To znamená, že každý typ elementu v PIM má implicitně definovanou sadu značek, kterými ho lze označit. Výsledkem každé transformace je, jak již bylo uvedeno, platformově specifický model a dále záznam o transformaci. Ten v sobě zahrnuje mapu, která ukazuje jaké druhy transformací byly použity pro konkrétní druhy mapování, což umožňuje provádět transformaci i v opačném směru. Tyto informace v důsledku pomáhají lépe synchronizovat jednotlivé vrstvy na různých úrovních abstrakce a tak dosáhnout lepší konzistence.

== Shrnutí ==
MDA nelze považovat za sjednocující standard. Hlavně proto, že neposkytuje přesnou metodiku (jedná se o velmi obecný standard), a také že jde o poměrně složitý koncept, který je neustále v procesu standardizace a vývoje, jenž je nasaditelný jen v určitých případech. Na druhou stranu MDA poskytuje řadu výhod, zjednodušuje analýzu, návrh, implementaci a integraci aplikací včetně i těch velkých a komplexních systémů. Celkově MDA přináší výhodu v podobě snadné přenositelnosti aplikace mezi jednotlivými platformami a dokonce umožňuje křížit jednotlivé platformy, pokud to architektura aplikace dovoluje nebo vyžaduje. Tento koncept bude mít určitě i nadále své místo v oblasti vývoje [[IS]], lze to usoudit z jeho rozšíření v praxi v posledních letech, která se projevuje jako rostoucí podpora MDA v [[CASE]] nástrojích.

== Literatura ==

{{Citace periodika
| příjmení = Lébl
| jméno = Jan
| autor =
| odkaz na autora =
| spoluautoři =
| titul = MDA technologie pro vývoj podnikových IS
| periodikum = Connect!
| odkaz na periodikum =
| rok = 2005
| měsíc = 10
| ročník =
| číslo =
| strany = 10-12
| url =
| issn =
}}

{{Citace monografie
| příjmení = Kolář
| jméno = Vít
| odkaz na autora =
| titul = Vazba mezi CASE nástroji a vývojovými prostředími (automatické generování kódu, automatický reverzní engineering
| vydavatel = VŠE FIS, Katedra informačních technologií
| místo = Praha
| rok = 2008
| isbn =
| kapitola = 5
| strany =
| jazyk =
}}

{{Citace monografie
| příjmení = Kohoutek
| jméno = Roman
| odkaz na autora =
| titul = MDA – Model Driven Architecture
| vydavatel = Fakulta informatiky Masarykovy univerzity, presentace Technology Preview Party
| místo = Brno
| rok = 2006
| isbn =
| kapitola =
| strany =
| jazyk =
}}

== Reference ==
<references />

Verze z 22. 1. 2010, 16:12

MDA, Model Driven Architecture (Modelem řízená architektura) je specifikace konsorcia OMG [1] založená na pevně stanovených standardech této skupiny. Tento koncept přináší „nový“ přístup v oblasti vývoje a především údržby informačních systémů, který je založen na klasickém OOP. Hlavní myšlenkou MDA je oddělit business a aplikační logiku od technologické platformy. Tato myšlenka není nikterak nová, potřeba vytvářet analytický a návrhový model tu existuje poměrně dlouho. To, co MDA přináší nového, jsou postupy a způsoby, jak tyto modely správně transformovat. Primárními cíly tohoto přístupu jsou zajištění přenosnosti, interoperability (součinnosti) a znuvupoužitelnosti díky oddělené architektury.

MDA poskytuje obecný přístup jak
  • Specifikovat systém nezávisle na platformě na které je systém vystavěn
  • Specifikovat platformy
  • Vybrat konkrétní platformu
  • Transformovat systém podle zvolené platformy
MDA člení architekturu na čtyři úrovně
  • Model nezávislý na počítačovém zpracování (CIM)
  • Model nezávislý na platformě (PIM)
  • Model specifický na konkrétní platformě (PSM)
  • Zdrojový kód aplikace (výsledná implementace)

Computation Independent Model (CIM)

Model, též známý jako doménový model, se zaměřuje výhradně na prostředí a obecné požadavky systému a jeho detailní struktura a konkrétní zpracování jsou v této fázi skryté nebo dosud neurčené. Tento model reflektuje „business“ požadavky zákazníka a pomáhá přesně popsat to, co se od systému očekává. Proto musí být nezávislý na technickém zpracování a popisovat systém čistě věcně a logicky. Předpokládá se, že uživatel těchto modelů je člověk, který není obeznámen s modely nebo konstrukcemi užívaných k vyjádření funkčnosti těch požadavků, které jsou právě specifikované v CIM. Nejčastějšími uživateli tohoto typu modelů jsou „business“ analytici případně sami uživatelé systému. Tento druh zobrazení neslouží pouze jako prostředek k pochopení problémů a vymezení problémové oblasti, ale také jako jakýsi sdílený zdroj pojmů (slovník problémové oblasti), které se používají v jiných modelech (úrovních MDA) nebo pro další modelovaní na stejné úrovni. Ve skutečnosti mohou být tyto modely např. procesní modely, Use case diagramy případně diagramy činností.

Platform Independent Model (PIM)

Tento model se zabývá tou částí kompletní specifikace systému, která se nemění podle konkrétního druhu zvolené platformy. PIM totiž zprostředkovává určitou míru nezávislosti konkrétního řešení dané problémové oblasti tak, aby se hodila na různé platformy podobného typu. Popisuje chování (algoritmy) a strukturu aplikace opravdu jen v těch mezích, které zajistí jeho přenositelnost mezi různými technologickými řešeními. Oproti předcházejícímu modelu je doplněn o ty informace (algoritmy, principy, pravidla, omezení…), které jsou nezbytně důležité k řešení dané problémové oblasti prostřednictvím informačních technologií. Ovšem je důležité poznamenat, že tento model přesně nevychází z CIM, nýbrž si z něho obvykle IT analytik vybere pouze to podstatné, co se považuje za smysluplné pro potřeby počítačového zpracování konkrétní problémové oblasti. Transformace z modelu CIM do PIM obvykle neprobíhá automaticky, je to dáno především odlišným charakterem těchto modelů, kde PIM je model struktury (objektový model), kdežto CIM je spíše procesní model. Tento přechod probíhá skrze Use Case scénáře, které přiblíží procesní model k objektovému. Velkou výhodou PIM modelu je jeho znovupoužitelnost a proto může posloužit jako výchozí bod pro různá zadání.

Platform Specific Model (PSM)

Poslední model (pokud se nebere v úvahu zdrojový kód) specifikace MDA, který je již závislý na cílové platformě, kombinuje PIM s konkrétním technologickým řešením (např. .NET, J2EE, Corba). Tento model věrně odráží strukturu kódu a proto je již dostatečným podkladem pro implementaci, de facto se jedná o vizualizaci kódu na stejné úrovni abstrakce. Vyskytují se v něm objekty, které úzce souvisí se zvoleným technologickým prostředím (např. operace pro přístup k atributům, konstruktory a destruktory tříd,…). Příkladem jsou třídy specifické pro danou platformu, které dovolují komunikovat s balíkem objektů běžně dodávaných s vývojovou platformou. Databázový model (model relační databáze) lze považovat také za PSM.

Transformace modelu PIM do PSM

Jedná se o proces aplikace konkrétních transformačních pravidel na model nezávislý na platformě, jenž vyústí v PSM. Otázkou je, jaká transformační pravidla mají být použita u konkrétních elementů z PSM. MDA specifikace popisuje hned několik způsobů, jak vytvořit (mapovat) tyto vazby (v čemž spočívá asi jeho největší přínos). Jednou z možností je mapovat přes meta-modely, kdy jednotlivé typy elementů jak v PIM tak v PSM, jsou specifikovány ve dvou odlišných tzv. MOF („Meta Object Facility“) meta-modelech. V tomto případě jsou určena jasná mapovací pravidla (algoritmy) určující protějšky ke konkrétním typům v meta-modelu PIM z meta-modelu PSM. Jedná se vlastně o překlad z meta jazyka uřčeného pro modelování v PIM do meta jazyka sloužícího k vyjádření typově různých elementů závislých na dané platformě (viz. následující obr.).

PIM transformace do PSM
PIM transformace do PSM

Dalším přístupem je mapování prostřednictvím tzv. značek. Těmito značkami se označí jednotlivé elementy a tím se určuje, jakým způsobem budou transformovány. Slouží tedy jako identifikátory pro transformační pravidla. Jednoduchým příkladem značky by mohla být „Entita“, která může být aplikována na nějakou třídu nebo jiný objekt z PIM. Složitější ukázkou je případ, kdy je více elementů modelu osázeno značkami, které dohromady tvoří identifikovatelnou sadu. K této sadě je jasně definována transformační šablona např. v podobě návrhového vzoru. A aby to nebylo jednoduché, je také možno jednomu elementu přiřadit více značek. To indikuje, že tento prvek hraje roli ve více než jednom mapování a proto také bude podle každého z nich transformován. Ve výsledku se to může projevit jak dodatečnou vlastností stejně tak jako novým elementem v PSM.

PIM transformace do PSM
PIM transformace do PSM

V reálu se k transformaci používá obvykle kombinace obou výše uvedených přístupů. Mapování pomocí meta-modelu totiž v sobě skrývá omezení, které nedovoluje více instancím jedno typu z PIM přiřadit různé protějšky z PSM. Tato neschopnost, dodatečně přidat potřebné informace, dělá tento způsob silně deterministickým. Proto některé charakteristické typy s PIM musejí být opatřeny značkou za účelem detailnějšího specifikování. Na druhou stranu každá transformace jednotlivých elementů v sobě přepokládá určitá typová omezení, kterých bych se každý návrhář měl držet, aby výsledná transformace měla vůbec nějaký smysl. To znamená, že každý typ elementu v PIM má implicitně definovanou sadu značek, kterými ho lze označit. Výsledkem každé transformace je, jak již bylo uvedeno, platformově specifický model a dále záznam o transformaci. Ten v sobě zahrnuje mapu, která ukazuje jaké druhy transformací byly použity pro konkrétní druhy mapování, což umožňuje provádět transformaci i v opačném směru. Tyto informace v důsledku pomáhají lépe synchronizovat jednotlivé vrstvy na různých úrovních abstrakce a tak dosáhnout lepší konzistence.

Shrnutí

MDA nelze považovat za sjednocující standard. Hlavně proto, že neposkytuje přesnou metodiku (jedná se o velmi obecný standard), a také že jde o poměrně složitý koncept, který je neustále v procesu standardizace a vývoje, jenž je nasaditelný jen v určitých případech. Na druhou stranu MDA poskytuje řadu výhod, zjednodušuje analýzu, návrh, implementaci a integraci aplikací včetně i těch velkých a komplexních systémů. Celkově MDA přináší výhodu v podobě snadné přenositelnosti aplikace mezi jednotlivými platformami a dokonce umožňuje křížit jednotlivé platformy, pokud to architektura aplikace dovoluje nebo vyžaduje. Tento koncept bude mít určitě i nadále své místo v oblasti vývoje IS, lze to usoudit z jeho rozšíření v praxi v posledních letech, která se projevuje jako rostoucí podpora MDA v CASE nástrojích.

Literatura

LÉBL, Jan. MDA technologie pro vývoj podnikových IS. Connect!. 10. 2005, s. 10-12. 

KOLÁŘ, Vít. Vazba mezi CASE nástroji a vývojovými prostředími (automatické generování kódu, automatický reverzní engineering. Praha: VŠE FIS, Katedra informačních technologií, 2008. Kapitola 5. 

KOHOUTEK, Roman. MDA – Model Driven Architecture. Brno: Fakulta informatiky Masarykovy univerzity, presentace Technology Preview Party, 2006. 

Reference

  1. OMG: „MDA Guide Version 1.0.1“, el. zdroj: http://www.omg.org/docs/omg/03-06-01.pdf, June 2007