Technologie ARAD snižuje náklady na vývoj aplikací

Potřebujete-li zvýšit produktivitu práce svých vývojářů, měli byste uvažovat o nástrojích stavějících na techn...


Potřebujete-li zvýšit produktivitu práce svých vývojářů, měli byste uvažovat o
nástrojích stavějících na technologii ARAD. Slibují rychlejší i levnější vývoj
než tradiční nástroje a v poslední době si získávají nemalou popularitu.
Pořizují si je především společnosti, které potřebují zvládnout práci na stále
složitějších projektech, a přitom se chtějí zaměřovat spíše na obchodní
požadavky s nimi související než na technické specifikace.

Software pro rychlý vývoj aplikací založený na technologiích ARAD (Architected
Rapid Application Development) využívá konstrukcí, které mohou sloužit jako
stavební bloky k vytváření společných částí aplikací například uživatelského
rozhraní nebo sady procesních pravidel. Protože tyto nástroje často generují až
80 % vlastního kódu, mohou vývojáři podle názoru průmyslových analytiků i
uživatelů přidat aplikační logiku a aplikaci dokončit rychleji než tradičními
vývojovými metodami. Podle studie firmy Gartner se nástroje ARAD stanou brzy
nezbytností pro společnosti, které přecházejí k tvorbě aplikací orientovaných
na služby. Studie upozornila, že nástroje ARAD zlepšují oproti použití
tradičních vývojových přístupů návratnost investic až 15krát.
"Generuje to například ty části kódu, k jejichž vytvoření nemá programátor
odborné znalosti kódu, v němž se vyzná architekt middlewaru nebo technický
návrhář aplikace," říká Michael Blechar, analytik firmy Gartner a spoluautor
zprávy. "Spolehlivost a kvalita takového kódu je mnohem, mnohem vyšší, než by
byla při ručním programování."
Zpráva zmiňuje, že vedle zisků v produktivitě uživatelé při průzkumu Gartneru
zmiňovali také podstatně nižší úroveň výdajů na pořízení a zaškolení, než kolik
očekávali. Většina organizací hlásila návratnost investice do jednoho roku.
"Náš OptimalJ spojuje přístupy tradičního modelování a integrovaného vývojového
prostředí (IDE)," říká Mike Burba, manažer programu OptimalJ u Compuware, a
vysvětluje: "Je navržen tak, aby dovedl objektově-orientovanou analýzu
modelovacích nástrojů na vyšší úroveň abstrakce a obsahuje transformační stroj,
jenž přímo převádí procesní model do aplikačního rámce. "Stejně jako IDE vám
umožňuje dostat se dovnitř vygenerované aplikace a editovat kód," říká Burba.
Mezi firmy, kteří vytvářejí nástroje ARAD, patří kromě Compuware i společnosti
IBM nebo Computer Associates. Počet výrobců přitom stále roste.

V praxi
A jak se nástroje ARAD osvědčují v praxi? Když byla například americká firma
Locus Systems, zabývající se vývojem aplikací a systémovou integrací, vystavena
outsourcingovým tlakům, začala podle Richarda Blaise, svého generálního
ředitele, používat právě nástroj OptimalJ od Compuware. Cílem bylo udržet svůj
provoz na konkurenceschopné úrovni. "Je to jako když děláte outsourcing
dovnitř," říká Blais. "Jako mít indické Bangalore přímo v počítači dává nám to
opravdu velikou konkurenční výhodu."
Locus dosud použil OptimalJ k vygenerování 65 až 70 % kódu pro 3 své aplikace.
"Tím firma ušetřila vývojářům hodiny práce a podstatně zmenšila počet chyb
nalezených v průběhu prvního kola testování," dodává Blais.
Také austinské ADC (Advanced Development Center) použilo nástroj ARAD k
zefektivnění vývoje aplikací a jejich údržby. V tomto případě se podle Bryana
Schwieninga, generálního ředitele střediska pro služby a prodej, jednalo o
produkt AllFusion Plex od Computer Associates. "I ty nejmenší detaily programu
byly vygenerovány," tvrdí Schwiening. "Najednou zjistíte, že se při vývoji
aplikace zabýváte více její architekturou a méně programujete."
Navíc nový nástroj podle Schwieninga ulehčil proces úprav aplikace a umožnil
uživatelům stavět na stávajících investicích do IT. "Když se rozhodnou, že
chtějí zpřístupnit část aplikace přes web, mohu vygenerovat tuto část nebo i
celou aplikaci tak, aby běžela v prostředí webového serveru," vysvětluje. "Až
budeme příště znovu generovat aplikační logiku, neztratíme již dříve vytvořený
vzhled v HTML."
Royal Bank of Canada začala podle Davida Hewicka, vedoucího skupiny pro
architekturu aplikací této torontské banky, používat nástroj OptimalJ. Cílem
podle jeho slov bylo těsnější spojení vývojářských a obchodních záležitostí,
jako například služeb zákazníkům. Banka používá OptimalJ v pilotním projektu
vytvoření webové aplikace na bázi J2EE a Hewick odhaduje, že vývojáři mohou
dosáhnout 25% až 30% nárůstu produktivity práce v porovnání s tradičním
přístupem k J2EE. "Byla to příležitost vylepšit vývojový cyklus, snížit výdaje
a zvýšit kompaktnost kódu," říká Hewick. "Modelovací prostředí
institucionalizovalo spoustu položek z výchozí architektury. Generuje hromadu
kódu, který nemusíme psát ani testovat. To se promítá do nárůstu času, který
nyní mohou vývojáři strávit na skutečné tvorbě aplikací."

Vývoj na trhu
IBM posiluje své pozice v oblasti ARAD nástrojů zaměřila se na svůj nový
modelovací nástroj Rational Software Modeler a software pro návrh a vývoj
Rational Software Architect, které ohlásila loni v říjnu. Tyto nástroje jsou
určeny jako náhrada balíku Rational Rapid Development, jemuž sice bude IBM i
nadále poskytovat podporu, ale který už nebude na trhu nabízet.
Společnost Computer Associates zase oznámila novou verzi produktu AllFusion
Plex, která k automatizaci vývoje pro prostředí Windows, J2EE a IBM i5/OS
používá programovací vzory. Mezi její vlastnosti patří mimo jiné schopnost
vytvořit komponenty aplikační logiky, jež mohou být zpřístupněny jako webové
služby nebo jako díly pro aplikace založené na technologii .Net.
David Kelly, ředitel společnosti Upside Research, říká, že jeho klienti
ohlašují významný přínos plynoucí jim z používání nástrojů ARAD včetně kratšího
času na vývoj a nižších nákladů. "Tyto nástroje jsou světelné roky vzdálené od
starých modelem řízených nástrojů architektury klient/server, jež bývaly
typicky příliš těžkopádné, velmi obtížně se z nich dalo něco znovu použít a
obecně neplnily dnešní potřeby na návratnost investic," dodává. Současně ale
upozorňuje, že používání těchto nástrojů vyžaduje po vývojářích osvojení si
nového způsobu myšlení při tvorbě aplikací.
"Vývojáři mají téměř kovbojskou mentalitu chtějí kód vytvořit rychle a hned
pokračovat nějakou další činností," říká Kelly. "Aby vám technologie ARAD
skutečně přinesla užitek, musíte mít trochu disciplíny zaměřit úsilí na
nalezení správných vzorů i vhodné architektury a zajistit, že vývojáři a
architekti budou používat odpovídající nástroje a postupy ve vzájemném souladu."

Technologie ARAD
Technologie ARAD, známá od některých dalších výrobců také pod zkratkou MDPB
(Model-Driven Pattern Based, modelem řízený a založený na vzorech), nabízí na
rozdíl od tradičních technologií vývoje přístup zaměřený na služby. Společnost
Gartner o tomto přístupu píše doslova jako o SODA (Service-Oriented Development
of Applications). Smyslem jeho existence je umožnit opakované používání služeb
a komponent. Produkty vývojářské práce, například vývojové vzory, rámce a
programy, mohou být při přístupu SODA opakovaně využívány v řadě projektů. To
by mělo zlepšit efektivitu a produktivitu vývojářské práce. Podle Gartneru
metody a nástroje ARAD teprve v současnosti začínají dosahovat uznání u
hlavního proudu vývojářů pracujících na platformách Java 2 Enterprise Edition
(J2EE) a .NET.

Nástroje ARAD
Podle studie firmy Gartner mohou nástroje založené na technologii ARAD oproti
tradičním nástrojům zvýšit návratnost investic dvojaž patnáctinásobně. Mezi
základní vlastnosti nástrojů ARAD patří:
n Zaměření na užívání vzorů. Ty slouží jako stavební bloky pro automaticky
generované sdílené části aplikace. n Schopnost generovat až 80 %
"organizačních" částí aplikace. Jde například o uživatelské rozhraní nebo o
opakovaně používanou procesní logiku.
n Usnadnění přenosu aplikace do nového prostředí například na web.

Úskalí vývoje aplikací
Mark Carroll z Microsoftu, který v současné době přednáší ve Worldwide
Institute of Software Architects na Novém Zélandu, se mimo jiné věnuje i
úskalím vývoje současných aplikací. Některé z jeho myšlenek naleznete v
následujícím textu.
Základem pro vývoj aplikace je zpravidla dokument popisující uživatelské
požadavky. Carroll ale upozorňuje, že zákaznické požadavky nutné pro uvedení do
provozu a potřeby koncového uživatele by měly být brány v úvahu odděleně. Jako
špatný příklad uvádí jeden systém, o němž věděl, že splnil všechny funkční
specifikace klienta, ale koncové uživatele rozzuřil. Byl totiž postaven na bázi
webového rozhraní a uživatelé už do něj nemohli tahat objekty myší, jak byli
zvyklí u dřívějšího systému.
To ale není jediný zádrhel vývoje. Vývojáři se často zaměřují na elegantní
systémové architektury vyvinuté se snahou zohledňovat pouze okamžité náklady a
zjednodušený popis předpokládaných uživatelských požadavků.
Mnohdy se věnuje nedostatečná pozornost faktorům, jako je dostupnost potřebných
schopností u zaměstnanců, jejich vlastní ambice, dodržování standardů a možnost
získat řešení nějaké části problému u jiných firem. Vyvíjíte-li pomocí
efektivních, ale nepopulárních nástrojů, riskujete omezení v oblasti dovedností
pracovní síly a dostupnosti odborné pomoci zvnějšku. Zaměstnanci a externí
pracovníci mohou být odrazováni od účasti na projektu, protože zkušenosti s tak
řídce používaným nástrojem jen málo obohacují profesní profil.
Optimální využití produktu a služeb jiné firmy znamená nejen to, že část řešení
může být vyvinuta napřed, ale také to, že se tu otevírá zdroj odborných
znalostí zaměstnanci dodavatele mohou poradit, jak nejlépe propojit jimi
nabízený software s vaším systémem. To ušetří vývojářům spoustu biflování o
funkčnosti a vlastnostech produktu. Na druhou stranu může špatně zvolený
produkt od jiné firmy omezovat možnost budoucí volby alternativ.
Přístup k novým standardům a metodikám se pohybuje v širokém rozmezí od
pokládání je za "svatý grál" až po jejich zavrhování jako nesmysl. Pravda je
podle Carolla někde uprostřed. "Nejsou žádným náboženstvím, ale jednou ze
strategií zmenšujících riziko," vysvětluje. Přinejmenším jejich použití přináší
"body za splnění" u vlády i u mnohých firem, zatímco jejich opomenutí znamená,
že vývojář může být v případě problémů systému pranýřován za nedodržování
standardů. A to bez ohledu na to, jde-li o pravou příčinu potíží nebo ne.
Schopnost vytvořit a nasadit nějaký systém rychle je přirozeně velmi podstatná,
ale stejně by měla být pozornost věnována i dlouhodobé životnosti. Software v
jádru systému nevyhnutelně zastará a požadavky zákazníka se budou měnit až do
bodu, kdy již nebude možno systém dále upravovat. Určení trvanlivosti už v
časných fázích projektu může mít významnou hodnotu při vytváření obchodního
případu. "Promluvte si s účetními, než budete sestavovat svůj obchodní případ,
a zjistěte si, jak jej budou hodnotit. Existuje asi 15 různých způsobů, jak
počítat hotovostní toky a čistou zůstatkovou cenu. Měli byste vědět, kterou
použijí," vysvětluje Carroll. A dodává: "Cena odchodu systému do důchodu na
konci jeho životnosti a jeho nahrazení něčím jiným by měla být započítána v
jeho návrhu již od samého začátku."









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