wiki.valek.net

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 24. Model driven architecture ======

Charakterizujte MDA a základní principy, na kterých je postavena. Jaké jsou hlavní přínosy a hlavní nedostatky tohoto přístupu? Jaké jsou předpoklady pro použití modelem řízeného vývoje. Jaká je podpora MDA v CASE nástrojích a metodikách?
===== Úloha =====
**Předpoklady:** 
Jste vedoucím projektu vývoje IS.

**Zadání:**
  * Zvolíte přístup MDA a proč (ne)? 
  * Jaká kriteria použijete pro výběr vhodného CASE nástroje.  

===== Teorie =====
==== Úvod ====

S postupným vývojem IS/ICT můžeme pozorovat zvyšující se nároky na systémovou integraci, dochází k celkové globalizaci zpracování informací. Od centralizovaného přístupu, převládajícího začátkem 80. let, kdy vše v daném podniku zpracovával jediný počítač, se postupně přešlo k distribuovanému zpracování založenému na architektuře klient/server. To dominovalo na počátku 90. let. V té době se v technologických slovnících ustálil nový výraz „Middleware“, jako označení pro softwarovou vrstvu řešící integraci jednotlivých částí ASW (aplikačního software) v rámci podniku.

V dnešní době je problémem podobná integrace mezi podniky. Již v 80. letech začaly vznikat standardy, které měly za cíl tento typ integrace řešit. Vzpomeňme například na EDI (Electronic Data Interchange) a normu UN/EDIFACT. V posledních deseti letech vznikala řada dalších pokročilejších technologií řešících mezipodnikovou komunikaci, jako jsou například ebXML, Microsoft .NET, RosettaNet a další iniciativy v oblasti webových služeb. Pomalu začíná být jasné, že žádná z výše uvedených technologií pravděpodobně nezačne dominovat a nestane se tedy univerzálním standardem. Proto budou v budoucnu podniky nuceny integrovat své systémy  zřejmě s několika technologiemi současně.

Mezinárodní standardizační organizace známá pod zkratkou OMG (Object Management Group) ustanovila před zhruba dvěma lety za svoji hlavní („mainstream“) vizi takzvanou Model-Driven Architecture (MDA), která si klade za cíl nabídnout pro tuto situaci řešení. V tomto článku se pokusím objasnit co MDA je, proč vzniká a co by dle mého názoru mělo tvořit její klíčové komponenty.

==== Motivace ====

Standardizační organizace OMG se kromě standardů Unified Modeling Language (UML) a Common Object Request Broker Architecture (CORBA), které ji proslavily, zabývá také řadou doménově specifických standardů z oblasti telekomunikací, zdravotnictví, vesmírného výzkumu, atd. Jejími členy je tudíž řada významných firem z širokého spektra oborů.

V současné době existuje na světě celá řada hardwarových platforem, od IBM PC, přes mainframy a velké podnikové servery firem Sun Microsystems, IBM, či HP, až po malé mobilní telefony. S tím je spojena také existence různých operačních systémů (Windows, Linux, Solaris, AIX, atd.), programovacích jazyků (Cobol, C, C++, Visual Basic, Java, C#, atd.) a síťových/komunikačních rozhraní (Ethernet, USB, Firewire, atd.)
Výsledkem je, že vývoj ASW se stává příliš nákladným a pracným a jeho údržba je  nesmírně náročná, zejména pokud vznikne požadavek na integraci stávajícího ASW s nějakou novou technologií. Celá logika aplikace je totiž zpravidla „zadrátovaná“ v jejím zdrojovém kódu, který je specifický pro danou platformu (programovací jazyk, operační systém, hardware a použité technologie). Portace na novou technologii tudíž znamená ruční přepsání nemalých kusů zdrojového kódu.

Podle většiny známých metodik pro řízení softwarových projektů, předchází implementační fázi, fáze analýzy a návrhu. V této fázi vzniká spousta dokumentů a modelů popisujících jak strukturu dat a procesy, které má vyvíjený software podporovat, tak také samotnou architekturu vyvíjeného programu. Část těchto artefaktů je sice platformově nezávislá a teoreticky by se tedy dala pro integraci s novou technologií použít. Ovšem bohužel, jen málokdy je praxí, že při pozdějších změnách architektury produktu ve fázi implementace se zpětně mění také tyto modely a dokumenty. Časem tudíž zastarávají, až se stanou irelevantními haldami papíru (či bajtů kdesi na disku). Je to zejména proto, že vazba mezi těmito artefakty a kódem musí být uměle ručně udržována, proces aktualizace není automatizován. Proto je zpětná aktualizace často opomíjena.

V současné době většina aplikací podporujících podnikové procesy musí interagovat s několika technologiemi – od databázových serverů, přes aplikační servery (ať už se jedná o platformu J2EE, či .NET), po různá klientská rozhraní (Java, HTML, atd.). Každá z těchto technologií se postupně s jejím rozvojem a zvyšující se flexibilitou stává také komplexnější. Výsledkem je, že vývoj aplikací pro tyto technologie je  nezvládnutelným pro nezkušené programátory. Firmy jsou tudíž nuceny zaměstnávat drahé experty. Ovšem velká část vývoje takovýchto aplikací je nekreativní – vyžaduje tvorbu velkého množství programových artefaktů. Zpravidla hodně informací je v různých artefaktech duplikováno, přičemž je nutné, udržovat mezi těmito artefakty integritu. Jako řešení se nabízí tuto nekreativní složku vývoje automatizovat generováním z modelů na vyšší úrovni abstrakce – to nejenom lépe zaručí dokonalou integritu tvořených (nyní již generovaných) artefaktů, ale také ušetří drahou práci expertů a umožní vytvořit pevnější vazbu mezi projektovou dokumentací a samotnou implementací.

=== Model-Driven Architecture (MDA) ===
{{ statnice:vyvoj:vyvoj_pomoci_mda.png?300|Vývoj pomocí MDA}}
Jednotlivé společnosti participující v OMG si uvědomily, že konsensus v otázkách jednotné hardwarové platformy, jednotného operačního systému, jednotného síťového protokolu, či jednotného programovacího jazyka není možný. Je tedy nutné zaměřit se na formální definici rozhraní a zlepšení interoperability mezi jednotlivými platformami.
Jako odpověď na problémy zde zmíněné začala tedy vznikat Model-Driven Architecture. Lze ji chápat jako rámec (framework) standardů pro podporu modelově řízeného (či modelově centrického) vývoje software. Cílem je umožnit doménovým expertům tvořit platformově nezávislé doménové modely na vyšší úrovni abstrakce, které pak mohou být (polo-)automatizovaně transformovány (za pomoci standardizovaného transformačního mechanizmu) do modelů na nižší úrovni abstrakce – od různého stupně platformově  specifických modelů až po samotný zdrojový kód (viz obr. 2.1.1).

Obrázek: Ilustrace vývoje pomocí MDA. Doménový model je transformován do několika platformově specifických modelů – relační model (model databáze), EJB model (model aplikačních objektů pro platformu J2EE), web-service model (model pro webovou službu, která bude sloužit pro přístup k aplikaci). Platformově specifické modely jsou pak transformovány dále do ještě konkrétnějších modelů – relační model do abstraktního modelu jazyka SQL, EJB model do modelu jazyka Java a XML (kvůli deployment descriptorům) a model webové služby taktéž. Z modelů kódu konkrétních programovacích jazyků (SQL, Java, XML) je poté již přímočarou transformací generován kód.

Při takto koncipovaném vývoji software lze do jisté míry zajistit, aby změny ve zdrojovém kódu, případně v modelech na nižší úrovni abstrakce byly automaticky propagovány do modelů na vyšších úrovních abstrakce, ať už v reálném čase, či ad-hoc (na vyžádání). Předpokladem je existence zpětných transformací, nebo navržení původních transformací tak, aby byly obousměrné (symetrické). O tomto a o dalších aspektech a standardech (již existujících i teprve vznikajících) klíčových pro realizaci MDA pojednám v následující sekci.

==== Klíčové komponenty MDA ====

Základními pojmy v MDA jsou modely a transformace mezi nimi. Aby bylo možné formalizovat jazyk pro popis transformací mezi libovolnými modely popsanými pomocí různých modelovacích jazyků (např. transformace platformově nezávislého modelu vyjádřeného v UML do databázového modelu vyjádřeného některým z modelovacích jazyků pro relační datové modelování), je nejdříve nutné formalizovat popis těchto modelovacích jazyků (nebo-li meta-modelů). Potřebujeme tedy meta-meta-model, jako nástroj pro formální definici meta-modelů. Z tohoto hlediska můžeme rozlišovat čtyři meta-úrovně (viz. tabulku 3.1).

Tabulka 3.1: Čtyř-úrovňová metamodelová architektura.

^Úroveň^Popis^Příklady^
|M0 instance|Data, konkrétní instance objektů.|Konkrétní věta v databázi (Jan Novák)|
|M1 model|Meta-data, definice dat, objektů (třídy).|Definice tabulky (Člověk={jméno, příjmení})|
|M2 meta-model|Definice jazyků/pojmů.|Definice databáze (co je to tabulka – že má jméno a sadu sloupců, co je sloupec, atd.)|
|M3 meta-meta-model|Definice jazyka pro popis jazyků|Definice pojmů pro definici jazyka.|

Ve výše uvedené tabulce je každá úroveň M(x), kde x<3, popsaná pomocí konstrukcí definovaných na úrovni M(x+1). Námi požadovaný meta-jazyk je reprezentován úrovní M3. Standard pro takovýto jazyk již v OMG existuje pod názvem Meta-Object Facility, nebo-li MOF.

==== Meta-Object Facility (MOF) ====
{{ statnice:vyvoj:model_jazyka_mof_v_uml.png|Zjednodušený model jazyka MOF vyjádřený pomocí notace jazyka UML}}
MOF je jazyk velmi podobný jádru UML (pro definici modelů tříd) a také z UML přebírá komponentu OCL (Object Constraint Language) pro popis různých omezení  objektů, tříd, jejich atributů a vazeb.
Sám o sobě je MOF abstraktním jazykem – jeho specifikace neobsahuje definici žádné konkrétní reprezentace (či už textové, nebo diagramatické/grafické). Jako jazyk je určen k popisu abstraktní syntaxe (nikoliv tedy konkrétní reprezentace, nebo-li gramatiky, či grafické notace) jiných jazyků a tedy i sama sebe. Tudíž je MOF samopopisným – je schopen popisu sama sebe, a tak je také formálně specifikován.
Základními konstrukcemi jazyka MOF jsou balík (Package), datový typ (DataType), třída (Class), atribut (Attribute), operace (Operation) a asociace (Association). Třídy v jazyce MOF podporují vícenásobnou dědičnost. Zjednodušený model jazyka MOF je znázorněn na obrázku 3.1.1.

Již dnes existuje řada OMG standardů, i nestandardních „proprietárních“ specifikací různých firem, které využívají MOF k formálnímu popisu. Jako příklad lze uvést již zmiňovaný jazyk UML (viz [6]), který je formálně vyjádřen v jazyku MOF, nebo sadu metamodelů pro datové sklady sdružených pod OMG standardem s názvem Common Warehouse Metamodel (viz [5]) obsahující mimo jiné také metamodel relačních databází. V budoucnu můžeme očekávat vznik dalších standardních metamodelů jak pro různé modelovací jazyky, tak pro populární technologie, jako jsou EJB, či webové služby.
Pro bližší popis jazyka MOF odkazuji čtenáře na jeho specifikaci [3].

==== XML Metadata Interchange (XMI) ====

Jak již bylo zmíněno dříve, specifikace jazyka MOF neobsahuje definici jeho konkrétní reprezentace. Ovšem bez možnosti nějaké konkrétní reprezentace jazyka, nejsme schopni dokumenty v tomto jazyku nijak distribuovat. Proto existuje separátní standard, který definuje konkrétní textovou reprezentaci MOFu pomocí XML (Extensible Markup Language). Navíc je tento standard tak obecný, že jej lze využít k reprezentaci nejenom metamodelů v MOFu popsaných (a MOF samotný, protože je popsán sám v sobě), ale také jejich instancí (tzn. modelů vyjádřených pomocí těchto metamodelů). Tento standard se jmenuje XML Metadata Interchange (viz [4]) a díky své obecnosti významným způsobem přispívá k interoperabilitě jednotlivých řešení postavených na jazyce MOF – pro řadu jazyků popsaných v MOFu (např. UML) již totiž není nutné tvořit separátní standardy pro jejich konkrétní textovou reprezentaci – ta je automaticky odvozena z metamodelu jazyka podle specifikace XMI.

Za zmínku stojí, že kromě XMI byl v OMG vytvořen také standard s názvem Human Usable Textual Notation, který také definuje textovou reprezentaci metamodelů popsaných v MOFu a jejich instancí, ovšem jím definovaná textová reprezentace je konfigurovatelná k dosažení co nejlepší čitelnosti (pro lidi) a z tohoto důvodu není založená na XML.

==== UML Profile for MOF ====

Textová reprezentace metamodelu je ne vždy dostačující, zejména když je založená na jazyku XML. Pro lepší názornost artefaktů vytvořených v daném jazyce se ukazuje jako efektivnější reprezentace grafická. Proto byl vytvořen také standard umožňující grafické znázornění metamodelů popsaných v MOFu. Tento standard se jmenuje UML Profile for MOF a jak již název napovídá, je to specifikace definující, jak reprezentovat MOF pomocí notace jazyka UML.
Tento standard je definován jako součást větší specifikace s názvem UML Profile for EDOC (viz [8]).

==== MOF Query/Views/Transformations (MOF QVT) ====

Po jazyku pro formální popis jiných jazyků můžeme přejít k další klíčové komponentě MDA, kterou je jazyk pro formální popis transformací mezi jednotlivými jazyky popsanými v MOFu. 
Specifikace takovéhoto obecného jazyka umožní definici jak transformací mezi modely vyjádřenými různými (či stejnými) modelovacími jazyky, tak transformací v rámci stejného modelu. Je tedy možné jej využít k transformacím:
mezi modely na různé úrovni abstrakce (bez ohledu na to, zda jsou vyjádřeny ve stejném metamodelu, či nikoliv),
normalizačním, či nějakým jiným způsobem refaktorujícím stávající model při zachování jeho sémantiky,
mezi abstraktní a konkrétní syntaxí jazyků (za předpokladu definice nejenom abstraktních, ale i konkrétních syntaxí v jazyce MOF) – viz. dále.
Základy takovéhoto standardu jsou v době psaní tohoto článku již položeny. Standard byl nazván MOF Query/Views/Transformations. Několik firem předložilo v OMG své návrhy řešení a nyní probíhá složitá práce a vyjednávání zaměřené na jejich konsolidaci. Spektrum návrhů je široké. Aspekty, ve kterých se jednotlivá řešení liší jsou například:

stupeň deklarativnosti – některé návrhy prosazují ryze deklarativní přístup, jiné kombinují deklarativní prvky s procedurálními. Objevují se i čistě procedurální řešení,

symetrie – řada navrhovatelů řeší pouze jednosměrné transformace. Pokud je tedy například nutné definovat transformaci mezi meta-modely A a B obousměrně, je zapotřebí dvou různých transformačních definic – jednu pro transformaci z A do B a druhou pro transformaci z B do A,
způsob parametrizace – řada transformací není plně jednoznačných – k jejich jednoznačnosti je nutné je parametrizovat. Způsob parametrizace je u různých řešení různý,

trasovatelnost – některá řešení podporují trasovatelnost transformací. To znamená, že se uchovávají vztahy mezi zdrojem a cílem transformace (který element z metamodelu B je transformovanou podobou daného elementu z metamodelu A).

Jako jeden ze spolunavrhovatelů řešení k tomuto standardu se osobně přikláním k transformačnímu jazyku, který je plně deklarativní. Domnívám se totiž, že je důležité, aby takovýto jazyk nediktoval časovou posloupnost a další implementačně-specifické detaily související s prováděním transformace, ale pouze definoval, jak při daném zdroji vypadá výsledek transformace. Tomu se ovšem při zavádění procedurálních prvků do jazyka nelze vyhnout. Dalším argumentem mluvícím pro deklarativní řešení je lepší udržovatelnost. U deklarativního řešení je jasně specifikován zdroj i cíl transformace. Díky tomu lze deklarativní řešení popisu transformace navrhnout tak, aby šlo transformaci definovat jako symetrickou a bylo ji možné provádět v obou směrech. U procedurálního řešení je nutné interpretovat jednotlivé příkazy k rozkódování podoby konečného výsledku a dosažení symetrie není možné.

Argumentem pro procedurální přístup je jeho determiničnost (nebo-li jednoznačnost). Ta u deklarativního přístupu není zaručená a její dosažení pro daný popis transformace není jednoduché. Dále není samozřejmé, že všechny možné typy transformací lze popsat deklarativně. Úkolem je tedy jasně vymezit množinu a složitost úloh, které mají transformace popsané v tomto jazyce řešit a ujistit se, že navrhovaný jazyk je k popisu takových transformací postačující. 

Co se týče trasovatelnosti, ta je důležitá pro podporu inkrementálních transformací, či k správnému zpětnému promítání změn v cílovém modelu do modelu zdrojového. S uchováváním vazeb mezi zdrojovými a cílovými elementy se také přirozeně nabízí uchovávání parametrů transformace přímo u těchto vazeb.

Pro detailnější popis jednotlivých navrhovaných řešení odkazuji čtenáře na literaturu uvedenou na konci tohoto článku ([12] – [19]).

==== Modelovací jazyky ====
Jak je asi zřejmé, k uplatnění MDA je zapotřebí jednoho, nebo více modelovacích jazyků formálně definovaných v MOFu. Tyto jazyky jsou nutné k tvorbě platformově nezávislých i platformově závislých modelů. Jako jeden takový jazyk se nabízí již zmiňovaný jazyk UML – jak jsem nastínil v části věnující se popisu jazyka MOF, UML je popsán v tomto jazyce. Ovšem, i když se UML staví do pozice univerzálního modelovacího jazyka, řada softwarových architektů a lidí, kteří přicházejí s modelováním do styku, jej tak nevnímá. Ne pro všechny a ne pro každý účel je tento jazyk vyhovující. Jedním z limitujících faktorů může být například jeho přílišná objektová orientace, nebo jeho slabá podpora modelování dynamické složky popisované reality nebo systému. MDA by se proto neměla omezovat na jediný modelovací jazyk.

==== Formální popis konkrétních syntaxí ====
Žádný jazyk není úplný bez konkrétní syntaxe. Pro většinu programovacích jazyků má konkrétní syntaxe podobu textovou (dále ji budu nazývat gramatikou), u modelovacích jazyků je běžnější podoba grafová, nebo grafická (dále ji budu nazývat notací). OMG v současné době disponuje dobrými prostředky pro popis abstraktní syntaxe jazyků, ovšem konkrétní syntaxe je dodnes v OMG standardech specifikována pouze slovně, alespoň co se týče notací. Slovní popis syntaxe má řadu nevýhod:
je velmi často nejednoznačný a nepřesný – vznikají různé interpretace, což se projevuje v omezené interoperabilitě výsledných implementací,
nelze jej zpracovat počítačem a tím automatizovat převod konkrétní syntaxe na abstraktní a naopak.

Domnívám se, že pro plné využití potenciálu MDA, je nutné prosadit v OMG standardizaci popisu konkrétních syntaxí jazyků. Osvědčilo se to již obecně na poli textových jazyků, kde dnes již většina syntaktické analýzy kódu probíhá za pomoci „parserů“ (nástrojů pro převod konkrétní syntaxe jazyka do jeho abstraktní reprezentace) automaticky vygenerovaných z poskytnutého formálního popisu gramatiky daného jazyka. Na poli modelovacích jazyků by tak formální popis notace mohl vést podobně k automatizované tvorbě modelovacích nástrojů pro daný jazyk.

Povede-li se navíc modelovat konkrétní syntaxe v jazyce MOF, bude možné využít jazyka MOF QVT pro definici transformací mezi abstraktní syntaxí a různými konkrétními syntaxemi. Tím se sjednotí způsob popisu transformací mezi dvěma modely se způsobem popisu transformací mezi modelem a kódem. 

Samotné generování skutečného kódu pak již bude pouhým izomorfním promítnutím konkrétní reprezentace vyjádřené v MOFu do textu, či grafiky.
V tomto úsilí jsou zatím průkopníky firmy Compuware a Sun Microsystems. Ty společně navrhly model, který by mohl sloužit jako základ pro formální popis gramatik a notací v jazyce MOF. Pracovní verze tohoto modelu je k nalezení v [11].

==== Architektura nástrojů podporujících MDA ====
{{ statnice:vyvoj:architektura_mda_nastroje.png?450|Diagram architektury MDA nástroje}}
V předchozích částech článku jsem vyjmenoval důležité standardy (resp. budoucí standardy) relevantní pro vizi modelově řízeného vývoje software. Nyní se pokusím nastínit, jak všechny tyto standardy mohou určovat architekturu softwarových nástrojů podporujících MDA.
Srdcem nástrojů podporujících MDA je bezesporu implementace standardu MOF  v podobě pomyslné databáze, která je schopna načítat definice abstraktních i konkrétních syntaxí různých jazyků (v MOFu popsaných) a spravovat jejich instance. Všechny modelovací jazyky a platformy, které má daný nástroj podporovat, musí tedy být popsané v MOFu.

Pro realizaci transformací musí být součástí MDA nástroje také implementace standardu MOF QVT. Ta umožní načtení definic různých transformací a bude tyto transformace provádět. Je to klíčová komponenta k realizaci vzájemných transformací modelů, generování kódu a synchronizace abstraktních syntaxí s konkrétními syntaxemi.

K tvorbě modelů slouží diagramatický editor, který je schopen na základě načtené notace podporovat modelování v této notaci.
Textový editor slouží k editaci zdrojového kódu. Na základě načtené gramatiky je schopen zvýrazňovat klíčová slova, upozorňovat uživatele na chyby v syntaxi případně automaticky nabízet doplnění psaného kódu výčtem relevantních symbolů.

Zjednodušený diagram této architektury je znázorněn na obrázku. Obrázek: Zjednodušený diagram architektury MDA nástroje. Znázorňuje nástroj podporující modelovací jazyk UML a programovací jazyk Java. (c.s. = concrete syntax, neboli konkrétní syntaxe; a.s. = abstract syntax, neboli abstraktní syntaxe)

Protože jednotlivé abstraktní syntaxe, konkrétní syntaxe a transformace lze popsat deklarativně, nástroj odpovídající této architektuře lze snadno rozšiřovat a přizpůsobovat potřebám jeho uživatelů. Například, načtením metamodelu pro EJB, notace pro reprezentaci EJB modelů a transformací mezi EJB, UML, Javou a konkrétní a abstraktní syntaxí pro EJB lze nástroj znázorněn na předchozím obrázku rozšířit o podporu pro EJB. Architekti v podniku mohou přizpůsobovat transformace mezi jednotlivými modely tak, aby výsledný generovaný kód přesně odpovídal potřebám a normám organizace, případně aby byl navázán na požadovaný aplikační framework.

Takto navržené nástroje výrazně urychlí a zlevní vývoj náročných, několika‑úrovňových aplikací a zlepší jejich udržovatelnost, jelikož modely se stanou nejen dokumentací, ale přímo centrálními artefakty pro vývoj software.

==== MDA jako klíč k systémové integraci ====
MDA nabízí dva způsoby řešení systémové integrace:
  - přemapováním aplikační logiky do nové platformy (technologie) – díky tomu, že platformově nezávislé modely použité při tvorbě aplikace jsou díky MDA pořád aktuální, bude možné velmi rychle aplikovat transformace těchto modelů do jiné technologie a tím vlastně existující ASW na tuto technologii přeportovat,
  - v reálném čase – ASW samotný může obsahovat implementaci MDA standardů a využívat ji k transformacím vstupních a výstupních dat z jednoho formátu do jiného na základě metamodelů těchto formátů a transformací mezi nimi. Tento přístup k integraci používá ve svém produktu například firma MetaMatrix (viz. www.metamatrix.com).

Standardní metamodely jednotlivých technologií i domén již v OMG vznikají (viz. zmíněný CWM, nebo metamodel technologie CORBA ve standardu CORBA Component Metamodel). Očekává se, že na půdě OMG i jiných standardizačních organizací (například Java Community Process) vzniknou i standardy pro transformace mezi jednotlivými technologiemi. To umožní firmám jednoduše „nahrát“ formální definice těchto standardů do implementace MDA frameworku (MOF, XMI, MOF QVT) a automaticky tím získat podporu pro výměnu dokumentů v daných formátech. Toto je již dnes možné pro CWM, či UML. 

Cílem výše popsaného přístupu je, aby se softwarové společnosti mohly zaměřit na tvorbu přidané hodnoty svých produktů a nemusely již být dále nuceny investovat nemalé prostředky do pouhé implementace standardů.

==== Závěr ====

Model-Driven Architecture přináší nové paradigma vývoje software. Je založeno na postupu od vyšších stupňů abstrakce k nižším stupňům abstrakce, za pomoci tvorby modelů s různou úrovní závislosti na cílové platformě. Na každém stupni abstrakce je umožněno tvůrcům aplikace zasahovat do modelu a upřesňovat jej pro danou specifickou platformu, pro kterou je určen. Přitom jak modelovací jazyky pro popis modelů, tak transformace mezi modely jsou plně parametrizovatelné a přizpůsobitelné.

Takovýto vývoj software má řadu výhod:
  - modely vznikající v úvodních fázích realizace projektu se nestávají „mrtvými“ dokumenty – naopak, jsou základem pro generování (významné části) cílové aplikace,
  - jádro veškeré logiky aplikace je zachyceno v platformově nezávislých modelech. Při potřebě přizpůsobení dané aplikace nové platformě, do velké míry stačí danou část aplikace pro novou platformu vygenerovat z platformově nezávislého modelu pomocí pozměněných transformací,
  - pozdější změny na nižších stupních abstrakce (např. v kódu) mohou být automaticky promítány zpět do abstraktních modelů a propagovány do ostatních platformově závislých modelů k zajištění konzistence generovaných artefaktů,
  - výsledné aplikace jsou mnohem lépe udržovatelné – většina kódu je generována z modelů na základě dobře odladěných transformací.

Při čtení tohoto článku možná mnohé napadne, že doba pokusů o prosazení nástrojů CASE (Computer Aided Software Engineering) podporujících generování aplikací z modelů tady už byla, a tyto nástroje nebyly moc úspěšné. Je nutné si ovšem uvědomit, že v minulosti (a bohužel ještě pořád i dnes) si mnoho firem představovalo modelově centrický vývoj jako pouhou reprezentaci programů pomocí obrázků, které ovšem byly na stejné úrovni abstrakce. 

Posun v úrovních abstrakce je pro MDA klíčový. Nejde tady tedy o pouhou simulaci jiné (grafické) konkrétní reprezentace pro textové jazyky, kdy každá třída v daném jazyku je reprezentována právě jednou třídou v modelovacím jazyku. Jedná se o transformace, kdy jedna třída v abstraktním modelu může být ve výsledku reprezentována několika tabulkami v databázi, třídami v Javě (které záznamy v databázi ohledně dané třídy zpřístupňují ostatním Java komponentám) a HTML stránkami (poskytujícími např. rozhraní pro zakládání, editaci, mazání a seznam instancí dané třídy). Navíc modely na vyšších úrovních abstrakce jsou platformově nezávislé a lze je tedy transformovat  do libovolné z platforem. Tím klesají náklady spojené s integrací existujících systémů s novými technologiemi. Neméně důležitým aspektem je možnost synchronizace jednotlivých artefaktů (zdrojového kódu, platformově nezávislých modelů, atd.) a udržování jejich konzistence v reálném čase, a to díky obousměrným trasovatelným transformacím.

===== Praxe =====

FIXME