Softwarové továrny a MDA

Současný způsob vývoje aplikací se jen velice obtížně vyrovnává s trendy, které doba přináší - zvyšující se ...


Současný způsob vývoje aplikací se jen velice obtížně vyrovnává s trendy, které
doba přináší - zvyšující se komplexnost, nové technologie nebo enormní rychlost
změn. Snaha architektů a vývojářů přizpůsobit metody vývoje těmto trendům je
pochopitelná. Softwarový průmysl proto čím dál tím častěji začíná hledat
postupy a nástroje, které by mu pomohly snížit náklady, rizika a čas potřebný k
vývoji produktu a zároveň zvýšit jeho kvalitu. Jako důležité se v tomto
kontextu jeví možnost opakovaného využití jednotlivých částí v jiných řešeních.

Možná, že jste slyšeli o modelově orientované architektuře (Model Driven
Architecture, MDA), za níž stojí skupina OMG (Object Management Group). Vedle
ní stojí iniciativa společnosti Microsoft s názvem softwarové továrny (Software
Factories) a také modelově orientovaný vývoj (Model Driven Development, MDD),
jež míří na stejné cíle, ale jinými postupy a prostředky.
Před tím, než se podíváme na oba přístupy přispívající k automatizaci vývoje
aplikací, k eliminaci chyb, ke zvýšení produktivity a k zavádění standardizace,
popišme si zásadní nedostatky, kterými trpí dnešní softwarový vývoj.
K existenci softwarových továren se váží čtyři základní problémové okruhy, jež
se nedaří po celou řadu let eliminovat - monolitické konstrukce, bezdůvodné
zobecňování, jednorázový vývoj a nevyzrálost vývojového procesu.

Monolitické konstrukce
Základní problém spočívá v neschopnosti realizace vývoje ve formě skládaní
existujících dílů, obdobně, jak to známe z jiných průmyslových oblastí,
například z výroby automobilů. Tato myšlenka provází tvorbu softwaru od svého
počátku a každá generace programátorů a architektů se snažila najít nějaké
řešení. Objektově orientované programování nebo komponentové technologie jsou
toho krásným příkladem.

Bezdůvodné zobecňování
Demonstrujme si tento fenomén na typické obchodní aplikaci, kde se většina
řešení skládá z několika charakteristických základních vzorů. Programy většinou
načtou potřebné informace z databáze, zobrazí je uživatelsky komfortním
způsobem, nechají uživatele provést změny, dohlédnou na dodržení definovaných
pravidel a výsledky zapíší zpět do datového zdroje. Byť jde o velmi
zjednodušenou představu, celkem věrně odráží skutečnost většiny obchodních
aplikací. Vedle toho stojí v kontrastu softwarové metody a postupy, které dnes
pro tvorbu aplikací máme a které nabízejí daleko větší úroveň volnosti, než je
pro vývoj většiny programů nutné.
J
ednorázový vývoj
Celý problém možnosti opakovaného využívání vyvinutého kódu spočívá ve způsobu,
jakým dnes software vzniká. Individuální přístup jednotlivých firem a vývoj v
izolaci vede k produkci problematického kódu s obtížnou integrací. Návratnost
investic by byla daleko vyšší, pokud by se vývoj prováděl s pomocí opakovaně
použitelných elementů podle standardů definovaných pro dané odvětví. Je
bolestnou skutečností, že opakované využití návrhu a kódu je více méně nulové,
pokud není na tuto skutečnost pamatováno již od naprostého prvopočátku. Mnoho
firem ve skutečnosti opakovaně využívá kód spíše ad hoc způsobem, než aby se
snažily vývoj systematizovat.

Nevyzrálost vývoje
Podíváme-li se na způsob, jakým firmy přistupují k vývoji softwaru, zjistíme,
že se jen málokdy podaří udržet rozpočet nebo termín. Je to jednoznačně
důsledek nevyzrálosti vývojového procesu. Bez něj se jen obtížně provádí
jakákoli automatizace, neboť vývojové nástroje nebo architektonické scénáře
nejsou schopny vyzrálý proces nahradit.

Řízení modelem
MDA je iniciativou skupiny Object Management Group, v jejímž rámci se definuje
způsob vývoje aplikací vytváření softwarových specifikací. Cíl snah spojených s
MDA spočívá v zodpovězení následujících otázek, jež se při vývoji softwarových
systémů neustále objevují:
n Jak zachytit a popsat požadovanou architekturu?
n Jak pomoci vývojářům při realizaci zadané architektury?
n Jak zjistit a prověřit, že vytvořené aplikace odpovídají zadané architektuře?
n Jak zajistit rychlé přijetí nové architektury při její nutné změně?
n Jak modifikovat existující aplikace a systémy s nízkými náklady?
n Jak zajistit, že při krizích a časových zpožděních nebude docházet k
obcházení architektury?
Model Drive Architecture využívá pro řešení uvedených otázek třívrstvý model
(viz schéma MDA v CW 32 strana 26, 27) a sadu transformačních pravidel.

Schéma MDA
První úroveň MDA s názvem Platformově nezávislý model (Platform Independent
Model - PIM) popisuje nejobecnějším způsobem řešený problém, aniž by brala v
úvahu jakoukoliv technologii či protokoly, které budou použity. Tento model se
navrhuje zcela manuálně.
Druhá vrstva, pojmenovaná Platformově specifický model (Platform Specific
Model, PSM), představuje již konkrétní systém, který je opřen o určitou
technologii. Tou může být konkrétní vývojové prostředí a programovací jazyk
(například C++, C#, Visual Basic) nebo platforma (například .Net Framework či
Java). PSM model vzniká pomocí transformačních pravidel definujících vztahy
mezi platformově neutrální a platformově specifickou vrstvou.
Třetí, nejnižší vrstva architektury se označuje jako Model kódu (Code Model -
CM). Stejně jako předchozí i tato úroveň se generuje automaticky pomocí
transformačních pravidel a vztahů mezi vrstvami. Výsledkem jsou již spustitelné
soubory schopné nasazení. Důležitý aspekt představuje dodržení předepsané
architektury a splnění všech standardů, které byly pro dané projekty přijaty.

Softwarové továrny a MDA
Softwarovou továrnu si můžeme představit jako produktovou řadu, která
konfiguruje vývojové prostředí - například Microsoft Visual Studio Team System
(VSTS) nebo IBM WebSphere Studio - pomocí hotových částí kódu a doporučujících
postupů pro průběh realizace konkrétního typu aplikace. Softwarové továrny
obsahují tři základní elementy:

Schéma softwarové továrny - představuje v podstatě recept, podle kterého se
vyrábí konkrétní typ aplikace. Obsahuje jednak seznam ingrediencí, ze kterých
je produkt sestaven (projekty, adresáře se zdrojovými kódy, SQL soubory a
konfigurace), a rovněž návod, jak všechny tyto ingredience použít, aby
dohromady vytvořily výsledný produkt. Intenzivně jsou zde využívány jazyky DSL
(Domain Specific Language, viz rámeček) pro vytváření modelů a dále informace,
pomocí nichž lze tyto modely převádět ve skutečný kód nebo v jiné modely.
Popisuje také architekturu konkrétního typu aplikace, vztahy mezi komponentami,
jež ho tvoří, a prostředím, na němž je postaven.

Šablona softwarové továrny - obsahuje sadu konkrétních ingrediencí, které se
budou používat při výrobě aplikací. V mnoha případech to jsou návrhové vzory,
softwarové šablony, skripty, XSD schémata (XML Schema Definition), CSS,
příklady, návody, editační nástroje a mnohé další.

Rozšiřitelné vývojové prostředí - v němž se vše vytváří a realizuje do finální
produkční podoby. Pokud se do vývojového nástroje přidají výše uvedená schémata
a šablony, stává se z něj právě ona "továrna na úzce vymezený software".
Po této více méně formální definici softwarové továrny si asi řeknete:
Neexistují tyto elementy již v existujících vývojových prostředích? Odpověď zní
zcela jasně - ne. Zásadní rozdíl mezi existující funkcionalitou nástrojů, jako
jsou Microsoft Visual Studio či IBM WebSphere Studio, a softwarovou továrnou je
v úrovni abstrakce. Zatímco vývojové nástroje se snaží být co
nejuniverzálnější, softwarové továrny zaměřují velmi úzký typ konkrétních
aplikací. Díky této orientaci mohou poskytnout daleko komplexnější automatizaci
a popis potřebných postupů. Ve výsledku jsou však vždy úzce orientovány.
Jedna továrna může například zjednodušit a urychlit vývoj aplikací pro
zdravotnictví (například reportovací služby nebo řízení laboratoří), ale být
zcela nepoužitelnou pro vytváření B2B extranetu v e-commerce systémech, a
naopak.
Někteří z vás možná také začnou přemýšlet o položení rovnítka mezi pojmy
softwarová továrna a "starter kit". V případě starter kitu jde o sadu
zdrojových kódů, určených pro konkrétní aplikaci, které lze uzpůsobit pro své
vlastní podmínky. Lze ji tedy považovat za statický prvek, ve kterém vývojář
dostává jen zdrojové soubory a případně dokumentaci. Softwarová továrna je z
tohoto úhlu pohledu dynamickým rozšířením vývojového prostředí samotného tak,
aby vývoj daného typu aplikace mohl být rychlejší a úspornější. To vše díky
využití definovaných vzorů, standardů a architektur.

Továrny v praxi

Praktické návody - většina standardních metodologií je popsána pouze písemnou
formou a očekává se, že ji uživatelé prostudují a začnou používat. Továrny
vedle dostupné dokumentace přinášejí návody ve formě přizpůsobeného vývojového
prostředí, v němž se veškerý vývoj odehrává. Dostupná je celá řada knihoven
tříd, projektů, průvodců, webových stránek, návrhových vzorů, vizuálních
návrhářů a nápovědy. Místo toho, aby bylo uživateli vtloukáno do hlavy, jak má
postupovat, softwarová továrna za vývojáře například vygeneruje potřebné třídy
a metody pro zpracování událostí podle navrženého uživatelského rozhraní.
Při návrhu aplikací se velmi často využívají různé návrhové vzory, přičemž knih
s touto tematikou existuje celá řada. Ne každý vzor musí být vhodný pro danou
situaci. Vzory pro konkrétní typ aplikace spíše určuje architekt a podle potřeb
projektu jsou posléze vývojáři naplněny.

Modelově orientovaný vývoj - je prvkem softwarových továren, pomocí něhož se
provádějí definice modelů. Ze samotného kódu aplikací bývá velmi obtížné tyto
definice vytušit. Model také slouží jako podklad pro automatizaci celé řady
úkonů.
Používané modely zachytávají všechny aspekty a informace potřebné pro vývoj
aplikace. Mohou jimi být například komponenty, kontrakty, sekvence výměny
zpráv, hierarchie tříd, procesy, subsystémy, ale třeba i mapy pro nasazení
systémů. Na rozdíl od mnoha modelů, které mají jen velmi nízkou výstižnost a
slouží pouze pro dokumentační účely, při modelově orientovaném vývoji se
využívá velice přesných modelů popsaných tzv. doménově-specifickými jazyky
(DSL). Ty zprostředkovávají požadovanou úroveň automatizace.

Vlastnostmi orientovaný vývoj - představuje další charakteristický znak
softwarových továren. Je zcela zbytečné, aby se analytici a architekti
opakovaně zabývali zjišťováním základních vlastností daného typu aplikace,
například reportovací služby. Místo toho mají k dispozici konfigurační nástroje
pro různé úrovně modelu, které umožňují zapínat nebo vypínat předdefinované a
často používané části systémů. Prostřednictvím konfigurací se tak realizuje
přizpůsobování továrny potřebám konkrétního systému, počínaje jeho logickou
architekturou přes fyzickou architekturu až po procesy testování a nasazení.

Závěr
Softwarové továrny a modelově orientovaná architektura zastupují moderní
technologie využitelné při vývoji programového vybavení. Nejde o žádná
rozšíření architektur, nové návrhové vzory nebo programovací jazyky. Jde o
metodologie navržené s cílem, co možná nejlepšího využití stávající technologie
při minimalizací nákladů, maximalizaci využití existujících architektur a
modulů a zlepšení procesu řízení změn.
Další informace k této problematice naleznete mimo jiné v těchto dokumentech:
J. Greenfield: Problems and Innovations, K. Short: Modeling Languages for
Distributed Applications, M. Regio, J. Greenfield, B. Thuman: A Software
Factory Approach To HL7 Version 3 Solutions (všechny 3 k nalezení na webu
msdn.microsoft.com) a M. N. Tierno, J. Greenfield: Perspectives of the IASA on
Software Factories (www.iasarchitects.org/iasa/others/
austinAdmin/IASANewsletter
002-102.pdf).
Autor je manažerem pro vývojové technologie
ve společnosti Microsoft.



Jazyk DSLDoménově-specifický jazyk umožňuje architektovi aplikace navrhnout
model přesným a věrným způsobem. Musí zajišťovat dostatečnou úroveň abstrakce,
avšak beze ztráty věrnosti s generovaným kódem. Jazyky DSL jsou na rozdíl od
všeobecně orientovaných programovacích jazyků úzce specializované na konkrétní
oblast.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.