UNIVERSITATEA ALEXANDRU IOAN CUZA IAŞI FACULTATEA DE INFORMATICĂ
LUCRARE DE DIZERTAȚIE
Dezvoltare coordonată de model folosind Enterprise Architect
propusă de
Simina Tofan
Sesiunea: februarie, 2014
Coordonator ştiinţific
Dr. Adrian Iftene
UNIVERSITATEA ALEXANDRU IOAN CUZA IAŞI FACULTATEA DE INFORMATICĂ
Dezvoltare coordonată de model folosind Enterprise Architect
Simina Tofan
Sesiunea: februarie, 2014
Coordonator ştiinţific
Dr. Adrian Iftene
Declaraţie privind originalitatea şi respectarea drepturilor de autor
Prin prezenta declar că Lucrarea de dizertaţie cu titlul “Dezvoltare coordonată de model folosind Enterprise Architect” este scrisă de mine și nu a mai fost prezentată niciodată la altă facultate sau instituție de învățământ superior din țară sau străinătate. De asemenea, declar că toate sursele utilizate, inclusiv cele preluate de pe Internet, sau indicate în lucrare, cu respectarea regulilor de evitare a plagiatului:
toate fragmentele de text reproduse exact, chiar și în traducere proprie din altă limbă, sunt scrise între ghilimele și dețin referința precisă a sursei;
reformularea în cuvinte proprii a textelor scrise de către alți autori deține referința precisă;
codul sursă, imagini etc. preluate din proiecte open-source sau alte surse sunt utilizate cu respectarea drepturilor de autor și dețin referințe precise;
rezumarea ideilor altor autori precizează referința precisă la textul original.
Iași,
Absolvent: Simina Tofan _______________
Declaraţie de consimţământ
Prin prezenta declar că Lucrarea de dizertaţie cu titlul “Dezvoltare coordonată de model folosind Enterprise Architect”, codul sursă al programelor şi celelalte conţinuturi (grafice, multimedia, date de test etc.) care însoţesc această lucrare să fie utilizate în cadrul Facultăţii de Informatică. De asemenea, sunt de acord ca Facultatea de Informatică de la Universitatea Alexandru Ioan Cuza Iaşi să utilizeze, modifice, reproducă şi să distribuie în scopuri necomerciale programele-calculator, format executabil şi sursă, realizate de mine în cadrul prezentei lucrări de dizertaţie.
Iași,
Absolvent: Simina Tofan _______________________
Sumar
Capitolul I. Motivaţie ... 1
I.1 Context ... 1
I.2 Contribuţii ... 2
I.3 Structura lucrării ... 2
Capitolul II. Dezvoltarea software coordonată de model ... 4
II.1 Modelarea şi rolul acesteia în sistemele software ... 4
II.2 Principii şi concepte ... 4
II.3 Arhitecturi coordonate de model... 9
II.4 Modele MDA ... 11
II.5 Ciclul de dezvoltare MDA ... 12
II.6 Beneficii ... 14
II.7 Utilizarea în industrie ... 15
II.8 Concluzii ... 17
Capitolul III. Rent A Book: MDA folosind Enterprise Architect ... 19
III.1 Descrierea aplicaţiei ... 19
III.2 Realizarea aplicaţiei ... 20
III.3 Modelul CIM ... 21
III.3 Modelul PIM ... 23
III.4 Modelul PSM – EJB ... 25
III.5 Modelul PSM – JPA ... 30
III.6 Modelul ISM EJB ... 36
III.7 Modelul ISM JPA ... 39
III.8 Concluzii ... 41
Bibliografie ... 42
1
Capitolul I. Motivaţie
I.1 Context
Complexitatea sistemelor software este în continuă creştere, iar o dezvoltare cu success nu mai este definită doar de efortul individual sau resurse alocate. Succesul şi calitatea sunt direct dependente de procesul de dezvoltare ales.
Ca alternative la stilul de dezvoltare tradiţional, au fost propuse noi abordări:
Dezvoltare software bazată pe iteraţii (Agile Software Development), Programare extremă (Extreme Programming - XP), Rationale Unified Process (RUP), etc.
Dezvoltarea Agile are ca scop minimizarea cantităţii de efort şi timp necesar pentru a construi modele (modelul privit doar ca documentaţie) şi garantarea livrării unui soft care funcţionează, iar pe măsură ce cerinţele se schimbă şi produsul software trebuie modificat corespunzător.
XP este o tehnică ades folosită şi are ca punct central scrierea incrementală de porţiuni mici de cod, astfel încât în orice moment să fie un sistem funcţional. Fiecare cerinţă nouă trebuie să fie însoţită de un scenariu de test explicit.
RUP este un proces de dezvoltare mai elaborat decât cele menţionate anterior. Sunt avantajate proiecte de dimensiuni mari dar pe de altă parte, unii consideră că procesul este prea extins şi oferaă prea multă atenţie documentaţiei.
Dezvoltarea coordonată de model aduce o noua definiţie pentru procesul de dezvoltare şi rezolvă diverse neajunsuri cauzate de procesele de dezvoltare existente. Punctul central este modelul iar acesta nu este doar o piesă de documentaţie ci este un artefact şi presupune creşterea gradului de abstractizare şi automatizare. O particularizare a acestei tehnici este procesul MDA propus de OMG.
Tehnica de dezvoltare MDA este implementată cu succes în diverse companii şi confirmă beneficiile aşteptate, însă cu toate acestea, nu este acceptată în industrie pe scară largă. Motive pot fi de o parte setul redus de instrumente existent pe piaţă, ce oferă suport pentru acest tip de devoltare, iar pe de altă parte tehnica nu este bine înţeleasă sau este privită cusceptisim şi reticenţă.
2 I.2
Contribuţii
Aşa cum spune Paul Meyer: “Productivity is never an accident. It is always the result of a commitment to excellence, intelligent planning, and focused effort.” [Paul J. Meyer]
consider că dezvoltare calitativă se bazează pe un proces de dezvoltare calitativ. Dezvoltarea coordonată de model nu este soluţia tuturor problemelor întâlnite în cadrul dezvoltării software, însă este soluţia pentru multiple probleme importante de care ne lovim zilnic, iar potenţialul acestei tehnici nu este explorat la maxim.
Am ales ca topic pentru acestă lucrare, dezvoltarea coordonată de model, deoarece reprezintă o îmbunătăţire calitativă a stilului tradiţional de dezvoltare software. Procesul de dezvoltare şi conceptele ce stau la baza sa sunt din o perspectivă diferită faţă de cum suntem obişnuiţi, iar ideea de bază este: concentrează efortul o dată, încât să creezi instrumentele potrivite (artefacte, scripturi, etc) şi apoi aplică si reutilizează.
De asemenea, un alt motiv pentru care am ales acest topic este acela că am avut ocazia, în cadrul experienţei mele de software developer, să observ beneficiile aduse de către această tehnică, în urma aplicării sale.
Aşa cum am constatat ulterior, tehnica nu este adoptată în orice companie din motive mai mult sau mai puţin bine justificate şi de aceea, prin această lucrare doresc să contribui la încurajarea adoptării acestei paradigme.
În cadrul lucrării am prezentat concepte de bază ale dezvoltării coordonate de model şi particularizarea MDA propusă de către OMG. MDA este acum un concept de referinţă pentru acest tip de dezvoltare, pentru multe companii, şi de aceea am ales să dezvolt o aplicaţie, cu rol demonstrativ, care să exemplifice noţiunile prezentate şi ciclul de dezvoltare MDA.
Astfel, pornind de la un set minim de cerinţe, voi arăta cum se pot crea toate tipurile de modele MDA. De asemenea, voi arăta ce înseamnă o transformare MDA, atât din perspectiva definirii sale ca şablon cât şi din perspectiva aplicării sale.
I.3
Structura lucrării
Lucrarea este structurata in 3 capitole, dintre care primul capitol este unul introductiv.
Al doilea capitol realizează o introducere în ceea ce reprezintă dezvoltarea coordonată de model, având în vedere contextul actual, dar si elementele cheie ale acestei paradigme.
3
De asemenea, în acest capitol este prezentată particularizarea MDA de dezvoltare coordonată de model, cu modelele şi principiile ce stau la baza sa. Capitolul include şi explicarea ciclului de dezvoltare MDA.
Spre finalul capitolului am descris beneficiile pe care le aduce acest tip de dezvoltare si gradul de acceptare in industrie.
Capitolul final descrie în detaliu aplicaţia realizată ca suport practic pentru această lucrare.
4
Capitolul II. Dezvoltarea software coordonată de model
II.1 Modelarea şi rolul acesteia în sistemele software
Pentru o perioadă destul de mare de timp, codul a reprezentat baza dezvoltării software, iar utilizarea modelelelor a fost percepută ca şi un cost, şi nu un câştig de productivitate. Dar această abordare nu este potrivită pe termen lung, întrucât nu ia în considerare faptul că sistemele construite trebuie să fie uşor de întreţinut şi de integrat [3].
Sistemele software sunt din ce în ce mai complexe, astfel încât necesită discuţii pe diferite niveluri de abstractizare şi se bazează atât pe componente noi cât şi pe evoluţia celor existente iar în dezvoltarea acestora sunt implicate atât persoane ce posedă cunoştinţe tehnice cât şi persoane ce nu au astfel de cunoştinţe [4].
Modelele şi lucrul cu acestea (modelare) sunt o soluţie pentru aceste probleme. Ele fac legătura între cerinţă şi implementare şi sunt o abstractizare a unei realităţi, o simplificare a acesteia. Ȋntr-un model se regăsesc doar acele elemente ale sistemului real ce sunt esenţiale pentru perspectiva descrisă [1]. Binenţeles, se pot formula mai multe modele, din diverse puncte de vedere, pentru o aceeaşi realitate, astfel încât elementele aduse în discuţie să fie pe înţelesul tuturor. Rolul modelelor este unul important în domeniul ştiinţific, întrucât se pot folosi în scop descriptiv, prescriptiv sau pot defini implementarea unui sistem [1].
Dezvoltarea software coordonată de model are ca element central modelul şi propune o abordare nouă: modele văzute nu ca documentaţie ci ca artefacte de valoare echivalentă codului, odată ce implementarea modelelor este automată [3].
Astfel, modelul are un rol şi mai important decât până acum, pentru domeniul ştiinţific şi, în plus, încurajează convergenţa între dezvoltarea sistemelor software şi analiza sistemelor.
II.2 Principii şi concepte
Există o mulţime de abordări care au la bază modelul. Pentru unele, modelul este resursa coordonatoare pentru întreaga activitate, pentru altele, modelul este doar o bază
5
teoretică. De asemenea, pentru aceste abordări s-au definit multiple acronime de forma: MD*
[1]. Pentru a clarifica relaţia între acestea este utilă figura următoare:
Fig. 1 Relaţia între acronimele MD* [1]
Ingineria software coordonată de model (Model Driven Engineering - MDE) este o abordare prin care sunt relaţionate mai multe spaţii tehnologice în o manieră uniformă, făcând posibilă comunicarea între acestea şi, de asemenea, integrează arii de cunoştinţe dezvoltate de diverse comunităţi de cercetare [5].
Acest tip de inginerie se poate aplica pentru o multitudine de scenarii, dintre care:
automatizarea dezvoltării software, interoperabilitate a sistemelor, inginerie inversă, întreţinere a unui sistem. Totalitatea tipurilor de inginerii coordonate de model poartă numele de MD* (Model Driven Star). Alt exemplu de inginerie din tipul MDE este Ingineria produsului coordonată de model (Model Driven Product Engineering – MDPE).
Dezvoltarea software bazată pe model (Model Driven Development - MDD) este o parte a ingineriei coordonate de model. Are la bază conceptele de model şi transformare şi descrie o modalitatea prin care se poate ajunge de la artefactul iniţial: modelul, la artefactul final: componenta executabilă (cod).
Ingineria bazată pe model (Model Based Engineering - MBE) descrie grupul acelor inginerii în care modelul este prezent în faza de analiză şi utilizat în cadrul dezvoltării dar nu este piesa centrală pentru ciclul de dezvoltare şi are doar o formă statică. Astfel, putem spune că MBE este o generalizare a tipului MDE ( cu mai puţine restricţii).
Arhitecturi coordonate de model (Model Driven architecture - MDA) este particularizarea pentru MDD propusă de către OMG şi constituie subiectul capitolului III.
6
În cadrul acestei lucrări, accentul este asupra dezvoltării software coordonate de model (adesea referită precum dezvoltare coordonată de model) şi asupra particularizării oferite de către OMG.
Principalele aspecte ale dezvoltării coordonate de model sunt descrise prin următoarea schemă:
Fig.2: Descriere a paradigmei de dezvoltare coordonată de model [1]
Sunt două axe despre care putem vorbi: implementare şi conceptualizare [1].
Implementarea se ocupă cu maparea modelelor la sisteme existente sau la sisteme care se doresc a se dezvolta, şi pentru aceasta se definesc 3 aspecte principale [1]:
Nivelul de modelare – stagiu în care se definesc modelele.
Nivelul de realizare – stagiu în care soluţiile sunt implementate şi se obţin artefacte finale(cod).
Nivelul de automatizare – stagiu în care se mapează legăturile între nivelul de modelare şi cel de realizare.
Conceptualizarea se ocupă cu definirea modelelor conceptuale pentru a descrie realitatea şi se aplică pe 3 niveluri [1]:
Nivelul aplicaţiei – modelele aplicaţiei sunt definite, regulile aplicate şi componentele finale sunt obţinute.
Nivelul domeniului aplicaţiei – nivel în care se stabilesc definiţiile după care se pot formula elementele necesare la nivelul aplicaţiei.
Nivelul meta – nivel în care se definesc conceptualizările modelelor.
7
Asa cum menţionam anterior, dezvoltarea software coordonată de model poate fi exprimată prin formula [1]:
Modelul este artefactul iniţial pentru această abordare şi este creat conform cu un metamodel.
Modelul conceptual al domeniului problemei de rezolvat poartă numele de domeniu şi reprezintă pasul de start pentru dezvoltarea coordonată de model. Acesta descrie diverse entităţi, cu rolurile şi relaţiile lor, constrângeri şi interacţiuni ce asigură integritatea elementelor de model. Ingineria coordonată de model pune accent pe crearea şi folosirea domeniului în defavoarea conceptelor de calcul sau algoritmică [9].
Metamodelul este tot o abstractizare precum modelul, însă mai generic, şi este o descriere a tuturor concepteler ce pot fi folosite într-un model (altfel spus, metamodelul reprezintă definirea limbajului de modelare). Poate avea rol de model pentru un alt metamodel (este o relaţie de compozit între model şi metamodel, dar în practică, se folosesc doar aceste două nivele ).
În practică, metamodelul se foloseşte ca [8]:
Schemă pentru informaţii semantice ce trebuiesc interschimbate sau stocate.
Limbaj ce suportă o anume metodă sau proces.
Limbaj de definire pentru semantici adiţionale de informaţii existente.
Mecanism de creare de instrumente ce lucrează cu o multitudine de modele la momentul rulării.
Un exemplu de utilizare în practică a conceptului de metamodel este UML.
Totalitatea operaţiilor (compunere, aliniere, refactorizare, translatare, etc) ce sunt efectuate asupra modelelor poartă numele de transformări. Acestea permit definirea de mapări între diverse modele. Sunt definite la nivel de metamodel şi se aplică la nivel de model.
Transformarea se face de la un model sursă la un model destinaţie şi presupune [1]:
prima fază – definirea unui şablon de transformare (creat de la zero sau poate fi produs automat după o serie de reguli de relaţionare de nivel înalt) între elementele modelului sursă si cele ale modelului destinaţie.
8
a doua fază – automatizarea generării, printr-un sistem care primeşte ca date de intrare două definiţii de modele, aplică şablonul si produce transformările.
În funcţie de intrările şi ieşirile din un proces de transformare, putem vorbi de transformare [1]:
Model – către – model – transformare în care atât intrarea cât şi ieşirea sunt tip model.
Model – către – text – transformare în care ieşirea este tip text.
Text – către – model – transformare în care intrarea este de tip text şi iesirea este de tip model (utilizată în tehnica de inginerie inversă).
În teorie, pentru transformarea de tip model – către – model, atât numărul de modele folosite ca intrare cât şi numărul de modele folosite ca ieşire poate să varieze de la un model la mai multe modele, şi se pot face oricâte combinaţii între aceste numere.
În practică, este folosită cel mai adesea forma: un model intrare – un model ieşire.
De asemenea, în funcţie de limbajul modelului de intrare şi de cel al modelului de ieşire, putem vorbi despre [6]:
Transformare endogenă – transformare în care modelele sunt exprimate în acelaşi limbaj (exemplu: refactorizare).
Transformare exogenă – transformare în care modelele sunt exprimate în limbaje diferite (exemplu: transformarea PIM către PSM în MDA).
O alta formă de clasificare este cea din punctul de vedere a direcţiei de transformare [7]:
Unidirectională – procesul de transformare va folosi întotdeauna acelaşi tip de intrare şi va produce acelaşi tip de ieşire, comportament în care ieşirea nu va avea niciodată rol de intrare („read-only”);
Bidirecţională – în cazul acestui tip de transformare, un tip de model poate avea rol dublu: intrare sau ieşire. Comportamentul este util în lucrul cu multiple modele ce trebuiesc menţinute consistente, iar acest lucru facilitează ca modelul să reacţioneze atunci când sunt adăugate informaţii redundante sau sunt produse unele erori;
Transformările de tip model – către – text sunt folosite pentru a automatiza diverse activităţi de inginerie software, precum generarea de documentaţie, administrarea de liste de activităţi. Însă rolul cel mai important şi mai nou, este acela de a genera cod. Astfel, transformarea de acest tip sprijină scopul dezvoltării coordonate de model, şi anume acela de a
9
obţine cod din model. În funcţie de performanţa aplicaţiei de generare, codul poate fi parţial generat sau complet generat.
Atât modelele cât şi transformările se exprimă printr-un limbaj, numit limbaj de modelare. Cu ajutorul acestuia, este posibil să se definească în mod concret o reprezentare a modelului conceptual, sub formă grafică, textuală sau combinaţie între acestea. Există două mari clase de astfel de limbaje [1]:
Limbaje specifice unui domeniu (DSL) – limbaje create cu scopul de a facilita descrierea unor lucruri din acel domeniu/context (ex: HTML, Matlab, SQL, etc).
Limbaje de modelare cu scop general (GPML) – limbaje folosite pentru descrierea de modele din orice domeniu/context (ex: UML, reţele Petri, etc). Acestea nu se bazează doar pe o notaţie ci pe mai multe, astfel încât să permită definirea a diferite aspecte. Aceste limbaje se poartă numele şi de Suită de limbaje de modelare sau Familie de limbaje (ex: UML, prin diverse tipuri de diagrame).
O notaţie folosită în modelare pune accent pe caracteristicile unei perspective specifice, astfel, analiza unei probleme poate duce la diverse modele pentru a descrie aceeaşi soluţie.
Totalitatea acestor modele creează o descriere cât mai completă a sistemului, fără a amesteca detaliile fiecărei perspective în parte.
II.3 Arhitecturi coordonate de model
Arhitectura coordonată de model (MDA) este versiunea propusă de către Object Management Group (OMG) pentru dezvoltarea coordonată de model. Cuvântul „arhitectură”
din MDA nu se referă la arhitectura sistemului ce urmează a fi modelat ci mai degrabă la arhitectura diferitelor standarde şi modele pe care se bazează procesul de dezvoltare (exemple de standarde folosite: Unified Modeling Language (UML), Meta Object Facility (MOF), XML Metadata Interchange (XMI), etc). În timp, acesta a devenit un framework conceptual de referinţă pentru dezvoltarea coordonată de model, adoptat de mai multe companii.
MOF este un standard OMG cu arhitectura pe 4 niveluri, numite în mod convenţional:
M3, M2, M1 si M0 [5], creat pentru a specifica, construi şi administra metamodele independente. MOF este baza pentru definirea limbajelor de modelare, precum UML şi chiar MOF.
10
Fig.3 Arhitectura MOF [5]
Nivelul M3 este nivelul pentru meta-metamodele. Un exemplu de astfel de model este însuşi MOF.
Toate modelele care sunt conforme cu un meta-metamodel sunt modele de nivel M2 şi se numesc metamodele. UML şi SPEM (Software Process Engineering Metamodel) sunt exemple pentru modelele acestui nivel. Metamodele descriu familii de modele din lumea reală, modele ale nivelului M1.
Un model din nivelul M1 este o instanţă a unui metamodel din nivelul M2 şi este utilizat pentru a descrie un limbaj. Modelele UML conforme cu metamodelul UML şi cele RUP (Rational Unified Process) conforme cu metamodelul SPEM fac parte din acest nivel.
Nivelul M0 este nivelul elementelor ce sunt descrise in cadrul nivelului M1.
Conceptele MOF sunt:
Clase – modelează meta-obiectele MOF.
Asocieri – modelează relaţiile binare dintre meta-obiecte.
Tipuri de date – modelează tipurile de date(primitive sau externe).
Pachete – modularizează modelele.
Standardul XMI este conceput pentru a defini, interschimba, manipula şi integra date şi obiecte în format XML. Cu ajutorul acestuia, sunt definite mapările pentru meta-metamodele, metamodele şi modele în documente şi scheme XML, ajutând astfel la obţinerea unui format de interschimb a modelelor UML şi metamodelelor MOF.
Abordarea MDA adoptată de OMG are la bază patru principii [1]:
Modelele trebuiesc exprimate în notaţii bine definite, astfel încât comunicarea şi înţelegerea sistemelor să fie eficiente.
Specificaţiile sistemelor trebuiesc definite pe baza unui set de modele, transformări ale acestora şi relaţii între modele, astfel încât să se poată crea un framework arhitectural din perspective multiple şi pe mai multe niveluri.
11
Modelele trebuiesc create în concordanţă cu specificaţiile unui set de metamodele, pentru a facilita integrarea şi transformarea automată între modele.
Frameworkul de modelare ar trebui să ofere cât mai mult suport pentru tehnicile ingineriei coordonate de model.
II.4 Modele MDA
Procesul de dezvoltare MDA separă specificaţiile despre funcţionalitatea sistemului de implementarea sistemului pe o anumita platformă. Astfel, specificaţiile create pentru un sistem pot fi re-folosite pentru tehnologii diferite şi platforme multiple.
În cadrul MDA, există patru nivele de abstractizare a modelelor:
Modelul independent de sistemul de calcul (CIM).
Modelul independent de platformă (PIM) – un model cu un nivel mare de abstractizare şi care este independent de orice tehnologie de implementare.
Modelul specific unei platforme (PSM) – model prelucrat pentru a specifica un sistem în limbajul specific unei implementări disponibile pe o anumită platformă.
Modelul specific unei implementări (ISM) – o descriere (specificare) a unui sistem în cod sursă.
Modelul independent de sistemul de calcul (CIM) este un model care descrie funcţionalităţile unui sistem, fără a prezenta detalii tehnice. Este descrierea cea mai generală a unui sistem, o perspectivă a clientului asupra sistemului, iar unul din beneficiile sale este că e o sursa de comunicare între experţii tehnici şi cei de business. Acest model reprezintă sursa de cerinţe pentru nivelul următor de modelare, însă, pentru că reprezentarea sa nu este una formală, transformarea din acest nivel de modelare în următorul nivel, PIM, este una manuală sau cel mult, semi-automată.
Modelul independent de platformă (PIM) este modelul de bază pentru procesul de dezvoltare MDA. Conţine toate cerinţele de business ale sistemului software. Prezintă componentele sistemului software şi funcţionalităţi ale acestuia, însă fără a prezenta orice detaliu despre plaforma de implementare. Specificarea unui model PIM este de obicei făcută în diverse tipuri de diagrame, realizate cel mai adesea în UML. Acest model este model sursă pentru transformări automate către următorul nivel PSM (transformare exogenă) dar şi pentru
12
transformări endogene (de la PIM către PIM), cu scopul de a crea un alt model pentru sistemul respectiv, din un alt punct de vedere, accentuând alte aspecte ale specificaţiei.
Conform OMG, modelul PIM are trei beneficii majore [4]:
Validează corectitudinea modelului. OMG consideră că este mai uşor să se valideze un sistem bazat pe modele, dacă aceste modele nu conţin detalii specifice unei platforme de implementare.
Este uşor să creezi un sistem portabil pe viitoare platforme.
Integrarea şi interoperabilitatea între sisteme sunt definite în mod mai clar, într-o manieră indiferentă de specificaţiile unei platforme de implementare.
Modelul specific unei platforme este obţinut prin transformare automată din modelul PIM şi adaugă la specificaţiile deja definite ale sistemului, elementele specifice platformei de implementare (elemente tehnice). Dintr-un model PIM se pot obţine mai multe modele PSM, conform cu tehnologiile folosite. Fiind rezultatul unei transformşri automate, se păstrează legătura între modelul sursă şi modelul destinaţie, şi astfel, dacă are loc o modificare în modelul PIM, atunci se poate regenera modelul PSM, obţinând astfel un model actualizat.
Este un model util pentru dezvoltatorii de sistem, deoarece este sursa pentru generarea automată de cod.
Modelul specific unei implementări este ultimul nivel din procesul MDA. Conţine toate informaţiile necesare pentru a construi un sistem executabil. Este obţinut prin generare automată din modelul tip PSM.
II.5
Ciclul de dezvoltare MDA
Ciclul tradiţional de dezvoltare software are 6 paşi [2]. În fazele 1-3 se creează documente şi diagrame cu descrierea cerinţelor, în format text, poze sau diagrame UML:
diagrame de clase, de interactiune, etc. Cel mai adesea, acestea sunt privite doar ca simple resurse descriptive, iar dacă procesul este de tip iterativ, atunci adesea ajung să nu mai fie actualizate. Chiar şi pentru un proces non-iterativ, partea de documentaţie este privită ignorant şi o cauză pentru aceasta este şi faptul că aceste diagrame descriptive nu sunt relaţionate, iar cu cât procesul de dezvoltare avansează, aceste resurse ajung să conţină informaţii învechite despre sistem, informaţii ce nu mai sunt valabile [2].
13
Această problemă este cunoscută sub numele de „scurtătura dezvoltatorului” [2].
Există diverse ideologii pe această tematică, cum ar fi Extreme Programming [10] sau Agile Software Development [11] însă acestea rezvolvă doar anumite părţi ale problemei.
Ciclul de dezvoltare MDA aduce propria rezolvare pentru problema menţionată. Deşi are aceiasi paşi ca şi procesul tradiţional, diferenţa principală este reprezentată de artefactele pe care le produce în cursul procesului şi tipologia acestora (PIM, PSM). Aceste artefacte produse sunt înţelese de către calculator şi sunt conectate între ele. Dezvoltatorii se pot concentra asupra modelului PIM, întrucât acesta este folosit pentru transformările ulterioare în PSM şi cod. Astfel, modelul PIM are rol de documentaţie de nivel înalt pentru un sistem software şi nu devine neactualizată, întrucât dacă se doreşte o modificare în sistem, este suficient să se facă la nivel de PIM şi să se regenereze modelele PSM şi codul aferent.
Fig. 4 Ciclul de dezvoltare a unui produs software: traditional(stânga) versus MDA(dreapta) [2]
Procesul de dezvoltare propus de către paradigma MDA este cel descris de către figura următoare:
14
Fig. 5 Procesul de dezvoltare MDA
Dezvoltarea software începe cu modelul CIM. Este un model creat în principal de analiştii de business. Există situaţii în care acest model nu este considerat necesar şi este omis.
Urmând modelul CIM, un software arhitect adaugă informaţii despre arhitectura unui sistem şi creează modelul PIM, într-un limbaj de modelare bazat pe MOF.
Modelul PIM astfel obţinut este sursa pentru transformare într-un model PSM, conform cu platforma tehnologică aleasă. Transformarea aceasta trebuie efectuată de către specialişti în platforma respectivă. Dacă toate informaţiile necesare dezvoltării au fost adăugate la aceste modele PSM, atunci se pot folosi ca sursă pentru generarea de cod, artefactul final al procesului de dezvoltare MDA.
În practică, procesul MDA nu se aplică doar în forma asta simplă: CIM – PIM – PSM, ci setul de transformări aplicat este unul mai complex. Din un PIM, se pot crea şi alte modele PIM, pentru a se prezenta sistemul din alte perspective. Aşa cum arată şi schema prezentată mai sus, un singur model PIM poate fi sursa mai multor transformări PSM, conform cu multiplele platforme tehnologice folosite dar chiar şi sursa pentru viitoare tehnologii ce se vor dori integrate în sistem.
II.6 Beneficii
Dezvoltarea software coordonată de model are următoarele beneficii:
Creşte viteza de dezvoltare – Datorită procesului de automatizare, codul executabil poate fi generat din modele, folosind una sau mai multe transformări;
15
Îmbunătăţeşte calitatea software – definirea prin limbaje de modelare şi automatizarea transformărilor implică aplicarea uniformă a şabloanelor respective în întreaga implementare;
Reutilizează componente – elementele de dezvoltare automată pot fi definite şi apoi aplicate ori de câte ori este nevoie (ca şi o linie de producţie);
Facilitează administrarea sistemelor complexe, datorită abstractizării;
Reduce riscul de dezvoltare – prin creşterea gradului de cunoaştere a sistemului şi reducerea factorilor variabili;
Îmbunătăţeşte comunicarea în cadrul unei echipe – datorită modelelor;
Îmbunătăţeşte luarea de decizii, la nivel de design al sistemului;
Permite detectarea erorilor din faze iniţiale ale dezvoltării (cu cât se descoperă o eroare de proiectare mai devreme, cu atât mai mici costurile de reparaţie);
Sprijină integrarea cu succes a unei functionalităţi prin faza de analiză asupra colaborării între proiectarea funcţionalităţii respective şi sistemul existent;
Permite identificarea facilă a surselor pentru diverse elemente, de pe fluxul:
cerinţe – implementare – testare ajutând la depanarea problemelor apărute;
II.7 Utilizarea în industrie
Conform cu diverse studii cantitative şi calitative, metodologia de dezvoltare software coordonată de model a demonstrat creşterea eficienţei şi productivităţii în dezvoltarea software. Datorită convergenţei dintre dezvoltare şi analiza de business, gradul de adoptare a tehnicii e în creştere, iar printre suporteri sunt: vânzători de instrumente, cercetători, companii dezvoltatoare de software, analişti de business [1].
Totuşi, în industie, practica este folosită mai puţin frecvent sau încă nu este integrată în procesul de dezvoltare.
Tipic pentru tehnologiile noi este ciclul de adopţie, în timp, aşa cum este prezentat în figura de mai jos. După o culme iniţială datorată aşteptărilor de pe piaţă, s-a atins un nivel de dezamăgire. În mod curent, gradul de adopţie a practicii este în faza de cunoaştere şi înţelegere, în care studiile asupra a ce înseamnă acest tip de dezvoltare şi care sunt cele mai bune practici de aplicare, ajută companiile în a decide când şi unde să fie aplicată tehnica,
16
astfel încât să se atingă nivelul de productivitate şi companiile să aibă într-adevar profit, ca urmare a aplicării tehnicii [1].
Fig.6 Ciclul de evoluţie a unei tehnologii noi [1]
Dacă tehnica nu este bine inţeleasă, aplicarea ei duce la rezultate mai puţin satisfăcătoare şi non-productive.
Pe lângă aspectele tehnice, experţii consideră adesea că cele mai mari provocări pe care le are o companie în a adopta tehnica de dezvoltare coordonată de model nu sunt de natură tehnică ci mai degrabă cu privire la factorul uman. Experţii în domeniu au răspuns că cea mai mare dificultate în a adopta tehnici noi precum dezvoltarea coordonată de model, modelarea proceselor de business, arhitecturi orientate pe servicii, etc sunt [1]:
“dealing with people’s habits and resistance to change” (R. M. Soley, OMG);
“accepting and adopting standards” (S. White, IBM);
“who to ask for guidance and training, and tools availability; difficulty of communication between users, business lines, and other stakeholders” (A. Brown, The Open Group);
“dealing and managing people” (S. Mellor);
“impatience of getting to the results” (T.Jensen, IBM);
Astăzi, dezvoltatorii au la dispoziţie diverse instrumente de modelare care oferă suport pentru dezvoltarea software coordonată de model, atât open source cât şi comerciale, framework-uri complete sau instrumente specifice, variante desktop sau cloud-based sau solutii SaaS. Unele din acestea oferă suport pentru întregul proces de dezvoltare, altele oferă suport doar pentru modelare în notaţii specifice domeniului sau limbaje cu scop general.
Abordarea OMG a acestei tehnici de dezvoltare a fost adoptate cu succes in mai multe companii. Pe pagina web OMG sunt listate următoarele firme ce au folosit cu succes MDA [12]:
17
Fig.7 Firme ce folsit cu success MDA in proiecte [12]
Spre exemplu, M1 Global Solutions a raportat pe pagina OMG următoarea comparaţie între dezvoltare tradiţională şi cea cu MDE [13]:
Fig.8 Comparaţia M1 Global Solutions dintre dezvoltarea tradiţională şi cea MDA [13]
Dupa cum se observă, atât costurile totale cât şi timpul necesar au fost cu aproximativ 60% mai mici.
II.8 Concluzii
Dezvoltarea software tradiţională are ca piesă centrală codul iar conceptul de model a fost perceput ca şi un cost, şi nu un câştig de productivitate. În prima parte a acestui capitol am arătat de ce dezvoltarea software tradiţională nu este potrivită pe termen lung.
18
În continuare, am prezentat un nou stil de dezvoltare, şi anume, dezvoltarea coordonată de model. Aceasta este doar o parte aplicativă a ingineriei coordonate de model. Pentru a se înţelege mai bine noţiunile MDD, MDE, etc şi legăturile dintre aceste domenii, am prezentat câteva elemente clarificative la începutului subcapitolului II.1, si apoi am continuat cu detalierea principiilor si conceptelor ce stau la baza acestei tehnici de dezvoltare.
Particularizarea propusă de OMG, sub numele de MDA, prin standardizarea şi promovarea sa a contribuit la clarificarea conceptelor de bază ale dezvoltării coordonate de model şi a ajuns să fie frameworkul conceptual de referinţă pentru multe companii De aceea, am descris modelele tipice acestei abordări: CIM, PIM, PSM, ISM şi importanţa lor pentru atingerea scopului final.În subcapitolul II.5 am descris ciclul de dezvoltare MDA.
Perspectiva asupra dezvoltarii oferită de către aceasta tehnică are o serie de beneficii, atȃt pe termen scurt cȃt şi pe termen lung. Acestea sunt prezentate în subcapitolul II.6. În continuare am adunat o serie de informaţii legate de modul în care este privit acest tip de dezvoltare în industrie, atȃt din perspectivă negativă cȃt şi pozitivă. Companiile care folosesc deja acesta tehnica confirmă beneficiile menţionate şi asta deoarece au ales să înţeleagă principiile acestei tehnici.
Eu consider că succesul dezvoltării unui sistem software nu constă doar în rezultatul final obţinut ci şi în calitatea procesului prin care un produs este obţinut.
Pentru a promova dezvoltarea coordonată de model, trebuiesc create cât mai multe demonstraţii ale tehnicii dar şi îmbogăţirea setului de instrumente utile în acest domeniu şi chiar şi a materialelor cu noţiuni teoretice.
Cu scopul de a contribui la adoptarea paradigmei MDD în cadrul companiilor dar şi pentru a încuraja crearea de lucrări cât mai detaliate şi utile pe acest topic, am ales să prezint noţiunile ce stau la baza dezvoltării coordonate de model şi de asemenea, forma particularizată a acesteia, MDA. Ca suport practic, am realizat o aplicaţie practică urmând practicile MDA şi aceasta este prezentată în detaliu în capitolul următor.
19
Capitolul III. Rent A Book: MDA folosind Enterprise Architect
III.1 Descrierea aplicaţiei
În această lucrare propun realizarea unei aplicaţii Rent a Book folosind tehnica de dezvoltare MDA şi programul Enterprise Architect, de la Sparx System, Trial version.
Rent a Book este un sistem prin care pasionaţii de cărţi pot închiria o carte spre lecturare, pentru o anumită perioadă.
Librăria Rent a Book dispune de un stoc de volume pentru fiecare carte înscrisă în lista de cărţi. În limita acestui stoc, o carte se poate închiria. Acţiunea de a închiria o carte reprezintă înregistrarea unei comenzi de închiriere, pe o perioadă definită. Dacă utilizatorul constată că are nevoie de mai mult timp pentru a lectura volumul respectiv, atunci poate extinde perioada respectivă. Atunci când utilizatorul a terminat de lecturat cartea sau s-a terminat perioada de închiriere şi nu mai doreşte extinderea sa, acesta poate returna cartea.
Orice utilizator al librăriei Rent a Book poate folosi serviciile oferite, nu este necesară înregistrarea în sistem, însă, dacă utilizatorii doresc, se pot înregistra. Dacă un utilizator este înregistrat şi foloseşte serviciile de închiriere, atunci cu fiecare închiriere, i se poate aloca un scor, pe baza căruia ar putea primi diverse bonusuri sau chiar prioritate la închiriere.
Librăria colaborează cu mai mulţi scriitori, iar atunci când un scriitor are inspiraţie, poate publica o carte nouă. Scriitorii colaboratori sunt de asemenea utilizatori ai sistemului Rent a Book.
Administratorii de sistem, Rent a Book Assistent, sunt cei ce se vor ocupa de achiziţionarea fizică a volumelor nou publicate, sau în anumite cazuri, scoaterea din stoc a unor volume. De asemenea, dacă este nevoie, ei pot face modificări asupra scorului unui utilizator.
Cărţile aflate în sistemul Rent a Book au diverse atribute, precum: ISBN, număr de pagini, editura, titlu, autori, descriere, dar şi diverse taguri, astfel, căutarea unei cărţi se poate face după oricare din aceste proprietăţi.
20 III.2 Realizarea aplicaţiei
Pentru crearea aplicatie Rent a Book am folosit următoarele programe:
Program Versiune Utilizare
Enterprise Architect Professional 10.0, Trial Version Modelare CIM, PIM, PSM, ISM
Eclipse Kepler, Open Source IDE
Jboss 4.3 GA, Open Source Server de aplicaţie
MySQL Server 5.6, Open Source Server de baze de date
DBVisualizer 8.0.12, Open Source Vizualizare schema baze de date
Schema de lucru este cea descrisă în figura următoare:
Fig 9 Modelele Rent a book Iar în subcapitolele ce urmează, voi detalia fiecare model.
21 III.3 Modelul CIM
Din descrierea aplicaţiei Rent a Book, se pot extrage o serie de cerinţe pe care trebuie să le aibă această aplicaţie. Cerinţele se pot modela cu ajutorul Enterprise Architect.
Rezultatul obţinut este o diagramă de cerinţe şi reprezintă totodată modelul CIM pentru aplicaţie.
Comportamentul general dorit este acela ca sistemul să ofere serviciile necesare pentru un sistem de închiriere de cărţi. Am identificat 4 cerinţe principale, de îndeplinirea cărora depind alte cerinţe:
Un utilizator al sistemului trebuie să poată căuta o carte dupa oricare din proprietăţile defnite de o carte.
Sistemul trebuie să permită utilizatorilor să îşi administreze lista de închirieri. Pentru a îndeplini această cerinţă este necesar să se îndeplinească cerinţele agregate:
o un utilizator trebuie să poată închiria o carte pentru o perioadă definită (iar această cerinţă depinde direct de posibilitatea de a căuta o carte după diverse caracteristici), iar dacă această cerinţă este îndeplinită, atunci şi cerinţa de a putea extinde perioada de închiriere pentru o comandă efectuată, poate fi îndeplinită.
o un utilizator trebuie să poată returna cărţile închiriate.
Sistemul trebuie să permită utilizatorilor să ataşeze date personale la contul de utilizator, iar de aceasta cerinţă depind în principal: abilitatea unui asistent de librărie sau chiar a sistemului, să modifice scorul personal al unui cont, în diverse situaţii.
Sistemul trebuie să permită administrarea stocurilor, mai exact:
o Un scriitor poate să publice o carte nouă, şi să o furnizeze sistemului de închiriere.
o Un asistent poate să modifice stocul unei cărţi, fie în urma aprovizionării cu volume a unei cărţi recent publicate, fie cu alte ocazii, precum deteriorarea / pierderea unor volume.
Modelul CIM este sursa de date pentru definirea modelului următor, modelul PIM.
Transformarea din modelul CIM în Model PIM este una manuală, întrucât cerinţele formulate sunt într-un limbaj mai puţin formal.
22 Fig. 10 Modelul CIM
23
III.3 Modelul PIM
Modelul PIM este cel din figura 11. Este un model UML: diagramă de clase, însă este conceput din perspectivă independentă de platforma de implementare.
Fig.11 Modelul PIM Caracteristici:
o Nu conţine elemente specifice platformei, cum ar fi elemente necesare în cadrul lucrului cu EJB sau adnotări JPA.
o Proprietăţile claselor sunt cu vizibilitate public, pentru că la acest nivel nu se cunosc cerinţele platformei de implementare (pentru Java, proprietăţile unei clase urmează principiul încapsulării).
24
o Tipurile de date sunt generice (Integer, String, Real, Boolean). Pentru tipuri de date mai specifice, foloseşte tipuri special definite (Date).
o Cerinţele sistemului sunt acoperite de modelarea PIM.
o Descrie domeniul sistemului Rent a Book.
Modelul PIM este sursă pentru orice transformare spre model specific unei platforme.
În cazul nostru, avem nevoie de două modele specifice:
o PSM – EJB, transformare prin care vom obţine modelul serviciilor EJB de care avem nevoie în aplicaţie
o PSM – JPA, transformare prin care vom obţine modelul claselor JPA (clase adnotate conform cu JPA) cu ajutorul căruia vom obţine structura de persistare.
Toate clasele modelului PIM modelează conceptul de entitate. Indiferent de serverul de baze de date în care se va implementa aplicaţia, orice entitate necesită un identificator unic.
Pentru a nu încărca modelul aplicaţiei cu această informaţie, tipică pentru nivelul de baze de date, am creat separat o clasă abstractă numită EntityBase, ce are ca proprietate un identificator, şi care va fi generalizarea oricărei entităţi din aplicaţie. Această clasă are ataşat stereotipul: EntityBase.
Fig.12 Entity Base
De asemenea, lucrul cu entităţi persistente în baza de date implică un serviciu care să se ocupe de operaţiile CRUD şi nu numai. Pentru aceasta am definit o entitate DataProvider.
Această entitate nu este tipică acestei aplicaţii, ci este o entitate cu comportament specific şi are aceleaşi principii, indiferent de aplicaţie. De aceea, am creat o diagramă separată, şi, în plus, am marcat entitatea cu stereotipul: DataProvider.
Fig. 13 DataProvider
25
III.4 Modelul PSM – EJB
Fig. 14 Modelul PSM_EJB _ partea 1
26
Fig. 15 Modelul PSM_EJB – partea a 2-a
Serviciile oferite de către aplicaţia Rent a Book sunt implementate cu ajutorul EJB- urilor. Conform tehnicii EJB3.0, avem nevoie de două interfeţe, una pentru apeluri Local şi alta pentru apeluri Remote, şi de asemenea, avem nevoie de bean-uri care să implementeze aceste doua interfeţe.
Pentru aplicaţia curentă, am creat o singură interfaţă, per bean, referenţiată atât pentru apelurile locale cât şi pentru cele Remote. Bean-urile ce vor implementa aceste interfeţe sunt de tip Stateless.
Fiind o aplicaţie simplă, nu voi crea două Bean-uri diferite, unul pentru operaţiile CRUD, altul pentru operaţii specifice, ci doar un Bean, cu ambele tipuri de servicii. Interfaţa fiecărui bean va extinde o interfata CRUD specifică bean-ului respectiv.
Serviciul DataProvider este un pic diferit de celelalte bean-uri, întrucât trebuie să asigure o funcţionalitate generică pentru operatiile CRUD, indiferent de tipul de Bean în care va fi injectat.
Pentru a obţine aceste modele EJB, este necesară o transformare din model PIM în model specific EJB. Pentru aceasta am creat un transformer ModelToEJB3 iar rezultatul aplicării sale este cel din figurile 14, 15 şi 16 (pentru modelul serviciului DataProvider)
27
Transformerul este definit pentru o transformare tip model – către – model, exogenă, unidirecţională.
Fig.16 Data Provider service
Am creat propriul transformer din PIM în model specific EJB folosind limbajul de scripting al programului Enterprise Architect.
Caracteristici ale transformării din PIM în PSM – EJB:
Pentru fiecare entitate de model, există 3 noi elemente:
- O interfaţă pentru operaţiile CRUD, numită după convenţia:
<NumeClasa>CRUDInterface (exemplu: BookFanCRUDInterface)
- O interfaţă pentru operaţiile specifice entităţii, conform cu specificaţiile PIM, numită dupa convenţia:
<NumeClasa>Interface (exemplu: BookFanInterface) şi extinde interfaţa CRUD a entităţii respective,
- O clasă (serviciul) ce implementează interfaţa definită pentru bean, numită dupa convenţia:
<NumeClasa>Bean (exemplu: BookFanBean)
28
Fiecare entitate generata in modelul EJB are un stereotip corespunzator:
CRUDInterface / EJBInterface / EJBImplementation.
Fiecare entitate generată în modelul EJB are setat limbajul JAVA ca limbaj de implementare.
Template-ul se aplică pentru fiecare entitate din modelul PIM, aşadar transformarea este omogenă în întreaga aplicaţie.
În modelul PSM – EJB sunt preluate din modelul PIM doar informaţiile utile perspectivei EJB (informaţii despre comportamentul dorit pentru fiecare entitate în parte, şi nu despre proprietăţi şi acţiuni asupra acestora).
Operaţiile CRUD asupra unei entităţi se bazează pe implementarea generică din serviciul DataProviderBean iar comportamentul unei entităţi, privitor la acestea, poate fi generalizat în cadrul template-ului. De aceea, am inclus în transformer generarea atât a metodelor cât şi a comportametului pentru fiecare metodă în parte.
Template-ul de generare are la bază următoarea schema (fig. 17):
- Crearea unei Interfeţe CRUD - Crearea unei Interfeţe EJB - Crearea unui Bean EJB
- Crearea dependinţei dintre un bean şi interfaţa sa
- Crearea dependinţei dintre o interfaţă EJB şi o interfaţă CRUD.
Fiecare din aceste fragmente sunt la rândul său sub-template-uri prin care se definesc diverse elemente necesare modelului final. În continuare voi prezenta câteva fragmente din aceste template-uri:
Fig. 17 Schema crearii unui Serviciu EJB 3.0 pentru o entitate
29
Crearea unei interfeţe EJB - figura 18 – presupune definirea elementelor componente (tipul de element, numele său, stereotip, limbaj de implementare, import-uri, dacă este cazul, relaţii cu alte entităţi)
Fig. 18 Crearea unei interfeţe EJB
Crearea unei operaţii CRUD în cadrul unui bean (fig. 19) – necesită definirea: tipului de element, numelui, scope-ului, parametrilor, tipului de return, cod (dacă se poate), diverse adnotări pentru metodă.
Fig. 19 Crearea unei operatii
Injectarea într-un bean a DataProvider-ului, ca şi atribut (construirea atributului – figura 20 ) – presupune definirea tipului de element, nume, scop, tip, diverse adnotări (adnotarea EJB prin care containerul va injecta dependinţa)
30
Fig. 20 DataProvider, ca attribut injectat într-un bean
Crearea unui conector (conectorul dintre un bean şi interfaţa sa) – figura 21
Fig. 21 Connector între un bean şi interfaţa sa
III.5 Modelul PSM – JPA
Modelul PSM – JPA are ca scop colectarea tuturor informaţiilor cu rol în persistenţa aplicaţiei (entităţi, relaţii între entităţi, etc) şi crearea unei diagrame complete din perspectiva JPA.
Entităţile JPA sunt modele orientate obiect pentru entitatile relaţionale ale unei aplicaţii. O entitate JPA trebuie să descrie într-un limbaj orientat obiect toate proprietăţile pe care le va avea acea entitate în format relaţional.
Pentru aplicaţia Rent A Book, modelul PSM – JPA este cel din figura: 22.
31
Fig.22 Modelul PSM-JPA
32
Orice entitate relaţională trebuie să aibă un ID unic de identificare în baza de date. În acest scop a fost definită entitatea EntityBase. Toate entităţile aplicaţiei extind această clasă, şi, întrucât pentru lucrul cu JPA toate entităţile trebuie să fie serializabile, tot la nivelul entităţii EntityBase am adăugat, în urma transformării JPA, implementarea interfeţei java.io.Serializable.
Fig. 23. EntityBase în urma transformarii PSM-JPA
Pentru a obţine aceste modele JPA, este necesară o transformare din model PIM în model specific JPA. Pentru aceasta am creat un transformer ModelToJPA iar rezultatul aplicării sale este cel din figurile 22 şi 23 (pentru modelul serviciului DataProvider)
Transformerul este definit pentru o transformare tip model – către – model, exogenă, unidirecţională.
Caracteristici ale transformării din PIM în PSM – JPA :
Clasele definite în cadrul diagramei PIM sunt entităţi JPA reprezentate prin o diagramă de clase.
Fiecare entitate generată în modelul JPA are stereotipul: JPAEntity.
Fiecare entitate generată în modelul JPA are setat limbajul JAVA ca limbaj de implementare.
Template-ul se aplică pentru fiecare entitate din modelul PIM, aşadar transformarea este omogenă pentru întreaga aplicaţie.
În modelul PSM – JPA sunt preluate din modelul PIM doar informaţiile utile perspectivei JPA (informaţii despre structura entităţilor şi relaţii între acestea, şi nu comportamente).
33
Toate entităţile JPA generate respectă principiul încapsulării, astfel dacă în PIM proprietăţile au ca vizibilitate, în mod standard: public, în cadrul modelului JPA, toate proprietăţile entităţilor au vizibilitate private şi sunt generate metode de accesare a acestora (get-eri şi set-eri).
Metodele get-er şi set-er au stereotip: property get respectiv property set.
Tipurile de date asociate atributelor entităţilor sunt transformare în tipuri de date specifice limbajului în care se vor implementa (Java în cazul nostru), astfel:
- Integer -> int
- Boolean -> boolean - Real -> double - String -> String
- UnlimitedNatural ->long
Tipul Date nu este inclus în EnterpriseArhitect ca şi tip de dată generică, şi am creat un tip intern: Date. În momentul transformării în o entitate JPA, Date va fi înlocuit cu java.util.Date.
Toate proprietăţile entităţilor JPA respectă convenţia de nume: lowerCamelCase.
Transformarea PSM – JPA citeşte conectorii (ce reprezintă relaţii între entităţi, de tip Is-A sau Has-A) şi îi transformă în elemente corespunzătoare.
- Relaţia Is-A (spre exemplu, entităţile BookFan şi Account sunt în acest tip de relaţie) - pentru acest tip de relaţie, clasa de bază va extinde EntityBase iar copii săi nu.
- Relaţia Has-A (spre exemplu, entităţile ItemRent şi BookFan sunt în acest tip de relaţie) – în urma transformării, pentru astfel de relaţie, capetele configurate ale conectorului, sunt transformate în atribute pentru clasele corespunzătoare.
Proprietatea adăugată trebuie să respecte mutiplicitatea definită pe connector, astfel:
o Simplă - în cazul lui ItemRent, conectorul are multiplicitate 1, iar proprietatea adăugată este una simplă, de tipul entităţii target, şi cu numele menţionat pe conectorul din diagrama PIM: account, de tip BookFan.
o Multiplă – în cazul lui BookFan, conectorul are multiplicitate 0..*
pentru rents, iar proprietatea adăugată este una de tip colecţie generică (cu tipul entităţii target), şi cu numele menţionat pe diagrama PIM: rents, de tip Set<ItemRent>.
Se poate defini orice tip de colecţie, însă pentru entităţi JPA este mai potrivit Set-ul.
34
Transformarea adaugă aceste proprietăţi, rezultate în urma conectorilor, împreună cu metode get / set pentru acestea dar şi metode de add / remove, datorită lucrului cu colecţii, binenţeles, urmând convenţia de nume: lower CamelCase.
Conectorii folosiţi în cadrul diagramei PSM_JPA sunt păstraţi doar pentru a facilita lizibilitatea diagramei.
Template-ul de generare în model JPA este creat în acelaşi limbaj ca şi transformerul anterior, diferenţa constă în tipurile de elemente şi aspectele pe care trebuie să le acopere o diagramă conformă cu principiile JPA. Astfel, pentru a crea o entitate, este necesar să luăm definiţia sa aşa cum o găsim în PIM şi să prelucrăm atributele, atât cele direct definite, şi cele pe care le vom crea pe baza informaţiilor stocate în conectori.
Template-ul aplicat atributelor este cel din figura 25 şi prespune conversia de tip, modificarea vizibilităţii, importul unor clase datorate diverselor adnotări JPA şi mai târziu, crearea proprietăţilor get / set pentru aceste atribute, aşa cum este în fragmentul din figura 26
Connectorii se generează într-un mod similar celui descris pentru template-ul ModelToEJB3. Însă, aşa cum am menţionat, pentru perespectiva JPA, connectorii joacă un rol important, şi pe baza configurării acestora, se generează atribute. În figura 27, este un fragment din template-ul ce se ocupă cu aceasta generare (este prezentată doar partea finala, în care s-a stabilit deja dacă tip-ul atributului este simplu sau colecţie):
Sunt o serie de parametri ce se citesc de pe conector, precum:
- multiplicitate (pentru a şti tipul atributului: colecţie sau tip simplu).
- destinaţia conectorului permite duplicate sau nu (asta este util în cazul colecţiilor) - destinaţia conectorului necesită ordonarea elementelor (pentru a stabili tipul de
colecţie)
- dacă sursa sau destinaţia conectorului permite navigarea între entităţi (pentru diverse adnotîri JPA)
Toate aceste informaţii ajută la stabilirea cât mai corectă a datelor de definire ale unui atribut JPA
Aşa cum am observat în urma acestui cod, există nişte informaţii: tag-uri ce se pot ataşa la clasă, în orice fază a modelului, pentru a ajuta la customizare (spre exemplu tag-ul LENGTH asociat atributului description în clasa Book, nivel PIM). Aceste informaţii contribuie la descrierea cât mai detaliată a perspectivei în cauza şi ajută la generea de cod.
35
Fig.25 Crearea unui atribut, din perspectiva JPA
Fig. 26 Crearea unei metode get-er
36
Fig. 27 Fragment din transformarea unui conector în atribut
În urma acestor două modele PSM_EJB şi PSM_JPA se observă foarte bine diferenţa de perspectivă ce se aplică modelului iniţial: o perspectivă a serviciilor, o altă perspectivă a entităţilor. Fiecare preia elementele necesare din PIM pentru a construi perspectiva dorită şi omite tot ce nu este relevant.
Din fiecare astfel de implementare specifică, se poate genera cod, componentă rulabilă şi ţintă a dezvoltării coordonate de model.
III.6 Modelul ISM EJB
Modelul PSM – EJB trebuie să conţină cât mai multe informaţii din perspectiva EJB, obţinute fie în urma transformării, fie adăugate direct în diagramă, ulterior, în cazul în care sunt informaţii non-generabile (precum comportamentul metodelor specifice unor entităţi).
Folosind ca şi sursă acest model, putem aplica template-uri de generare de cod. În cazul nostru, aplicaţia se doreşte dezvoltată în limbajul Java, şi, în plus, toate elementele generate din modelele specifice sunt configurate să fie implementate în limbajul Java.
Template-ul de generare de cod va parcurge fiecare element în parte şi va transforma în componentă cod orice element configurat pentru limbajul asociat template-ului.
Ca şi în cazul template-urilor pentru tehnica MDA, EnterpriseArchitect oferă un set de template-uri de generare de cod, pentru cele mai folosite limbaje şi oferă posibilitate atât pentru a modifica aceste template-uri. Cât şi pentru a crea altele noi pentru un limbaj anume.
Pentru aplicaţia noastră, folosim template-ul pentru Java, fără alte modificări asupra lui.
Ca rezultat al aplicării template-ului, vom obţine cate un fişier java pentru fiecare element din modelul sursă. Acestea pot fi importate în mediul de dezvoltare ales (Eclipse) şi pot fi deploy-ed pe server.
37
Am creat un proiect tip EJB numit RentABookServices în care am importat clasele generate:
Fig 28. Proiectul RentABookServices Câteva exemple din cod-ul generat:
Fig. 29 Un fragment din o interfaţă EJB
38
Fig. 30 Antetul Bean-ului: DataProvider şi o metodă dintre operaţiile CRUD
Fig. 31 Fragment din un Bean specific
39
III.7 Modelul ISM JPA
Tot în limbaj Java putem transforma şi modelul JPA pentru a obţine artefactele ce mapează modelul relaţional în model orientat obiect. Rezultatul generării poate fi importat într-un proiect, şi deploy-at pe server. În acest scop, am creat un proiect Java numit RentABookModel şi am importat artefactele rezultate. În continuare voi prezenta câteva fragmente din codul obţinut.
În figura 32 este un fragment din o entitate JPA (cu adnotările necesare), cu atribute atât simple (description) căt şi atribute tip colecţie, cu adnotări potrivite, dar şi metode tip get / set, metoda de add în colecţie (addTag)
Am creat un alt proiect: RentABookWizard tip EAR care să grupeze jar-ul proiectului RentABookModel cu cel al proiectului RentABookServices, iar în urma deploy-erii pe server, schema de date, create, este cea din figura 33.
Fig. 33 Reprezentarea in format relational a entitatilor JPA, in schema demo
Având aceste două niveluri de aplicaţie, baza de date şi servicii, se poate adăuga un nivel de GUI, dacă se doreşte, sau se poate testa cu diverse teste JUnit funcţionalitatea aplicaţiei.
40
Fig. 32 Fragment din o entitate JPA generată
41
III.8 Concluzii
În cadrul acestui capitol am arătat cum se poate dezvolta o aplicaţie, din prisma dezvoltării coordonate de model, şi nu urmând perspectiva tradiţională. Pornind de la un set minimal de cerinţe pentru o aplicaţie Rent A Book, am urmat pas cu pas ciclul de dezvoltare descris de particularizarea MDA a dezvoltării coordonate de model, si am arătat modelele ce intră în ciclul de viaţă al unei aplicaţii dezvoltate conform cu această tehnică. De asemenea, am arătat două transformări din model independent de platformă, în modele specifice unor platforme: EJB şi JPA, implementate în final în limbajul Java şi cum se pot implementa aceste modele folosind programul Enterprise Architect (Trial Version).
Aplicaţia în sine constă în câteva clase de model, aşadar o complexitate mică, însă o parte din beneficiile aplicării acestei tehnici sunt vizibile de la bun început. În prima parte, efortul este concentrat asupra modelării aplicaţiei. Apoi, efortul este direcţionat şi concentrat asupra scrierii template-urilor de transformare. Însă, de îndată ce aceşti pasi au fost făcuţi, generarea unei aplicaţii devine o acţiune de câteva minute. (exemplu: dacă se observă că o clasă nu este corect denumită, sau este o greseală în logica iniţială, atunci se modifică modelul PIM şi se reaplică transformările. Întreaga aplicaţie este actualizată. Un alt beneficiu uşor de observat este faptul că aplicaţia este mult mai uşor de înţeles, în urma separării perspectivelor specifice unei platforme. Beneficiile obţinute sunt cu atât mai importante cu cât aplicaţia este de dimensiuni mai mari.
Tehnica de dezvoltare coordonată de model este o tehnică îmbunătăţită de dezvoltare.
În general, adoptarea oricărei tehnici mai noi şi mai bune decat standardul în dezvoltare înseamnă investiţie în performanţă şi calitate.
42
Bibliografie
[1] Jordi Cabot, Marco Brambilla, Manuel Manuel Wimmer: Model-Driven Software Engineering in Practice (2012)
[2] Anneke Kleppe, Jos Warmer, Wim Bast: MDA Explained – The Model Driven Architecture:
Practise and Promise, Addison-Wesley (2003)
[3] Thomas Stahl, Markus Völter, Jorn Bettin, Arno Haase, Simon Helsen, Krzysztof Czarnecki, Bettina von Stockfleth: Model-Driven Software Development: Technology, Engineering, Management (2006)
[4] Object Management Group: MDA Guide Version 1.0.1
[5] Liliana Favre: Model Driven Architecture for Reverse Engineering Technologies: Strategic Directions and System Evolution (2010)
[6] Tom Mens, Pieter Van Gorp: A Taxonomy of Model Transformation (2006) [7] Perdita Stevens: Bidirectional model transformations in QVT: semantic issues and
open questions. Software and Systems Modeling (2010).
[8] Wikipedia website: http://en.wikipedia.org/wiki/Metamodeling
[9] Wikipedia website: http://en.wikipedia.org/wiki/Model_driven_development [10] Kent Beck: Extreme Programming Explained: Embrace Change, Second Edition
(2006)
[11] Alistair Cockburn: Agile Software Development: The Cooperative Game, Second Edition (2006)
[12] OMG website: http://www.omg.org/mda/products_success.htm [13] OMG website: http://www.omg.org/mda/mda_files/M1Global.htm
