Model Driven Arch
Transcript of Model Driven Arch
-
8/6/2019 Model Driven Arch
1/21
Etapele dezvoltrii software utiliznd MDA(Model Driven Architecture)
Prof Coordonator:
Prof.univ.dr. Florin Dumitriu
Studeni:Andreea Ioana Gheorghiu
Livia-Maria Ciobanu
Anca-Lavinia Moruz
Master SIA-Gr 2
-
8/6/2019 Model Driven Arch
2/21
Cuprins
CAP1. Modelul tradiional de dezvoltare a aplicaiilor informatice i problemele generate de
acesta .........................................................................................................................................3Dezvoltarea tradiional de software i problemele sale..........................................................3
A. Problema productivitii ............................................................................................... 4B. Problema portabilitii ..................................................................................................4C. Problema interoperabilitii .......................................................................................... 5D. Problema mentenanei i a documentrii .......................................................................5
CAP2. Ciclul de dezvoltare al MDA........................................................................................... 52.1 Ce este modelarea?...........................................................................................................52.2.Beneficiile MDA..............................................................................................................62.3 Ciclul de via: punctele cheie i etapele dezvoltrii MDA ...............................................7
3. Exemplu aplicare MDA........................................................................................................153.1 Serviciul de mic-dejun al Anei ....................................................................................... 15
Sistemul software .............................................................................................................. 163.2 Aplicarea standardului MDA..........................................................................................16
3.2.1 PIM i PSM .............................................................................................................. 173.2.2 Transformrile de la PIM la PSM.............................................................................. 173.2.3 Transformrile de la PSM la modelul de cod ............................................................. 18
3.2.4 Trei modele de abstractizare...................................................................................... 18
3.3 PIM n detaliu ................................................................................................................ 193.4 Concluzii........................................................................................................................ 19
Bibliografie: ............................................................................................................................. 21
-
8/6/2019 Model Driven Arch
3/21
CAP1. Modelul tradiional de dezvoltare a aplicaiilor informatice i
problemele generate de acesta
Dezvoltarea de software a fost mereu considerat o misiune dificil pentru toate
persoanele implicate. O dat cu mrirea numrului de funcionaliti dorite dar i cu formularea
de cerine tot mai complexe a fost nevoie ca i metodele de dezvoltare s fie mbuntite.
Modelul clasic, n cascad, a fost nlocuit cu tot felul de modele complexe: iterative,
incrementale, n spiral, n V, n X, orientat pe obiecte, dar nu tot timpul acest model se preta pe
nevoile clientului sau ale aplicaiei de construit.
n lucrarea sa Software Development M. Hamilton, ncearc s creeze o paralel ntre
cele 10 porunci primite de Moise i cele 10 porunci pentru creatorii de software. Glumind el
spun c n fiecare diminea, mcar un programator, un analist sau un proiectant trebuie s setrezeasc cu o idee nou de tehnic, un nou instrument sau un prototip de aplicaie1. Dezvoltarea
unui bun software nu este uoar. Procesul necesit mult disciplin, grij pentru calitate la
fiecare nivel i un model eficient.2
Majoritatea sistemelor software nu mai pot fi construite de la zero, i cum acestea devin
din ce n ce mai complexe, re-utilizarea devine un factor important. Promovarea re-utilizrii este
aproape imposibil fr abstractizare, detaliile irelevante ar trebui s fie ignorate pentru reuita
proiectului. Exist o gam larg de metodologii n trend care ncearc s abstractizeze ct mai
mult conceptele i rezultatele ingineriei software. Abordat din perspectiva ingineriei software,MDD-ul (Model Driven Development) este una din aceste metodologii. Scopul principal este
portabilitatea, interoperabilitatea i reutilizarea.
MDA (Model Driven Architecture ) este o particularizare a MDD-ului, care se bazeaz
pe o serie de standarde care prezint modul de creare, management i traducere a modelului
produs 3.
Dezvoltarea tradiional de software
i problemele sale
n termeni de maturitate, dezvoltarea software este adeseori comparat cu cea hardware.
n timp ce pentru dezvoltarea de hard s-au fcut progrese enorme, progresul realizrii de soft
pare s fie infim. Aceast problem este mai mult o aparen, pentru c progresul nu poate fi
1 HAmilton, M., Software development- building reliable software, Prentice Hall, 1999, p.42 http://www.tedogrady.com/development.htm3J. Miller, and J. Mukerji,MDA Guide Version 1.0.1, Object Management Group (OMG), 2003
-
8/6/2019 Model Driven Arch
4/21
msurat n cost sau viteza dezvoltrii. Progresul n dezvoltarea de software devine evident cnd
ne gndim c este mult mai fezabil s se construiasc sisteme mult mai mari i mai complexe.
Totui, procesul de creare de sisteme informatice este un domeniu destul de problematic. Munca
intens, refacerea programelor odat cu apariia noilor tehnologii, comunicarea ntre componente
dar i o continu modificare a cerinelor.
Pentru a demonstra cum MDA-ul rezolv aceste probleme vom analiza cteva din aceste
probleme pentru a le descoperi cauza.
A. Problema productivitiiProcesul dezvoltrii, aa cum este el cunoscut astzi este caracterizat de o codare i un design
precar. Procesul tipic cuprinde urmtoarele faze: conceptualizare i primirea cerinelor, analiz i
descriere funcional, design, codare, testare i implementare. Fie c este folosit un model
incremental i iterativ sau cel clasic n cascad, documentarea i diagramele sunt produse n
primele trei faze incluznd descrierea cerinelor i multe diagrame UML: diagramele cazurilor de
utilizare, diagrame de clase, de interaciune, de activiti, etc. Masa de hrtie produs este de
obicei doar hrtie irosit i nimic mai mult. Documentele i diagramele create i pierd rapid
valoarea. Conexiunea dintre cod i diagrame dispare o dat ce se ncepe scrierea programelor.
Mai mult o dat cu schimbarea sistemului n timp, aceste diagrame nu mai sunt refcute, din
perspective de cost, iar distana devine i mai mare.
Idee de Extreme Programming a devenit popular, pentru c se baza pe faptul c partea de
scriere a codului i de testare sunt singurele etape productive ale procesului. Dar dup cum
afirma A. Cockburn n cartea Agile Development, tehnica nu rezolv dect pe jumtate
problema; avnd doar cod i testare mentenana devine din ce n ce mai dificil.
B. Problema portabilitiiIndustria software se face remarcat n faa altor domenii prin felul n care anual apar
tehnologii noi. Majoritatea companiilor trebuie s adopte aceste tehnologii noi dintr-o serie de
motive: tehnologia este cert de client, rezolv o serie de probleme, nu mai exist suport din
partea productorilor pentru vechile tehnologii.
Situaia devine mai complex deoarece i tehnologiile se schimb la rndul lor. Ele vin n
diferite versiuni fr garania compatibilitii. Ca o consecin softul existent este fie portat la o
tehnologie mai nou fie la o versiune mai nou a vechii tehnologii. Altfel el va trebui s opereze
mpreun cu sisteme noi i pot aprea probleme de comunicare4.
4 Warmer, J., Kleppe, A., Bast, W., MDA Explained: The Model Driven Architecture: Practice andPromise, Addison-Wesley, 1998, pp. 9-12
-
8/6/2019 Model Driven Arch
5/21
C. Problema interoperabilitiiSunt rare cazurile n care un sistem poate funciona n izolare. Majoritatea au nevoie s
comunice cu alte sisteme. Majoritatea aplicaiilor recente au o arhitectur pe trei nivele bazat pe
web. Chiar i n cazul sistemelor construite de la zero, sunt folosite mai multe tehnologii, uneori
i noi i vechi. De exemplu un sistem care folosete EJB are nevoie i de o baz de date
relaional. De-a lungul timpului am nvat s nu mai construim sisteme imense monolitice, i
ne strduim s producem componente car s fac acelai lucru prin interaciune. Problema apare
la comunicarea dintre diferitele componente dezvoltate pe diferite tehnologii.
D. Problema mentenanei i a documentriin seciunile precedente am amintit de problema mentenanei. Documentarea a fost i ea
mereu o problem. Mereu este realizat prea trziu. Majoritatea programatorilor cred c
principala lor ndatorire este s produc cod. Scrierea de documentaie cost bani i timp i
ncetinete procesul. Documentarea rmne sarcina fazelor ulterioare. Acesta este principalul
motiv pentru care documentaia are o calitate precar i nu este la zi. Desigur programatorii
greesc. n ciuda opiniei lor, scrierea documentaiei este una din ndatoririle lor majore.
O soluie la aceast problem ar fi generarea documentaiei direct din cod, cu ajutorul
acestuia, pentru a fi mereu la zi. Documentaia este de fapt parte a codului. Soluia este suportat
de unele limbaje cum ar fi java. ns problema este soluionat doar pentru documentaia de la
nivelul cel mai de jos. Restul documentelor (texte i diagrame) trebuie s fie refcute manual.
Avnd n vedere complexitatea sistemelor, documentarea, la cel mai nalt grad de abstractizare
este absolut necesar.
CAP2. Ciclul de dezvoltare al MDA
2.1 Ce este modelarea?
Problema principal care se ridic n momentul realizrii unei analize de sistem, n
general n domeniul creativitii tehnice, const n faptul c dei literatura de specialitate prezint
o serie de metode i tehnici pentru obinerea mai nti sub o form abstract modelul unui produs
tehnic i apoi realizarea fizic a acestuia, aceste metode i tehnici nu pot fi aplicate rutinelor.
Intervine n aceast activitate o serie de caracteristici, unele dobndite n urma experienei
specialistului: putere de analiz i sintez, spirit de abstracie, creativitate, etc.
Modelele reprezint abstractizri ale sistemelor. Un model este o reprezentare
simplificat sau abstractizat a unei realiti (un obiect sau un fenomen din lumea real).
Simplificarea este folosit deoarece realitatea este prea complex, iar pe de alt parte prea mult
-
8/6/2019 Model Driven Arch
6/21
complexitate face irelevant analiza problemei respective. Obiectivul modelrii nu este acela de
a copia realitatea ci de a selecta aspectele relevante i de a le analiza comportamentul. Modelele
sunt nite nlocuitori ai sistemului real care surprind esena i nu detaliile sistemului real.
Un model care descrie situaia n care un sistem va fi folosit ofer un important punct de
pornire. Un astfel de model este uneori numit Modelul de domeniu sau Model de afaceri. Acesta
poate ascunde destul de multe sau toate informaii cu privire la utilizarea sistemelor de prelucrare
automat a datelor.Este util s fie utilizate modele n diferitele proiecte desfurate, nu doar ca
un ajutor pentru a nelege o problem, dar i ca un surs de un vocabular comune pentru
utilizarea n alte modele.
Dac un model al unui sistem este pregtit corespunztor acesta arat sistemul n
mediul n care aceasta va funciona, acest model va ajuta s se neleag exact ceea ce sistemul
face.
2.2.Beneficiile MDAMDA (Model Driven Architecture) este o modalitate de a organiza i administra
arhitectura ntreprinderii suportat de instrumente automate i de servicii de definire a modelelor
cat i de facilitare a transformrilor dintre diferitele tipuri de modele, aa cum este definit n
OMG (Object Management Group).
MDA a fost introdus n mod oficial de ctre OMG n 2001, ca un termen umbrel
pentru a acoperi o gama larga de software de modelare i arhitectura caietul de sarcini a OMG.
De atunci, ambele seturi de specificaii MDA i utilizarea lor s-au extins n mod substanial, iar
termenul "MDA" (i mai generictermenul de "model cu motor") este acum recunoscut pe scarlarg n ntreaga lume - un succes clar pentru OMG, comunitatea de practicieni MDA este n
cretere.
MDA ncurajeaz utilizarea eficient a sistemului de modele n procesul de dezvoltare
software i sprijin refolosirea celor mai bune practici la crearea de familii de sisteme (sisteme
interconectate).
Dei conceptul de MDA este nou i nu este testat pe proiecte foarte mari, are foarte multe
beneficii:
generarea automata a codului de aplicare pentru orice limbaj; detalii de punere n aplicare diferite de funciile de afaceri; ofer o arhitectur care permite utilizarea unei platforme independente; includerea rapid a tehnologiilor emergente n sisteme deja existente; uor de adaptat pentru a se potrivi viitoarelor dezvoltri software avansate;
-
8/6/2019 Model Driven Arch
7/21
aplicaii i modelele de date trebuie s fie create o singur dat i pot fi apoimeninute sau mbuntite cu un minim de efort suplimentar;
modificri la logica de business de baz (i date) sunt realizate ntr-un singur loci sunt apoi transpuse n mod automat la toate aplicaiile care se bazeaz pe
aceast logic;
toate aplicaiile instalate pe un singur PIM sunt garantate pentru a partaja osingur, versiune coerent a logicii de afaceri i de date. Printre altele, acest lucru
nseamn c vor interopera cu uurin;
procesul de dezvoltare MDA asigur nu numai respectarea cerinelor de afacericonstruite prin proiectare i terminate prin implementarea final, dar, de
asemenea, asigur i ndeplinirea cerinelor de afaceri non-funcionale
(scalabilitate, securitate etc.);
cost redus pe parcursul ciclului de via al dezvoltrii aplicaiei; reduce timpul de dezvoltare pentru noile aplicaii; mbuntirea calitii aplicaiilor; creterea randamentului investiiilor tehnologie.
2.3 Ciclul de via: punctele cheie i etapele dezvoltrii MDA
Ciclul de via al dezvoltrii de software (System Development Life Cycle =SDLC) este
un proces ce are rolul de a asigura c toate cerinele funcionale i cerinele utilizatorilor,
obiectivele strategice i obiectivele sunt ndeplinite.
SDLC ofer o structurat i un proces standardizat pentru toate fazele de dezvoltare a
unui sistem. Este util a fi utilizat un ciclu de via generic pentru MDA - bazat pe dezvoltare de
software care poate fi folosit ca baz pentru construirea MDA - metodologii de baz printr-un
proces Metoda Inginerie (ME).
Ciclul de dezvoltare al MDA, care este prezentat n Figura 2.1, nu este foarte diferit de
ciclul de dezvoltare tradiional al unui sistem informaional. Sunt identificate aceleai faze de
dezvoltare n ambele situaii: dezvoltare tradiional i abordare cu ajutorul MDA. Una dintre
diferenele majore rezid n natura viziunilor, artefactelor care sunt create n timpul procesului de
dezvoltare. Artefactele sunt modele formale, de exemplu, modele care pot fi nelese de
computere.
-
8/6/2019 Model Driven Arch
8/21
Figura 2.1 Ciclul de dezvoltare software utiliznd MDA
Urmtoarele trei modele se afl n centrul de MDA:
PIM (Platform Independent Model) PSM (Platform Specific Model) Cod
Primul model care definete MDA este un model cu un nivel ridicat de abstractizare, care
este independent de orice tehnologie de punere n aplicare. Aceasta poart numele dePlatform
Independent Model(PIM).
Un PIM descrie un sistem software care accept unele modele de afaceri. ntr-un PIM,sistemul este modelat din punct de vedere al modului n care aceasta susine cele mai bune
afaceri. Faptul c un sistem va fi implementat pe un mainframe cu o baza de date relaional sau
pe un server de aplicaii nu joac nici un rol ntr-un PIM.
n urmtoarea etap, PIM este transformat ntr-unul sau mai multe Platform Specific
Model(PSMs). Un PSM este un model adaptat ce specific, pentru sistemul dat, n termeni de
implementare care sunt tehnologiile necesare de punere n aplicare a cerinelor. Un PIM este
transformat ntr-unul sau mai multe PSMs. Pentru fiecare platform tehnologic specific este
generat un PSM separat. Majoritatea sistemelor de astzi au mai multe tehnologii de control, prinurmare, este foarte des ntlnit ca mai multe PSMs s fie atribuite unui PIM.
Ultimul pas n dezvoltarea MDA este trecerea fiecrui PSM n cod, aceast transformare
este relativ simplu de realizat.
MDA definete PIM, PSM, i codul, i, de asemenea, definete modul n care acestea fac
referin unele la altele. Un PIM ar trebui s fie creat, apoi transformat n unul sau mai multe
-
8/6/2019 Model Driven Arch
9/21
PSMs, care apoi sunt transformate n cod. Un pas mai complex n procesul de dezvoltare MDA
este cel n care un PIM este transformat ntr-unul sau mai multe PSMs.
PIM, PSM, i codul sunt prezentate ca piese ale etapelor ciclului de via pentru
dezvoltarea software-ului cu ajutorul MDA-ului. Important de menionat este c ele reprezint
diferite nivele de abstractizare ale procesului de dezvoltare a sistemelor informaionale.
Figura 2.2 Cei trei pai importani n procesul de dezvoltare MDA
Standardul MDA definete termenii de PIM i PSM, ns documentaia OMG face
distincia dintre ei ca i o problem white black susinnd c un model este ntotdeauna fie de
tip PIM sau PSM. n realitate este foarte greu a stabili grania dintre cele dou modele.Este un model scris n UML specific pentru platforma Java, deoarece una dintre diagrame
de clase definete una sau mai multe interfee? Este un model care descrie interaciunile dintre
componentele specifice pentru anumite platforme doar pentru c unele din componentele sunt
componente motenite, care pot fi scrise n, s zicem, COBOL? Este greu de spus.
Aa cum am mai zis MDA folosete abstractizarea n procesul de dezvoltare a sistemelor
informaionale. Prin intermediul limbajului UML, MDA poate adopta diferite puncte de vedere
n proiectare sau diferite nivele de abstractizare. n figura urmtoare sunt prezentate premisele
MDA:
(a) Zooming in/out obiecte (b) Zooming in/out interaciuni
Simbolul reprezint o interaciune.
Figura 2.3 Zooming in and out (preluat i adaptat dinModel Driven Architecture
(MDA) Document number ormsc/2001-07-01, Architecture Board ORMSC,July 9, 2001
publicat pe www.omg.org).
-
8/6/2019 Model Driven Arch
10/21
"Zooming" out dintr-un model prezint o reea complex de obiecte (de exemplu,
obiecte de infrastructur, noduri, legturi, etc), pentru a obine un model simplificat cu mai
puine obiectele mari, respectiv, o privire asupra sistemului pentru a vedea aceste detalii.
"Zooming" out dintr-un model detaliaz protocolul de interaciune (de exemplu, o
platform specific, protocolul pentru log-in si autentificare) pentru a obine un model
simplificat cu o interaciune unic mai abstract, cu efectul global acelai, i, respectiv,
pentru a vedea acele interaciuni detaliate.
MDA permite zoom in pentru a duce la mai multe modele alternative (i vice-versa), prin
separarea modelului rafinat care se refer la punctele de vedere detaliate i simplificate.
MDA are nevoie de aceast flexibilitate pentru a face fa modelului platformei multiple
specifice implementri funcionalitii sistemului respectiv.
n MDA, termenul de platform este folosit pentru a se referi la detalii de inginerie
tehnologic i care sunt irelevante pentru funcionalitatea fundamental a unei componente
software. Lund n considerare, de exemplu, o definiie formal a unei operaiuni ce spune c
transferurile de fonduri dintr-un cont la un cont de economii trebuie verificate. Funcionalitatea
fundamental a acestei operaiuni este c o anumit sum se scade dintr-un cont desemnat i e
adugat la un cont de economii, cu o constrngere c cele dou conturi trebuie s aparin
aceluiai client. Aceast funcionalitate rmne aceeai i dac operaia se efectueaz de un
obiect CORBA, Enterprise Java Beans, sau de un alt tip de obiect5.
MDA se bazeaz pe transformarea i adaptarea sistemului existent la un nou sistem ce va
fi capabil s rspund tuturor cerinelor utilizatorului.
Transformarea modelului este procesul de conversie a unui model la un alt model de
acelai sistem. Platform Independent Modeli alte informaii sunt combinate pentru a produce
un Platform Specific Model. Aceast transformare poate fi fcut n mai multe moduri. Se
produce, de la un PIM, un anumit model pentru o platform particular. n cazul n care PIM
este bazat pe virtual machine, transformrile nu sunt necesare. n schimb, PIM bazat pe maina
virtual este transformat ntr-un PSM pentru o anumit platform. PSM pot fi apoi transformate
ntr-o implementare concret pentru acea platform. O implementare furnizeaz toate
informaiile necesare pentru a construi un sistem i pentru fi funcional.
Figura de mai jos prezint o descriere a meta-modelului MDA, sau mai bine zis paii
efectuai n modelarea MDA a sistemului. PIM, PSM i maparea tehnicilor se bazeaz pe
metamodel i sunt dezvoltate, de preferin, cu tehnologii de baz recomandate de OMG ca
MOF, CWM sau UML.
5Model Driven Architecture ormsc/2001-07-01
-
8/6/2019 Model Driven Arch
11/21
Figura 2.4 MDA- metamodel descriere
Unul dintre elementul cheie al abordrii MDA este noiunea de mapping sau mapare. O
mapare este reprezentat de un set de reguli i tehnici utilizate pentru a modifica un model, n
scopul de a obine un alt model. Maprile sunt utilizate pentru transformarea:
1. PIM la PIM. Aceast transformare este utilizat atunci cnd modele sunt mbuntite,filtrate sau specializate n timpul ciclului de via fr a avea nevoie de o alt platform
dependent de informaii. Una dintre cele mai evidente mapri este analiza pentru
proiectarea modelelor de transformare. Maprile PIM-PIM sunt n general legate de
modelul de rafinament.
2. PIM la PSM. Aceast transformare este utilizat atunci cnd PIM este suficient de rafinatpentru a fi proiectat n infrastructura de execuie. Proiecia se bazeaz pe caracteristicile
platformei. Descrierea acestor caracteristici ar trebui s fie fcut cu ajutorul unui
instrument ce utilizeaz limbaj UML (i, eventual, un profil pentru a descrie concepte
platformele comune). Trecerea de la componentele modelului logic la componentele
model comercial cu ajutorul diferitelor instrumente (cum ar fi EJB pentru platforma
J2EE sau CNC pentru platforma CORBA) reprezint un model de mapare PIM - PSM.
-
8/6/2019 Model Driven Arch
12/21
Figura 2.5 Modelul de mapare PIM-PSM (preluat din preluat din Kleppe, A., Warmer, J., Bast W. -MDA
Explained: The Practice and Promise of the Model Driven Architecture, Ed. Addison Wesley, 2003)
3. PSM la PSM. Aceast transformare este necesar pentru realizarea de echipamente ia implementrii. Maparea PSM - PSM este n general legat de platforma dependent demodelul de rafinament.
4. PSM la PIM. Aceast transformare este necesar pentru abstractizarea modelelor dinimplementrile existente ntr-o anumit tehnologie ntr-un model independent de
platform. Aceast procedur seamn adesea cu "exploatare", proces greoi de
automatizat. Ea poate fi sprijinit de instrumente. n mod ideal, rezultatul acestei mapri
va corespunde maprii PIM - PSM.
Figura 2.6 Metamodel MDA - exemplu
Pentru a nelege mai bine cum funcioneaz principiile MDA vom ncerca o
exemplificare a pailor necesari aplicrii acestuia.
-
8/6/2019 Model Driven Arch
13/21
Dup cum am menionat deja n prima parte a prezentului document, MDA definete o
abordare a specificaiilor de sistem care separ cerinele funcionalitii sistemului cerinele de
punere n aplicare specifice platformei. Aceasta se face prin specificarea standardelor de model a
sistemului ntr-un mod reutilizabil. Acest lucru permite dou direcii principale:
1. Un sistem poate fi definit ca platform independent i apoi se poate realiza pe maimulte platforme prin standarde de mapare auxiliare.
2. Diferite aplicaii pot fi integrate chiar dac acestea nu ruleaz pe aceeai tip deplatform.
Primul pas atunci cnd se creeaz o aplicaie bazat pe MDA este crearea modelului
independent de platform (PIM). PIM vor fi exprimate n UML n funcie de modelul de baz
corespunztor. Modelele de baz sunt disponibile sub form de profile UML dintre care un
numrdestul de mare sunt pe cale de a fi standardizate de OMG.
Urmtorul pas este de a converti acest model de aplicare general, pentru o anumit
platform Model (PSM). PSM este derivat din PIM prin utilizarea unor reguli de transformare
standard. Dei PIM definete funcionalitatea necesar, PSM specific modul n care aceast
funcionalitate este realizat pe o platform special.
Aceast separare ntre cerine, activiti general operaionale i sistemul de funcii
specifice, oferind specificaiilor acestor activiti o implementare real, este foarte bine
cunoscut, de exemplu, n domeniul militar.
PIM este echivalent cu sistemul independent Operational View al modelului ("Ce ne-am
construit? Ce funcii sunt necesare din punct de vedere funcional?"). PSM poate fi interpretat ca
Systems View de arhitectura modelului ce va fi construit ("Cum putem pune n aplicare?").
Punctele de vedere tehnice ("Ce standarde avem nevoie pentru punerea n aplicare?"), de
asemenea, se reflect n MDA, prin introducerea unor aa-numite stereotipuri n UML - ntr-un
ultim pas al procesului de rafinament al modelului.
Ultimul pas este de a genera codul de la aceste modele specifice UML. Figura 2.7 arat
organigrama pentru procesul de ansamblu. n aceasta figur, dou seturi de cerine nu au fost
tratate n mod explicit pn acum, Pervasive Services Model i Domain Facilities Model:
1. Pervasive Services Model este conectat direct la domeniile CORBA standardizate deDomain Task Forces (DTF) membru OMG. Fiecare DTF produce framework-ul standard
pentru funcii standard i modul aplicrii lor. n cartea lui Andreas Tolk: "Heterogeneous
Synergy A Vision for the Next Generation of Warfighter IT Systems, sunt prezentate
mai multe modele (inclusiv referiri la DTF care se ocup cu probleme C4ISR din
perspectiva CORBA) .
-
8/6/2019 Model Driven Arch
14/21
2. Domain Facilities Model cuprinde definirea unui set de servicii eseniale, care sunt
implementate de serviciile CORBA; de exemplu, servicii precum eveniment de
notificare, obiect de securitate, tranzacii, etc n plus, atributele hardware i software
precum scalabilitate, real-time, toleranei la erori, etc pot fi modelate, de asemenea, dac
utilizatorul simte nevoia s fac acest lucru n scopul de a standardiza modelul.
Figura 2.7 Generare aplicaie utiliznd MDA
Un alt aspect ce trebuie s fie menionat, de asemenea: dup ce PSM a generat n UML,
codurile surs, fiiere de configurare, respectiv DTD (Document Type Definition termen
utilizat n XML pentru a defini elementele utilizate n scheme) sau scheme XML, SOAP, etc
partea de elaborare i asamblare a elementelor generate de UML - poate fi susinut - n cele mai
multe cazuri, chiar i executat - de instrumente software.
Unul dintre domeniile care vor fi mbuntite n viitorul apropiat este dezvoltarea i
implementarea instrumentelor software ce vor sprijini dezvoltatorii de aplicaii bazate MDA. n
prezent un numr redus de instrumente MDA sunt disponibile, dar dac ne amintim de evoluia
CORBA i UML, acest lucru este destul de probabil s se schimbe n viitorul apropiat. Aceste
instrumente nu vor sprijini numai utilizatorul n crearea PIM bazate pe facilitile din domeniu i
serviciile existente, de asemenea i depozitul comun va avea o mulime de soluii gata pentru a fi
reutilizate, soluii ce trebuie s fie modificate sau rafinate pentru a se potrivi cerinelor. Aceste
instrumente vor ajuta la maparea PIM n mod automat la PSM pentru cele mai utilizate platforme
(cum ar fi CORBA si NET.). Ele vor sprijini i modelul de mediere i integrare a modelelor
vechi.
Ca majoritatea standardelor tehnice, MDA faciliteaz eforturile reengineering-ului de
modele vechi, reengineering care nu vine odat cu introducerea MDA automat. Este necesar un
efort suplimentar de gestionare ntr-o form de aliniere a proceselor participative. Obiectele i
-
8/6/2019 Model Driven Arch
15/21
modelele de date, care nu sunt aliniate corespunztor nu vor fi armonizate prin utilizarea
aceluiai standard care face structurarea. Metodele necesare pentru a face fa acestei provocri
de interoperabilitate - cum a propus n Andreas Tolk n lucrrile sale i Steven P. Wartik, Brian
A. Haugh, Francisco Loaiza, Michael R. Hieb n lucrarea A Methodology for Comparing C4I
Data Models and Simulation Object Models - nu fac parte din MDA, dei acestea sunt
demersurile necesare pe cale de a interoperabilitii. Cu toate acestea, MDA este o alegere
excelent pentru a alinia arhitecturile, sau cel puin pentru a descrie arhitecturile ntr-un limbaj
comun ce va facilita compararea i identificarea neconcordanelor posibile.
Trebuie menionat c MDA a fost numit o tendin cheie n industria de software de
PricewaterhouseCoopers n publicaiile Technology Forecast pentru anii 2002-2004, care
raporteaz c MDA este gata s revoluioneze proiectarea software i procesul de dezvoltare.
Prin urmare, MDA va deveni un instrument de succes precum soluia de middleware CORBA,
limbajul de modelare UML.
3. Exemplu aplicare MDA
Capitolul de fa i propune s ofere un exemplu concret de aplicare a procesului MDA.
Pentru a evidenia importana abordrii MDA, sistemul descris nu este unul trivial, ci unul
concret, desprins din viaa real.
3.1 Serviciul de mic-dejun al AneiExemplul de fa expune sistemul de comenzi aferent Serviciul de mic-dejun al Anei.
Ana a nfiinat o companie ce furnizeaz micul dejun complet la domiciliul clienilor si.
Clienii pot alege din meniul disponibil pe pagina de internet a Anei, indicnd ora i adresa la
care doresc sa fie livrat mic-dejunul, introduc datele crii de credit, iar comanda este onorat.
Sloganul Anei este: "Surprinde-i soul, soia, iubitul, iubita, mama, tatl sau cel mai bun prieten
ntr-o zi special fr a renuna la confortul patului tu".
Ana a conceput o serie de mic-dejunuri, fiecare dintre acestea fiind oferite cu decoraiuni
speciale. De exemplu, mic-dejunul de Sf. Valentin este servit pe farfurii decorate cu inimioare icupidoni, avnd erveele asortate. Mic-dejunul poate fi unul franuzesc (cafea, suc de portocale,
croissant, unt i dulcea), englezesc (ou i bacon, pine prjit, marmelad i ceai) sau festiv
(ampanie, baghete, brnz franuzeasc i cafea). Comenzile pot fi plasate i pentru un grup mai
numeros, fiecare persoan avnd posibilitatea de a comanda un anume mic-dejun.
Modalitatea n care mncarea este servit poate diferi: simplu, regular sau deluxe. Un
mic-dejun simplu va fi servit pe o tav de plastic, farfurii de carton i pahare de plastic. Cel
-
8/6/2019 Model Driven Arch
16/21
regular implic o tav de lemn, vesela de porelan li paharele de sticl. Mic-dejunul deluxe va fi
servit pe o tav de argint, o vaz cu flori i erveele de mtase. Evident, preurile cresc pe
msur ce stilul de servire este unul mai bun. Unele tipuri de mic-dejun pot fi comandate doar n
stilul deluxe.
Ana are 10 angajai care ajung n buctrie la 5:30 n fiecare diminea i care muncesc
pn la prnz. Cinci dintre ei se ocup de livrri, iar ceilali 5 de prepararea meniurilor. Buctria
Anei este localizat n vecintatea unei brutrii. Primul lucru pe care Ana l face dimineaa este
s se aprovizioneze cu pine proaspt. Restul ingredientelor sunt inute pe stoc. De dou ori pe
sptmn se face reaprovizionarea.
Ana i dorete s le ofere clienilor ei flexibilitate. Clienii au posibilitatea, dup alegerea
unui anumit meniu de baz, s adauge anumite feluri suplimentare sau s renune la ele.
Sistemul software
n acest exemplu suntem interesai s urmrim sistemul necesar susinerii afacerii Anei inicidecum de mic-dejunul delicios preparat de Ana. Sistemul de comand este reprezentat de o
aplicaie web- based standard, pe trei straturi. Va fi nevoie de doua interfee web, una pentru
clieni i cealalt pentru angajaii Anei care va indica tipurile de mic-dejun comandate. n cazul
n care clientul este de acord, numele i adresa acestuia vor fi reinute n sistem. n acest fel, Ana
va putea oferi discount-uri clienilor fideli.
Interfaa web destinat clienilor va trebui s rspund la informaiile clienilor. cnd un
client fidel se autentific, o list a comenzilor anterioar va fi disponibil cu posibilitatea
repetrii comenzii. Baza de date va trebui s conin astfel informaii despre clieni: nume,preurile tuturor tipurilor de meniu disponibile i detalii despre comenzi anterioare. Nivelul 2 al
aplicaiei va avea rolul adugrii comenzilor i clienilor n baza de date.
Am luat astfel decizia de a folosi o arhitectur pe trei nivele pentru sistemul Anei.
Bineneles, se pot face i alte alegeri legate de arhitectura sistemului. Aplicaia va conine astfel
o baz de date, un nivel 2 care utilizeaz Enterprise Java Beans (EJB) i o interfa client
construit cu Java Server Pages (JSP).
3.2 Aplicarea standardului MDAAna va fi interesat doar de sistemul final. Dar, deoarece acesta este un exemplu care
ilustreaz modul n care standardul MDA poate fi aplicat, vom fi interesai n mod special de
procesul construirii sistemului dedicat afacerii Anei.
Vom analiza prile procesului care sunt relevante n cadrul modelului. Vom identifica
care dintre modelele specifice platformei (PSMs) i modelele de cod ar trebui definite i ce
definiii de transformare (transformation definitions) ar trebui utilizate pentru generarea acestora.
-
8/6/2019 Model Driven Arch
17/21
Toate elementele modelului MDA utilizate n cadrul acestui exemplu sunt regsite n
figura 3.1. Modelele sunt simbolizate prin dreptunghiuri, iar transformrile prin sgei.
Figura 3.1 Model pe trei nivele pentru sistemul Anei (traducere i adaptare dup Kleppe, A., Warmer, J.,
Bast W. -MDA Explained: The Practice and Promise of the Model Driven Architecture, Ed. Addison Wesley, 2003)
3.2.1 PIM i PSM
Pentru a ncepe procesul MDA trebui s construim un model independent de platform ce
acoper ntreaga afacere a Anei. Pentru a simplifica, PIM-ul va fi schematizat n limbaj UML.
Acesta este singurul model pe care dezvoltatorul l va crea n ntregime manual. Celelalte modele
sunt n cea mai mare msur generate.
Deoarece fiecare nivel este implementat prin utilizarea unei tehnologii diferite, vom avea
nevoie de 3 PSM, unul pentru fiecare strat. Primul PSM specific baza de date i este descris
printr-un model relaional reprezentat ntr-o diagram Entitate Relaie.
PSM-ul destinat stratului de mijloc, care poate fi denumit modelul EJB, este scris ntr-un
limbaj ce reprezint o variant de UML. Folosete clase, asocieri la fel ca n UML, dar conine o
serie de stereotipuri definite explicit de platforma EJB.
PSM-ul interfeei web este de asemenea scris intr-o variant de limbaj UML. acest limbaj
utilizeaz stereotipuri diferite de cele folosite pentru modelul EJB. Nici una dintre aceste
variante nu este standardizat ns.
3.2.2 Transformrile de la PIM la PSM
Deoarece aceste trei PSM trebuiesc generate, avem nevoie de trei transformri de la PIM
la PSM:
-
8/6/2019 Model Driven Arch
18/21
transformare de la PIM la relaional: o transformare care ia ca date de intrare un modeldefinit n UML i care produce un model scris n termeni specifici diagrame lor entitate-
relaie.
transformare de la PIM la modelul EJB: o transformare ce are ca date de intrare un modeldefinit n UML i care produce un model scris ntr-o variant de UML ce folosete
stereotipuri EJB.
transformare de la modelul web la modelul EJB: o transformare ce are ca date de intrareun model definit n UML i care produce un model scris ntr-o variant de UML ce
folosete stereotipuri pentru interfaa web.
3.2.3 Transformrile de la PSM la modelul de cod
Pentru fiecare PSM trebuie s generm cod. Codul este explicit inclus s se ncadreze
definiia modelului. Aadar, putem vorbi de modele de cod scrise n diferite limbaje de
programare. Modelul de cod definete aplicaia n cod. Pentru afacerea Anei vom avea nevoie detrei modele de cod: SQL, Java i JSP. Aadar, va fi nevoie de trei transformri de la PSM la cod:
transformare de la modelul relaional la SQL: o transformare ce ia ca date de intrare unmodel de tipul entitate-relaie i produce un model scris n SQL.
transformare de la modelul EJB la Java: o transformare ce ia ca date de intrare un modelscris n UML varianta EJB i produce un model scris n Java.
transformare de la modelul web la JSP i HTML: o transformare ce ia ca date de intrareun model scris n UML varianta web i produce un model scris n JSP i HTML.
3.2.4 Trei modele de abstractizare
Toate modelele din acest exemplu descriu acelai sistem, dei la un nivel diferit de
abstractizare.
La cel mai nalt nivel de abstractizare definim PIM. Acest model definete conceptelefr a specifica nici un detaliu referitor la tehnologie.
La urmtorul nivel se afla PSM. Aceste modele se distaneaz de specificitatea codului,dar sunt totui specifice platformelor.
La nivelul inferior se afl trei modele de cod. Aceste modele sunt, evident, modele pure,specifice platformelor.
Figura 3.1 structureaz diferitele modele pe cele trei nivele de abstractizare i evideniaz
transformrile dintre ele. Se poate observa c nivele de abstractizare sunt prezentate de sus n jos.
Straturile sunt reprezentate de la dreapta la stnga.
-
8/6/2019 Model Driven Arch
19/21
3.3 PIM n detaliu
PIM al sistemului de mic-dejun al Anei este reprezentat n figura 3.2. PIM este singurul
model ce trebuie creat de ctre dezvoltatori. Modelul este reprezentat n limbaj UML.
Figura 3.2 Modelul independent de platform pentru sistemul Anei
n PIM fiecare mic-dejun standard conine un numr de pri; fiecare parte reprezint
cantitatea n care un anumit fel de mncare coninut n mic-dejun. fiecare comand conine unnumr de mic-dejunuri. Preul fiecrui mic-dejun este determinat pe baza stilului ales i al
preului micului-dejun standard ales. Preul fiecrei comenzi este suma preurilor tuturor mic-
dejunurilor plus o tax de livrare.
Modelul din figura 4.2 definete serviciile de mic-dejun indiferent de tehnologie, deci
este intr-adevr un Model Independent de Platform. Dar Ana nu i dorete un model, ci un
sistem funcional. Aadar, PIM trebuie transformat ntr-un numr de Modele Specifice
Platformei lund n considerare relaiile dintre aceste modele.
3.4 Concluzii
Pentru a sublinia caracteristicile abordrii MDA este necesar descrierea unui sistem real.
Exemplul referitor la sistemul de mic-dejun al Anei - o companie care livreaz mic-dejunul la
domiciliu este departe de a fi trivial.
Un Model Independent de Platform relativ simplu este descris. PIM va fi transformat
automat ntr-un Model Specific Platformei Relaional, un Model Specific Platformei Web i un
-
8/6/2019 Model Driven Arch
20/21
Model Specific Platformei EJB. Cele trei PSM vor fi transformate n trei modele de cod separate.
Dup cum am specificat i anterior, modelul MDA i demonstreaz utilitatea atunci cnd
procesele de transformare nu sunt triviale sau atunci cnd transformarea este cunoscut, dar
implic un volum mare de munc. n acest exemplu, ambele situai i sunt ntlnite. Maparea
UML-Relaional este util deoarece aduce rapiditate procesului. Maparea UML-EJB este o
maparea non-trivial n cadrul crora regulile de transformare mbuntesc valoarea tiinific a
platformei.
Transformrile modelului relaional n cod sunt simple deoarece modelul relaional
conine structuri ce pot fi mapate una cte una ctre structurile utilizate n limbajul SQL.
Transformarea modelului EJB n cod implic folosirea unui model intermediar numit
Clasa EJB PSM. Aceasta a fost scris n limbajul definit de o variant UML - profilul EJB
standardizat. Deoarece generarea codului din clasa EJB PSM este foarte simpl, nu a fost
descris n acest capitol. Pentru a evita complexitatea codului Web, a fost definit o transformare
simpl din modelul Web n cod JSP i HTML
La modul general, se poate afirma faptul c atunci cnd sursa i limbajele surs sunt
foarte diferite, transformarea devine foarte complex. Modificri nesemnificative n modelul
surs pot avea un impact major asupra structurii modelelor destinaie i implicit asupra codului
de implementare.
Procesul implementrii PIM este mbuntit semnificativ de aplicarea modelului MDA
n termeni de calitate deoarece suntem forai s specificm n mod explicit definiiile de
transformare care au o aplicabilitate general.
-
8/6/2019 Model Driven Arch
21/21
Bibliografie:
1. Hamilton, M., Software development- building reliable software, Prentice Hall, 19992. F. Truyen, The Fast Guide to Model Driven Architecture, The Basics of Model Driven
Architecture
3. David S. Frankel,Model-Driven Architecture TM4. J. Miller, J. Mukerji, MDA Guide Version 1.0.1, Object Management Group (OMG),
2003
5. Kleppe A., Warmer J., Bast W., MDA Explained: The Model Driven Architecture:Practice and Promise
6. Ph. Dr. Richard Mark Soley, Model Driven Architecture An introduction7. Model Driven Architecture (MDA) Document number ormsc/2001-07-01, Architecture
Board ORMSC,July 9, 2001 publicat pe www.omg.org
8. http://www.compuware.com/dl/Model_Driven_41.pdf9. http://www.omg.org10.http://www.sdtimes.com/article/special-20021015-01.html11.http://www.omg.org/mda/mda_files/Kabira_on_Model_Driven_Architecture.pdf12.http://www.tedogrady.com/development.htm