Lucrare de Licenţă: Ție de Verificare Și Validare A Unui Program

Universitatea POLITEHNICA Bucure ș
ti
Facultatea Automatică şi Calculatoare
Departamentul Automatică şi Informatică Industrială

LUCRARE DE LICENŢĂ

Aplicație de verificare și validare a unui program
Java cu diagrama UML din specificaţie

Coordonator
Prof. dr. Ing. Anca Daniela Ioniță
Absolvent
Anca Simona Varvaroi

Bucureşti
2016

Cuprins

1. Introducere ............................................................................................................ 4
2. Verificare și Validare ............................................................................................... 6
2.1.Principiul Verificării ........................................................................................... 6
2.2.Principiul Validării .............................................................................................. 7
3. Tehnologii folosite .....................................................................................................9
3.1. Programe .............................................................................................................9
3.1.1. NetBeans ............................................................................................. 9
3.1.2.StarUML ............................................................................................ 10
3.2. Limbaje de programare .................................................................................... 12
3.2.1.Java ..................................................................................................... 12
3.2.2.XML .....................................................................................................14
3.2.3.XML ……………………………….………….……………………..15
3.2.4.UML .…………………………….…………………………………..17
3.3.Trasformări între modele………………………………………………………..19
3.3.1.
Spații tehnologice……………………………………………………..19
3.3.2.Instrumente software cu generare de cod și inginerie inversă………...22
3.3.3.Definirea mapărilor între UML și Java…………………….………….23
4. Aplicaţie software .................................................................................................... 27
4.1. Structură...........................................................................................................27
4.1.1. Frontend………………………………………………………………...27
4.1.2. Backend…………………………………………………………….......28
4.2. Funcționalitate..................................................................................................29
4.2.1. Transformatorul T1…………….……………………….………………33
4.2.2. Transformatorul T2…………….………………………….……………34
2
4.2.3. Transformatorul T3……………..………………………………………35
4.2.4 Transformatorul T4……………..……………………………………….36
5. Concluzii şi dezvoltări ulterioare (contribuţii originale, domenii de utilizare posibile,
comparații cu realizări similare cu sublinierea avantajelor, performanţelor etc., alte
aspecte relevante)....................................................................................................... 39
6. Bibliografie.................................................................................................................43
7. Anexă………………………………………………………………………………..44

3
1. Introducere

Dea lungul timpului omul șia dovedit perspicacitatea și ingeniozitatea în
diferite arii de dezvoltare. În ceea ce privește domeniul tehnic, evoluția sa realizat atât
pe latura hardware cat și pe cea software, în ultimul secol realizanduse o ascendență
rapidă a celor două. Clasificarea software/hardware sa realizat tocmai în scopul
eficientizării perioadei de dezvoltare, mintea umană considerând că este necesară
studierea acestora cât mai în detaliu.
Latura software, creată în scopul unei implementări hardware cat mai bune șia
atribuit și o dezvoltare independentă, ajungand sa se îmbine și cu latura artistică pentru
un aspect plăcut și comod utilizatorului. La început a existat un sigur limbaj de
comunicare cu calculatorul scris în cod mașină. În timp au aparut mai multe limbaje de
programare flexibile în funcție de cerințele utilizatorului cum ar fi: C, C++, .Net, PHP,
Java, C#, JavaScript, HTML, CSS, Matlab, Pascal, Python, Perl, PL/SQL, Prolog,
Ruby, SQL, Verilog, VBScript, XML, XMI, UML etc . În topul celor mai utilizate și
dezvoltate limbaje se află Java, PHP și C#, iar în această lucrare ne vom îndrepta atenția
în special către Java.
Java este un limbaj de programare orientat pe obiecte ce determină manipularea
datelor prin intermediul claselor, obiectelor și metodelor. Această metodă de codare a
eficientizat cu mult munca dezvoltatorilor şi oferindule utilizatorilor o gamă cat mai
largă de opțiuni.
Cu toate acestea, nu sa urmărit o dezvoltare doar cu scopul de al mulțumi pe
utilizator, ci sa dorit și îmbunătățirea mediului de lucru al dezvoltatorului, aducand pe
piață noi unelte verificare și testare a codului.
Pentru crearea unei aplicații sau a unei interfețe web, dezvoltatorul se confruntă
cu numeroase etape pană se ajunge la varianta finală a proiectului. Printre aceste etape
se numără implementarea, planificarea, dezvoltarea si testare. De multe ori, etapa de
testare aduce cele mai multe probleme proiectului, ajungând în final să se schimbe o
mare parte din funcționalitate, ceea ce duce la o modificare majoră a codului. Acest
lucru a dus la dezvoltarea unor instrumente care optimizează perioada de dezvoltare a
proiectelor.
Pentru o cat mai bună implementare a codului Java sa dezvoltat un instrument
de proiectare prin intermediul căruia clasele, obiectele, metodele şi atributele acestora
sunt reprezentate sub forma unor diagrame împreună cu specificaţiile cerute. Limbajul
de implementare a acestor diagrame poartă denumirea de Unified Modeling Language
(UML).
Aşadar, limbajul de modelare UML realizând o reprezentare sub formă de
diagrame a claselor și metodelor ce urmează a fi implementate în programul Java
specificat conferă o proiectare mai bună ce poate fi mai ușor înțeleasă și de persoanele
4
ce nu aparțin domeniului tehnic. Cu ajutorul acestor diagrame, dezvoltatorul poate
realiza în ce masură a respectat planul proiectului și ce mai are de adăugat sau modificat
la acesta. Practic diagramele folosesc la proiectarea cerinţei ce trebuie implementată.
Această lucrare aduce o funcționalitate ce servește utilizatorului în același scop
și anume de verificare a proiectului dar şi de validare a cerințelor impuse.
Cunoscânduse Diagrama UML si Programul Java, se dorește verificarea și validarea
celor două prin generarea unui fișier ce conţine diferențele dintre ele sau asemănările,
fapt ce determină dacă diagrama UML aparține programului Java specificat în cerințele
tehnice.
Funcționalitatea impusă este realizată sub forma unei aplicații desktop ce rulează
la nivel local, independent creată în limbajul de programare Java şi folosind ca soft
pentru dezvoltarea ei programul NetBeans.
În cele ce vor urma se va detalia modul în care a fost implementată aceată
funcționalitate dar și o descriere a tehnologiilor folosite, a principiilor ce au dus la
realizarea ei și a modului de lucru cu aceasta.

5
2.Verificare și Validare

Verificarea şi validarea reprezintă procesele prin care se stabileşte dacă un
produs software îndeplineşte cerinţele iniţiale şi îndeplineşte scopul pentru care a fost
dezvoltat. Cele două noțiuni au fost introduse cu scopul unei organizări cat mai precise
a etapei de testare. Prin respectarea acestora se atinge scopul testării. Împreună aceste
două procese se regăsesc sub denumirea de “controlul calităţii software”. Este important
de ştiut că verificarea şi validarea nu sunt acelaşi lucru, cu toate că adesea sunt
confundate. Pe scurt, verificarea asigură că produsul a fost dezvoltat corect , pe când
validarea confirmă dacă produsul îndeplineşte sau nu scopul pentru care a fost
dezvoltat.
Un produs este considerat validat dacă satisface nevoile consumatorului.
Validarea presupune asigurarea că procesele de dezvoltare îndeplinesc specificațiile
inițiale şi verificarea face referire la efectuarea tuturor pasilor necesari în realizarea
unui produs ce respectă necesităţile şi specificațiile inițiale.
Figura 2.1

6
2.1.Principiul Verificării

Principiul Verificării presupune asigurarea că produsul este construit în
concordanță cu cerințele, specificațiile și standardele. Îi sunt asociate răspunsurile la
următoarele întrebări: Sunt îndeplinite cerințele specificate?/Produsul este construit
corect?. Acest tip de activitate ne ajută în evaluarea proiectului pentru a stabili dacă un
produs dintro anumită fază de dezvoltare satisface cerinţele stabilite înainte de
începerea acestei faze. Activităţile care verifică corectitudinea pentru faza de dezvoltare
sunt denumite activităţi de verificare.

Figura 2.2.

2.2.Principiul Validării

Principiul Validării asigură intrarea produsului pe piață. Acesta are asociate
răspunsurile la următoarele întrebări: Produsul acoperă nevoile operaționale?/Produsul
poate fi utilizat în mediul intenționat?.
Cerintele specificate trebuie sa fie si sub forma de document scris. Fără acesta
din urmă procesul de validare nu poate fi finalizat. Testele folosite pentru validare
trebuie sa fie efectuate şi preventiv, nu numai după ce a fost deja scris codul. Este
7
important să se prevină introducerea de greşeli în sursă. Validarea necesită timp şi efort
considerabil , astfel este preferabil ca pregătirile necesare acestui proces să înceapă chiar
din etapa de dezvoltare.
Cand un produs software îşi atinge ciclul de viaţă, procesul de validare trebuie să
fie reluat deoarece specificațiile care trebuiesc respectate se pot modifica în timp.
Folosirea unui plan este esenţială. Acesta defineşte ce anume se va realiza prin efortul
de validare a softului. În plan sunt specificate scopul, abordarea, resursele ,etc. Procesul
propriuzis de validare este realizat prin proceduri. Acestea stabilesc cum anume se va
desfăşura efortul de validare a softului.

Figura 2.3.

În diagrama de mai sus este precizat flowul unui proces de Validare și
Verificare.
8
3. Tehnologii folosite

Prin tehnologii folosite facem referire la instrumentele de creare a aplicaţiei cât
şi la cele de creare a problemelor sau situaţiilor de testare a acesteia. Secțiunea aceasta
conține enumerarea cât şi o scurtă descriere a softurilor de dezvoltare folosite și a
limbajelor de programare alese pentru realizarea aplicației.

3.1. Programe

Ca programe sau ales Netbeans pentru crearea aplicaţiei în sine şi a
funcţionalităţii aceasteia cât şi a programelor Java specifice testate în vederea verificării
funtionalităţii aplicaţiei şi StarUML pentru crearea Diagramei UML corespunzătoarea
sau nu programului Java verificat. Am ales StarUML deoarece este un soft uşor de
utilizat şi accesibil oricărui tip de utilizator şi din care se poate face exportul diagramei
cu extensia XMI de care va fi nevoie în implementarea funcţionalităţii aplicaţiei, fapt ce
va fi detaliat în secţiunile de mai jos.

3.1.1. NetBeans

Figura 3.1.

9
NetBeans reprezintă o platformă de dezvoltare software scrisă în Java care
permite ca aplicaţiile să fie dezvoltate utilizând un set de componente software
modulare numite module. NetBeans IDE este în principal dedicat dezvoltării de aplicații
în limbajul de programare Java, dar suportă şi alte limbaje de programare cum ar fi
PHP, C/C++ si HTML5. NetBeans poate fi rulat pe diverse sisteme de operare ca
Microsoft Windows, Mac OS, Linux, Solaris etc.
NetBeans a fost lansat în 1996 ca Xelfi, un proiect studenţesc realizat sub
conducerea Facultății de Matematică şi Fizică de la Universitatea Charles din Praga. În
1997 a fost creată o companie în jurul acestui proiect care producea versiuni comerciale
ale sale până când a fost cumpărată de Sun Microsystems în 1999. În 2010, Sun, care
includea şi NetBeans, a fost cumpărat de Oracle.
Platforma de dezvoltare NetBeans funcționează doar împreună cu JDK (Java
Development Kit) care este un ansamblu de instrumente software destinat dezvoltării de
aplicaţii în Java oferit de firma Sun Microsystems. Siteul firmei Sun oferă spre
descărcare şi versiuni de JRE (Java Runtime Environment, procesorul virtual Java
necesar rulării aplicaţiilor) dar, pentru dezvoltarea de aplicaţii cu NetBeans trebuie
descărcat şi instalat JDK. De altfel în kitul conţinând JDK există şi JRE.
Ultima versiune de NetBeans IDE a fost lansata impreuna cu noile tooluri
pentru HTML5/JavaScript si suport pentru dezvoltarile Java/C++.
Aplicația este realizată în NetBeans IDE 8.1 (lansat la 4 Noiembrie 2015)
deoarece este o versiune actualizată și stabilă ce contine updateuri ce nu implică
buguri de vreo natura anume. Din aceste motive realizarea aplicației nu a întampinat
probleme sau dificultăți date de softul ales sau de versiunea acestuia.

3.1.2. StarUML

StarUML este un proiect opensource de dezvoltare rapidă, flexibil, extensibil,
de viitor și gratuit rulării pe platforme Win32 .
StarUML este un instrument UML creat
de MKLab. După ce a fost abandonat pentru o perioadă, proiectul a revenit la viață
atunci când limbajul în care era dezvoltat a fost schimbat de la Delphi la Java. În 2014,
o variantă rescrisă a sa a fost publicată sub drepturi de autor, dar o variantă opensource
încă există.
Scopul aplicaţiei a fost să înlocuiască aplicaţiile mai mari şi comerciale cum ar fi
Rational Rose sau Borland Together. StarUML suportă majoritatea diagramelor
specificate de UML 2.0. Din Decembrie 2005, aplicația nu a mai fost actualizată.
Totuși, câteva module externe au fost actualizate.
StarUML realizează o distingere conceptuală clară între modele, viewuri și
diagrame. Un Model este un element care conține informații pentru un model software.
Un View este o expresie vizuală a informației conținute întrun model, și o Diagramă
10
este o colecție de elemente de view care reprezintă designul părerilor specifice
utilizatorului.
StarUML este construit ca un instrument deschis și modular. Dispune de
frameworkuri pentru extinderea functionalitătii toolului. Este construit să permită
accesul la toate functiile de model/metamodel si dispune de extensii ale meniului și
opțiunilor. De asemenea, toolul poate fi integrat cu orice alt tool extern.

Figura 3.2.

StarUML suportă următoarele tipuri de diagrame:
● Diagrama Cazurilor
● Diagrama Claselor
● Diagrama Secvențială
● Diagrama Colaborării
● Diagrama Statechart
● Diagrama Activităților
● Diagrama Componenetelor
● Deployment Diagram
● Diagrama Structurii Compozite

StarUML are multe utilități puternice și cu siguranță este mai mult decât un
simplu instrument de construit diagrame.
Împreună cu suportul sau MDA (Model Driven Architecture), este mai plăcut
utilizatorilor să folosească UML mai mult împreună cu generarea codului corespunzător
11
decât simpla desenare a diagramelor conform specificațiilor din document. Cu toate
acestea, utilizarea StarUML doar ca un instrument de creat diagrame este una bună, mai
ales în Windows.
Cu ajutorul StarUML se pot realiza diferite tipuri de diagrame datorită meniului
și a toolurilor numeroase de care dispune. De asemenea prezintă o proprietate de
salvare a documentelor cu extensia xmi de unde rezultă o trecere simplă către extensia
xml.

3.2. Limbaje de programare

Având în vedere faptul că lucrarea presupune validarea și verificarea unei
diagrame de clase UML cu programul în Java , a fost convenabilă utilizarea limbajului
de programare Java și pentru dezvoltarea aplicației. De asemenea folosim şi UML
pentru crearea diagramei şi XML este folosit ca limbaj intermediar între cele două tipuri
de fişiere pentru citirea acestora.

3.2.1. Java

Java este un limbaj de programare general, dezvoltat de Sun Microsystems în
1991. Initial, el sa numit OAK şi a fost conceput pentru a fi utilizat de dispozitive
portabile sau receivere tv. OAK nu a avut succes, aşa că în 1995 numele ia fost
schimbat în Java şi limbajul a fost modificat în aşa fel încât să poata fi utilizat şi de
World Wide Web.
Java este asemanator cu C++, puşin simplificat pentru a reduce erorile de
programare cele mai frecvente. Java a fost creat aproape exclusiv pentru a fi un limbaj
orientat pe obiecte. Întreg codul este structurat în clase. Spre deosebire de C++, Java nu
permite suprascrierea operatorilor sau moştenirea multiplă decât în cazul interfeţelor.
De aceea, numărul erorilor care pot apărea este mai mic.
Fişierele care conţin cod sursa Java (.java) sunt compilate întrun format numit
bytecode (fisierele .class), care urmează să fie executate de un interpretor Java.
Java conţine o mulţime de clase predefinite şi metode care pot trata majoritatea
cerinţelor fundamentale ale unei aplicaţii. Kitul Dezvoltatorului Java (JDK Java
Developer’sKit) include clase pentru gestionarea de ferestre, intrare/ieşire şi
comunicaţie în reţea. Java mai conţine un număr de utilitare care ajută la dezvoltarea
aplicaţiilor. Aceste utilitare tratează operaţii cum sunt: depanarea, descărcarea şi
instalarea, documentarea.
Datorită acestui lucru, aplicaţiile create în Java sunt portabile, pot fi rulate pe
sisteme care folosesc orice combinaţie de componente hardware şi sofware.
12
Scopul limbajului a fost de a uşura munca dezvoltatorilor în ceea ce priveşte
nevoia de a rescrie anumite secvente de cod. „Scris o dată, rulat oriunde” înseamnă că
fişierele care conţin cod Java pot fi rulate pe orice platformă care susţine Java fără a fi
nevoie să fie recompilate. Folosind limbajul de programare Java pot fi dezvoltate
aplicaţii web, aplicaţii desktop, dar și aplicaţii mobile.
De câţiva ani, Java a avut o ascendență rapidă, ajungând să conţină numeroase
functionalități.
Interpretorul Java este gândit să lucreze pe maşini mici , precum ar fi
procesoarele cu care sunt dotate aparatele casnice. Interpretorul plus bibliotecile
standard cu legare dinamică nu depăşesc 300 Kocteţi. Chiar împreună cu interfaţa
grafică totul rămâne mult sub 1 Moctet, exact ca in vremurile bune.
Limbajul Java este orientat obiect. Cu el se pot crea clase de obiecte şi instanţe
ale acestora, se pot încapsula informaţiile, se pot moşteni variabilele şi metodele de la o
clasă la alta, etc. Singura trăsătură specifică limbajelor orientate obiect care lipseşte este
moştenirea multiplă, dar pentru a suplini această lipsă, Java oferă o facilitate mai
simplă, numită interfaţă, care permite definirea unui anumit comportament pentru o
clasă de obiecte, altul decât cel definit de clasa de bază. În Java orice element este un
obiect, în afară de datele primare. Din Java lipsesc funcţiile şi variabilele globale. Ne
rămân desigur metodele şi variabilele statice ale claselor.
Java este distribuit
, având implementate biblioteci pentru lucrul în reţea care ne
oferă TCP/IP, URL şi încărcarea resurselor din reţea. Aplicaţiile Java pot accesa foarte
uşor reţeaua, folosinduse de apelurile către un set standard de clase.
Java este robust
. În Java legarea funcţiilor se face în timpul execuţiei şi
informaţiile de compilare sunt disponibile până în momentul rulării aplicaţiei. Acest
mod de lucru face ca sistemul să poată determina în orice moment neconcordanţa dintre
tipul referit la compilare şi cel referit în timpul execuţiei evitânduse astfel posibile
intruziuni răuvoitoare în sistem prin intermediul unor referinţe falsificate. În acelaşi
timp, Java detectează referinţele nule dacă acestea sunt folosite în operaţii de acces.
Indicii în tablourile Java sunt verificaţi permanent în timpul execuţiei şi tablourile nu se
pot parcurge prin intermediul unor pointeri aşa cum se întâmplă în C/C++. De altfel,
pointerii lipsesc complet din limbajul Java, împreună cu întreaga lor aritmetică,
eliminânduse astfel una din principalele surse de erori. În plus, eliberarea memoriei
ocupate de obiecte şi tablouri se face automat, prin mecanismul de colectare de gunoaie,
evitânduse astfel încercările de eliberare multiplă a unei zone de memorie.
Java este un limbaj cu securitate ridicată . El verifică la fiecare încărcare codul
prin mecanisme de CRC şi prin verificarea operaţiilor disponibile pentru fiecare set de
obiecte. Robusteţea este şi ea o trăsătură de securitate. La un al doilea nivel, Java are
încorporate facilităţi de protecţie a obiectelor din sistem la scriere şi/sau citire.
Variabilele protejate întrun obiect Java nu pot fi accesate fără a avea drepturile
necesare, verificarea fiind făcută în timpul execuţiei. În plus, mediul de execuţie Java
poate fi configurat pentru a proteja reţeaua locală, fişierele şi celelalte resurse ale
calculatorului pe care rulează o aplicaţie Java.
13
Limbajul Java are inclus suportul nativ pentru aplicaţii care lucrează cu mai
multe fire de execuţie , inclusiv primitive de sincronizare între firele de execuţie. Acest
suport este independent de sistemul de operare, dar poate fi conectat, pentru o
performanţă mai bună, la facilităţile sistemului dacă acestea există.
dinamic
Java este . Bibliotecile de clase în Java pot fi reutilizate cu foarte mare
uşurinţă. Cunoscuta problemă a fragilităţii superclasei este rezolvată mai bine decât în
C++. Acolo, dacă o superclasă este modificată, trebuie recompilate toate subclasele
acesteia pentru că obiectele au o altă structură în memorie. În Java această problemă
este rezolvată prin legarea târzie a variabilelor, doar la execuţie. Regăsirea variabilelor
se face prin nume şi nu printrun deplasament fix. Dacă superclasa nu a şters o parte
dintre vechile variabile şi metode, ea va putea fi refolosită fără să fie necesară
recompilarea subclaselor acesteia. Se elimină astfel necesitatea actualizării aplicaţiilor,
generată de apariţia unei noi versiuni de bibliotecă aşa cum se întâmplă, de exemplu, cu
MFCul Microsoft (şi toate celelalte ierarhii C++).

3.2.2. XML (Extensible Markup Language)

Extensible
XML este extensibil. Îti permite să definești propriile taguri, în ordinea în care
acestea au loc și în modul în care trebuie procesate sau afișate. Un alt mod de a exprima
acest aspect este să considerăm faptul că XML ne permite tuturor să ne expunem
notiunea de ce înseamna un document : poate fi un fișier care traiește pe un server sau
poate fi o piesă tranzacționabilă de date care fluctuează între două sisteme PC.
Markup
Cea mai recunoscută componenetă XML o reprezintă tagul, sau elementele

(mai exact). De fapt , elementele pe care le vei crea întrun XML vor fi foarte
asemănătoare cu cele pe care leai creat deja în documentele HTML. Cu toate acestea,
XML îți permite sa îți definești propriile taguri.
Language
XML este un limbaj similar cu cel HTML. Este mult mai flexibil decat cel
HTML deoarece îți permite sa îți creezi propriile taguri. Cu toate acestea, este
important să conștientizăm faptul că XML nu este doar un limbaj. XML este un
metalimbaj: un limbaj care ne permite să creăm sau să definim alte limbaje. De
14
examplu, cu ajutorul XML putem crea alte limbaje, precum RSS, MathML (a
mathematical markup language), ba chiar instrumente precum XSLT.
XML a fost dezvoltat de către un grup de lucru (XML Working Grup cunoscut

la început ca şi SGML Editorial Review Board) format sub suspiciile Consortiului
World Wide Web (W3C), în anul 1996. Scopurile proiectate pentru XML sunt:
● Trebuie să fie simplu de utilizat pe Internet/Intranet;
● Trebuie să suporte o mare varietate de aplicaţii;
● Trebuie să fie compatibil cu SGML;
● Trebuie să fie uşor de scris programe care vor procesa documente XML;
● Numărul facilităţilor opţionale din XML sunt reduse la minimum, ideal, la zero;
● Documentele XML trebuie să poată fi citite uşor de către utilizatori;
● Proiectarea XML ar trebui să fie pregatită rapid;
● Designul XML trebuie să fie formal şi concis;
● Documentele XML trebuie să fie uşor de creat.
Limbajul XML, acronimul de la eXtensible Markup Language, reprezintă un
metalimbaj de marcare care descrie date. Altfel spus, el defineşte un set de reguli în
ceea ce priveşte structurarea datelor din documente.
Ca şi HTML, XML se bazează pe taguri. El poate fi folosit de dezvoltatorii de
pagini web ale căror nevoi depaşesc limitele HTMLului. Tagurile XML nu sunt
predefinite, adică XML permite crearea tagurilor personalizate. Pentru descrierea
structurilor de date, fişierele XML pot utiliza un fişier de tip DTD (Document Type
Definition).
XML este utilizat pentru a descrie şi a identifica informaţii cu acurateţe întrun
mod cât mai simplist şi general astfel încât să poată fi utilizat de o varietate de aplicații.
XML permite crearea de seturi de date care sunt de acelaşi fel şi pot fi manipulate fără
erori. De asemenea, oferă în format standard pentru schimburile de informaţii dintre
aplicaţii.
Documentele XML pot fi create, scrise, folosind un editor simplu de texte
(precum Notepad). Un document XML e asemănător cu unul HTML. Datele sunt
încadrate în nişte taguri. Spre deosebire de HTML, în XML denumirea tagurilor
(tehnic elemente) nu e strictă, putând fi folosite nume alese de fiecare în funcţie de
opţiunea fiecăruia pentru recunoaşterea datelor ce vor fi scrise, care respectă câteva
reguli minime.

15

Figura 3.3.

Datele astfel stocate pot fi relativ uşor citite şi înţelese de om (putând fi
modificate simplu dacă e nevoie) dar şi de un limbaj de programare care le preia din
fişierul .xml, le prelucrează şi le poate aranja, manipula şi transmite către o altă
aplicaţie, precum un navigator (browser) web. În practică se folosesc de obicei pentru
stocarea datelor baze de date SQL, iar acest format XML este de preferat când se
doreşte utilizarea acestor date de către mai mulţi agenti, în general în scop de citire;
transmiterea fiind mai rapidă şi economică, de exemplu: Ştiri, Meteo, Clasamente, etc.

3.2.3. XMI

XMI a fost iniţial sponsorizat de către IBM şi Unisys ca un rezultat al
colaborării lor din ultiml an asupra standardelor OMG, UML şi MOF. Oracle, DSTC şi
Platinum Technology sunt coaplicatori la cerere. Alţi suporteri îi includ pe cei de la
SELECT Software Tools, Relational Software, Inline Software şi Sysbase.
XMI (XML Matadata Interchange) intenţionează sa aducă o metodă standard
pentru utilizatori pentru a schimba orice tip de metadate care pot fi exprimate utilizând
MOF(Meta Object Facility) specificate de către OMG (Object Management Group).
Acesta integrează trei mari industrii: MOF(OMG), UML(OMG) şi XML(W3C). Faptul
că specificaţiile UML definesc metamodelul UML ca un metamodel MOF implică
direct faptul că XMI serveşte ca un format de schimb pentru UML.
16
XMI a fost creat cu scopul de a realiza interschimbul atât de date (modele şi
fragmente de modele) cât şi de metadate. În particular, XMI permite generarea automată
a sintaxei de transfer pentru un model, bazat doar pe metamodelul modelului. Întreaga
validare a modelului nu este cerută pentru interschimbul metadata. Alte proprietăţi
interesante ale XMI ar fi:
● XMI poate transfera diferenţa documentelor astfel încât documentul modificat
trebuie transferat o singură dată. Noul model poate poate fi obţinut din vechiul
model la care se adaugă diferenţele.
● Un document XMI poate face referire la un element XMI dintrun alt document
XML folosind tehnologia Xlink.
● XMI generează un mecanism de extensie de aşa natură încât diferite tooluri pot
modifica modelul fără pierderi de informaţie şi confuzii.
● XMI suportă abilitatea de a transfera metadate incomplete în model, ceea ce
înseamnă că XMI poate transfera subseturi ale unui model.
OMG este un concept deschis, nonprofit, care produce şi menţine standardele
recunoscute internaţional pentru aplicaţiile interactive.
Fiind un limbaj bazat pe XML, XMI constă din două părţi: DTD (Document
Type Declarations) şi documentele XML. Documentele XML conţin informaţia cât şi
un set de taguri, pe când DTD defineşte ce taguri pot fi folosite în documentul XMI şi
cum.
Procesul producerii documentului XML corespunzător documentului XMI este
definit de un set de reguli de producţie. Un document XML poate fi generat aplicând
aceste reguli de producţie unui model sau a unui fragment de model. Procesul invers
poate fi aplicat documentului XML pentru a reconstrui modelul sau fragmentul de
model. În ambele situaţii, regulile sunt aplicate implicit în contextul metamodelului
specific pentru interschimbarea metadata.

Figura 3.4.
17

(1) Un set de reguli de producţie XML DTD pentru generarea meta modelului MOF
corespunzător.
(2) Regulile de producţie a documentului XML pentru codarea,decodarea
modelelor MOF.
Pentru un model UML specific, se poate genera un document XML utilizând
metamodelul său DTD sau schema bazată pe MOF. Ceilalţi utilizatori ai documentului
XML ar trebui să folosească Scheme sau DTDuri corespunzătoare pentru validarea
documentului XML şi pentru a înţelege sintaxa din acest document.

3.2.4. UML (Unified Modeling Language)

Modelarea reprezintă crearea aplicaţiilor software înaintea codării. Modelarea
reprezintă o parte esenţială în realizarea proiectelor de mare amploare dar şi în
realizarea celor de complexitate medie sau mică. Folosind un model, cei responsabili de
succesul dezvoltării proiectului software se pot asigura că funcţionalitatea este completă
şi corectă şi că cerinţele utilizatorului au fost îndeplinite. Modelele ne permit să lucrăm
la un nivel mai înalt de abstractizare. Un model permite aceste lucruri prin ascunderea
sau mascarea unor detalii, aducând în faţă imaginea de ansamblu sau prin focusarea pe
anumite aspecte ale prototipului. Se poate modela orice tip de aplicaţie, rula pe orice
combinaţie hardware, sistem de operare, limbaj de programare sau reţea, în UML.
Flexibilitatea sa îţi permite modelarea aplicaţiilor distribuite care pot folosi orice mediu
de pe piaţă. Construite pe baza conceptelor fundamentale orientate pe obiect incluzând
clasa şi operaţia, este o potrivire pentru limbajele orietate pe obiect şi mediile precum
C++, Java şi C# dar poate fi folosit şi pentru modelarea aplicaţiilor nonorientate pe
obiect cum ar fi Fortran, VB sau COBOL.
Există multe procedee pentru analizaşi proiectarea orientată pe obiecte. Pentru
totate acestea se foloseşte un limbaj grafic de comunicare a rezultatelor numit Unified
Modeling Language(UML). Prima versiune a acestui limbaj a fost lansată în anul 1996
de către James Rumbaugh, Grady Boochşi Ivar Jacobson de la Rational Software
Corporation. În acelaşi timp, organizaţia nonprofit Object ManagementGroup (OMG) a
lansat, la iniţiativa companiilor HP, IBM, Microsoft, Oracleşi RationalSoftware, o
propunere de creare a unui limbaj unic de modelare. UML a fost limbajul adoptat de
OMG care, începând cu anul 1997 asigură revizuirea permanenta sa. UML este o
schemă de reprezentare grafică pentru modelarea sistemelor orientate pe obiecte. Una
dintre cele mai atractive caracteristici ale sale este flexibilitatea. UML este extensibil şi
independent de multele procese de analiză şi proiectare orientate pe obiecte. Tehnologia
obiectelor a devenit indispensabilă în industria software, iar UML este din ce în ce mai
folosit.
18

Figura 3.5.

Modelarea cu UML defineşte treisprezece tipuri de diagrame, clasificate în trei
mari categorii : 6 tipuri reprezentând structuri de aplicaţii statice, trei reprezentând tipuri
generale de comportament şi patru reprezentând diferite aspecte ale interacţiunilor.
O diagrama UML de clase are următoarea structură:

Figura 3.6.
19
3.3.Trasformări între modele

Transformarea de limbaj este un proces pentru a transforma un text primit ca
intrare întrun limbaj formal şi pentru a obţine la ieşire un text modificat care
îndeplineşte anumite reguli. Există limbaje speciale create cu acest scop: de a folosi ca
intermediar între alte limbaje ce nu pot fi codificate sau transpuse uşor în alte limbaje.
Printre acestea se numără şi XML, care este un limbaj de programare creat special cu
scopul de a trasforma un document de intrare XML întrun document de ieşire care
satisface anumite condiţii. Acesta are o flexibilitate mare şi ca fişier de ieşire: adică
orice tip de document poate fi transpus întrun fişier de tip XML. Este un tip de fişier
care gestionează şi un numar mare de informaţii, permiţând transpunerea datelor în alt
format fără pierderi de informaţii. Un alt tip de fisier usor de prelucrat este cel de tip
text deoarece poate fi deschis de orice compilator si poate fi citit sau prelucrat cu
ușurință fara a se efectua pierderi de informații sau denaturarea acestora.

3.3.1.
Spații tehnologice

În zilele noastre inginerii software trebuie în general să facă față la o mare
varietate de posibile soluții atunci când le este cerut să rezolve o problemă specifică.
Foarte des aceeași problemă poate fi rezolvată cu ajutorul diferitelor tehnologii, la
prețuri diferite, cu calități diferite. Cum am putea să dăm un sfat de folosire a unei
anumite tehnologii pentru rezolvarea unei probleme date? Care sunt diferitele avantaje
ale folosirii unei tehnologii în locul alteia? Dacă alegem un set de soluții, cât de departe
suntem captivi acestei alegeri când o să trebuiască, mai târziu, să evoluăm sau să
menținem soluția? Acestea sunt câteva dintre întrebările practice pe care cineva poate să
și le pună când dezvoltă o soluție software. Pentru a putea asigura niște îndrumări care
vor fi mai mult decât speranțe, trebuie să începem să vorbim explicit despre
caracteristicile și proprietățile fiecărui context tehnologic și să arătăm cum am putea să
asigurăm îndrumare despre folosirea unui context specific când rezolvăm o anumită
problemă.

20

Figura 3.7.

Implementăm conceptul de Spatiu Tehnologic (ST) ca fiind conceptul central
al analizei și comparației noastre.
Un spațiu tehnologic este un context lucrator cu un set de concepte asociate,
corp de cunoaștere, unelte, skilluri necesare și posibilități. Este des asociat cu o
comunitate de utilizatori data, cu knowhow împărtășit, suport educațional, literatura
comună, până și întâlniri de workshop și conferință. Este în același timp o zonă de
expertiză stabilită și cercetare continuă și un depozit pentru resurse abstracte și concrete.
În loc să întrebăm existența apriori a unei teorii unificatoare pentru toate spațiile
tehnologice, mai bine ne întrebăm cum să cunoaștem avantaje și dezavantajele fiecăruia
și cum să sugerăm stategii practice de utilizare. Este posibil ca unele concluzii ale
acestei investigații să ne facă conștienți de niște similarități conceptuale dintre spațiile
tehnologice. Să considerăm inițial cinci spații tenologice: limbaje de programare cu
sintaxa concretă și abstractă, inginerie ontologică, limbaje bazate pe XML, Sisteme de
Management a Bazelor de Date (SMBD), Arhitectura de Conducere a Modelelor
(ACM), ca definită de către OMG. O clasificare a spațiilor tehnologice ar fi următoarea:
21
3.3.1.1. ST ACM
Arhitectura de Conducere a Modelelor (ACM) este o abordare recent propusă
de către OMG1. Potrivit ACM, procesul de dezvoltare software este populat cu un
număr de diferite model, fiecare reprezentand o anumită perspectivă asupra sistemului
de construit. Modele sunt scrise în limbajul metamodelului lor.
3.3.1.2. ST XML
Extensible Markup Language (XML) este un framework pentru definirea
limbajelor markup standardizat de către W3C. Este larg acceptat ca și standard de
reprezentație și schimb de date structurate și semistructurate. Documentul XML este un
conept central în ST XML.
3.3.1.3. ST Sintaxa Abstractă
ST SA este spațiul cu cea mai lungă istorie înrădăcinată în zilele când inginerii
de calcultor au început să construiască abstracții peste limbajul mașină nativ și
exprimarea acestor abstracții prin limbaje mai apropiate de domeniul problemei.
3.3.1.4. ST Ontologic
Conform spuselor lui Gruber, ontologia este o specificație explicită a unei
abstracții. Dimensiunea de acord consensual (în mod obișnuit normativ) ar trebui
adăugat acestei definiții.

XML MDA AS Ontologic
Executabilitate slabă slabă excelenta slabă
Aspecte bună excelentă slabă neutră
Formalizare slabă slabă excelentă neutră
Specializare neutră bună slabă neutră
Modularitate bună bună bună slabă
Trasabilitate bună neutră slabă excelentă
Transformabilitate excelentă neutră neutră neutră

Tabel 3.1.

Spații de legătură/conectare

Este un anumit lucru să discutăm diferitele posibilități de Spații Tehnologice și
un altul să gestionăm problemele de interoperabilitate reală dinte ele. În această secțiune
ne vom ocupa de a doua parte, și anume cum putem să importăm și să exportăm
rezultatele obținute întro anumite tehnologie sau către o altă tehnologie diferită. O
22
acoperire completă a conectării dintre spații ar include descrieri ale tehnicilor și
uneltelor, probleme întâmpinate și exemple.

3.3.2. Instrumente software cu generare de cod și inginerie inversă

Odată cu dezvoltarea limbajelor și modelelor de reprezentare a informațiilor a
apărut și necesitatea de trasformare a acestora în alte limbaje, motiv pentru care au fost
dezvoltate diverse tooluri de convertire a acestora. În ceea ce privește limbajele de
modelare a fost mai complicat deoarece maparea metainformațiilor în modele implică o
complexitate mai mare la asocierea cu o gramatica standard de limbaj. Dar, cum
tehnologia a ajuns întrun stadiu foarte avansat în zilele noastre, sau creat extensii
pentru softurile existente care permit aceste tipuri de conversii de limbaj. Printre aceste
softuri menționăm Eclipse care dispune de posibilitatea de transformare a unui fișier
UML în unul Java.
De altfel și cei de la IBM au realizat un proces similar, adăugând unui soft
deal lor posibilitatea generării codului Java corespunzător Diagramei UML create, dar
și invers: generarea Diagramei UML pe baza programului Java creat. Mai jos avem
două imagini reprezentând cele două tehnologii exemplificate mai sus.

Figura 3.8.
23

Figura 3.9.

Practic, necesitatea obținerii diagramei UML sau a programului Java
corespunzător a dus la crearea de tooluri specifice realizării acestora pe piață. Cu toate
acestea, aceste instrumente presupun crearea automată a fișierului convertit în limbajul
cerut, dar nu și verificarea fișierului în limbajul existent cu un alt fișier în alt limbaj
exterior. Acest lucru este de o complexitate mai mare, motiv pentru care acest tip de
instrumente nu reușesc să surprindă și această funcționalitate.

3.3.3. Definirea mapărilor între UML și Java

Unul dintre blocurile de construcție cheie în Unified Modeling Language (UML)
este conceptul de asociere. O "asociere" în UML este definită ca un tip de relație dintre
24
două clase, care reprezintă o relație semantică între două sau mai multe clase, ce implică
conexiuni între instanțele lor.
Scopul acesteia are trei concepte. Primul, de a scrie o serie de tiparuri de cod
care vor ajuta programatorii în maparea asocierilor UML în limbajul programare
orientat pe obiect necesar. În acestă lucrare, limbajul ales a fost Java, deși, principiile pe
care leam urmărit pot fi aplicate și altor limbaje apropiate, precum C++ sau
frameworkul .NET. Al doilea, de a construi un tool ce generează cod pentru asocieri
folosind tipare, asocierile fiind citite din modelul stocat în format XMI.
Un al treila concept ar fi acela de a face posibila ingineria reversibila, aceasta
fiind, obtinerea asocierilor dintre clase prin analiza codului ce le implementează.
Toolul nostru nu realizează acest task în prezent, deși este o procedură foarte simplă și
directă, dacă codul a fost scris cu tiparele alese.

Problema de multiplicitate

Multiplicitatea unei asocieri binare, plasată la capătul unei asocieri (sfarșitul
țintit), specifică un număr de instanțe țintă ce ar putea fi asociate cu o singură instanță
sursă dea lungul unei asocierii date, în alte cuvinte, câte obiecte ale unei clase (clase
țintă) pot fi asociate cu un singur obiect dat din cealaltă clasă (clasa sursă).

Asocieri opționale și obligatorii
Valoare multiplicității minime poate fi orice întreg pozitiv, deși cele mai comune
valori sunt 0 și 1. Când valoare este 0 putem spune că asocierea este opțională pentru
clasa de la celălalt capăt, iar când valoare este 1 sau mai mare putem spune că este
obligatorie. Asocierile opționale nu ridică probleme speciale pentru implementare, dar
asocierile obligatorii da. Dintrun punct de vedere conceptual, un obiect participant
întro asociere obligatorie trebuie să fie legat la orice moment cu un obiect (sau mai
multe) de la celălalt capăt al asocierii, altfel sistemul se afla în starea greșită.

Asocieri singure/simple și multiple
Valoarea multiplicității maxime întrun capăt de asociere poate fi un întreg mai
mare sau egal cu 1, deși cele mai comune valori sunt 1 sau *. Când valoarea este 1
spunem că asocierea este singură, simplă pentru clasa de la celălalt capăt. Când valoarea
este doi sau mai mare spunem că este multiplă. Asocierile simple sunt mai ușor de
implementat decât asocierile multiple: pentru a stoca singura instanță posibilă a unei
asocieri simple, de obicei implementăm un atribut ce are tipul clasei țintă
corespondente, dar pentru a stoca multele posibile legături de asocieri multiple trebuie
să folosim un fel de colecție de obiecte, cum ar fi Vectorul predefinit Java, HashSet, etc.
25
În cazul general nu putem folosi un vector de obiecte, deoarece primește o dimensiune
fixă când este instanțiat. Cum colecțiile în Java pot avea orice număr de elemente,
constrangerea de multiplicitate maximă nu poate fi exprimată în declarația colecție în
codul Java, dar trebuie verificată altundeva în timpul rulării.

Problema navigabilității

Direcționalitatea, sau navigabilitatea, unei asocieri binare, reprezentată grafic ca
o sageată deschisă la capătul liniei de ascociere ce conectează două clase, specifică
abilitatea unei instanțe a clasei sursă să acceseze instanțele clasei țintă prin intermediul
instanțelor de asociere (legăturilor) ce le conectează. Dacă asocierea poate fi parcursă în
ambele direcții atunci este bidirecțională (două căi/direcții), altfel este unidirecțională (o
cale/direcție).

Asocieri unidirecționale
O asociere unidirecțională singură/simplă este foare similară cu un atribut cu o
singura valoare în clasa sursă, de tipul clasei țintă: o referință embedded, pointer, sau
cum doriți să o numiți. Echivalența, în schimb, nu este completă. Pe când valoare unui
atribut este "deținută" de către instanța clasei și nu are identitate, un obiect referit extern
are identitate și poate fi împărțit/ shared de către instanțele altor clase care au o referință
către același obiect. Oricum, echivalența este suficient de satisfăcătoare pentru a servi ca
baza pentru implementarea acestor tipuri de asocieri. De fapt, în Java nu sunt deloc
diferențe: cu excepția cazului valorilor primitive, atributele în Java sunt obiecte cu
identitate, și dacă sunt publice nu se poate evita ca ele să fie referite și împărțite/ shared
de către alte obiecte.

Asocieri bidirecționale
Echivalența parțială dintre atribute și asocierile unidirecționale nu mai sunt
regăsite printre asocierile bidirecționale. În schimb, o instanță a unei asocieri
bidirecționale este asemănătoare unui cuplu de elemente. Combinând multiplicitățile din
ambele capete ale asocierii, putem să avem trei cazuri: singursingur/ simplăsimplă,
singură/simplămultiplă și multiplămultiplă.

Problema vizibilității

Până acum neam ocupat numai de implementarea Java a două caracteristici a
asocierilor UML: multiplicitate și navigabilitate (direcționalitate), dar suntem de
26
asemenea interesați de implementarea vizibilității. Conform Standardului, vizibilitatea
unui capăt de asociere "specifica vizibilitatea unui capăt de asociere din punctul de
vedere a clasificatorului de la celălalt capăt". Standardul asimiliează vizibilitatea unui
capăt de asociere cu vizibilitatea unui atribut, și oferă aceleași patru posibilităti:
• public alți clasificatori pot naviga asocierea și să folosească rolenameul în

expresii, similar cu folosirea unui atribut public.
• protected descendenții clasificatorului sursă pot naviga asociera și pot folosi

rolenameul în expresii, similar cu folosirea unui atribut protected.
• private numai clasificatorul sursă poate naviga asocierea și poate folosi

rolenameul în expresii, similar cu folosirea unui atribut private.
• package clasificatorii din același pachet (sau subpachet imbricat, la orice

nivel), cum declarația asocierii poate naviga asocierea și poate folosi
rolenameul în expresii.

O interfață uniformă

Codul necesar implementării unei asocieri UML este format practic dintro
combinatie adecvată de atribute și metode Java, dar această combinație depinde de
multiplicitatea, navigabilitatea și visibilitatea asocierii. În legătură cu multiplicitatea,
pentru a stoca singura posibilă instanță a unei asocieri singure/simple putem implementa
un atribut al clasei țintă corespondente, dar pentru a putea stoca multiplele legături
potențiale ale unei asocieri multiple avem nevoie de un tip de colecție de obiecte. În
legatură cu navigabilitatea, o asociere unidirecțională este implementată numai în clasa
sursă, pe cand o asociere bidirecțională este implementată în ambele clase, cu cod care
asigură sincronizarea ambelelor capete. Vizibilitatea capătului asocierii se mapează
direct pe vizibilitatea metodelor necesare; atributele, în schimb, vor ramane mereu
private, pentru a menține un acces controlat prin metodele de interfață.

27
4. Aplicație software

Figura 4.1.

Aplicația este una ce conține o interfață simplă, adevărata complexitate
realizânduse în partea de funcționalitate. În partea de interfață avem 3 butoane prin
care inserăm fișierele ce se doaresc a fi comparate și generarea raportului în care este
specificat în ce măsură fișierul Java coincide cu diagrama UML aleasă. Cele trei
butoane contin o logica de activare a evenimentelor de conversie in limbaj dar si de
parsare a fisierelor noi create.
Logica ce stă la baza realizării aplicaţiei constă de fapt în compararea celor două
fişiere introduse, dar cum acestea sunt fisiere in limbaje diferite si avand extensii
diferite se fac niste proceduri de conversie de limbaj intrun limbaj comun si usor
prelucrarii informatiilor : XML. Fișierele noi convertite de tip XML urmează a fi
parsate prin procese și trasformări specifice după care sunt transpuse în fişiere text
pentru a putea fi accesate cu uşurinţă şi a evita pierderea de informaţii. Sa ales
principiul parsării deoarece prin parsare se ajunge la o segmentare a documentului care
optimizează şi imbunătăţeşte calitatea verificării şi validării fara pierderi de informatii.
În cele ce urmează se prezintă în detaliu structura aplicaţiei cu toate componentele ei
atât din partea de interfaţă cât și din partea de backend dar și partea de funcționalitate
prin explicarea procesului de obținere a rezultatului dorit.

4.1. Structură
Aplicaţia este compusă din partea frontend şi cea backend. Partea de frontend
este cea mai simplă deoarece conţine doar elememtele de selectare a celor două fişiere
28
de comparat şi un element de generare a fişierului ce conţine diferenţele dintre cele
două selectate, pe cand complexitatea este data de partea de backend. Partea
backend este la rândul ei compusă din cinci mari secţiuni: patru transformatoare şi un
comparator despre care se va detalia mai târziu. Mai jos este prezentată o schemă a
modului în care aceasta funcționează:

Figura 4.2.

T1, T2, T3, T4 reprezintă cele 4 transformatoare de limbaj despre care vom detalia în
partea de funcționalitate. F1, F2, F3, F4, F5, F6, F7 reprezintă cele 7 fișiere folosite
dea lungul procesului. C reprezinta procesul de comparare a celor două fișiere
parsate.

4.1.1. Frontend

Aplicaţia este una de tip desktop, ce se rulează local şi este prezentată printro
fereastră ce include practic întreaga logică. Fereastra conţine 8 elemente din care: 3
elemente de tip JLabel care descriu conţinutul obiectului imediat succesor, 2 elemente
de tip JTextField care conţin calea absolută a fişierului deschis la activarea butonului
corespunzător, 3 elemente de tip JButton definite ca butonul de deschidere a fişierului
XMI corespunzător diagramei UML, butonul de deschidere a fişierului Java
corespunzător programului Java şi butonul de generare a fişierului cu specificaţiile
rezultate în urma comparării celor două fişiere transformate şi parsate.
Prin apăsarea butonului Java se face selectarea fișierului Java. Pe acesta este
aplicată o activitate de tip Event care după selectarea fișierului dorit se ocupă de cele
două transformări de limbaj corespunzătoare acestuia: T1 reprezentând algoritmul de
transformare din fișier cu extensia .java în fișier cu extensia .xml . Această trasformare
se face pentru a avea o mai mare flexibilitate în prelucrarea datelor din fișier, fișierul de
29
tip xml fiind mult mai ușor de citit și interpretat decât cele cu extensia .java. În
interiorul acestei trasformări trecerea nu este una directă, ci se trece de la fișierul .java la
unul intermediar de tip .txt care este prelucrat și transformat în fișierul .xml dorit. După
efectuarea primei transformări de limbaj este activat următorul transformator T2 care
reprezintă de fapt procesul de parsare a fișierului .xml generând astfel un fișier de tip
text cu o structură aleasă pentru a putea fi prelucrat cât mai ușor și eficient.

Figura 4.3.

Prin apăsarea butonului UML se provoaca o succesiune de evenimente similare
cu cele în cazul apăsării butonului Java, doar că în acest caz fișierul selectat este unul cu
extensia .xmi corespunzător diagramei de clase UML. Este necesar ca diagrama UML
sa fie salvată cu extensia .xmi pentru a se putea implementa un algoritm de citire a
conținutului acesteia. Extensia originală a unei diagrame UML nu poate fi percepută și
trasformată în alt limbaj pentru a se putea prelucra informațiile din interiorul fișierului,
motiv pentru care sa ales extensia .xmi care este mult mai flexibil și poate fi exportată
sub această formă direct din programul în care a fost realizat, în cazul acesta fiind
StarUML. Fișierul selectat cu extensia .xmi este mai departe prelucrat de un
transformator T3 care realizează trecerea de la limbajul xmi la xml. După efectuarea
acestei trasformări, fișierul nou rezultat de tip xml este trecut printro altă trasformare
T4 similară trasformării T2 de parsare care va parsa fișierul xml și va genera la rândul ei
un fișier de tip text cu structura aleasă.
Butonul Raport este cel la care se aplică ultima parte a procesului și anume cea
de comparare a celor două fișiere parsate create după activarea celorlalte butoane. Prin
30
apăsarea lui, algoritmul de comparare C generează un fișier de tip text care conține
informații referitoare la aspectele asemănătoare sau diferențele dintre fișierul Java și
diagrama UML selectate inițial.

4.1.2. Backend

Partea de funcţionalitate este dată de codul Java asociat fiecărei componente din
interfaţă şi a modului de rulare a acestor obiecte. Codul este compus dintro clasă
principală, cea de interfaţă, adică de creare a ferestrei împreună cu constructorul asociat
şi a obiectelor din interiorul ei şi sase clase subordonate ce conţin modul de activare a
fiecarui buton şi metodele de parsare asociate documentelor deschise cât şi metodele de
tranformare din limbajul fişierelor introduse în fişiere XML. Fiecărei transformări ii este
asociată o clasă și un constructor în interiorul căruia se implementează practic procedura
de transformare de limbaj.
Mai există câteva metode destinate generării unui cod automat asocierii
documentului text parsat cu scopul evitării suprascrierii, metodă de comparare a
conţinutului celor două fişiere parsate şi generarea unui document text în care este
prezentat rezultatul comparării acestora şi alte metode create cu scopul eficientizării
procesului de rulare.
4.2. Funcționalitate

Figura 4.4.
Ca și tehnologie de realizare a aplicației am ales NetBeans IDE 8.1, în care a
fost creată atât aplicația cât și fișierul Java cerut în specificație pe care il utilizam ca
exemplu pentru mai multe situatii, iar diagrama UML a fost realizată în programul
31
StarUML dupa cum se obsevă și în imaginea de mai jos. StarUML ne oferă posibilitatea
de a exporta diagrama UML a claselor sub forma unui fișier cu extensia .xmi pe care ne
va fi mult mai ușor să îl interpretăm.

Figura 4.5.

Pentru această secţiune se va explica pas cu pas logica aplicaţiei. Aplicaţia
conţine o singură fereastră ce cuprinde întregul proces. Componentele ferestrei rămân
aceleaşi pe tot parcursul rulării aplicaţiei. Prin apăsarea butoanelor se deschide o
fereastră dialog din care se selecteaza fişierul Java sau Diagrama UML salvată cu
extensia .xmi ce se doreşte. După selectarea acestuia este activat și procesul de
transformare din limbajul existent în XML dupa care se apelează o metoda de
generare a denumirii fişierului ce va urma a fi creat cât şi introducerea elementelor
parsate în acel nou document creat. După introducerea ambelor fişiere se apasă
butonul de generare de raport la a cărui activare se apelează metoda de comparare
care compară linie cu linie cele două fişiere text parsate, generând un fişier cu
rezultatele comparării.
Fișierul generat va fi salvat automat în același folder în care au fost create și
fișierele text parsate. În cele ce urmeaza se va explica detaliat modul în care
funcționează fiecare trasformator și cum a fost conceput.
Fiecărui transformator îi corespunde o clasa cu metodele corespunzătoare
obținerii rezultatului dorit.

32
4.2.1. Transformatorul T1

T1 este primul trasformator care face conversia fișierului Java selectat întrun
fișier XML pentru a putea fi parsat mai departe de transformatorul T2. T1 constă în
crearea unei clase TxtToXml în interiorul căreia se face citirea fișierului cu extensia
Java și afișarea conținutului acestuia in Consolă dupa care informațiile din consolă
sunt copiate intrun fișier cu extensia .txt. Fișierul text rezultat este in cotinuare
deschis și citit linie cu linie pentru a crea fișierul xml dorit. Crearea fișierului xml
presupune utilizarea a trei metode : openXml(), process(String str) și closeXml()
despre care vom detalia în continuare.
openXml() este metoda care realizează crearea fișierului cu extensie .xml.
împreună cu tagurile corespunzătoare obținerii unui fișier xml valid ce îndeplinește
criteriile standard unui fișier xml.
Secțiunea de cod din cadrul metodei va crea fișierul și va scrie la începutul
acestuia următoarea secvență de cod:
<?xml version="1.0" encoding="UTF8"?>
specifică oricărui fișier de acest tip. De asemenea instrucțiunile specifice deschiderii,
respectiv închiderii tag ului sunt:

th.startElement(null, null, "class",atts);
th.endElement(null, null, "class");
unde atts face referire la definirea atributelor specifice tagului respectiv.

Figura 4.6.
process(String str) această metodă parcurge fișierul text , adică face citirea
linie cu linie din fișier (recunoaște clasele, atributele și metodele din programul Java)
și crează tagurile cu atributele corespunzătoare. Se face căutarea după cuvântul class,
se afișează denumirea corespunzătoare a acesteia, după care se verifică tipul de
33
vizibilitate al acesteia (public, protected, private) și se crează tagul corespunzător
clasei, ce conține atât numele acesteia, cât și tipul de vizibilitate. În fișierul XML
acesta va avea următoarea structură:
<class name ="Course" visibility ="public">
Se vor căuta atributele specifice clasei în funcție de vizibilitate (private, public,
protected) și în funcție de tipul acestora (String, int, boolean) și vor fi afișate în
fișierul XML cu tagul având structura următoare:
<attribute name ="seminarID" visibility="private" type ="String"/>
În cazul metodelor se aplică funcționalitatea asemănătoare atributelor, având
următoarea structură:
<method name =" addStudent" visibility="private" type ="void"/>
closeXml()
această metodă realizează închiderea fișierului XML creat.


T2 reprezintă cel de al doilea transformator care realizează parsarea
documentului XML creat de transformatorul T1. Transformarea se realizează în
interiorul constructorului clasei Parsare, care parcurge fișierul XML și recunoaște
tagurile specifice claselor, atributelor și metodelor corespunzătoare. Această metodă
va genera un fișier de tip .txt în care informațiile vor fi aranjate întro structură
proprie creată pentru a realiza o comparare cât mai exactă a celor două fișiere de
input. Structura fișierului parsat este următoarea:
[Class]: [Name]: "Person" [Visibility]: public
[Connection]: [Name]: is [Type]: Association
[Connection]: [Type]: Association
[Attribute]: [Name]: Name [Visibility]: public [Type]: String_id
[Attribute]: [Name]: Birthday [Visibility]: public [Type]: TimeDate_id
[Attribute]: [Name]: Email [Visibility]: public [Type]: String_id
[Class]: [Name]: "Professor" [Visibility]: public
[Attribute]: [Name]: staffID [Visibility]: "public [Type]:String_id
[Method]: [Name]: getSeminars [Visibility]: public
[Method]: [Name]: isEligible [Visibility]: public
34


T3 este transformatorul care realizează conversia diagramei UML, introduse cu
extensia .xmi, întrun fișier de tip XML, ce urmează a fi parsat. Acesta este
reprezentat de clasa XmiToXml.java care realizează trasformarea din XMI în XML.
În interiorul acestei clase se face citirea conținutului fișierului XMI și afișarea
acestuia întrun fișier de tip text după care se face citirea linie cu linie a fișierului text
nou creat în care sunt identificate tagurile specifice fișierelor de tip XMI ce mapează
o diagramă UML. Fișierul XMI stochează informațiile din diagrama UML a claselor
sub o anumită structură standard, ce va fi utilizată în generarea noilor taguri din
fișierul XML, astfel:
● Clasele pot fi recunoscute prin tagul “packagedElement” și atributul
“xmi:type="uml:Class"”.
● Atributele pot fi recunoscute prin tagul “ownedAttribute”, iar tipul și
vizibilitatea acestora prin cuvintele cheie “visibility="public"”, respectiv
“type="String_id"”.
● Metodele pot fi identificate prin tagul “ownedOperation”, iar tipul și
vizibilitatea acestor sunt recunoscute asemănător atributelor.
● Clasele derivate sau moștenite pot fi recunoscute prin identificatori unici de
forma: “uml:Association”.

Figura 4.7.

După cum se observă și în imaginea de mai sus, tag urile sunt definite în noul
fișier xml prin identificarea termenilor cheie mapați în documentul xmi după structura
descrisă anterior, motiv pentru care a fost creat alt trasformator diferit de T1 deoarece
35
fișierul XMI contine elemente specifice acestui tip de limbaj iar recunoașterea se face în
mod diferit a claselor, atributelor și metodelor, dar și a legăturilor dintre clase.


Transformatorul T4 realizează parsarea fișierului XML, corespunzător diagramei
UML, prin criterii și metode asemănătoare transformatorului T2. Acestuia îi corespunde
clasa ParsareUML.java care are conținutul structurat în figura de mai jos. Motivul
pentru care sa creat un transformator specific diagramei UML, si nu sa folosit același
ca în cazul programului Java, este faptul că structura fișierului XML corespunzător
diferă de cea a fișierului XML asociat programului Java, datorită existenței unor taguri
specifice care indică tipul fișierului sursă și elemente specifice acestuia, cum ar fi:
elementele de tip “import”, “package”, “diagrama”, “model” și “program”.

Figura 4.8.

Comparatorului C i se atribuie clasa “compare”, în interiorul căreia se apelează
constructorul, având ca parametrii: fișierele de comparat și fișierul generat. În interiorul
constructorului se realizează deschiderea celor două fișiere și citirea acestora linie cu
linie. Se caută identificatorii unici "[Class]", "[Visibility]", “[Connection]”, “[Name]”,
“[Type]”, “[Attribute]” si “[Method]”, și se verifică în ce masură se aseamănă, iar
concluzia este scrisă în fisierul de comparare generat.

36

Figura 4.9.

FileInputStream este folosit pentru a defini fișierul ce urmează a fi deschis.
DataInputStream este folosit pentru citirea datelor din fișierul deschis. BufferedReader
segmenteaza citirea din fișierele text de așa natură ca acestea să poată fi citite pe linii
sau vectori.
În cele ce urmează vom detalia structura atât a fișierelor introduse, cât și a celor
noi create: F1, F2, F3, F4, F5, F6 si F7.
F1 reprezintă fișierul cu extenisa .java, selectat după apăsarea butonului “Java”.
În urma selectării acestuia se va realiza citirea și transformarea lui, prin utilizarea
instrumentelor descrise mai sus.
F2 reprezintă fișierul cu extensia .xml, generat de către transformatorul T1.
Generarea acestuia se realizează după selectarea fișierului Java și apelarea
transformatorului T1 și prezintă următoarea structură:

37
Figura 4.10.

F3
este fișierul .txt corespunzător programului Java care a fost parsat în urma
apelării transformatorului T2, generând astfel un fișier .txt, cu o structură ușor de
interpretat în vederea aplicării comparatorului.
F4
este fișierul XMI introdus corespunzător diagramei UML a claselor. Acesta
are o structura standard de mapare a metainformațiilor din diagrama UML, structura
surprinsă în imaginea de mai jos.
Orice fișier XMI corespunzător unei diagrame UML a claselor are structura
definită mai sus, obiectele și atributele specifice din diagrama fiind mapate după o
structura standard, fapt ce va contribui la o identificare mai ușoară a acestora.

Figura 4.11.

F5 este fișierul XML generat de către transformatorul T3 în urma introducerii
fișierului XMI. Acesta are o structură asemănătoare fișierului XML corespunzător
programului Java, dar conține și câteva taguri specifice, care fac referire la tipul sau
structura fișierului inițial:
<?xml version="1.0" encoding="UTF8"?>
<inserts exporter ="StarUML" type ="Model">

F6 este fișierul .txt rezultat în urma parsării fișierului XML corespunzător
diagramei UML. Acesta respectă aceeași structură cu cea a fișierului Java parsat în
vederea efectuării unei comparări cât mai precise și fără pierderi de informații. Structura
fișierului parsat respectă aceleași reguli cu cea a fișierului Java parsat:

[Class]: [Name]: "Student" [Visibility]: public
38
[Connection]: [Name]: enrolled in [Type]: Association
[Attribute]: [Name]: Name [Visibility]: private [Type]: String_id
[Attribute]: [Name]: StudentID [Visibility]: public [Type]: String_id
[Attribute]: [Name]: Birthday [Visibility]: public [Type]: TimeDate_id
[Method]: [Name]: getSeminars [Visibility]: public
[Method]: [Name]: isEligible [Visibility]: public

F7 este ultimul fișier generat de către aplicație în momentul apelării procesului
de comparare în cadrul evenimentului atribuit butonului “Compare”. Acesta este un
fișier de tip .txt care conține informații legate de măsura în care se regăsesc elementele
din diagrama UML în fișierul Java. În funcție de execuția comparatorului C, în fișierul
F7 este afișat fiecare element regăsit atât în primul fișier parsat cât și în cel deal doilea
fișier parsat. Dacă elementul se regăsește în ambele fișiere atunci este precizat că se află
atât în fișierul Java cât și în diagrama UML, în caz contrar se precizează că acesta se
află în fișierul Java dar nu se regăsește și în Diagrama UML. Acest lucru duce la
realizarea unei dezvoltări ulterioare descrise în ultimul capitol.

39
5. Concluzii și dezvoltări ulterioare

Dezvoltarea softurilor pentru aplicațiile de dimensiuni și spații mari a devenit
un task foarte complex. Cu noile presiuni și constrângeri politice și de marketing din
industrie de a livra mai mult la costuri mai mici, a fost necesară o îmbunătățire a
metodelor și standardelor.
În momentul de față, piața se confruntă cu diverse metode de dezvoltare a
modului de realizare a proiectelor prin încercarea de optimizare a realizării acestora dar
și eficientizarea timpului de execuție al acestora. Se încearcă îmbunătățirea acestor
aspecte prin crearea diferitelor tooluri iar în acest proiect de licență este realizat un
instrument care îndeplinește aceste condiții.
Proiectul şia propus realizarea unei aplicaţii de validare şi verificare a
programului Java cu diagrama UML din specificaţie, ceea ce sa şi realizat. De
asemenea există multe posibilități de dezvoltare a acestuia sau de adăugare de noi
funcționalități.
Principiul validării și verificării este un concept cunoscut, dezvoltat pe mai
multe domenii, care servește la obținerea produsului dorit de către utilizator, indiferent
de natura acestuia. Cele două noțiuni, de validare și verificare, au fost descrise mai în
detaliu în al doilea capitol, drept urmare nu vom insista în privința lor.
Pe piață există numeroase instrumente de verificare și validare a produselor
cerute de către utilizatori. În ceea ce privește programele Java și lucrul cu modelarea și
maparea metainformațiilor nu a fost creat un produs exact care să îndeplinească aceste
principii de validare și verficare. Cu toate acestea există instrumente de recunoaștere a
metamodelelor și de asociere a codului corespunzător.
În domeniul dezvoltării produselor software, realizarea proiectelor implică o

serie de pași, printre care se află și modelarea proceselor care va duce la crearea unei
structuri ce va include elementele și obiectele implicate în proces. Respectarea pașilor
asociați structurii vor duce la realizarea produsului final. Omiterea unei etape ar putea
cauza o disfuncționalitate în momentul lansării produsului pe piață, motiv pentru care au
fost inventate diverse tooluri care verifică respectarea în totalitate a pașilor impuși în
structura proiectului. Aceste tooluri au fost create cu scopul de a ușura munca
dezvoltatorilor, dar și pe cea a celor din echipa de testare. De asemenea, acestea se
asigură că structura implementată respectă anumite standarde, prin validarea acestora.
40

Figura 5.1.
În figura de mai sus este afișat graficul situației tehnicilor de verificare în anii
2007, 2012, respectiv 2014.
Aplicația noastră verifică în ce masură un program Java respectă diagrama UML

din specificații. În interiorul său se efectuează o serie de transformări prin care se obțin
fișiere ce respectă o structura standard și care pot fi trimise mai apoi spre a fi procesate
în vederea obținerii concluziei dorite. Ca și concluzie, aplicația îndeplinește următorii
pași:
● citirea și interpretarea fișierului Java introdus și conversia acestuia în
limbajele alese
● citirea și interpretarea diagramei UML și conversia în limbajele alese
● compararea fișierelor obținute în urma diverselor conversii
● generarea unei concluzii în baza acestor comparații
Acest tip de instrument este foarte util în cazul proiectelor ce implică crearea
unor programe Java compuse din mai multe clase, conectate între ele, și având atribute
și metode specifice. Pe baza cerințelor impuse se crează diagrama UML a claselor.
După crearea programului se poate folosi acest instrument pentru verificarea
41
corectitudinii datelor scrise și în ce măsură acestea respectă informațiile din cadrul
diagramei UML. Astfel se obtine o mai buna performanta a produsului, cât și
optimizarea timpului de execuție, prin faptul că se evită o trimitere a unei variante
incomplete sau eronate a produsului catre client.
Ca îmbunătățiri ulterioare se poate aduce o diversificare a tipului de diagrama
UML introduse, adică, în afară de diagrama claselor utilizata actual, să se aducă
funcționalități care implică citirea și interpretarea mai multor tipuri de diagrame UML.
Acest lucru ar presupune posibilitatea introducerii unor diagrame UML de cazuri sau
diagrame UML ale activităților și verificarea programului Java în conformitate cu
acestea.
O altă îmbunătățire ce ar putea fi adusă aplicației ar fi găsirea elementelor lipsă
din fișierul asociat diagramei UML comparativ cu cele regăsite în fișierul asociat
progrmului Java și precizarea acestora spre a fi adăugate în vederea completării
procesului de validare și verificare. Această modificare ar avea o contribuție enormă la
micșorarea timpului de execuție, ajutând dezvoltatorul să meargă direct la sursa
problemei fără a mai efectua o analiza mai în detaliu a elementelor ce trebuiesc
adăugate.
Plecând de la această idee, se poate aduce o noua îmbunătățire instrumentului.
Această îmbunătățire ar constă în modificarea fișierului Java cu elementele lipsă găsite
în cadrul fișierului Java, fapt ce ar presupune modificarea automată a fișierului Java
introdus prin adăugarea claselor, atributelor sau metodelor lipsă din acesta dar care se
regăsesc în diagrama UML.
Pe scurt, putem rezuma posibilitățile de dezvoltare în câteva idei principale:
● diversificarea tipului de digramă introdusă
● specificarea elementelor lipsă din fișierul Java dar existente în diagama
UML
Ca urmare, utilizarea acestui tip de instrument este foarte importantă în
optimizarea timpului de execuție și a profitului. Folosirea acestuia ar presupune o
verificare și o validare mai rapidă a pașilor efectuați ce vor duce la rezultatul final, ceea
ce ar însemna trimiterea produsului mai devreme în producție, deci automat sar ajunge
la obținerea de profit mai rapid. Se poate spune ca scopul principal pentru crearea
acestui instrument sunt obținerea profitului și micșorarea timpului de execuție,
reprezentând astfel obiectivele principale ale pieței actuale.
Atât instrumentul creat dar și celelalte în proces de realizare pe piață urmăresc
ajustarea considerabilă a valorilor grafice din ultimii ani conform graficului de mai sus
spre obținerea unor intervale de timp mai bune si a unui profit mai mare.
42
Drept urmare, acest subiect este întro continuă dezvoltare, ceea ce ănsemnă că
mereu vor exista îmbunătățiri ce se pot aduce acestor tipuri de instrumente.
43
6. Bibliografie

1.
https://www.oracle.com/java/index.html
.
2. Cornelia Dudac Ingineria sistemelor de programe(2011). Editura Alma Mater Bacau
3. J. Sommerville – Software Engineering. Ediția 8.
Java de la 0 la expert
4. Sefan Tanasa, Stefan Andrei, Cristian Olaru (2007). . Ediția a
IIa. Editura Polirom
5.
http://www.ibm.com/developerworks/rational/library/08/1202_berfeld/
6.
http://staruml.io/
7.
http://www.jot.fm/issues/issue_2003_09/article4/
8.
http://docs.geotools.org/latest/javadocs/org/opengis/annotation/docfiles/
9.
http://www.uml.org/resourcehub.htm
l
10. Donald Bell UML basics: An introduction to the Unified Modeling Language
11. James Rumbaugh, Ivar Jacobson, Grady Booch UML basics: An introduction to
the Unified Modeling Language, 2005
12. Prof. Dr. Harald Störrle, Dr. Alexander Knapp Unified Modeling Language 2.0,
20052006
13. David J. Eck Hobart and William Smith Colleges Introduction to Programming
Using Java, Version 6.0, June 2011
14. Herbert Schildt Java : The Complete Reference, Seventh Edition,2007
15. Ivan Kurtev, Jean Bézivin, Mehmet Aksit Technological Spaces: an Initial
Appraisal
16. Allen B. Downey How to Think Like a Computer Scientist, 2012
17.
https://netbeans.org/community/releases/81/
18.
https://www.sitepoint.com/reallygoodintroductionxml/
19.
http://www.htmlgoodies.com/beyond/xml/article.php/3473531
20. Timothy J. Grose, Gary C. Doney, Stephen A. Brodsky, Ph.D. Java Programming
with XMI, XML and UML, 2002

44
7. Anexă

Figura 2.1.

http://programmers.stackexchange.com/questions/168264/
Figura 2.2.

https://blogs.mentor.com/verificationhorizons/blog/2011/04/04/
Figura 2.3.
Creare in cadrul proiectului
Figura 3.1.

https://zeroturnaround.com/rebellabs/javaeeproductivityreport2011/
Figura 3.2.

https://commons.wikimedia.org/wiki/
Figura 3.3.

http://akshayam.in/services/xmlconversion/
Figura 3.4. Mastering XMI Java Programming with XMI, XML, and UML, .Timothy
J. Grose, Gary C. Doney, Stephen A. Brodsky, Ph.D.
Figura 3.5.
http://creately.com/blog/diagrams/umldiagramtypesexamples/
Figura 3.6.
http://www.yourdictionary.com/uml
Figura 3.7.
Ivan Kurtev, Jean Bézivin, Mehmet Aksit Technological Spaces: an
Initial Appraisal
Figura 3.8.
https://www.visualparadigm.com/tutorials/eclipseumltojavatutorial.jsp
Figura 3.9.
http://www.ibm.com/developerworks/rational/library/
Figura 4.1.

https://www.visualparadigm.com/features/codeengineering/
Figura 4.2.
Creată în interiorul proiectului pentru a reda structura acestuia
Figura 4.3.
Print Screen din interiorul proiectului
Figura 4.4.
Figura 4.5.
Figura 4.6.
Figura 4.7.
Figura 4.8.
45
Figura 4.9.
Figura 4.10.
Figura 4.11.
Figura 5.1.

https://blogs.mentor.com/verificationhorizons/blog/tag/
46

Lucrare de Licenţă: Ție de Verificare Și Validare A Unui Program

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Lucrare de Licenţă: Ție de Verificare Și Validare A Unui Program

Încărcat de

Drepturi de autor:

Formate disponibile

comparații cu realizări similare cu sublinierea avantajelor, performanţelor etc., alte

Cea mai recunoscută componenetă XML o reprezintă tagul, sau elementele

XML a fost dezvoltat de către un grup de lucru (XML Working Grup cunoscut

Executabilitate slabă slabă excelenta slabă

Aspecte bună excelentă slabă neutră

Formalizare slabă slabă excelentă neutră

Specializare neutră bună slabă neutră

Modularitate bună bună bună slabă

Trasabilitate bună neutră slabă excelentă

Transformabilitate excelentă neutră neutră neutră

În domeniul dezvoltării produselor software, realizarea proiectelor implică o

Aplicația noastră verifică în ce masură un program Java respectă diagrama UML

Figura 3.4. Mastering XMI Java Programming with XMI, XML, and UML, .Timothy

S-ar putea să vă placă și

Lucrare de Licenţă: Ție de Verificare Și Validare A Unui Program

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Lucrare de Licenţă: Ție de Verificare Și Validare A Unui Program

Încărcat de

Drepturi de autor:

Formate disponibile

comparații cu realizări similare ­ cu sublinierea avantajelor, performanţelor etc.­, alte

Cea mai recunoscută componenetă XML o reprezintă tag­ul, sau elementele

XML a fost dezvoltat de către un grup de lucru (XML Working Grup ­ cunoscut

Executabilitate slabă slabă excelenta slabă

Aspecte bună excelentă slabă neutră

Formalizare slabă slabă excelentă neutră

Specializare neutră bună slabă neutră

Modularitate bună bună bună slabă

Trasabilitate bună neutră slabă excelentă

Transformabilitate excelentă neutră neutră neutră

În domeniul dezvoltării produselor software, realizarea proiectelor implică o

Aplicația noastră verifică în ce masură un program Java respectă diagrama UML

Figura 3.4. ­ Mastering XMI Java Programming with XMI, XML, and UML, .Timothy

S-ar putea să vă placă și

comparații cu realizări similare cu sublinierea avantajelor, performanţelor etc., alte

Cea mai recunoscută componenetă XML o reprezintă tagul, sau elementele

XML a fost dezvoltat de către un grup de lucru (XML Working Grup cunoscut

Figura 3.4. Mastering XMI Java Programming with XMI, XML, and UML, .Timothy