Rolul modelarii in realizarea aplicatiilor

1.Rolul modelarii in realizarea aplicatiilor

In prezent exista tendinta ca sistemele informatice sa devina din ce in ce mai complexe si mai mari. Aceasta se datoreaza, in parte, puterii de calcul din ce in ce mai mari. Aceasta conduce la pretentii crescute din partea utilizatorilor. Un alt factor determinant este Internetul : el permite schimbul de informatii in diverse formate ( de la text simplu la text formatat, imagini, diagrame sau multimedia ). Apetitul pentru produse din ce in ce mai sofisticate creste pe masura ce dezvoltatorii invata de la o versiuna la alta cum pot imbunatati produsele. Aceasta crestere a dimensiunii si complexitatii sistemelor conduce la cresterea timpului de dezvoltare. Pe de alta parte beneficiarii doresc realizarea produselor intr-un timp cat mai scurt. Astfel apare necesitatea controlului modului de lucru. Este nevoie de un proces care sa integreze mai multe aspecte ale dezvoltarii software. Este nevoie de o abordare care :

- sa sprijine ordonarea activitatilor echipei;

- sa directioneze activitatea dezvoltatorilor individuali si ale echipei;

- sa ofere un cadru propice pentru specificarea produselor ce trebuie dezvoltate;

- sa ofere criterii pentru monitorizarea si masurarea produselor proiectului si

activitatilor.

Pe langa cele mentionate mai sus exista si alte probleme care apar in procesul de dezvoltare al aplicatiilor :

Spatiul problemei nu este inteles in totalitate. Se pierde foarte mult timp analizand diferitele pareri asupra modului de abordare al problemei

Exista multe constrangeri asupra solutiilor care trebuie luate in considerare: de exemplu, raportul dintre timpul si efortul necesar implementarii, integrarea cu aplicatii existente si coordonarea mai multor echipe care produc componente diferite ale sistemului

Pot aparea multe tipuri de modificari la toate nivelele de dezvoltare: vor fi descoperite erori, proiectarea va fi actualizata, prioritatile se vor schimba, etc. Din dinamica procesului de dezvoltare rezulta faptul ca se va pierde mult timp pentru intelegerea impactului pe care il are o modificare asupra sistemului.

Inginerii software s-au orientat spre mai multe tehnici pentru a rezolva aceste probleme. Dintre aceste tehnici folosirea modelelor si a modelarii este fundamentala. Modelele ofera abstractizari ale unui sistem fizic care permit ingineriilor sa se concentreze doar asupra detaliilor relevante. Toate tipurile de inginerie se bazeaza pe modele, acestea fiind esentiale pentru intelegerea sistemelor complexe din lumea reala.

Exista multe aspecte ale unui sistem care ar putea fi de interes. In functie de ce este considerat relevant, la orice moment in timp, pot fi utilizate diferite concepte de modelare si notatii pentru a sublinia unele perspective sau vederi ale sistemului. Mai mult, in unele cazuri modelele pot fi completate cu reguli care pot ajuta la transformarea lor. De exemplu, deseori este necesara transformarea intre diferite vederi ale sistemului la acelasi nivel de abstractizare(de exemplu, intre vederea structurala si cea comportamentala) sau intre diferite nivele de abstractizare.

Daca se definesc tipurile de modele care trebuie produse si se aplica unele rigori asupra semanticii acestor modele, se pot defini unele reguli pentru :

Automatizarea multor pasi necesari in transformarea modelelor.

Proiectarea elementelor de model(Tracing between model elements.

Analiza caracteristicilor importante ale modelelor

Acest stil de Model Driven Development, numit Model Driven Architecture (MDA), este sustinut de catre Object Management Group (OMG) si se bazeaza pe un set de standarde pentru a defini modele, notatii si reguli de transformare. In ultima perioada tot mai multe organizatii au inceput sa-si concentreze atentia asupra MDA ca si abordare in proiectarea si implementarea aplicatiilor. MDA sprijina folosirea eficienta a modelelor in procesul de dezvoltare al aplicatiilor si refolosirea celor mai bune practici atunci cand se creaza familii de sisteme.

Practica curenta poate fi caracterizata prin observarea diferitelor moduri in care modelele sunt sincronizate cu codul sursa pe care il descriu. Aceasta este ilustrata in Fig. 1.1 din care rezulta spectrul abordarilor de modelare utilizat de catre practicieni de azi.

Astazi, majoritatea dezvoltatorilor software au ca si abordare doar codul si nu utilizeaza deloc modele definite separat. Acestia se bazeaza aproape in intregime pe codul pe care il scriu, si ei isi specifica modelul sistemului direct intr-un limbaj de programare de generatia a treia (3GL), cum ar fi Java, C + +, C # sau in cadrul unui mediu de dezvoltare integrat (IDE)
cum ar fi IBMWebSphere Studio, Eclipse, Microsoft VisualStudio sau alte astfel de medii. Singura modelare pe care o fac este construirea de pachete, module, interfete care sunt gestionate prin mecanisme de biblioteci si ierarhii de clase. Orice separare a modelarii de arhitectura este informala si intuitiva, si ramane doar in prezentari PowerPoint, sau in memoria dezvoltatorilor. In timp ce aceasta ar putea fi adecvata pentru persoane fizice si echipe foarte mici, aceasta abordare face dificila intelegerea caracteristicile-cheie ale sistemului printre detalii cu privire implementare. Mai mult, devine mult mai dificil gestiunea evolutiei acestor solutii cand dimensiunea si complexitatea se afla in crestere, ca sistem care evolueaza in timp, sau in momentul in care membri echipei de proiectare nu sunt in contact direct cu echipa de mentinere a sistemului. Dezvoltatorii care se ocupa de analiza sau crearea aplicatiei vor dori in mod frecvent sa vizualizeze niste reprezentari grafice care sa ii ajute la intelegerea mai usoara, rapida si clara a diferitelor aspecte ale problemei. In acelasi timp poate exista posibilitatea manipularii notatiilor grafice ca si alternativa la editarea codului ca si text astfel aranjarea vizuala devine reprezentarea directa a codului. O asemenea reprezentare este numita uneori model de cod sau modelul implementarii, desi multi numesc aceste artefacte 'diagrame' si rezerva cuvantul 'model' pentru nivele mai inalte de abstractizare. In instrumentele care permit folosirea acestor diagrame(de ex. IBM WebSphere Studio si Borland Together/J) codul si modelul pot fi vizualizate simultan ; in timp ce dezvltatorii modifica una dintre aceste vederi(cod sau model) cealata se sincronizeaza imediat. In cadrul acestei abordari diagramele sunt strans legate de reprezentarea codului si produc o cale alternativa  pentru vederea si posibilitatea editarii la nivelul codului.

Un alt avantaj al modelelor poate fi obtinut prin 'roundtrip engineering' (RTE) dintre modelul abstract al sistemului care descrie arhitectura sistemului sau proiectarea si cod. Dezvoltatorii de obicei elaboreaza proiectarea sistemului la un anumit nivel de detaliu, apoi creaza un prim pas de  punere in aplicare a acestui cod, prin aplicarea transformarii de la model la cod. De exemplu, o echipa care lucreaza la un nivel inalt de proiectare ofera modele de proiectare echipei care se ocupa de implementare.

Instrumentele pot ajuta la pastrarea modelelor de proiectare si implementare sincronizate pe masura ce acestea evolueaza. In mod normal instrumentele genereaza bucati de cod pe baza modelelor de proiectare pe care utilizatorul le poate rafina. Pe masura ce se efectuaza modificari asupra codului acestea trebuie ca la un moment dat sa se reflecte asupra modelului original. Intrumentele care adopta aceasta abordare , cum ar fi IBM Rational Rose, pot oferii mai multe servicii de sprijinire a transformarii RTE dintre modele si implementarea lor in diferite limbaje.

In abordarea centrata in jurul modelelor modelele sistemului sunt suficient de detaliate pentru ca implementarea completa a sistemului sa poata fi generata doar pe baza modelelor. Pentru realizarea implementarii complete modelele pot include, de exemplu, reprezentari ale datelor persistente si nepersistente, vederea logica a modelului si elemente de prezentare. Procesul de generare de cod sprijina specificarea unor sabloane pentru a transforma modelele in cod, permitand dezvoltatorului unele alegeri in sabloanele care sunt aplicate (de exemplu, intre diferitele topologii de implementare)

Abordarea model-only se afla la sfarsitul spectrului de modelare. In cadrul acestei abordari dezvoltatorii folosesc modelele doar pentru intelegerea problemei sau a domeniului solutiei sau pentru analiza arhitecturii unei solutii propuse. Modelele sunt folosite de obicei pentru discutii, comunicare si analize intre echipele dintr-o organizatie.

Instrumentele existente sunt inadecvate

Instrumentele de dezvoltare existente au in comun doua probleme generice :

Ele nu ofera dezvoltatori de nivel inalt constructii intr-un cadru metodologic bine definit. Prin urmare, aplicatiile sunt de obicei construite din fragmente de cod care sunt la un nivel mai scazut decat cel al specificatiei problemei. Diferenta semantica dintre Spatiul Problemei si Spatiul Solutiei, intre programare si modelare, de obicei cauzeaza ca specificarea sistemului care este creata in sfera de aplicare a spatiului problemei sa fie reprezentata incorect in domeniul de aplicare al Spatiului Solutiei. Acest lucru se intampla deoarece constructorii care sunt obisnuiti cu medii de programare nu sunt potriviti sa reprezinte modele din viata reala produse in faza de modelare conceptuala in mod direct.

Ele nu ascund in mod adecvat complexitatea tehnologica, si de multe ori fac exact opusul: tehnologia precum si complexitatea ei, uneori, sunt promovate ca o caracteristica a mediului de dezvoltare, mai degraba decat sa fie pastrate la un nivel scazut al detaliilor de implementare. Cele mai multe instrumente de pe piata sunt prea specializate si axate pe o anumita parte din procesul de dezvoltare, astfel ca multe dintre acestea trebuie integrate cu altele pentru a avea un mediu de dezvoltare care acopera toate fazele de dezvoltare a unui produs software.

Dezvoltarea aplicatiilor cu instrumentele actuale devine o munca intensa de programare, care este intotdeauna un mod de lucru la un nivel de abstractizare prea mic.

2.Limbaje de modelare care sa contina concepte adecvate domeniului problemei

Cresterea complexitatii sistemelor informatice a condus la necesitatea utilizarii unor noi metode de dezvoltare, moderne si performante, pe baza carora sa se poata realiza o modelare optima a sistemelor. De asemenea, a aparut si necesitatea standardizarii limbajelor de modelare. Primele limbaje de modelare orientate obiect au aparut si s-au cristalizat ca metodologii in perioada cuprinsa intre mijlocul anilor '70 si sfarsitul anilor '80, ca urmare a noilor generatii de limbaje de programare orientate obiect si a cresterii complexitatii aplicatiilor. In perioada cuprinsa intre 1989 si 1994 numarul metodelor orientate-obiect a crescut de la mai putin de 10 la peste 30. Treptat insa, pe baza experientei acumulate, noi generatii de metode au inceput sa apara, cu un numar relativ restrans de metode importante:

. Metoda lui G. Booch;

. OOSE (Object-Oriented Software Engineering), a lui I. Jacobson;

. OMT (Object Modelling Technique), a lui J. Rumbaugh;

. Altele: Fusion, Shlaer-Mellor, Coad-Yourdon.

Fiecare din acestea este o metoda completa, avand insa puncte tari si puncte slabe, unanim recunoscute. Spre exemplu, metoda lui Booch era folositoare in special pentru fazele de proiectare si constructie ale proiectelor, OOSE oferea un sprijin excelent pentru cazurile de utilizare - ca un mod de a coordona identificarea cerintelor, analiza si proiectarea de nivel inalt, in timp ce OMT-2 era folositoare pentru analiza si pentru sistemele informatice avand de prelucrat masive de date.

Limbajele constituie o parte esentiala in dezvoltarea sistemelor informatice. Dezvoltatorii folosesc o colectie de limbaje surprinzator de variate. Aceasta include limbaje de modelare de nivel inalt de la cele abstracte aflate departe de implementarea detaliilor specifice, la cele bazate pe o implementare specifica a tehnologiilor. Multe dintre aceste limbaje cu scop general ("general-purpose") ofera abstractiuni care sunt aplicabile intr-o mare varietate de domenii.

In alte situatii ele vor fi limbaje specifice unui domeniu(domain specific languages) care asigura un set foarte specializat de concepte ale domeniului.

In plus fata de folosirea pentru proiectarea si implementarea sistemelor, limbajele ofera multe alte utilitati care sunt o parte esentiala a procesului de dezvoltare. Acestea includ:

Executia: permite ca modelul sau programul sa fie testat si rulat

Analiza: ofera informatii despre proprietatiile modelelor sau programelor

Testarea: permite construirea de cazuri de test in vederea testarii si validarii modelelor

Vizualizarea: multe limbaje au o sintaxa grafica si suportul pentru aceasta se face prin intermediul interfetei utilizator

Parsarea: daca limbajul are o sintaxa textuala trebuie sa existe mijloace pentru citirea expresiilor scrise in acest limbaj

Translatarea(Translation): limbajele nu sunt izolate. De obicei sunt interconectate, in mod formal sau automat, prin generarea de cod sau compilare

Integrarea: permite integrarea caracteristicilor dintr-un model sau program in altul, de exemplu combinarea diferitelor puncte de vedere sau aspecte ale domeniului problemei

Desi exista multe tipuri diferite de limbaje, exista unele caracteristici pe care le au toate limbajele. Acestea trebuie sa fie intelese daca dorim sa dezvoltam o abordare generica asupra definirii limbajului. Caracteristicile primare sunt :

Sintaxa concreta

Toate limbajele au o notatie care sa faciliteze prezentarea si constructia modelelor. Aceasta notatie este cunoscuta sub numele de sintaxa concreta. Exista doua tipuri de sintaxa concreta: textuala si grafica. Sintaxa textuala permite descrierea modelelor si programelor intr-o forma textuala structurata. Sintaxa grafica permite reprezentarea modelelor sau a programelor sub forma de diagrame. Avantajul sintaxei textuale este buna reprezentare a detaliilor, iar cel al sintaxei grafice este structura de comunicare.

Sintaxa abstracta

Sintaxa abstracta a unui limbaj descrie vocabularul conceptelor oferite de catre limbaj si felul cum pot fi combinate pentru a crea modele sau programme. Consta intr-o definitie a conceptelor, relatiile care exista intre concepte, si mai poate contine reguli care spun cum pot fi combinate legal concepte. Este important de subliniat faptul ca sintaxa abstracta este independenta de sintaxa concreta si semantica. Sintaxa abstracta se ocupa cu forma si structura conceptelor intr-un limbaj fara a lua in considerare prezentarea sau sensul lor.

Semantica

Semantica unui limbaj descrie intelesul si ceea ce fac modelele sau programele in cadrul limbajului. In contextul limbajelor de programare executia semantica este esentiala pentru rularea programelor. Semantica este de asemenea importanta in contextul limbajelor de modelare. Fara semantica, limbajele de modelare precum UML ar fi putin mai mult decat o colectie de notatii, iar utilitatea lor pentru dezvoltatori ar fi redusa.

Limbajele de modelare incearca sa evite specificarea tehnologiilor de implementare. Acest lucru este deosebit de important, deoarece permite dezvoltatorilor sa se concentreze
pe ceea ce este necesar ca un sistem sa faca, spre deosebire de detaliul referitor la modul in care aceasta este implementat. O problema cu limbajele de modelare este ca acestea sunt in general
slab definite. Multe ofera putin mai mult decat notatii. Aceasta simplitate limiteaza utilizarea lor pe durata dezvoltarii in doua moduri principale:

Modelele construite in aceste limbaje nu pot fi validate deoarece acestea sunt prea
simple pentru a sustine capacitati semantice, cum ar fi executia, analiza,
si testarea.

Corectitudinea translatarii lor in alte limbaje nu poate fi validata deoarece nu poate fi demonstrat faptul ca semantica limbajului tinta este echivalenta cu semantica limbajului de modelare.

In cele din urma, limbajele de modelare trebuie sa fie capabile sa ofere abstractizari relevante
pentru dezvoltatori. In multe situatii, dezvoltatorii vor dori sa foloseasca abstractizari cu scop general(general-purpose), cum ar fi componentele, obiectele, sabloanele.
In alte situatii, ei vor dori sa foloseasca limbaje de modelare care sunt
adaptate pentru a sprijini un anumit domeniu de afaceri(business domain).

Arhitectii limbajelor de modelare s-au confruntat cu urmatoarele doua provocari:

Provocarea abstractizarii : Cum se poate asigura suport pentru crearea si manipularea abstractiunilor de la nivelul problemei ca prima-clasa de elemente de modelare intr-un limbaj?

Provocarea formalitatii(formality) : Care aspecte ale semanticii limbajului de modelare trebuie formalizate in scopul sustinerii manipularii formale, si cum trebuie aspectele sa fie formalizate ?

In comunitatea MDE au aparut doua scoli de gandire cu privire la modul de a aborda problemele de abstractizare :

Scoala Limbajelor de Modelare cu Scop General(general-purpose) Extensibile: problema abstractizarii este abordata prin furnizarea unui limbaj de baza cu scop general cu posibilitatea extinderii lui cu abstractiuni specifice domeniului(de exemplu, abstractiuni care sunt specifice domeniului unei probleme).

Scoala Limbajelor de Modelare Specifice Domeniului : provocarea este abordata prin definirea de limbaje specifice domeniului folosind mecanisme de meta-metamodelare. Tema de lucru in acest domeniu este furnizarea de instrumente care sa sprijine ingineria limbajelor de modelare. Produsele oferite de Xactium, MetaCase si Microsoft furnizeaza exemple de incercari pentru producerea de astfel de instrumente.

Este important de retinut ca ideea de cercetare, tehnicile si tehnologiile folosite de cele doua scoli nu se exclud reciproc. Atat limbajele de modelare extensibile cat si tehnologiile de meta-metamodelare pot juca un rol vital intr-un mediu MDE. Trebuie sa avem in vedere ca cercetarile din ambele scoli vor oferi descoperiri valoroase si rezultate care vor conduce spre o convergenta a ideilor.

In cele din urma s-au identificat doua modalitati pentru obtinerea unor limbaje de modelare adcvate pentru un anumit domeniu : utilizarea profilelor UML sau crearea unor limbaje de modelare specifice unui domeniu(DSML).

2.1 Profile UML

Atunci cand limbajul UML nu poate reprezenta un sistem sau o aplicatie intr-un mod adecvat, profilele UML pot realiza acest lucru. Un profil este un pachet de elemente asupra carora s-au aplicate mecanisme de extensie cum ar fi : stereotipuri, valori etichetate si constrangeri.

Un stereotip extinde vocabularul UML, permitand crearea de noi tipuri de blocuri constructive derivate din cele existente, dar care sunt specifice unei anumite probleme. O valoare etichetata extinde proprietatile unui bloc constructiv UML, permitand crearea de noi informatii in cadrul specificatiei elementului. Extinderea unui element de model introdusa de un stereotip nu trebuie sa contrazica proprietatiile asociate cu elementul de model. O constrangere este o extindere a semanticii unui element de model care permite adaugarea de noi reguli sau modificarea celor existente.

Un profil este un mecanism de extensie usoara si acesta nu poate fi folosit pentru adaugarea de noi elemente de model sau stergerea elementelor de model existente. Cu ajutorul unui profil se pot defini si relatii noi intre elementele de model UML.

Pana in prezent OMG a reusit sa standardizeze o serie de profile, cum ar fi :OMG System Modeling Language(SysML), UML Profile for COBRA, UML Profile for Enterprise Application Integration (EAI), UML Profile for Modeling QoS and Fault Tolerance Characteristics and Mechanisms, UML Profile for Schedulability, Performance and Time, UML Profile for System on a Chip (SoC), UML Testing Profile.

2.2 Limbaje de modelare specifice unui domeniu(DSML)

Un limbaj specific unui domeniu consta in constructii care surprind fenomenele din domeniul pe care il descriu. Limbajele specifice unui domeniu(DSL) acopera o gama larga de forme. Un DSL poate fi folosit pentru comunicarea dintre componentele soft(de exemplu, dialectele XML) sau poate fi incorporat intr-un wizard care cere iterativ utilizatorului informatii de configurare.

DSL poate ajuta la crearea unei punti de legatura intre problema si implementare, dar folosirea lor creaza noi provocari :

Imbunatatirea intrumentelor : fiecare DSL are nevoie de propriul set de instrumente(editoare, validatoare, analizatoare, generatoare de cod). Aceste instrumente trebuie sa se dezvolte pe masura ce domeniul se dezvolta. Constructia si dezvoltarea acestor instrumente poate fi costisitoare. O provocare majora pentru cercetatorii DSL este dezvoltarea unei fundatii necesara pentru producerea de meta-instrumente eficiente pentru dezvoltarea de DSL-uri.

Provocarea DSL-Babel : folosirea mai multor DSL-uri poate conduce la probleme serioase de interoperabilitate, language-version si language-migration. Aceasta problema impune propriile provocari cu privire la forma si comunicarea pe diferite domenii. DSL-urile vor evolua si vor fi mai multe versiuni si asa vor trebui sa fie si aplicatiile care sunt implementate folosind DSL-urile. Mai mult, parti diferite ale aceluiasi sistem pot fi descrise folosind DSL-uri diferite si prin urmare trebuie sa existe un mijloc de a lega concepte intre DSL-uri si un mijloc pentru a asigura consistenta reprezentarii conceptelor din limbaje. Integrarea DSL-urilor va fi probabil la fel de greu de realizat precum integrarea diferitelor tipuri de diagrame intr-un model UML.

Dezvoltatorii responsabili pentru crearea si dezvoltarea instrumentelor DSL trebuie sa aiba cunostinte profunde asupra domeniului si trebuie sa mentina o legatura stransa cu dezvoltatorii de aplicatii. Mai mult, calitatea instrumentelor DSL trebuie sa fie o preocupare principala, si programele de asigurare a calitatii pentru sectorul de dezvoltare a instrumentelor al unei organizatii trebuie sa fie integrate cu programele de asigurare a calitatii din sectoarele de dezvoltare a aplicatiilor. In plus fata de aceste provocari multe dintre provocarile asociate cu dezvoltarea de limbaje de modelare standardizate se aplica si DSL-urilor.

DSL-urile sunt mult mai apropiate de domeniul problemei si de concepte decat limbajele de programare cu scop general(general-purpose) cum ar fi Java sau limbajele de modelare precum UML. Multe companii isi creaza propriile limbaje specifice pentru a rezolva unele probleme specifice de modelare sau testare.

3. Modalitati de abordare in definirea DSML-urilor

Trebuie subliniat faptul ca dezvoltatorii sunt mult mai implicati in "language driven development" decat cred ei. Sa consideram aplicatiile din domeniul financiar. Multi dezvoltatori isi vor crea sau utiliza framework-uri sau sabloane care cuprind conceptele financiare de pe parcursul mai multor proiecte. Acestea sunt, de fapt definitiile unui limbaj specific unui domeniu. Cum interactioneaza cu limbajul(de exemplu, prin servicii web) este, de fapt, un produs al sintaxei concrete si al semanticii. Recunoasterea acestui lucru conduce spre un mod de intelegere al dezvoltarii aplicatiilor radical diferit.

Nevoia de a obtine limbaje independente intr-un format independent de platforma nu este noua pentru MDA. In MDA exista un standard pentru descrierea meta-datelor, numit MOF(Meta Object Facility). Scopul MOF este de a defini un mod comun de a descrie toate standardele de modelare(adica, limbajele) folosite de MDA. Limbajele care sunt definite in termenii MOF pot fi inrudite unele cu altele datorita faptului ca au fost definite in acelasi fel. De exemplu, daca vrem sa trecem de la un model scris in UML la un model scris in Java, procesul este foarte mult  facilitat datorita faptului ca ambele limbaje respecta standardul MOF.

MOF descrie limbaje diferite cu ajutorul metamodelelor. Un metamodel este un model de concepte pe care limbajul le suporta. In cazul UML, acesta include concepte precum Class, Attribute, Operation, etc.

Desi MOF este un bun punct de plecare pentru definirea de limbaje, are un set de limitari:

Nu este suficient de puternic pentru a descrie conceptele semantice intr-un mod independent de platforma. De exemplu, MOF nu poate exprima executia semantica a unei masini de stari sau un business process. Proiectantul instrumentului trebuie sa recurga la specificarea acestei semantici intr-o tehnologie de implementare externa precum Java.

MOF nu furnizeaza un mijloc pentru exprimarea sintaxei concrete a unui limbaj, fie ca este vorba de o sinataxa textuala sau grafica.

MOF nu ofera abstractizari pentru descrierea interfetelor utilizator si a instrumentelor intr-o forma generica. Aceasta inseamna ca fie proiectantul limbajului are putin control asupra interfetei utilizator a unui instrument care suporta limbajul, fie aceste aspecte trebuie codificate intr-un mod specific platformei.

Language Driven Development implica adoptarea unei abordari unificate pentru descrierea limbajelor. O caracteristica esentiala pentru aceasta abordare este capacitatea de a descrie toate aspectele limbajelor intr-un mod independent de platforma, inclusiv a sintaxei concrete si a semanticii. Aceste definitii de limbaje trebuie sa fie suficient de puternice pentru a genera instrumente care sa ofere suportul necesar pentru utlizarea limbajelor, cum ar fi editoare sintax-aware, editoare de interfete grafice, compilatoare si interpretoare.

Language Driven Development se concentreaza spre centrul diversitatii si problemelor de abstractizare facand posibil integrarea rapida a mai multor limbaje si definirea unor capacitati de modelare bogate semantic. Folosind o abordare unificata a definirii limbajelor, "language driven development" ofera dezvoltatorilor o gama larga de limbaje care accepta necesitatile lor de dezvoltare:

Limbajele de modelare informale precum UML pot fi facute precise si folositoare semantic : adica, modelele UML pot fi executate si analizate prin extinderea limbajului cu o definitie a unei actiuni a limbajului si a regulilor pentru executia actunilor.

Abstractiunile limbajului, cum ar fi componentele, aspectele, sabloanele, constrangerile pot fi definite, inclusiv semantica lor. De exemplu, un aspect poate fi modelat ca si un nou concept care incapsuleaza un element de model, impreuna cu regulile de unificare a aspectului cu un model.

Abstractiunile limbajului pot fi combinate cu usurinta in mai multe moduri pentru a construi caracteristici specifice limbajelor. De exemplu, o componenta a limbajului de modelare ar putea fi unita cu un aspect al limbajului sau cu un sablon, astfel oferind
un mediu de proiectare mai puternic.

Limbajele de modelare specifice unui domeniu pot fi create rapid si (daca este nevoie) integrate cu limbaje cu scop general(general-purpose).

Limbajele pot fi specificate precis, astfel asigurandu-se ca definitia lor este
lipsita de ambiguitate pentru partile interesate, furnizori de instrumente, dezvoltatori de aplicatii.

Limbajele bune permit dezvoltatorilor sa fie semnificativ mai productivi decat utilizand tehnologiile traditionale de dezvoltare. Decat sa se confrunte cu probleme de codificare de nivel scazut, dezvoltatorii pot folosi abstractiuni puternice ale limbajului si medii de dezvoltare care sprijina procesul lor de dezvoltare. Ei pot crea modele care sunt suficient de puternice pentru a permite analiza si simularea proprietatiilor sistemului inainte de generarea completa a codului pentru sistem. Ei pot integra limbaje si automatiza transformarea dintr-un limbaj in altul. Ei pot manipula modelele si programele lor in moduri mult mai sofisticate decat codul sursa. In acest sens, mediile de dezvoltare au devenit tot mai mult inrudite cu instrumentele CAD/CAM folosite in domeniul ingineriei in care analiza extrem de sofisticata a proprietatiilor si comportamentului unui produs sunt bine efectuate inainte de constructia fizica. Mai mult decat atat, definitiile limbajelor fiind flexibile, dezvoltatorii isi pot adapta cu usurinta limbajele lor pentru a-si indeplini nevoile de dezvoltare.

Pentru a sprjini definirea unor limbaje de modelare specifice unui domeniu(DSML) s-au construit o serie de instrumente bazate pe diferite abordari. Cele mai folosite instrumente din aceasta categorie sunt : EMF, XMF, MetaEdit+ si Microsoft DSL.

XMF(eXecutable Metamodeling Facility) este o implementare comerciala care suporta definirea completa a limbajelor folosind metamodele executabile. A fost construit in special pentru a sustine language-driven development. XMF este un produs complet in sensul instrumentelor pe care le suporta(editoare de diagrame, compilator, parser, interpretor, etc., toate sunt modelate in propriul sau limbaj). XMF permite o constructie dinamica a DSL-urilor care pot fi independente sau intretasute cu altele.

EMF(Eclipse Modeling Framework) este un framework si un generator de cod  folosit pentru construirea de instrumente si alte aplicatii care se bazeaza pe un model. EMF ofera instrumente care permit producerea unui set de clase Java pentru model, unui set de clase care permit vederea si editarea pe baza de comenzi a modelului si un editor din specificarea unui model in format XMI. Modelele pot fi specificate folosind documente XML sau instrumente precum Rational Rose si apoi pot fi importate in EMF.

MetaEdit+

Microsoft DSL

4. Utilizarea Visual Studio Domain-Specific Language Tool pentru specificarea limbajelor de modelare

DSL Tools este un proiect destul de nou al celor de la Microsoft care doreste sa extinda Microsoft Visual Studio 2005 pentru a sprijini o modalitate puternica de dezvoltare a soft-ului numita Domain-Specific Development.

Domain Specific Development este o modalitate de rezolvare a problemelor care poate fi aplicata atunci cand o anumita problema apare de mai multe ori. Fiecare aparitie a problemei are o multime de aspecte care sunt aceleasi de fiecare data si aceste parti pot fi rezolvate o singura data. Aspectele problemei care difera de fiecare data pot fi reprezentate de un limbaj special. Fiecare aparitie a problemei poate fi rezolvata prin crearea unui model sau a unei exprimari in limbajul special si introducerea acestui model in partea fixa a solutiei.

Partea fixa a solutiei este scrisa folosind mijloace obisnuite de proiectare, codificare si testare. In functie de marimea si forma problemei, partea fixa a solutiei poate fi numita framework, platforma, interpretor, sau Application Programming Interface(API). Partea fixa contine sabloane de arhitectura(arhitectural patterns) care alcatuiesc domeniul si expune puncte de extensie care permit folosirea acestei parti intr-o gama larga de solutii. Ceea ce face aceasta abordare aplicabila este faptul ca partea variabila a solutiei poate fi creata folosind un limbaj special-purpose - un DSL.

DSL-urile pot textuale sau grafice. Ca si tehnologie pentru domain-specific development, ne asteptam sa existe instrumente care sa permita dezvoltarea si integrarea ambelor tipuri de DSL, grafice sau textuale. Oamenii au diferite preferinte in privinta tipului de limbaj pe care doresc sa-l foloseasca. De exemplu, multi prefera limbajele textuale pentru intrare, deoarece pot scrie mai rapid, dar limbajele grafice pentru iesire, deoarece este mai usor sa vezi  poza  intr-o diagrama.

Pentru a crea o solutie pentru problema abordata, partea fixa a solutiei trebuie integrata cu partea variabila exprimata de catre model. Exista doua abordari comune in privinta realizarii acestei integrari. In cadrul primei abordari partea fixa contine un interpretor pentru DSL-ul folosit pentru descrierea partii variabile. O asemenea abordare poate fi flexibila, dar poate avea dezavantaje cum ar fi performanta slaba si dificultate in depanare. In cadrul celei de a doua abordari anumite expresii si diagrame pot fi complet convertite in cod care poate fi compilat impreuna cu restul solutiei(abordarea generarii de cod). Aceasta este o procedura de conversie mai complexa, dar ofera avantaje in extensibilitate, performanta si depanare.

Initial se dorea ca DSL Tools sa fie parte integrata a Visual Studio, dar mai apoi a aparut ca parte a Visual Studio SDK februarie 2007 care contine si cateva exemple de folosire a acestui instrument.

Printre personalitatile care au contribuit la construirea acestui instrument se numara Steve Cook, Gareth Jones, Stuart Kent si Alan Cameron Wills.

Steve Cook s-a alaturat echipei de la Microsoft in 2003 pentru a lucra la proiectul DSL Tools. In prealabil a lucrat la IBM pe care l-a reprezentat la OMG in specificarea UML 2.0. Are o experienta de 30 de ani de munca in industria IT si a lucrat ca si architect, programator, autor, consultant si profesor. A fost unul dintre primii oameni care a introdus programarea orientata pe obiecte in Marea Britanie si s-a concentrat asupra limbajelor, metodelor si instrumentelor de modelare inca din 1990.

Gareth Jones este unul dintre liderii echipei care a construit DSL Tools. S-a alaturat echipei Microsoft din 1997 si pana acum a condus un numar mare de proiecte.

Stuart Kent s-a alaturat echipei Microsoft in 2003 pentru a lucra in cadrul proiectului DSL Tools. Inainte a fost un cadru didactic si consultant cu reputatie in modelarea si model-driven development. Are peste 50 de publicatii pana in prezent si a adus contributii semnificative la specificarea UML 2.0 si MOF 2.0.

Alan Cameron Wills a fost consultant mai bine de 10 ani si a venit la Microsoft in 2003 pentru a ajuta la crearea proiectului DSL Tools. Are un doctorat in informatica si este unul dintre creatorii dezvoltarii bazate pe componente.

DSL Tools permite crearea a patru tipuri de meta-metalimbaje: Class Diagrams, Component Models, Minimal Language, Task Flow.

Class Diagrams este un meta-metalimbaj care contine concepte asemanatoare cu cele din limbajul UML: clasa, atribut, asociere, agregare, mostenire. Acesta este folosit atunci cand se doreste crearea de modele asemanatoare cu cele din UML.

Component Models este un meta-metalimbaj care permite crearea de limbaje de modelare bazate pe component. Acesta foloseste concept precum: componenta, port de intrare, port de iesire, conexiune, generalizare.

Task Flow este folosit pentru reprezentarea unui flux de sarcini si ofera urmatoarele concepte : sarcina, actor, flux, obiect in stare, stare initiala, stare finala.

Minimal Language este un meta-metalimbaj care permite definirea de limbaje de modelare specifice unui domeniu si foloseste conceptele de element si relatie. Acesta este cel mai general dintre meta-metalimbajele prezentate mai sus.

DSL Tools este o abordare grafica pentru constructia de DSL-uri. Cand se creaza un proiect DSL apare un DSL Designer care permite crearea unui  editor de diagrame  sub forma unui Visual Studio Designer generat, numit Experimental Hive(instanta a metalimbajului specificat- Fig. 2). Acest lucru poate crea confuzii deoarece este folosit un Designer de Designer care va fi folosit pentru crearea unui Designer personalizat care va fi folosit de catre utilizatori la crearea de diagrame si la generarea de cod. In primul Designer va fi specificat tipul diagramelor pe care utilizatorul le poate crea : flow chart, class diagram, workflow diagram. Dupa folosirea DSL Designer-ului pentru a specifica designer-ul personalizat se vor folosi sabloanele standard pentru a genera cod care apoi va fi rulat. Codul generat dupa ce va fi rulat va crea un designer personalizat care va avea un toolbox ce contine entitatiile si relatiile specificate in metamodel si in acest moment se pot creea diagrame de tipul celor specificate in metamodel. Urmatorul pas este adaugarea de sabloane care genereaza cod pe baza diagramelor create in prealabil.

Figura 2. "Experimental Hive" pentru meta-metalimbajul Minimal Language

In suprafata de proiectare se pot adauga elemente din toolbox si acestea pot fi legate cu ajutorul relatiilor existente tot in toolbox, iar in fereastra de proprietati vor aparea proprietatile elementelor selectate din suprafata de proiectare.

De obicei limbajele sunt insotite de o serie de constrangeri care au fost definite in momentul specificarii metalimbajului. Aceste constrangeri se pot imparti in doua categorii:

 Hard constraints  sunt constrangeri care nu permit utilizatorului sa incalce o anumita regula, de exemplu, se permit numai numere valide pentru completarea unui camp al unui element.

 Soft constraint  sunt constrangeri pe care utilizatorul le poate incalca in unele momente, dar in altele nu. De exemplu, toate elementele dintr-un model trebuie sa aiba nume unice.

In Figura 3 este prezentat codul sursa pentru o constrangere simpla care asigura unicitatea numelor unui element.

[ValidationState (ValidationState.Enabled)]

public partial class IssueStateModel

' is used more than once.',

state.Name);

context.LogError(description,

'Err 01',

state,

stateNames[state.Name]);

}

stateNames[state.Name] = state;

}

}

Figura 3. Exemplu de constrangere

Pentru definirea unei constrangeri se declara in primul rand o metoda privata in clasa partiala corespunzatoare unei clase(domain class) din DSL. Aceasta metoda primeste ca parametru un ValidationContext pe care il va folosi pentru inregistrarea de erori, atentionari sau mesaje de informare atunci cand apar unele nereguli.

MDA and Language Definition

Rich Metamodeling: Raising the Bar

Atunci cand abordarile MOF sunt insuficiente pentru definirea limbajului, ce poate fi facut pentru a rezolva problema? Cum pot fi create rapid limbaje de modelare puternice care sunt necesare pentru MDA ?

In scopul de a sprijini definirea rapida a limbajelor in MOF, MDA trebuie aplicata pentru ea insasi, in sensul ca MOF trebuie sa furnizeze un limbaj specific domeniului corespunzator pentru definirea tuturor aspectelor limbajului intr-un mod independent de platforma. Metamodelarea se ocupa cu definirea unor asemenea limbaje specifice domeniului. Mai mult decat atat, aceste limbaje de metamodelare trebuie sa se auto-descrie si sa se auto-reprezinte, acestea facand posibil ca orice limbaj sa fie definit complet independent de o tehnologie externa.

O caracteristica centrala a acestei abordari este executabilitatea - aceasta trebuie construita inca de la inceput pentru a putea defini semantica limbajului de modelare insusi. Fara ea, definirea limbajului devine bazata pe tehnologii de implementare externe in locul definirii semanticii limbajului.

Un limbaj de modelare cu scop general extensibil trebuie sa ofere cel putin abstractiuni dintre cele disponibile la nivelul codului care accepta o gama larga de concepte din domeniile cunoscute ale problemei, si mecanisme de extensie a limajului care permit utilizatorilor extinderea sau specializarea limbajului care ofera abstractiuni corespunzatoare specifice domeniului.

Se obtin beneficii semnificative prin folosirea limbajelor de modelare extensibile cu scop general cum ar fi UML. De exemplu, un asemenea limbaj faciliteaza comunicarea dintre mai multe domanii ale aplicatiei(application domains) si face posibila pregatirea modelatorilor care pot munci in mai multe domenii.

UML este de asemenea unul dintre cele mai criticate limbaje de modelare. In ciuda problemelor sale, nu exista nici un dubiu aspra faptului ca eforturile de standardizare UML joaca un rol vital ca si sursa de descoperiri in problemele asociate cu dezvoltarea de limbaje de modelare.

O provocare majora cu care se confrunta dezvoltatorii de limbaje de modelare extensibile cu scop general este identificarea unui mic set de baza de concepte de modelare care pot fi utilizate pentru a exprima o gama larga de abstractiuni ale problemei. Procesul de standardizare UML ilustreaza dificultatea convergerii pe un set mic de concepte extensibile. Una dintre probleme este aceea ca in prezent exista o experienta foarte mica in analiza modelarii care poate fi folosita la extragerea unui mic set de concepte de modelare extensibile. O modalitate de a aborda aceasta problema este de a crea facilitati pentru colectarea, analiza si schimbul de experienta de modelare, in special din industrie Exista un numar destul de mare de initiative care urmaresc sa dezvolte si sa mentina un repository al experientei de modelare. Colectarea experientei relevante din industrie va fi extrem de dificila. Asigurarea ca drepturile de proprietate intelectuala nu vor fi incalcate si depasirea reticentei organizatiilor de a face public artefactele sunt cateva dintre problemele pe care aceste initiative trebuie sa le abordeze.

Complexitatea limbajelor precum UML se reflecta in metamodelele lor. Metamodelele complexe sunt problematice pentru dezvoltatorii care au nevoie sa le inteleaga si sa le foloseasca. Acestia includ dezvoltatorii de instrumente MDE si transformari. Complexitatea metamodelelor pentru limbajele standard cum ar fi UML reprezinta de asemenea provocari pentru grupurile care se ocupa cu dezvoltarea standardelor. Un proces de evolutie in care schimbarile metamodelului sunt facute  si evaluate manual este groi si predispus la erori. Tehnicile manuale fac dificila stabilirea ca schimbarile facute asupra metamodelului sunt consistente, determinarea impactului schimbarilor asupra celorlalte elemente de model si determinarea faptului ca metamodelul modificat este solid si complet. Mecanismele de conformitate pot fi apoi dezvoltate si folosite de catre furnizorii de instrumente pentru a verifica faptul ca interpretarile lor asupra regulilor din metamodel sunt corecte.

Instrumentele pot juca un rol semnificativ in reducerea complexitatiilor accidentale asociate cu intelegerea si folosirea metamodelelor mari. De exemplu, un instrument care extrage vederi ale metamodelului tipurilor de diagrame UML care contin doar concepte si relatii care apar in diagrame poate ajuta la intelegerea relatiilor dintre elementele vizibile ale unei diagrame UML. O abordare mai flexibila si mai utila este furnizarea de instrumente care permit dezvoltatorilor sa interogheze metamodelul si sa extraga vederi specificate din metamodel. Instrumentele de interogare/extragere trebuie sa fie capabile sa extraga relatii derivate simple intre concepte si vederi mai complexe care constau din relatii derivate dintre mai multe concepte. Utilizatorii metamodelului pot folosi asemenea instrumente pentru intelegerea mai buna a metamodelelor si pentru obtinerea vederilor asupra metamodelului care pot fi folosite in specificarea sabloanelor si transformarilor. Utilizatorii care au nevoie sa extinda sau sa dezvolte metamodelul UML pot folosi asemenea instrumente pentru a ajuta la determinarea impactului modificarilor (de exemplu, o interogare care returneaza o vedere constand in toate clasele care sunt direct sau indirect legate de un concept pentru a fi modificata in metamodel poate oferi informatii utile) si la verificarea ca modificarile sunt facute consecvent in metamodel. Dezvoltarea unor astfel de instrumente nu se afla dincolo de tehnologiile disponibile in prezent. Instrumentele de dezvoltare existente ofera support pentru manipularea metamodelului UML care poate fi extins cu ajutorul caracteristicilor de interogare si extragere care sunt accesibile utilizatorilor.

Un alt instrument folositor care poate usura utilizarea metamodelului UML este acela care ia un model UML si produce o vedere a metamodelului care descrie structura sa.

Developing Formal Modeling Languages

Metodele formale au tendinta de a restrange punctele de vedere asupra modelarii in scopul de a oferi tehnici puternice de analiza, transformare si generare. O provocare este integrarea tehnicilor formale cu abordarile MDE care utilizeaza limbaje de modelare cu o varietate bogata de puncte de vedere. O abordare comuna este aceea de a transforma vederea modelului (de exemplu, o clasa din UML) intr-o forma care poate fi analizata folosind o anumita tehnica formala. De exemplu, exista un numar de abordari care urmaresc transformarea vederilor de proiectare UML in reprezentari care pot fi analizate de instrumente de validare a modelelor. Provocarile de aici sunt asigurarea ca traducerea este corecta semantic si ascunde complexitatiile limbajului formal tinta si a instrumentelor fata de modelator. Intalnirea celei din urma implica traducerea automata a rezultatelor analizei intr-o forma care utilizeaza concepte din limbajul de modelare sursa.

O alta abordare va fi integrarea algoritmilor de analiza/generare cu limbajul de modelare existent. Aceasta este mai costisitoare, dar va imbunatatii foarte mult aplicabilitatea unui instrument de analiza intr-un limbaj de modelare.

In comunitatea metodelor formale se pune accent mai putin pe dezvoltarea de noi limbaje formale si mai mult pe imbunatatirea notatiilor si tehnicilor existente. Limbajele MDE ofera un context bun pentru executarea unor asemenea imbunatatiri.

Analyzing Models

Daca modelele sunt artefactele primare ale dezvoltarii atunci trebuie sa existe o implicare in evaluarea calitatii lor. Metodele bune de modelare trebuie sa ofere modelatorilor criterii si linii de ghidare pentru dezvoltarea de modele de calitate. In realitate modelatorii se bazeaza in ultima instanta pe feedback-ul de la experti pentru determinarea calitatii modelelor lor. Cercetarile privind evaluarea riguroasa a calitatii modelelor au adus contributii importante privind imbunatatirea modului de evaluare a calitatii modelelor. Un numar de cercetatori lucreaza la dezvoltarea unei tehnici de analiza riguroasa bazate pe buna-definire(well-defined) a modelelor.

Domain - Specific Development

DSL-urile grafice nu sunt doar diagrame.

Conditii necesare pentru indeplinirea obiectivului mai sus mentionat

Limbaje de modelare care sa contina concepte adecvate domeniului problemei

Modele corecte in conformitate cu sintaxa si semantica limbajului de modelare si cu problema de rezolvat.

Modalitati pentru obtinerea unor limbaje de modelare adecvate: utilizarea profilelor (UML) sau crearea unor limbaje de modelare adecvate (specific) DSML.

A doua estesi solutia adoptata de Microsoft.

Modelarea eficienta se realizeaza prin cresterea nivelului de abstractizare. In cazul DSL-urilor, a abstractizarii se realizeaza in primul rand prin utilizarea mai multor DSL pentru modelarea unei probleme. In cazul vostru, un DSL pentru specificarea UI un altul pentru specificarea domeniului problemei. In final modelele (vederile) specificate cu DSL-uri adecvate, vor fi intretesute (model weaving).

Problema voastra descriere - obiective. Identificarea conceptelor corespunzatoare:

Interfetei

Domeniului problemei

Functionalitatile oferite de Microsoft.

Specificarea fiecarui DSL in parte. Constuirea modelelor.

Intreteserea modelelor.

Realizarea aplicatiei, testarea si imbunatatirea ei.

Avantajele obtinute prin aplicarea acestei tehnologii si metode.  (inclusive usurinta si rapiditatea realizarii unor alte aplicatii care folosesc aceleasi concept.)

Pretul platit. Neajunsuri constatate (dificultati)

Posibilitati de extindere.