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


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


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


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


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


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;


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/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


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).


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


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.


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.


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) .


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


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


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.


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:


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.


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


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.


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

Date post:	07-Apr-2018
Category:	Documents
Upload:	tkdokid
View:	332 times
Download:	0 times

Model Driven Arch

Documents