You are on page 1of 135

Introducere

Limbajul Unificat de Modelare (UML) reprezint rezultatul colaborrii dintre Gereid


Booch, James Rambo, Ivar Jakobson, Rebecca Wirfs-Brock, Peter Yourdon i muli alii.
Jacobson primul a descris procesul de identificare i fixare a cerinelor fa de sistem sub form
de seturi de tranzacii, numite cazuri de utilizare (use case). Jacobson, de asemenea, a realizat
metoda proiectrii sistemelor sub denumirea de Proiectarea orientat pe obiecte a asigurrii
program (Object Oriented Software Engineering, OOSE), concentrnd atenia asupra analizei.
Booch, Rambo i Jacobson, despre care de obicei se spune ca despre "trei prieteni" (three
amigos), lucreaz n corporaia Rational Software. n general activitatea lor este legat de
standardizarea i

mbuntirea limbajului UML. Simbolurile UML amintesc foarte mult

notaiile lui Booch i OMT, dar, de asemenea conin i elemente din alte notaii. n figura 1 este
artat un exemplu de notaii.
Pune bani pe cont

Transfera bani

Clientul

Scoate bani de pe cont

Arata balanta

Fig.1. Exemple de simboluri n notaia Booch


Procesul de consolidare a metodelor, incluse n UML, a nceput n anul 1993. Fiecare din
cei trei autori ai acestui limbaj - Booch, Rambo i a Jacobson - a nceput s introduc n
aplicaiile sale ideile celorlali doi autori. O astfel de unificare a metodologiei a durat pn n
1995, cnd a aprut Versiunea 0.8 a Metodei Unificate (Unified Method). n 1996, Metoda
Unificat a fost actualizat i transformat n UML. n 1997 UML1.0 a fost ratificat i transmis
grupului Object Technology Group, dup care au nceput s-l adapteze muli dintre principalii
productori de produse program. n sfrit, la 14 noiembrie 1997 grupul OMG a declarat
limbajul UML1.1 standart industrial.
Ce reprezint Rational Rose?
Rational Rose este un instrument puternic pentru analiza i proiectarea sistemelor
software orientate pe obiecte. Acesta permite modelarea sistemelor nainte de a scrie codul,
astfel nct de la nceput putei fi siguri n caracterul adecvat al arhitecturii lor. Cu ajutorul
modelului gata neajunsurile proiectului sunt uor de detectat la etapele cnd corectarea lor nu
este att de costisitoare.
Mediul Rational Rose permite proiectarea cazurilor de utilizare i diagramele lor pentru
vizualizarea posibilitilor funcionale ale sistemului. Diagramele de interaciune arat cum

lucreaz obiectele mpreun, oferind funcionalitatea necesar. Pentru vizualizarea obiectelor


sistemului i relaiilor lor se utilizeaz diagramele Claselor. Diagramele Componentelor
ilustreaz modul n care clasele se suprapun cu componente fizice gata ale sistemului. n cele din
urm, diagramele Desfurrilor utilizeaz pentru vizualizarea proiectului sisteme distribuite.
Modelul Rose - este o imagine a sistemului. Aceasta conine toate diagramele UML,
actorii, cazurile de utilizare, obiectele, clasele, componentele i ansamblurile sistemului. Ea
descrie detaliat, ce conine sistemul i cum funcioneaz, astfel nct experii o pot folosi n
calitate de schi sau ca un plan al sistemului n realizare.
Acest plan ajut la rezolvarea problemei vechi. De exemplu, echipa de experi a discutat
cu utilizatorii i a determinat cerinele fa de aplicaie. Programatorii sunt gata de a scrie cod.
Unul dintre ei (fie Bob) ia o parte din cerine, adopt anumite decizii i scrie un careva fragment
de cod. Altul (Jane), de asemenea, ia o parte din cerine, i ia propria sa decizie complet diferit
de a lui Bob cu privire la proiect, i scrie un alt cod.
Evident ca se atept diferene ntre stilurile de programare; primind acelai set de
cerine, 20 de experi vor creea 20 de sisteme diferite. Astfel, fr examinarea detaliat a lucrului
cu fiecare participant la proiect va fi dificil de a nelege ce decizii asupra proiectului sunt luate,
din ce elemente const sistemul i ce reprezint n sine nsi structura sa general. Neavnd
proiectul documentat, este dificil chiar de a fi sigur, c aplicaia creat - este exact ceea ce au
dorit utilizatorii.
Procesul tradiional pe care l urmrim este prezentat n figura 2.

Cerinte

AC

: Bob

Fig. 2. Analiza i proiectarea sistemului din punctul de vedere a lui Bob


Cu toate c cerinele au fost documentate, ntregul proiect se afl n capul lui Bob, i
nimeni, dect Bob, nu nelege destul de bine arhitectura sistemului. Cnd Bob prsete echipa,
informaia pleac mpreun cu el. Dac v-ai aflat n astfel de situaie, fii de acord, c este foarte
greu de a nelege sistemul ru documentat.
Modelul Rose - propune o abordare complet diferit (figura 3).
Cerinele

Modelul obiectului

Codul

Fig. 3. Analiza i proiectarea sistemului cu ajutorul modelului Rose

n acest caz, proiectul este deja documentat. Experii se pot aduna i discuta deciziile
luate cu privire la proiect nainte de codificarea real. Nu trebuie s v facei griji c fiecare
dintre ei va proiecta n felul su diferit prile unei i aceleai aplicaii.
Cu toate acestea, modelele sunt utilizate nu numai de experi:
1. Cu ajutorul Diagramelor Cazurilor de Utilizare, clienii i managerii proiectului vor
avea o idee general despre sistem i vor putea lua decizii cu privire la domeniul lui de aplicare.
2. Cu ajutorul Diagramelor Cazurilor de Utilizare manageri proiectului vor putea diviza
proiectul pe diferite sarcini de gestionare.
3. Din documentaia privind cazurile de utilizare analitii i consumatorii vor nelege ce
va face sistemul deja finisat.
4. Studiind aceeai documentaie scriitorii tehnici vor putea ncepe s scrie un ghid
pentru utilizatori i s pregteasc planuri de studiere a lor.
5. Din diagramele de Secven i diagramele de Cooperare analitii i experii vor
clarifica ct de logic funcioneaz sistemul, vor nelege obiectele acestuia i mesajele dintre ele.
6. Cu ajutorul documentaiei privind cazurile de utilizare, precum i diagramele de
Secven i de Cooperare specialitii cu privire la controlul calitii vor putea obine informaia
cerut de acesta pentru a scrie scenarii de testare.
7. Cu ajutorul diagramelor Claselor i Strilor, experii vor avea idee despre fragmentele
sistemului i interaciunile dintre ele.
8. Din diagramele Componentelor i Desfurrilor personalul de exploatare va putea
cunoate, ce fiiere *. EXE i *. DLL i alte componente vor fi create, precum i unde acestea
trebuie s fie plasate n reea.
9. Cu ajutorul modelului ntreaga echip de participani la proiect vor putea monitoriza
realizarea cerinelor iniiale fa de cod, deasemenea din orice fragment de cod va arta cerinele
iniiale, pe care el le realizeaz.
Deci, Rose este un instrument care poate fi utilizat de ctre toi participanii la proiect.
Acesta de fapt, este un depozit de informaii despre contextul i proiectul sistemului, din care
fiecare participant la proiect poate selecta ceea de ce are nevoie.
n afar de cele amintite mai sus, Rational Rose permite generarea unui cod schelet n
diferite limbaje, inclusiv C++, Java, Visual Basic i PowerBuilder. Mai mult dect att, putem
efectua proiectarea invers a codului i crea, astfel, modelele sistemelor deja existente. Este
destul de avantajos de a avea modele Rose pentru aplicaiile deja existente. Dac n model s-au
introdus schimbri, Rose permite s modificm codul pentru execuia lui. n cazul n care codul a
fost modificat, automat putem rennoi n mod corespunztor i modelul. Datorit acestuia putem
menine corespondena dintre model i cod, reducnd riscul de "mbtrnire" a primului.

Mediul Rose poate fi extins cu ajutorul limbajului de programare RoseScript, importat


mpreun cu Rose. Cu RoseScript putem scrie codul pentru introducerea automat a
modificrilor

model,

pentru

crearea

rapoartelor

efectuarea

altor

sarcini.

n prezent sunt disponibile trei versiuni diferite de Rose:


1. Rose Modeler, care permite de a dezvolta modelele sistemului, dar nu suport
posibiliti de generare a codului i de proiectare invers.
2. Rose Professional, ce permite generarea codului ntr-un careva limbaj.
3. Rose Enterprise, permite generarea codului n C++, Java, Visual Basic i scheme
Oracle8.
Mai mult dect att, n cea mai recent versiune Rose 2002 o atenie deosebit se acord
pentru integrarea sa cu aa instrumente, cum ar fi Rational RequisitePro, TeamTest, Visual Basic,
C++ i altele. Rose 2002 asigur publicarea modelelor dumneavoastr pe pagini web. La fel ca
i versiunea anterioar, aceasta este disponibil n variantele Modeler, Professional i
Enterprise. Toate exemplele sunt scrise pentru toate versiunile Rational Rose.

LUCRAREA DE LABORATOR NR. 1


TEMA: Familiarizarea cu tehnologiile, metodologiile i principiile elaborrii modelelor n baza
blocurilor constructive ale limbajului UML i CASE Rational Rose

Scopul lucrrii:
1. Studierea prii teoretice i verificarea cunotinelor n mediul instrumentului CASE
Rational Rose.
2. Aprecierea importanei tehnologiilor, metodologiilor i principiilor elaborrii modelelor n
ingineria softului, evideniind principalele aspecte importante.
3. Studierea notaiei i descrierea destinaiei elementelor/componentelor blocurilor
constructive UML.
4. nsuirea principiilor de creare, modificare i salvare a respectivelor modele-diagrame
elaborate.
5. Studierea i evidenierea respectrii cerinelor metodologice din exemplul reprezentat n
partea teoretic a acestui ndrumar.
6. Analiza propriului sistem i determinarea cerinelor i precedentelor, descriind succint i
elocvent scenariul (pas cu pas) cu exemple concrete.

Sarcina: Elaborai cte dou diagrame de fiecare tip utiliznd instrumentul CASE Rational
Rose. Descriei 5 exemple din Booch.

Consideraii teoretice generale.


Cerinele generale fa de metodologii i tehnologii n ingineria
softului
Metodologiile, tehnologiile i mijloacele instrumentale de proiectare (CASE - mijloace)
alctuiesc baza proiectrii oricrui sistem informaional. Metodologia se realizeaz prin
tehnologiile concrete i standardele care le susin, metode i mijloace instrumentale care asigur
ndeplinirea proceselor ciclului vital.
Tehnologia proiectrii se definete ca un ntreg din trei componente:
-

procedura pas-cu-pas, care definete succesiunea operaiilor tehnologice de proiectare (fig.


1);

criteriile i regulile, care se folosesc pentru aprecierea rezultatelor de ndeplinire a operaiilor


tehnologice;

notaii (a mijloacelor grafice i textuale), folosite pentru descrierea sistemului proiectat.

Fig.1.1. Reprezentarea operaiei tehnologice de proiectare


Instruciile tehnologice, care alctuiesc coninutul general al tehnologiei, trebuie s fie
alctuite din descrierea succesiunii operaiilor tehnologice, condiiile, n dependen de care se
efectuiaz o operaie sau alta, i descrierea nsui a operaiilor.
Tehnologia de elaborare: analiza, proiectarea, dezvoltarea i sprijinul sistemului
informaional ar trebui s satisfac urmtoarele cerine generale:
1. Tehnologia ar trebui s acorde suport deplin ciclului vital al softului;
2. Tehnologia ar trebui s asigure realizarea scopurilor garantat de dezvoltarea sistemului
informaional cu calitatea fix i n timpul stabilit;
3. Tehnologia ar trebui s furnizeze un prilej de realizare a proiectelor mari, pe msur ce
subsistemele (adic prilejul de decompoziie a proiectului pe componente, care au fost
dezvoltate de grupuri de executori ntr-un numr limitat, cu integrarea ulterioar de
componente). Experiena de elaborare a sistemelor informaionale mari, arat c pentru
sporirea eficienei lucrului este necesar de a separa proiectul pe pri slab legate ntre ele, pe
date i funcii a unor subsisteme. Realizareaa subsistemelor ar trebui s fie ndeplinit de
grupurile separate de experi. Astfel este necesar de a furniza coordonarea executrii
proiectului comun pentru a exclude duplicatul ntre grupuri de proiectare care poate s apar
din cauza prezenei datelor i funciilor comune;
4. Tehnologia ar trebui s furnizeze un prilej de dirijare a ocupaiei de proiectare a
subsistemelor separate de grupurile mici (3-7 persoane). Fapt cauzat de principiile de
controlare a colectivului, i sporirea productivitii pe seama minimizrii comunicrilor
externe;
5. Tehnologia ar trebui s furnizeze timpul minim de recepie a sistemului informaional
eficient. ntrebarea nu este despre termenul de realizare a ntregului sistem informaional, ci
despre termenul de realizare a subsistemelor separate. Realizarea sistemului informaional ca
ntreg ntr-un timp scurt poate atrage un numr mare de programatori, astfel nct efectul
poate fi mai slab, dect la ndeplinirea ntr-un timp mai scurt a subsistemelor aparte cu un

numr mai mic de programatori. Practica arat, ns c chiar i la prezena n ntregime a


proiectului complet, introducerea merge consecvent pe subsisteme separate;
6. Tehnologia ar trebui s furnizeze prilej unei configuraii a proiectului, dirijnd versiunile
proiectului i ale componentelor sale, un prilej de eliberare automat a documentaiei de
proiect i sincronizarea ei cu versiuni ale proiectului;
7. Tehnologia ar trebui s furnizeze independena realizrilor de proiect, de mijloacele realizrii
sistemului informaional (sisteme de gestiune a bazelor de date (SGBD), sisteme
operaionale, limbaje i sisteme de programare);
8. Tehnologia ar trebui s fie meninut cu complexul coordonat de Case-mijloace, furnizatori
de automatizarea proceselor care se ndeplinesc pe toate scenariile ciclului vital.
Aplicarea real a oricrei tehnologii de proiectare, elaborare i nsoire a sistemului
informaional ntr-o organizaie concret i proiectul concret, este imposibil fr elaborarea unui
ir de standarde (reguli, nelegeri) care ar trebui s fie observate de toi participanii proiectului.
Din aceste standarde fac parte urmtoarele:
-

standardul proiectrii;

standardul de nregistrare a documentaiei de proiectare;

standardul interfeei utilizatorului.

Standardul de proiectare ar trebui s fondeze:


1. Configuraiile modelelor necesare (diagrame) pe fiecare scen a proiectului i gradul lor de
detalizare;
2. Regulile de fixare a deciziilor proiectului pe diagrame, incluznd: reguli de denumire a
obiectelor (incluznd nelegeri pe terminologie), un set de atribute pentru toate obiectele i
regulile lor de oformare la fiecare nivel, regulile de oformare a diagramelor, incluznd
cererile la forme i dimensiunile obiectelor, etc.
3. Cererile privind configuraiile locurilor de munc a elaboratorilor, incluznd opiunile
sistemului de operare, opiunile mijloacelor CASE, opiunile generale ale proiectului, etc.
4. Mecanismul asigurrii lucrului n colaborare asupra proiectului, i desigur regulile de
integrare a subsistemelor proiectului, regulile de ntreinere a proiectului n stare similar
pentru toi elaboratorii (regulamentul schimbului informaiei de proiect, mecanismul fixrii
obiectelor comune, etc), regulile de verificare a rezultatelor de proiect la noncontrazicere, etc.
Standardul oformrii documentaiei de proiect trebuie s stabileasc:
1. Completarea, componena i structura documentaiei pe fiecare nivel al proiectrii;
2. Cerinele privid oformarea acestei documentaii (incluznd cerinele la coninutul
compartimentelor, subcompartimentelor, punctelor, tabelelor, etc.);

3. Regulile de pregtire, de privire, nelegere i acceptare a documentaiei cu indicarea


limitelor maxime pentru fiecare nivel;
4. Cerinele la setrile sistemului de editare, folosite n funcie de mijloc integrat pentru
pregtirea documentaiei;
5. Cerinele la setrile mijloacelor CASE pentru asigurarea pregtirii documentaiei n
corespundere cu cerinele stabilite.
Standardul interfeei utilizatorului trebuie s stabileasc:
1. Regulile de oformare a ecranului (fonturi i paleta de culori), componena i plasarea
ferestrelor i elementelor de rulare;
2. Regulile de folosire a tastaturii i a mouse-ului;
3. Regulile de oformare a textelor de ajutor;
4. Setul de mesaje standarde;
5. Regulile de prelucrare a reaciei utilizatorului.
Una din nelegerile de baz a metodologiei de proiectare a sistemului informaional este
nelegerea ciclului vital al softului ei. Ciclul vital al softului (CVS) e un proces nentrerupt,
care se ncepe de la momentul hotrrii despre necesitatea crerii lui i se termin n momentul
excluderii lui totale din exploatare.
Documentul normativ de baz, care reglementeaz CVS este standardul internaional
ISO/IEC 12207 [1,2] ( ISO International Organization of Standardization, IEC International
Electrotechnical Commision). El determin structura CV, care conine procese, aciuni i
probleme, care trebuie s fie rezolvate n timpul crerii softului.
Etapele elaborrii / dezvoltrii tradiionale ale produselor software
n timpul dezvoltrii produselor software s-a constatat c exist anumite tipuri de activiti
care trebuie efectuate la un moment dat: -analiza cerinelor -proiectarea arhitectural proiectarea detaliat -scrierea codului -integrarea componentelor -validarea -verificarea ntreinerea.
1.1. Analiza cerinelor. Se stabilete ce anume vrea clientul ca s fac programul. Scopul este
nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel. Claritatea se refer la lipsa
ambiguitii, iar fidelitatea la nregistrarea ct mai exact (posibil cuvnt cu cuvnt).
1.2. Proiectarea arhitectural. Din motive de complexitate, programele mari nu pot fi
concepute i implementate ca o singur bucat. Astfel programul va trebui construit din module
sau componente. Proiectarea arhitectural mparte sistemul ntr-un numr de module mai mici i
mai simple, care pot fi abordate individual.

1.3. Proiectarea detaliat. Se realizeaz proiectarea fiecrui modul al aplicaiei, n cele mai
mici detalii.
1.4. Scrierea/ generarea codului. Proiectul detaliat este transpus ntr-un limbaj de
programare. n mod tipic, aceasta se realizeaz modular, pe structura rezultat la proiectarea
arhitectural.
1.5. Integrarea componentelor. Modulele programului sunt combinate n produsul final.
Rezultatul este sistemul complet.
De obicei specialitii se conduc de anumite metodologii ale elaborrii i metodele lor
conform modelului ciclui de via a sistemului care cuprinde mai multe etape. ns, pentru
nceput, n timpul elaborrii cnd ncepem dezvoltarea unui produs soft avem nevoie de:
-

o nelegere clar a ceea ce se cere;

un set de metode i instrumente de lucru;

un plan de aciune.

Deci trebuie s ne punem urmtoarele ntrebri, cel puin, n legtur cu arhitectura


sistemului:

Ce diagrame exist, ce legturi sunt ntre ele?

Care mecanisme regleaz interaciunea claselor?

Unde trebuie s fie prezentat fiecare diagram? Etc.


Metodologia spiral. Metodologia spiral, propus tot de Boehm, este un alt exemplu bine

cunoscut de metodologie a ingineriei programrii. Acest model ncearc s rezolve problemele


modelului n cascad, pstrnd avantajele acestuia: planificare, faze bine definite, produse
intermediare. El definete urmtorii pai n dezvoltarea unui produs:
a) studiul de fezabilitate;
b) analiza cerinelor;
c) proiectarea arhitecturii software;
d) implementarea.
Modelul n spiral recunoate c problema principal a dezvoltrii programelor este riscul.
Riscul nu mai este eliminat prin aseriuni de genul: n urma proiectrii am obinut un
model corect al sistemului, ca n modelul cascad. Aici riscul este acceptat, evaluat i se iau
msuri pentru contracararea efectelor sale negative. Exemple de riscuri:
a) n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului sunt
b)
c)
d)
e)

ignorate;
clientul schimb cerinele;
o firm concurent lanseaz un program rival pe pia;
un dezvoltator/arhitect prsete echipa de dezvoltare;
o echip nu respect un termen de livrare pentru o anumit component.

n modelul spiral se consider c fiecare pas din dezvoltare conine o serie de activiti
comune:
1. pregtirea: se identific obiectivele, alternativele, constrngerile;
2. gestionarea riscului: analiza i rezolvarea situaiilor de risc;
3. activiti de dezvoltare specifice pasului curent (de exemplu analiza specificaiilor sau
scrierea codului);
4. planificarea urmtorului stadiu: termenele limit, resurse umane, revizuirea strii
proiectului.

Fig.1.2. Metodologia spiral


Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri:
Ciclul 1 Analiza preliminar:
1. Obiective, alternative, constrngeri
2. Analiza riscului i prototipul
3. Conceperea operaiilor
4. Cerinele i planul ciclului de via
5. Obiective, alternative, constrngeri
6. Analiza riscului i prototipul
Ciclul 2 Analiza final:
7. Simulare, modele, benchmark-uri
8. Cerine software i validare
9. Plan de dezvoltare
10. Obiective, alternative, constrngeri
11. Analiza riscului i prototipul
Ciclul 3 Proiectarea:
12. Simulare, modele, benchmark-uri
13. Proiectarea produsului software, validare i verificare
14. Integrare i plan de test
15. Obiective, alternative, constrngeri

16. Analiza riscului i prototipul operaional


Ciclul 4 Implementarea i testarea:
17. Simulare, modele, benchmark-uri
18. Proiectare detaliat
19. Cod
20. Integrarea unitilor i testarea acceptrii
21. Lansarea produsului
Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe msur ce
spirala este parcurs, produsul se maturizeaz. Cu fiecare ciclu, sistemul se apropie de soluia
final.
Dei este considerat ca un exemplu generic pentru metodologia ciclic, metoda are i
elemente secveniale, puse n eviden de evoluia constant de la o etap la alta.
Metodologiile orientate pe obiecte. Abordarea orientat pe obiecte se bazeaz pe
identificarea obiectelor, entiti distincte care pot fi concrete (la nivel fizic) sau abstracte (la nivel
conceptual).
Obiectele sunt caracterizate prin structura datelor care le descriu i prin comportamentul pe
care l pot manifesta, altfel spus operaiile care lucreaz cu datele lor. Rumbaugh subliniaz c
fiecare obiect are identitatea sa chiar dac dou obiecte au aceleai valori ale atributelor ele
rmn totui dou obiecte distincte.
Obiectele sunt clasificate, definind clase pentru toate obiectele cu aceeai structur i
comportament. Un principiu important n abordarea OO este ascunderea informaiilor n
interiorul clasei - numit ncapsulare. Astfel, aspectele externe, vizibile din exteriorul clasei, de
ctre utilizatorii acesteia, sunt separate de detaliile interne de implimentare, care trebuie ascunse.
Aceeai operaie poate avea comportri diferite n clase diferite proprietate numit
polimorfism. ntr-un limbaj OO metoda corect este selectat automat, n funcie de numele su
i de clasa din care face parte obiectul.
Dac mai multe clase au atribute i operaii comune, ele pot fi incluse ntr-o superclas care
este apoi divizat n subclase ce i includ proprietile, prin mecanismul de motenire, i adaug,
de asemenea, atribute i operaii noi. Astfel, se reduce redundana att la nivel conceptual al
proiectului ct i la nivelul codului, obinndu-se unul dintre cele mai importante avantaje ale
abordrii orientate pe obiecte.
Pentru a reduce complexitatea problemelor se folosete abstractizarea ce permite
concentrarea pe aspectele eseniale, inerente ale unei entiti; nu se iau decizii legate de

implimentare pn nu se ajunge la o nelegere aprofundat a problemei. Poate urma astfel o


proiectare clar, care s contribuie la o abordare mai uoar a etapelor urmtoare: implimentarea,
documentarea, ntreinerea.
Limbajul UML
UML (Unified Modeling Language) este prima platform pentru dezvoltarea rapid a
aplicaiilor. Cauza apariiei UML a fost necesitatea abordrii unificate despre descrierea
modelelor aplicaiilor business la nceputul anilor 90 ai secolului XX. Atunci au i aprut cteva
zeci de variante de instrumentarii pentru crearea modelelor de acest tip, ns incompatibilitatea
dintre ele, fcea dificil dezvoltarea CASE (Computer Aided Software Engineering) mijloacelor i introducea unele neclariti.
CASE - dezvoltarea soft-ului cu ajutorul calculatorului, adic dezvoltarea automatizat a
soft-ului. CASE-mijloacele pe atunci aveau n majoritatea cazurilor, rolul de interfa a SGBD,
ceea ce permitea automat generarea bazei de date dup schema ei grafic. Dezvoltarea UML a
fost efectuat de ctre compania Rational Software, care a creat unul din primele CASE
mijloace - Rational Rose.
UML apare datorit efortului colaborativ a lui Grady Booch, Dr. James Rumbaugh, Ivar
Jacobson, Rebecca Wirfs-Brock, Peter Yourdon, i muli alii. UML a fost recunoscut ca standard
al notaiilor folosit la modelarea sistemelor n baza celor mai relevante concepte ale primilor trei
autori cu completri i de la ali specialiti. n UML mai este prevzut un important aspect ce
reprezint creterea rigorii n definirea conceptelor utilizate, cretere realizat prin utilizarea
limbajului OCL (este un limbaj tipizat de modelare, fr efecte secundare) la definirea semanticii
conceptelor metamodelului. UML a aprut ca urmare a unificrii diferitor metode i a experienei
anterioare, unde principalele obiective au fost: de a reflecta cele mai bune practici ale industriei;
de a demistifica procesul de modelare a sistemului soft.
Prima versiune a UM (Unified Method) 0.8 a fost introdus n 1995. UM a fost refcut i
schimbat n UML n 1996. n octombrie 1995 a demarat procesul de unificare a metodelor OOD
i OMT. Acest proces a fost extins pn n anul 1996 prin integrarea metodei Objectory i
aderarea lui Ivar Jacobson la grupul format de Booch i Rumbaugh.
n septembrie 1997 'rzboiul metodelor' ia sfrit prin adoptarea de ctre OMG a limbajului
UML ca limbaj standard de modelare a aplicaiilor.

OMG (Object Management Group)

reprezint un consoriu internaional al crui obiectiv principal l constituie promovarea abordrii


orientate obiect n cadrul ingineriei softului.

Pentru a ne crea o imagine corect despre noile limbaje de modelare trebuie inut cont att
de avantajele ct i de dezavantajele inerente ale unei unificri. Pe scurt, avantajele principale
constau n:
Eliminarea unor diferene existente ntre conceptele i notaiile unor metode, diferene
nesemnificative, dar care au produs multe confuzii.
Realizarea unei stabiliti n lumea productorilor i utilizatorilor de instrumente CASE,
prin intermediul unui limbaj i metodologii care acoper integral etapele realizrii aplicaiilor.
Eliminarea conceptelor care nu i-au dovedit viabilitatea i pstrarea celor care s-au
dovedit a fi utile. Stabilirea unui numr suficient de documente (diagrame, rapoarte) pentru toate
etapele (de via).
Inconvenienele majore se datoreaz faptului c:
Unificarea unor metode distincte presupune aproape inevitabil creterea numrului de
concepte utilizate. Cu toate eforturile de generalizare, noua metod (noul limbaj) devine mai
complex.
Fiecare din metodele participante la procesul de fuziune accentueaz anumite aspecte ale
procesului de modelare. Metoda rezultat nu poate ine cont de aceste aspecte n egal msur.
De aceea este posibil ca modelarea unui tip particular de aplicaii s poat fi mai bine realizat cu
o metod participant la procesul de reunificare, i nu cu metoda unificat.
UML 1.0 a fost ratificat i dat OMG-ului n 1997. n 1997, OMG a emis UML 1.1 ca un
standard industrial.
Peste ani, UML a evoluat cu noi idei, ca de exemplu: sisteme web-based i modelarea
datelor. Mai trziu n 2000 a fost ratificat versiunea UML 1.4. n prezent se lucreaz asupra
noilor versiuni mai moderne i mai puternice.
Utilizarea UML la modelarea i designerului bazei de date nu doar simplific comunicarea,
dar i nltur barierile dintre elaboratori, oferindu-le un mediu mai eficient de modelare. Cu
modelul bazei de date n limbajul UML, proiectantul bazei de date poate primi aa informaie ca
constrngerile, triggere i indeci direct pe diagram. Cnd aceast informaie e modelat,
utilizatorilor le este mult mai simplu s asigure comunicarea cu modelul bazei de date n
ntregime.
Pe scurt UML furnizeaz imagini standardizate ale aplicaiilor soft, el este un limbaj i un
proces cu notaie neutr, ceea ce nseamn c se poate utiliza la designul ntregului sistem
orientat pe obiecte n orice limbaj de programare i n orice proces de dezvoltare.
UML este un limbaj de vizualizare, specificare, construire i documentare a componentelor
sistemelor.

Ca limbaj de vizualizare nseamn c mai nti se face designul sistemului desennd


diagrame, adic asigur reprezentarea grafic a modelului prin una sau mai multe scheme, i apoi
se folosesc instrumente pentru a converti aceste diagrame n cod. Valoarea acesteia const n
faptul c deseori codul este scris automat elibernd programatorul de elaboararea codului, plus
tranziia de la design la faza de implimentare este mai simpl i mai rapid. Mai mult ca att
folosind generarea codului, proiectantul se poate mica n cod i ntre cod i design care este
exprimat prin diagrame.
Ca limbaj de specificare ne permite specificarea tuturor soluiilor importante care se refer
la analiza, proiectarea i realizarea n procesul elaborrii i dezvoltrii produselor soft adic
construirea modelelor fixe i complete.
Ca limbaj de construire cu toate c UML nu este limbaj de programare vizual (UML n
primul rnd este un mijloc de descriere) dar ne permite ca toate modelele elaborate n baza lui s
fie traduse automat n diverse limbaje de programare ca: Java, ANSI, C++.
Practic toi productorii mondiali ai mijloacelor CASE au anunat despre susinerea UML
n versiunile urmtoare ale lui. Deja azi exist multe mijloace CASE ce automatizeaz procesul
analizei i proiectrii n UML (Rational Rose, Paradigm Plus, Select Enterprise, Microsoft
Visual Modeler for Visual Basic i altele), susin multe limbaje de programare C++, Java, Delphi,
Power Builder, Visual Basic, Centura, Forte, Ada, Smalltalk, de asemenea permite generarea
bazelor de date pentru majoritatea SQL-serverelor. Modelele, elaborate n UML, permit
simplificarea considerabil a procesului de codare i transferul nemijlocit al eforturilor
programatorilor asupra sistemului.
Diagramele mresc caracteristicile proiectului i uureaz procesul desfurrii
documentaiei sistemului soft.
UML este limbaj de modelare independent de platform, se abstractizeaz de specificul
limbajelor de programare concrete i mijloacele lor de dezvoltare etc.
UML mai este necesar:

conductorilor de proiecte, care conduc cu gestionarea sarcinilor i controlul asupra


proiectului;

proiectanilor sistemelor informaionale, care dezvluie sarcini tehnice pentru


programatori;

business analitilor, care cerceteaz sistemul i care administreaz afacerile unei


companii;

programatorilor care efectueaz modulele sistemului informaional.

Fiind un instrument orientat pe obiecte de modelare Rational Rose se bazeaz pe UML,


care a fost elaborat cu scopul de a crea un limbaj mai optimal i universal pentru descrierea att a
domeniului de obiecte ct i pentru probleme concrete de programare.
Una dintre proprietile cele mai importante ale Rational-Rose se consider arhitectura
accesibil, ceea ce permite de a completa instrumentele existente cu noi funcii.
Rational Rose este un instrument pentru crearea i modelarea sistemelor informaionale,
deci poate fi utilizat pentru crearea unui sistem informaional definitivat sub form grafic i n
form de cod.
Rational Rose este o resurs orientat pe obiecte de proiectare capabil de a modela
situaii de orice dificultate: de la proiectul unui sistem bancar pn la elaborarea codului n
diverse limbaje de programare: C++, Delphi, Java etc.
Modelarea bazei de date n Rational-Rose ofer urmtoarele posibiliti:
1. Corespunderea dintre structurile orientate pe obiecte i modelul de date permite
urmrirea transformrii modelului obiectului n modelul bazei de date. Aceast form
de corespundere permite analiza legturii dintre aplicaiile i bazele de date i
nnoirea lor pe baza schimbrilor efectuate n procesul elaborrii.
2. Proiectarea direct i invers a modelului de date i a bazei de date permite crearea
modelului de date bazat pe structura bazei de date prin proiectarea direct sau invers,
schema poate fi generat vis a vis de baza de date sau salvat ca script pentru
utilizarea ulterioar. Ea va conine tabele, coloane, limite, indeci, triggere, etc.
3.

Integritatea referenial pstreaz integritatea bazei de date datorit transferului


automat al cheilor primare ale tabelelor principale n tabele dependente, cnd referina
este creat s aleag cum s asigure integritatea referenial: sau prin trigger sau prin
integritate declarativ.

Rational-Rose spre deosebire de alte resurse de acest tip de proiectare e capabil de a


proiecta sisteme de orice complexitate, adic programul permite att redarea la nivel nalt
(abstract) (de exemplu schema automatizrii unei ntreprinderi), ct i la nivel jos (interfaa unui
program, schema unei baze de date). Modelarea se bazeaz pe nou (unsprezece) diagrame care
n funcie de situaie sunt capabile s descrie diverse aciuni.
La modificarea sistemului aspectul obiectual permite uor de a include n sistem obiecte
noi i de a le exclude pe cele vechi fr schimbul esenial al ciclului de via. Folosirea
modelului construit, n timpul modificrii sistemului, permite de a elimina consecinele nedorite
ale schimbrilor, deoarece ele nu distrug structura stabil a sistemului, ci numai schimb
comportamentul obiectelor.

Sfera de aplicare a limbajului UML nu se limiteaz doar la modelarea produsului soft,


experimentarea lui permite modelarea documentelor n sistemele juridice, modelarea structurii i
funcionrii sistemelor de deservire a pacienilor n spitale, la proiectarea unor mijloace de aparataj.
Pentru a nelege limbajul UML e necesar de neles modelul conceptual al lui, care include n
sine trei pri principale: blocurile principale de construire ale limbajului (sistemul de notaii
grafice), regulile de mbinare i unele mecanisme principale eficiente pentru tot limbajul n
ntregime. Cunoscnd aceste lucruri, nu doar c vei putea citi modelele n limbajul UML, ba chiar
vei crea altele noi.
Sistemul de notaii grafice
O consideraie important n modelarea vizual este alegerea notaiilor grafice ce vor fi
folosite pentru reprezentarea variatelor aspecte ale unui sistem. Aceast notaie trebuie s fie
convenit de toate prile interesate n caz contrar modelul nu va fi de folos. Muli au propus
notaii pentru modelarea vizual.
Schemele-bloc reprezint n sine o minune a simplitii. nsemnrile grafice convenionale
descriu pe deplin paii necesari pentru a ncheia o aciune sau alta. Procesele se aeaz n
consecutiviti logice clare, care fac ca schemele-bloc s reprezinte un mijloc excelent de redare
a unei sarcini de afacere i simplific codificarea aplicaiilor. Spre exemplu, n schemele bloc
uor se observ legtura etapelor predecesoare cu cele succesoare. n acelai timp descrierea
fiecrei aciuni necesit o cantitate de detalii, astfel nct ea poate fi conceput ca un proces
aparte. Nu e greu de observat c la construcia unei scheme bloc se atrage mult atenie descrierii
situaiilor comune (de exemplu imposibilitatea accesului la o baz de date). Nivelul necesar de
detaliere complic descrierea proceselor, nedorind se ajunge la greeli i neclariti.
Dezvoltarea de mai departe a fost condiionat de aspectul obiectual orientativ. Creatorii
de soft au primit o concepie care reflect viaa real. Lumea e compus din obiecte. Fiecare din
ele avnd atribute i comportament propriu. Limbajele orientate pe obiecte permit determinarea
elementelor de conducere, responsabile de comportamentul unui sau altui obiect. Tehnologiile
orientate pe obiecte permit elaboratorilor s reprezinte obiectele ca o totalitate de date i funcii,
ridicnd prin aceasta proiectarea la un nou nivel calitativ. Programatorii pot elimina din codul
programului fragmentele de operaii tipice ce se repet, nlocuindu-le cu descrierea fiecrui
obiect. Datorit arhitecturii care face ca funciile i elementele de conducere s fie public
accesibile, totodat ascunznd codul care le creaz, creatorii pot utiliza obiectele neavnd idee
despre structura lor interioar. n rezultat, la scrierea codului, programatorul se poate concentra
la sarcinile reale ale sistemului, excluznd nevoia de a cunoate structura interioar a obiectelor.

Odat cu apariia tehnologiei orientate pe obiecte a aprut necesitatea n mijloace instrumentale


care permit de a primi o descriere mai complex dect prin simplele scheme bloc.
Programatorilor le sunt necesare instrumente care s le creeze nchipuirea vizual a proceselor.
n anii 90 au aprut o serie de metode de dezvoltare a aplicaiilor, fiecare dintre acestea
introducnd notaii (grafice sau formale) particulare.

Printre cele mai populare metode se

numrau notaiile OMT (Object Modeling Technique James Rumbaugh ), OOD (Object
Oriented Design Greedy Booch) i OOSE (Object-Oriented Software Engineering) Ivar
Jacobson. Fiecare dintre aceste metode aveau puncte tari i slabe. OMT era potrivit pentru
etapa de analiz, OOD pentru etapa de proiectare, iar OOSE avea n vedere n special etapa de
analiz comportamental. Anii 90 sunt caracterizai de aa-numitul 'rzboi al metodelor', n
care fiecare dintre autori (numii i guru) ncerca s impun propria metod de analiz i
proiectare a aplicaiilor.
Rational Rose suporta toate aceste trei notaii; totui, UML este standardul care a fost
adoptat de majoritatea industriei ca i ANSI i OMG( Object Management Group).
Blocurile constructive n UML
n limbajul UML sunt incluse trei tipuri de blocuri de construcie:
1

Entitile

Relaiile

Diagramele
Entitile sunt abstracii ale principalelor elemente din model. Relaiile fac legtur dintre

diferite entiti, pe cnd diagramele grupeaz ansamblurile de entiti pe interese.


Entitile
Entitile sunt unicele blocuri orientate obiectual n UML. n UML sunt patru tipuri de entiti:
1

Structurate

Comportamentale

De grup

De adnotare
Entitile structurate sunt numite substantive n model care de obicei reprezint
prile statice, care corespund elementelor conceptuale sau fizice ale modelului. Sunt
prevzute apte tipuri de entiti structurate:

Clasa (Class) reprezint descrierea ansamblului de obiecte cu atribute comune. Clasa


realizeaz una sau mai multe interfee. Clasa are nume (Casete), atribute (Seria,
Mrimea, Timecod), precum i operaii (de inserare, de tergere i de modificare).

Interfaa (Interface) reprezint un ansamblu de operaii, care determin setul de


servicii, pe care poate s le asigure respectiva clas sau component. Astfel interfaa
descrie componentul vzut din exterior. Interfaa determin numai specificarea operaiei
semantice, dar nici o dat executarea operaiei. Grafic interfaa este reprezentat n form
de un cerc. Numele interfeei se afl n partea de jos a cercului.
Interaciunea (Collaboration) reprezint prin sine ansamblul de roluri i de alte
elemente care funcioneaz mpreun producnd un oarecare efect de colaborare.
Interaciunea, aadar, are aspect att structural ct i de comportament. Una i aceeai clas
poate s participe n mai multe interaciuni. Astfel ea realizeaz imaginea de
comportament, care la rndul su formeaz sistemul. Grafic interaciunea este reprezentat
n form de o elips care este alctuit dintr-o linie ntrerupt, iar n mijlocul ei de obicei
se scrie numai numele interaciunii.

Precedentele (Use case) reprezint o descriere, o succesiune de aciuni pe care le


efectueaz sistemul i produce rezultatul urmrit important pentru un oarecare actor. Ele
se folosesc pentru structurizarea entitilor comportamentale i se realizeaz prin
intermediul cooperrii. Grafic precedentul este reprezentat printr-o elips.
Urmtoarele trei entiti descriu totalitatea obiectelor cu ajutorul atributelor,
operaiilor, relaiilor i a semanticii. Dar totui ele n bun msur difer una de alta i au
o mare importan la modelarea sistemelor obiect-orientate trebuie atras atenia fiecrei
n parte.
Clasele active (Active class ) sunt clasele obiectele crora sunt atrase n una sau mai
multe proceduri, sau fire (Threads), i de aceea ele pot s iniieze aciuni de gestionare
(comand). Clasa activ seamn cu clasa obinuit, cu excepia c obiectele ei reprezint
elemente, aciunile crora se efectueaz paralel cu alte elemente. Reprezentarea grafic e

aceeai ca i la clasa obinuit care const dintr-un dreptunghi i la fel are nume, atribute
i operaii. ns diferena const n conturul liniei groase ce contureaz dreptunghiul.
New
Component

Componentele (Component) reprezint prile fizice ale sistemului, care corespund


unui set de interfee i asigur realizarea lor. n sistem se pot ntlni aa fel de componente
ca COM sau Java, chiar i componentele care sunt artefactele procesului de elaborare, de
exemplu fiierul cod. Componentele de regul reprezint prin sine o cutie fizic, care
conine elemente logice, aa ca clasele, interfeele i cooperrile.
New
Device

Nodurile (Node) reprezint un element fizic real al sistemului, care exist n timpul
funcionrii complexului de programe, i reprezint prin sine resurse de calcul, care de
obicei deine minimum un oarecare volum de memorie, dar mai des i posibilitatea de
prelucrare a informaiei. Grafic nodurile sunt reprezentate n form de cub, ce conine
doar numele.
Aceste apte elemente de baz clasele, interfeele, cooperrile, precedentele, clasele
active, componentele i nodurile sunt entitile principale, care pot fi incluse n
modelele UML. Exist diferite modificri ale acestor entiti de structuri: actori, semnale,
utilite, procese i fire, aplicaii, documente, fiiere, biblioteci, pagini i tabele.
Entitile de comportament (Behavioral things) sunt componente dinamice ale
limbajului UML i sunt verbe care descriu comportamentul modelului n timp i spaiu.
Exist doar dou tipuri de entiti de comportament: interaciunea i automatul.
Interaciunea (Interaction) reprezint comportamentul esena cruia const n
schimbul de mesaje (Messages) dintre obiecte n cadrul unui context concret, pentru
atingerea scopului dorit. Cu ajutorul interaciunii se poate descrie att o operaie aparte, ct
i comportamentul unui ansamblu de obiecte. Ea propune un alt set de elemente, aa ca
comunicarea, consecutivitatea faptelor i legturilor. Reprezentarea grafic a interaciunii
are forma unei sgei deasupra creia este scris numele operaiei corespunztoare .
Nu exista seria

Automatul (State machine) reprezint prin sine un algoritm de comportament, care


determin succesiunea strilor prin care trece obiectul sau interaciunea pe tot parcursul

ciclului de via. De asemenea pot fi i reacii de evenimente. Cu ajutorul automatului se


poate descrie comportamentul unei clase aparte sau a unui grup de clase. Ele au legturi i
cu alte elemente ca: starea, tranziii, evenimente i tipuri de aciuni. Grafic starea este
reprezentat printr-un dreptunghi cu muchiile rotungite ce conine numele i posibil
substarea.
Automatele i interaciunile sunt unicele entiti de comportament, care intr n
modelul limbajului UML. Schematic ele deseori sunt legate cu diferite elemente de
structur i n primul rnd cu clasele, cooperrile i cu obiectele.
Entitile de grup sunt prile organizatorice ale modelelor limbajului UML. Acestea
sunt blocurile pe care se bazeaz modelul. Exist numai o singur esen de grup i
anume Pachetele.
NewPackage

Pachetele (Packages) reprezint prin sine un mecanism universal de organizare a


elementelor n grup. Pachetul poate conine entiti de structur, de comportament chiar i
alte tipuri de entiti de grup. n comparaie cu alte elemente, care exist pe parcursul
lansrii programului, pachetul poart un caracter conceptual, adic exist numai n timpul
elaborrii. Exist i diferite variaii ale pachetelor de exemplu ca: carcasa (Frameworks),
modele i subsisteme.
Esene de adnotare reprezint un model de comentariu. El se folosete pentru
descrierea, explicarea sau pur i simplu pentru notie la orice element al modelului. Exist
numai un singur tip de baz de adnotare acesta e comentariul (Note).
Note

Comentariu pur i simplu reprezint un simbol de marcare a notielor sau a


restriciilor, anexate la un element sau un grup de elemente. Grafic comentariul este
reprezentat sub forma unui dreptunghi cu colul din partea dreapt de sus ndoiat n
interior.
Acest element este unica esen de notare care poate fi inclus n modelele UML. Cel
mai des comentariile se folosesc pentru a nsoi diagramele cu comentariu sau cu
restricii, care se poate de reprezentat prin text formal sau neformal. Exist variaii ale
acestui element, de exemplu cerinele, n care este descris comportamentul dorit din
punctul de vedere exterior al modelului.

Relaiile
n limbajul UML sunt definite patru tipuri de relaii:
1

Dependene

Asociaii

Generalizri

Realizri

Aceste relaii sunt unicele relaii ce leag blocurile de construcii n UML i se folosesc
pentru crearea modelelor corecte.
Dependenele (Dependency) reprezint o relaie semantic ntre dou entiti, n care
schimbarea uneia dintre ele poate s provoace schimbarea celei de-a doua esen
dependent. Grafic dependena este notat printr-o sgeat punctat .

Asociaiile (Association) reprezint o relaie structurat, care descrie un ansamblu de


legturi, iar prin legturi se subneleg legturile dintre obiecte. Exist i alte tipuri de
asociaii. Una din cele mai rspndite este Agregarea (Aggregation). Astfel se numete
relaia structurat dintre partea ntreag i prile ei componente. Reprezentarea grafic a
asociaiei este efectuat printr-o linie dreapt, cte o dat se poate termina cu o sgeat
fiind completat cu semnificaii specifice suplimentare, de exemplu, 0..1 arat
multiplicitatea, lucrtor, patron numele rolului i * arat c e patron.

Generalizrile (Generalization) reprezint un raport dintre specializare i


generalizare, adic cnd un obiect al unui element specializat (urma) poate nlocui un alt
element generalizat (printe). n aa mod urmaul (Child) motenete structura i
comportamentul printelui su (Parent). Grafic generalizarea este reprezentat printr-o
sgeat transparent i care indic spre printe .

Realizarea (Realization) reprezint un raport semantic dintre clasificatoare, unde un


clasificator determin contractul, iar altul asigur ,,ndeplinirea lui. Cel mai des
realizrile se ntlnesc n dou cazuri:
1.

ntre interfee i componentele care le realizeaz;

2.

ntre precedente i componentele care le realizeaz;

Grafic realizarea este descris sub form de o sgeat triunghiular transparent


ntrerupt .

Aceste patru relaii descrise mai sus sunt unicele tipuri de relaii pe care le putem folosi n
UML. ns mai exist i abateri referitor la aceste relaii, de exemplu: precizri (Refinement),
calea (Trace), includerea i lrgirea (pentru dependene).
Diagramele UML
n UML sunt diverse tipuri de diagrame de baz, care sunt necesare unui proiect, pentru a fi
neles din toate perspectivele. Astfel, cu ajutorul diagramelor noi crem modelul sistemului,
dnd de neles altora ce dorim s elaborm de fapt. Apoi dup construirea diagramelor folosim
un soft special pentru a genera codul din diagrame.
Diagramele n UML sunt reprezentrile grafice ale unui set de elemente, cel mai des
descriu legturile unui graf unde vrfurile sunt entitile, iar muchiile sunt relaiile. Diagramele
reprezint sisteme din mai multe puncte de vedere. n oarecare msur, diagrama reprezint una
din proieciile sistemului. Diagramele redau o imagine strns a elementelor din care este alctuit
sistemul. Unul i acelai element poate s fie prezent n orice diagram, sau aproape n toate, ori
de loc (foarte rar). Teoretic diagramele pot conine orice numr de combinaii de entiti i de
relaii. n practic sunt folosite comparativ o parte mic de diagrame, care alctuiesc arhitectura
sistemului.
UML permite elaborarea a cel puin nou tipuri de diagrame: diagrama claselor, obiectelor,
precedentelor, succesiunilor, interaciunii, de stare, de aciune, componentelor, de desfurare.
Limbajul UML nu e o simpl totalitate de rezolvri alternative. Concepia sa,difer
esenial de tehnologiile vechi. n loc s ilustreze prile izolate ale procesului, UML prefer
diagramele de nivel superior, ce permit de a ascunde detaliile i de a concentra atenia asupra
particularitilor funcionale i nu pe traiectoria aciunilor. Acest aspect permite de a crea la
nceput o impresie general asupra aplicaiei, apoi detaliile precezndu-le pe parcurs. Fiecare
diagram folosit n UML permite aprecierea proceselor sub unghiuri diferite.
Diagrama variantelor de utilizare prezint aciunile reciproce dintre variantele posibile de
utilizare i personaje sau sisteme. Diagramele reflect cerinele fa de sistem din punctul de
vedere al utilizatorului. n aa mod variantele de utilizare sunt funciile efectuate de sistem, iar
persoanele snt persoane cointeresate de sistemul elaborat. Diagrama arat c persoana iniiaz
varianta diagramei de utilizare. La fel din ea se vede c persoanele cointeresate primesc date de
la varianta de utilizare. Din diagrama variantelor de utilizare se poate afla mult informaie
coninut n sistem. Acest tip de diagrame descrie funcionarea sistemului la general, iar
utilizatorii, managerii proiectrii analitice, specialiti i toi cei cointeresai n sistemul dat pot s
neleag sistemul studiat.

Limbajul UML se bazeaz pe abordarea obiect-orientat i include diagrama claselor


pentru descrierea structurii si consistena modelului. Diagrama claselor este de baz pentru
formarea modelului aplicaiei i joac rolul principal n lucrul cu unele medii de dezvoltare.
Diagrama claselor i obiectelor descrie starea static a elementelor n sistem n fiecare moment
concret, arat structura obiectelor, atributele lor, legturile reciproce. Specialitii folosesc
diagrama claselor i obiectelor pentru a nelege cum pot include componentele date n codul lor.
Diagrama claselor i de stare (pentru sisteme n timp-real)

sunt foarte importante pentru

generarea codului.
Diagramele de aciune reflect fluxurile conductoare, care vin de la o aciune la alta.
Consecutivitatea i legturile reciproce oglindesc procesele interactive: se vd nu numai
obiectele i clasele ci i mesajele cu care comunic. n aa fel cu ajutorul sistemului se pot
modela situaii folosind tehnologia ce dac. Diagramele de stare

se utilizeaz pentru

descrierea obiectelor dinamice ce transmit i primesc mesaje. i diagramele componentelor i


amplasrii snt destinate pentru nchipuirea fizic a sistemului (inclusiv modulele folosite,
biblioteci i interfee).
Elaborarea diagramelor nc nu nseamn analiz i proiectare. Diagramele ne permit s
descriem comportamentul sistemului (pentru analiz) sau prezentarea detaliilor arhitecturale
(pentru proiectare).
Una din cele mai importante tendine n lumea UML este stereotipizarea. Aceast metod
permite extinderea vocabularului fundamental al UML. Utiliznd blocurile de construcie n
schema UML se poate obine un nou cod ce descrie procese concrete. Codul stereotipic se
folosete pentru identificarea fiierelor executabile i fizice, pentru crearea i distrugerea
exemplarelor claselor, pentru generarea programelor trigger, ce reacioneaz la apariia unui
eveniment. Programatorii pot lega pictogramele de stereotipurile pentru modificarea modelului
UML, innd cont de particularitile operaiilor specifice.
Pachetele instrumentale UML (spre exemplu Rational Rose) conin mijloace instrumentale
ce uor permit crearea modelelor UML i generarea codului n diferite limbaje de programare.
Majoritatea pachetelor arat informaia detaliat despre obiectul ales. E necesar numai un click
pe pictograma lui. Intrnd n comand, se observ setul de operaii ce se pot efectua asupra
obiectului i se observ diagrama de aciuni consecutiv. Limbajele de modelare servesc i
pentru proiectarea invers a sistemelor deja existente.
Deci, limbajul UML propune un set de instrumente, ce permit

analiza proiectelor

complexe din mai multe puncte de vedere, att din punct de vedere tehnic, ct i din punctul de
vedere al necesitii businessului. Limbajul dat simplific procesul de proiectare, micoreaz

cheltuielile i mrete eficiena. Concepia UML permite programatorilor s determine metodele


aplicaiilor complicate tehnic, care se vor efectua ntr-un mediu multinivel.

Analiza exemplului elaborrii modelelor serviciului bancar pentru clieni


(ATM)
Diagrama variantelor de utilizare (Use Case) - Diagrama ce descrie sistemul ca un tot
ntreg, integru.
Aici se conin actori (care execut anumite roluri, funcii) i precedente (funciile propriuzise ce pot fi obinute) i relaii dintre actori.
transfer

depozitare
schimbare PIN

ofiter bancar

client

decontare
plata

sis de credit

verificare bilant

Fig.1.3. Diagrama precedentelor pentru ATM


Aceast diagram arat interaciunea dintre precedentele i actorii unui sistem ATM
(Automated Teller Machine). Sgeata care vine de la precedent la un actor arat c precedentul
produce o informaie pe care o folosete actorul.
Analiznd diagrama precedentelor putem obine mult informaie. Utilizatorii, managerii de
proiect, analitii, inginerii ce asigur calitatea, orice persoan care este cointeresat n sistem ca
un ntreg poate analiza diagrama i nelege ce trebuie s realizeze sistemul.
Diagrama de activiti - descrie cursul functionalitii sistemului.
Poate fi folosit pentru a ilustra cursul evenimentelor printr-un precedent. Acest diagram
definete unde ncepe cursul lucrului i unde se sfrete, ce activiti au loc pe parcursul
lucrului, i n ce ordine au loc activitile.
obtine informatie
despre client

crearea unui
cont nou

setare limita de
credit

cont

revizuire istorie
de credit
cont
respins

cont
acceptat

semnare
documente

Fig.1.4. Diagrama de activiti pentru deschiderea unui cont

n aceast diagram putem observa cursul obiectelor. Cursul obiectelor ne arat ce obiecte
sunt folosite sau create de o activitate i cum obiectul i schimb starea parcurgnd cursul de
lucru. Liniile se numesc tranziii, ele arat modul n care o activitate pleac la alta n proces.
Dac este nevoie putem plasa mai multe detalii pe tranziii, descriind circumstanele sub
influena crora tranziia poate sau nu poate avea loc i ce aciune va fi luat n timpul tranziiei.
Nu e nevoie de creat diagrama de activiti pentru orice curs de lucru n parte, ele
(diagramele de activiti) fiind un puternic instrument de comunicare, n special n cursul de
lucru mare i complex.
Diagrama de secven - arat cursul funcionalitii ntr-un precedent. De exemplu,
precedentul decontare are cteva secvene posibile, decontare, ncercarea de a deconta fr bani
disponibili, ncercarea de a deconta cu PIN greit, i multe altele. Scenariul normal de decontare
a 20$ (fr nici o problem) este artat n fig.5.
client

card reader

ATM ecran

cont

emitator bani

accepta card
citeste nr card
initializare ecran
deschide cont
cere PIN
introduce PIN

verifica PIN

cere tranzactia
selectare tranzactie
cere suma
introduce cantitatea

decontare
verificar bani
extrage
distribuie cash
distribuie cec
scoatere card

Fig.1.5. Diagrama de secven


Aceast diagram de secven arat cursul procesrii ntr-un precedent Decontare. n
diagrama de sus sunt obiectele de care are nevoie sistemul pentru a realiza precedentul
Decontare. Fiecare sgeat reprezint un mesaj transmis ntre actori i obiect sau obiect i
obiect pentru a ndeplini funcionalitatea necesar. Utilizatorii pot vedea n aceste diagrame
specificul procesrii afacerii. Analitii vd cursul procesrii. Dezvoltatorii vd obiectele ce
trebuie create i operaiile pentru aceste obiecte. Inginerii ce asigur calitatea pot vedea
detaliile procesului i dezvolta teste pentru procesare.
Diagrama de colaborare - arat exact aceeai informaie ca i cea de secven. Totui,
Diagrama de colaborare arat aceast informaie n alt mod i cu un scop diferit. Diagrama
din fig.6 este o diagram de colaborare.

6: introduce PIN
9: selectare tranzactie
11: introduce cantitatea

client

ATM
ecran

5: cere PIN
8: cere tranzactia
10: cere suma

7: verifica PIN
12: decontare
13: verificar bani
14: extrage

3: initializare ecran
1: accepta card
2: citeste nr card

4: deschide cont
card
reader

cont

17: scoatere card

emitator
bani

15: distribuie cash


16: distribuie cec

Fig.1.6. Diagrama de colaborare pentru decontarea 20$ de pe cont


Diagrama claselor - arat interaciunea dintre clase n sistem. Clasele pot fi privite ca
nite prototipuri pentru obiecte. Clasele conin informaie i comportament care conduce cu
aceast informaie.
card reader
nr card

ATM ecran

acceptare card()
scoate card()
citeste card()

cere()
accepta intrarea()

cont
nr cont
PIN
bilant

emi tator bani


bilant cash

deschi de()
decontare()
scoate bani()
veri fica cont()

distribuie cash()
distribuie cec()

Fig.1.7. Diagrama claselor pentru sistemul ATM precedentul


Decontare bani
Liniile ce conecteaz clasele arat relaiile dintre ele. De exemplu, clasele Cont i ATM
ecran sunt conectate pentru c comunic direct ntre ele.
Dezvoltatorii folosesc diagramele claselor pentru a le dezvolta. Instrumente precum
Rational Rose genereaz scheletul codului pentru clase, dezvoltatorii introduc detaliile n
limbajul ales de ei. Analitii folosesc diagramele claselor pentru a arat detaliile sistemului.
Arhitecii se uit la diagramele claselor ca s neleag structura sistemului. Un arhitect cu
ajutorul diagramei claselor poate vedea dac aceasta conine prea mult informaie i poate
mpri functionalitatea n clase multiple.
Diagrama de stare - distribuie un mod de modelare variat a strilor n care un obiect se
poate afla. n timp ce diagrma claselor arat imaginea static a claselor i relaiilor dintre ele,

diagrama de stare este utilizat la modelarea comportamentului dinamic al sistemului. Aceste


tipuri de diagrame sunt folosite extensiv n construirea sistemelor n timp-real. Rational Rose
poate chiar genera codul ntreg pentru un sistem n timp-real din diagramele de stare.
O diagram de stare arat comportamentul unui obiect. De exemplu, un cont bancar
poate exista n cteva stri diferite. Un cont se poate comporta diferit cnd este n fiecare din
aceste stri.
decontare[ bilant<0 ]
deschide

cont gol

deposit[ bilant<0 ]

cerere de
inchidere a
clientului

verficare bilant[ bilant<0 pentru 30 zile ]

inchis

Fig.1.8. Diagrama de stare pentru clasa Cont


n aceast diagram putem observa strile n care se poate afla contul. Chiar putem
vedea cum contul trece dintr-o stare n alta. De exemplu cnd contul este deschis i clientul
cere nchiderea contului, contul trece n starea nchis. Cererea clientului este numit
eveniment, iar evenimentul este ceea ce cauzeaz tranziia.
Condiia din paranteze ptrate se numete condiie de gard i controleaz cnd o
tranziie poate sau nu poate avea loc.
De asemenea sunt dou stri speciale - starea nceput i starea sfirit.
Diagrama de stare se creaz numai pentru clase complexe. ns multe proiecte nu au
nevoie de astfel de diagrame.
Diagramele de stare sunt create doar pentru documentare.
Diagrama componentelor - arat viziunea fizic a modelului, adic componentele
software n sitem i relaiile dintre ele. Sunt dou tipuri de componente
executabile i biblioteci.
ATM .ex e

dis tribuitor c ash

c ard reader

distribuitor cash
ATM ecran
card reader

ATM ec ran

Fig.1.9. Diagrama componentelor pentru ATM client

n diagram:

Componentele haurate sunt numite corpul pachetului. Ele reprezint corpul fiierului
(.cpp) a clasei ATM ecran n C++. Componentele nehaurate sunt numite specificaia
pachetului. Specificaia reprezint fiierul antet (.h) n C++. Componenta ATM.exe este
numit specificaia sarcinii i reprezint un fir de execuie. n acest caz, firul de execuie este
programul executabil.
Componentele sunt unite prin sgei ntrerupte artnd relaiile de dependen dintre ele.
Diagramele componentelor sunt folosite de responsabilii de compilarea sistemului.
Diagramele indic ordinea n care componentele necesit a fi compilate.
Diagrama de amplasament arat schema fizic a reelei i unde vor fi amplasate
diferite componente variate. Aceast diagram este folosit de managerii de proiect,
utilizatori, arhiteci, i echipa de amplasament pentru a nelege amplasamentul fizic al
sistemului i unde vor fi amplasate variate subsisteme.
Toate aceste diagrame mpreun descriu sistemul din diferite perspective. Deci, aceste
diagrame sunt foarte importante n modelarea vizual a sistemelor.
UML este un limbaj foarte puternic dac este folosit de persoane, echipe bine
familiarizate cu el i cu modelarea vizual. Instrumente ca Rational Rose pot genera scheletul
codului proiectului sau invers poate genera diagramele din cod (Re-Engineering).
Pachetele instrumentale UML (spre exemplu Rational Rose) conin mijloace instrumentale
ce permit uor crearea modelelor UML i generarea codului n diferite limbaje de programare.
Majoritatea pachetelor arat informaia detaliat despre obiectul ales. E necesar numai un click
pe pictograma lui. Intrnd n comand, se observ setul de operaii ce se pot efectua asupra
obiectului i se observ diagrama de aciuni consecutiv. Limbajele de modelare servesc i
pentru proiectarea invers a sistemelor deja existente.
UML se dezvolt n continuu, de exemplu, n versiunea 1.3 s-au inclus o serie de
mbuntiri, la care se refer noile construcii semantice, citirea perfecionat a documentelor i
de asemenea susinerea interfeei XMI (XML Metadata Interchange). S-au exclus erorile
detectate anterior. Mai departe creatorii intenioneaz s propun interfee pentru tehnologiile
CORBA, Enterprise JavaBeans i XML, mijloace de control asupra versiunilor modelelor i
schimbul reciproc cu diagrame.
ntrebri de control:
1. Care sunt elementele componente ale tehnologiei proiectrii?
2. Descriei etapele elaborrii tradiionale ale produselor software.
3. Care sunt etapele metodologiei spiral?

4. Ce numim polimorfism?
5. Ce aduce nou limbajul UML?
6. Descriei principalele blocuri constructive din UML.
7. Caracterizai toate tipurile de diagrame folosite n UML.

LUCRAREA DE LABORATOR NR. 2


TEMA: Analiza sistemului n baza metodologiei APOO i elaborarea modelelor prin
diagramele cazurilor de utilizare n mediul Rational Rose i dezvoltarea lor n alte
diagrame
Scopul lucrrii:
1. Studierea prii teoretice i verificarea cunotinelor nsuite pentru modelarea sistemului
dat n mediul instrumentului CASE Rational Rose.
2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea,
destinaia elementelor i modelarea precedentelor cu use case diagram (cu perspectiva
dezvoltrii n Sequence i Collaboration) din Rational Rose.
3. Reprezentarea structurii sistemului real i analiza n baza metodologiei APOO (etapa
planificrii, sincronizrii, analizei), evideniind artefactele, precedentele pentru elaborarea
modelului conceptual din domeniul respectiv al sistemului.
4. nsuirea tehnicii de creare, modificare i salvare a respectivelor modele elaborate n
diagramele use case ale sistemului real-propus.
5. Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor din meniurile:
Browse, Create, Model Properties, TOOLS din Logical View, componentele i operaiile de
manipulare (generare, modificare i salvare a modelului).
6. Efectuarea diverselor manipulri n diagrama use case pentru evidenierea tehnicii
eficiente.
7. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n
procesul efecturii lucrrii de laborator.
8. Dezvoltarea elaborrilor cu alte diagrame (Sequence i Collaboration) pentru diverse
modele din domeniul IT n baza limbajului de modelare UML.
Sarcina: Pentru un sistem concret realizai cinci diagrame ale precedentelor.
Consideraii teoretice generale.
Descriere general
n ultimul timp o atenie deosebit i se acord alegerii metodologiei dezvoltrii soft-ului.
Cum arat experiena, fr o metodologie corect chiar i unele proiecte mici puin probabil pot

fi reuite. Astfel tot mai muli dezvoltatori, analiti i conductori de proiecte ncep s
contientizeze acest lucru.
Mai nti se formuleaz scopurile, fr care nu este posibil nici un proiect. Sarcina de baz
a oricrui proiect reuit const n aceea, ca la momentul pornirii sistemului i pe parcursul
ntregii perioade de exploatare s fie posibil de asigurat:
funcionalitatea necesar a sistemului i nivelul de adaptare la condiiile schimbtoare
ale funcionalitii lui;
permitivitatea (rata de transfer) necesar sistemului;
timpul de reacie necesar la cererea sistemului;
lucrul sistemului fr ntreruperi n regimul stabilit, adic: gradul de pregtire i
accesibilitatea sistemului la prelucrarea cererilor utilizatorilor;
simplitatea exploatrii i ntreinerii sistemului;
sigurana cerut.
Randamentul constituie factorul fundamental, care determin eficiena sistemului. O soluie
de proiect este baza sistemului de mare randament.
n condiii reale proiectarea sistemelor informaionale - este cutarea metodei, care asigur
funcionalitatea necesar a sistemului prin intermediul tehnologiilor, lundu-se n consideraie
restriciile date.
Prin metodologie de dezvoltare se subnelege un ansamblu de metode i criterii de
evaluare, care se folosesc pentru formularea sarcinii, planificarea, analiza i modelarea pentru
atingerea scopului necesar.
nceputul tradiional - n care se precizeaz informaii de baz despre proiect i despre acest
sistem.
1. Cercetarea domeniului de interes.
2. Analiza unde sunt prevzute cerinele, modelul logic (identificarea obiectelor i
dinamica legturilor) i static (determinarea detaliat a structurii fiecrui component).
3. Proiectarea generalizarea tuturor obiectelor i crearea claselor ce determin obiectele
date, modul de interaciune ntre clase prin intermediul diagramelor de clase.
4. Realizarea determinarea specificrilor, generarea codului n limbajul de programare
(C++, Delphi etc.).
5. Implementarea implementarea proiectului.
Un timp ndelungat procesul

de dezvoltare a Soft-ului se realiza n concordan cu

metodologiile, obinute n domeniul ingineresc - practica standard a crerii pe etape a


produsului, ncepnd cu ntocmirea specificaiior i finisnd cu livrarea la client. Exist standarde

(Rusia) i ISO (Europa, Rusia), CMM (Capabity Maturity Model - rspindit n SUA), care
reglementeaz procesul dat (de dezvoltare)
Modelul spiral al ciclului de via al sistemului - o atenie deosebit se acord etapelor
nceptoare de dezvoltare: elaborarea strategiei, analiza i proiectarea, unde realizarea unor sau
altor soluii tehnice se verific i se fundamenteaz prin intermediul crerii, modelrii
(prototiturilor, machetare). Fiecare cerc al spiralei presupune crearea unei versiuni a produsului
sau careva component a lui.
Modelarea vizual este metoda de percepere a diferitor probleme cu ajutorul abstraciilor
vizuale, care reproduc noiunile i obiectele lumii reale. Modelul servete drept un instrument
comod pentru analiza diferitor probleme, n privina schimbului de informaii ntre prile
cointeresate (utilizatorii, specialitii din domenii de interes, analitii, programatorii, e.t.c.), care
particip la proiectarea produselor soft, precum i la pregtirea documentaiei corespunztoare.
Modelarea conduce la asimilarea mai complet a cerinelor, ridicarea calitii arhitecturii
sistemului i a gradului de administrare a acestui sistem. Cu ajutorul modelului problema
propus poate fi simplificat, n rezultatul dezicerii de la detalii nesemnificative, adic
concentrrii asupra esenialului.
Capacitatea de abstractizare este proprietatea fundamental a intelectului uman, care
asigur nvingerea fenomenului de complexitate. Pentru a crea un sistem soft complex,
proprietile acestuia necesit abstractizare din diferite puncte de vedere. Cu ajutorul unui limbaj
de notaii determinat se realizeaz modelul, dup, care se revine la cerinele iniiale fa de
sistem, i se controleaz dac modelul corespunde acestor cerine. Dup aceasta modelul se
realizeaz practic, i n continuare se extinde cu funcii noi. Notaiile menionate nainte, sunt
necesare n orice model deoarece reprezint acele elemente care asigur unificarea proceselor.
Notaia realizeaz urmtoarele funcii:
joac rolul unui limbaj, folosit pentru descrierea concluziilor neevidente, care nu reies din
codul propriu-zis.
descrie semantica deciziilor strategice i tactice.
asigur o form de reprezentare, destul de concret pentru perceperea de ctre om, i
posibilitatea manipulrii acesteia prin intermediul instrumentelor.
Un astfel de limbaj este Unified Modeling Language, care cuprinde etapa analizei, ct i cea
de design. Unele elemente ale limbajului (clasele, asociaii i ierarhii de derivare) se folosesc n
procesul de analiz, iar altele (elemente de realizare i definirea proprietilor) se introduc n
perioada de proiectare.
Necesitatea i importana modelrii const n aceea c omul nu poate percepe o problem
complex concomitent. Modelarea permite o viziune general asupra relaiilor dintre

componentele proiectului ocolind necesitatea analizei proprietilor specifice fiecrui


component. n ajutor vine modelarea care permite, conceperea, organizarea, vizualizarea i
construirea celor mai complicate sisteme.
Determinarea i definirea scopului proiectului
O importan deosebit o are ntrebarea, care trebuie formulat naintea iniierii proiectului,
i aceast ntrebare nu atinge sfera metodologic i nici cea tehnic. La prima vedere pare
simplu. Pentru unele sisteme poate va fi, simplu, pentru celelalte ns formularea scopului
reprezint garania succesului, cci n caz contrar linia de via a proiectului nu va ncepe. Deci
ntrebarea sun astfel: Care sistem anume necesit a fi elaborat, i pentru cine?. Procesul
formulrii scopurilor viitorului sistem, mpreun cu definirea formei de reprezentare al acestuia,
ntocmesc faza ciclului de via a proiectului, care se sfrete cu declararea ce sun astfel:
Sistemul care necesit a fi proiectat, trebuie s ndeplineasc . n acest proces sunt implicai
nu numai, specialitii care particip la proiectare, dar i reprezentanii (consultaniipotenialii
utilizatori) din domeniul de interes pentru care se proiecteaz sistemul. Acetia ajut la analiza
specificului domeniului, potenialelor riscuri i avantaje. La nceputul fazei se formuleaz
problemele propuse spre rezolvare, i se disting diferite propuneri, unele din ele se accept. Deci
aciunile ntreprinse la aceast faz a elaborrii sistemului, pot purta caracter formal sau
neformal, dar ele totdeauna trebuie s prevad necesitile reale a businessului, resursele,
tehnologiile la moment, i dorinele utilizatorilor.
Rezultatul desfurrii eficiente a acestei faze servete la formularea strict a cerinelor fa
de calitile tehnologice ale sistemului i condiiile de exploatare.
Modelul sistemului
Un model este o abstractizare a unui sistem, ntr-un anumit context, pentru un scop bine
precizat. Un model capteaz conceptele relevante ale acelui sistem (din punct de vedere al
scopului pentru care a fost conceput), ignornd aspectele neeseniale. Conceptele definite se
numesc abstractizri, iar tehnica de identificare a acestor concepte se numete abstractizare. Aa
cum un sistem complex poate fi descompus n multiple subsisteme i fiecare subsistem poate fi
descompus n continuare, pn la elemente primitive (care nu mai pot fi descompuse), un model
al unui sistem poate fi, la rndul su structurat pe mai multe nivele, ca modele ale
subansamblelor componente.
Caracteristicile comportamentului sistemului se fixeaz i se documenteaz cu ajutorul
elementelor modelului, care definete funciile produsului (precedente dialog dintre actor i
sistem) accesibile utilizatorului, determin mediul sistemului (actorii interacioneaz direct cu

sistemul), i relaiile dintre precedente i actori (diagrama precedentelor). Fundamentele


modelului ncep nc de la etapa procesului elaborrii, cnd sunt obiectele active i precedentele,
apoi la etapa de planificare, modelul se dezvolt i se extinde prin adugarea unor elemente noi.
Modelul conceptual
La aceast etap poate fi vorba fie de un model unic, fie de un prim model dintr-un grup,
care s constituie punctul de pornire pentru modelele elaborate ulterior, prin modificarea unor
elemente sau prin includerea unor elemente noi. Modelul trebuie s reflecte esena sistemului
real, fr a include detalii inutile.
Precedentele, fiind unele din cele mai importante componente ale modelului conceptual,
iniial se deduc din formularea sarcinii, reieind din cerinele fa de sistem. Formal,
precedentele reprezint setul de tranzacii, efectuat de sistem, n scopul obinerii unui rezultat, i
acest rezultat este nu altceva dect ceea ce ateapt utilizatorul. La depistarea precedentelor sunt
utile astfel de ntrebri:

Ce fel de probleme trebuie s rezolve sistemul nostru?

Poate sau nu, utilizatorul, s vizualizeze, s salveze informaii din contextul sistemului?

Care sunt precedentele care garanteaz efectuarea operaiilor n privina informaiei, din
ntrebarea pus anterior?
La elaborarea unui sistem e necesar de a se ine cont de urmtoarele etape, prevzute

conform metodologiei APOO (analiza i proiectarea orientat - obiectual):


-

etapa de elaborare:
-

planificarea

sincronizarea

analiza

proiectarea

construirea

testarea

etapa de ntreinere:
-

nvarea

utilizarea

modificarea

reutilizarea

Etapa de ntreinere se parcurge doar dup implementarea sistemului, deaceea n lucrare se


va analiza (parcurge) doar etapa de elaborare.

Planificarea include evidenierea noiunilor, surselor iniiale ale domeniului de obiecte,


formularea cerinelor, obinerea schiei modelului conceptual.
Artefactele. Artefactele este denumirea simpl pentru diferite tipuri de informaii create,
schimbate de colaboratori la crearea sistemului. Drept exemple de artefacte pot servi diagramele
limbajului de unificare i modelare.
Se pot enumara 2 tipuri principale de artefacte tehnice i de conducere.
n timpul elaborrii programelor se creaz i artefacte de conducere. Unele artefacte de
conducere triesc un timp scurt, doar n timpul de via al proiectului. Din ele fac parte busness
planul, planul de elaborare, planul de selectare a cadrelor i mprirea tipurilor de activitate ale
angajatului n colaborare cu planul. Aceste artefacte se caracterizeaz ca text sau diagrame n
orice izvor de vizualizare necesare pentru explicarea cerinelor date echipei de elaborare i
oamenilor interesai. Artefactele de conducere la fel includ specificarea cilor de elaborare, a
programului pentru automatizarea procesului de elaborare a platformelor de calculatoare,
necesare pentru elaborarea i pstrarea artefactelor tehnice.
n fiecare caz al procesului raional unificat sunt artefacte care sunt date la intrare sau se
primesc la ieire. Artefactele se folosesc ca date de ieire pentru activitatea ulterioar, conin
date, dicionare despre proiecte i au rolul de primire a contractului de baz.
O parte din prezentrile arhitecturale sunt prezentrile modelelor precedentelor, ce sunt
necesare pentru arhitectura precedentelor. La ele se refer precedentele care descriu capacitatea
funcional important, ndeosebi se realizeaz cele mai importante cerine, sau una i alta.
Arhitectura unui sistem informaional include o interfa grafic i legatura cu bazele de
date n cteva nivele. Arhitectura unui sistem trebuie s posede urmtoarele caliti:

s prezinte prin sine un sistem abstract pe mai multe nivele de prezentare;

interfaa abstraciilor la orice nivel este restrns de la realizare, ns relizarea se poate

efectua fr a se schimba interfaa;

arhitectura s fie simpl: se folosesc abstracii, mecanisme comune etc.


Elaborarea sistemului trebuie s fie iterativ, elaborarea iterativ reprezint modificarea

multipl a sistemului n decursul cruia el se mbuntete la orice etap. Cerinele fa de


sistem pot rmne neschimbate pentru cteva cicluri, dar pot fi i concretizate de la un ciclu la
altul. n procesul iterativ de elaborare se mresc posibilitile funcionale ale sistemului, fiecare
din versiunile lui realiznd noi i noi funcii.

Specificarea cerinelor pentru realizarea proiectului :


1. Utiliznd APOO e necesar s se modeleze un sistem de calcul i anume fazele:
pregtirea sistemului de lucru i ndeplinirea de ctre sistem a unei comenzi.
2. Proiectul va fi modelat prin intermediul limbajului UML.
3. Proiectul e necesar s fie fiabil, flexibil i eficient (s permit cu uurin efectuarea
modificrilor).
Analiza cerinelor i modelarea sistemului. Programul unui sistem elaborat, se bazeaz
pe un ansamblu de caracteristici care sunt identificate din discuiile dintre clieni, utilizatorii
finali, experii domeniului aplicaiei, personalul de la nivelul conducerii i echipa de dezvoltare
a software-ului. Aceste condiii sau sarcini care trebuie ndeplinite de ctre sistem sunt cunoscute
sub denumirea de cerine.
Pentru a determina i formula cerinele se contacteaz toate categoriile de persoane
interesate de programul respectiv, se organizeaz grupuri de discuii, se analizeaz obiectivele
organizaiilor implicate, se trimit chestionare, se analizeaz diverse documente. Utilizarea unui
prototip al produsului poate oferi o alt perspectiv asupra aplicaiei, att pentru partea care
comand software-ul, ct i pentru cea care particip la dezvoltare. Important este c analitii
descoper nevoile reale ale clienilor i elaboreaz o specificaie a cerinelor utilizatorilor. Acest
lucru este posibil numai lucrnd ntr-o manier iterativ i coopernd strns cu toate persoanele
care pot constitui surse de informaii legate de diagrama respectiv.
Faza de analiz. Aceast faz definete cerinele sistemului, independent de modul n care
acestea vor fi ndeplinite. Aici se definete problema pe care clientul dorete s o rezolve.
Rezultatul acestei faze este documentul cerinelor, care trebuie s precizeze clar ce trebuie
construit.
Documentul red cerinele din perspectiva clientului, definind scopurile i interaciunile la
un nivel descriptiv nalt, independent de detaliile de implementare, cum ar fi, de exemplu:
formularea problemei, ateptrile clientului sau criteriile pe care trebuie s le ndeplineasc
produsul. Hotarul dintre descrierile de nivel nalt i cele de nivel sczut nu este foarte bine trasat.
Uneori, dac un detaliu tehnic important trebuie specificat, el va aprea n document. Totui,
aceasta trebuie s fie excepie i nu regul. Aceste excepii pot fi determinate de necesitatea
meninerii compatibilitii cu alte sisteme deja existente, sau a unor anumite opiuni dorite de
client, de exemplu utilizarea unui anumit standard sau o constrngere asupra dimensiunilor
imaginii aplicaiei, care poate fi destinat unei categorii speciale de utilizatori sau care va rula pe
nite sisteme cu o serie de particulariti (monitoare care nu suport rezoluii mari).

Faza de analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre detaliile de nivel
nalt i cele de nivel sczut sunt puse mai bine n eviden de abordrile top-down (unde se
merge ctre detaliile de nivel sczut) i bottom-up (care tind ctre detaliile de nivel nalt).
Documentul cerinelor poate fi realizat ntr-o manier formal, bazat pe logic
matematic, sau poate fi exprimat n limbaj natural. n mod tradiional, el descrie obiectele din
sistem i aciunile care pot fi realizate cu ajutorul obiectelor. Aici noiunea de obiect nu trebuie
confundat cu obiectul din programarea orientat obiect. Descrierea obiectelor i aciunilor
trebuie s fie general i s nu depind de o anumit tehnologie. Desigur, ntr-o abordare POO,
descrierile vor lua forma obiectelor i metodelor, ns n alte abordri, obiectele pot fi de
exemplu servicii care acceseaz baze de date.
n general, documentul cerinelor descrie ontologia proiectului, adic vocabularul de
cuvinte cheie (n special construcii substantivale i verbale) care va fi utilizat pentru definirea
protocolului specific aplicaiei. Descrierile acestea nu implic proiectarea arhitecturii aplicaiei,
ci enumerarea prilor componente i a modului n care acestea se comport. Mai trziu, n faza
de proiectare, acestea vor fi transformate n primitive informatice, precum liste, stive, arbori,
grafuri, algoritmi i structuri de date.
Mai concret, documentul trebuie s conin descrieri pentru urmtoarele categorii:
1. Obiecte: Documentul trebuie s defineasc mai nti ontologia sistemului, care este bazat n
mare parte pe construcii substantivale pentru identificarea pieselor, prilor componente,
constantelor, numelor i a relaiilor dintre acestea;
2. Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care trebuie s le
ndeplineasc sistemul i care sunt sugerate n general de construcii verbale. Exemple de
aciuni sunt: metodele, funciile sau procedurile;
3. Stri: Sunt definite ca mulimi de setri i valori care separ sistemul n dou ipostaze spaiotemporale. Fiecare sistem trece printr-o serie de schimbri de stare. Exemple de stri sunt:
starea iniial, cea final sau strile de eroare. Cele mai multe stri depind de domeniul
problemei. Strile sunt asociate cu obiectele sistemului. Un eveniment declaneaz o tranziie
de stare care poate conduce la ndeplinirea unei aciuni de ctre sistem;
4. Scenarii tipice: Un scenariu este o secven de pai urmai pentru ndeplinirea unui scop.
Cnd sistemul este terminat i aplicaia este disponibil, clientul trebuie s poat utiliza, ntr-o
manier ct mai facil i clar specificat, toate scenariile tipice ale aplicaiei. Scenariile tipice
trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei. Ponderea acestora
variaz de la un sistem la altul, dar 90% se consider o proporie acceptabil. Bineneles c
un sistem cu un singur scenariu de utilizare este relativ simplu de obinut, pe cnd unul cu mii
de scenarii posibile va fi mult mai dificil de analizat. Deseori este invocat regula 80/20:

80% din funcionalitatea sistemului se realizeaz cu 20% din efortul de munc. Executarea
restului minoritar de funcionalitate necesit marea majoritate a timpului de lucru;
5. Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem numai n cazuri
speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut este un eveniment
atipic. Totui, sistemul trebuie s gestioneze un numr ct mai mare de categorii de erori, prin
tehnici stabilite, precum tratarea excepiilor, monitorizarea proceselor etc.;
6. Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentru toate
situaiile care pot aprea n condiii de lucru reale nu este posibil. n logica tradiional, o
teorie este definit de o mulime finit de axiome. Teoremele din teoria respectiv sunt
propoziii adevrate. Dac se adaug ulterior noi axiome, teoremele existente rmn valide iar
noile teoreme dezvoltate sunt adugate teoremelor stabilite. n logica nemonoton, adugarea
de noi axiome poate invalida unele teoreme care au fost demonstrate anterior. O nou teorie
nu mai este o simpl extensie a teoriei vechi, ci o mulime de teoreme noi, mpreun cu o
parte din teoremele vechi. Procesul de stabilire a cerinelor are o natur iterativ i
nemonoton. Mulimea iniial de cerine (axiomele) definete posibilitile (teoremele)
sistemului. Noile cerine pot infirma soluiile vechi. Pe msur ce un sistem crete n
dimensiuni i complexitate, stabilirea cerinelor devine din ce n ce mai dificil, mai ales cnd
procesul de colectare a cerinelor este distribuit, fiind realizat de indivizi cu specializri
diferite.
Precedente. Pentru asigurarea eficienei elaborrii procesul trebuie s fie bazat pe analiza
precedentelor. Precedentul poate fi o descriere sau un caz de utilizare (use case) al sistemului.
Principalele artefacte pentru reformularea precedentelor sunt:
-

reformularea general a problemei;

determinarea utilizatorilor (consumatorilor) sistemului;

definirea scopului;

funciile sistemului;

atributele sistemului etc.

Exist dou tipuri de precedente:


-

Precedente ideale (essential use-case) - ele exprim o entitate general a procesului


fr detalierea realizrii lor.

Precedente reale (real use-case) - descrie concret procesul n termeni de soluii reale,
n baza tehnologiilor concrete de introducere i afiare a informaiei.

Precedentele reprezint consecutivitatea aciunilor pe care le efectueaz actorul n


concordan cu sistemul pentru a cpta un anumit rezultat. Precedentele sunt reprezentate sub
form de elips. Denumirea precedentului poate fi amplasat n interiorul elipsei sau sub ea.

UML prevede i existena de legturi ntre diferite cazuri de utilizare - extensia, generalizarea i
incluziunea.
Diagramele cazurilor de utilizare (Use case diagram, prezentare)
Diagrama variantelor de utilizare reprezint partea nceptoare de la care se ncepe
modelarea unui sistem nou. Aici se reflect aciunile reciproce dintre variantele posibile de
utilizare i persoanele cointeresate sau sisteme. Diagrama reflect cerinele ctre sistem din
punctul de vedere al utilizatorului. Variantele de utilizare sunt funciile efectuate de sistem.
Avantajul principal al variantelor de utilizare este c folosindu-le separm implementarea
sistemului de descrierea funciilor sale. Acest fapt ajut la concentrarea ateniei la aa ntrebri
precum satisfacerea cerinelor sistemului fr a fi nevoie de a defini modul cum sistemul va fi
implementat. Diagramele variantelor de utilizare ne demonstreaz ce va face sistemul i cum
poate fi utilizat nc la nceputul proiectului.
Metoda diagramelor variantelor de utilizare nu este cea standard i difer de ea foarte mult.
Separnd proiectul n diagramele variantelor noi atragem atenia mai mult asupra procesului de
percepere a sistemului, nu i felului de implementare a lui. Decompoziia funcional are ca scop
divizarea poiectului n subprobleme cu care se va confrunta sistemul, apoi diagramele variantelor
de utilizare concentreaz atenia asupra aspiraiilor utilizatorului ctre sistem.
La nceputul oricrui proiect apare ntrebarea: Care sunt variantele de utilizare pentru
proiectul dat?. Este preferabil de citit atent documentaia clientului, luai n vedere opinia
oricrui utilizator care va folosi acest sistem. Este bine s obinei rspunsuri la urmtoarele
ntrebri de la fiecare din viitorii utilizatori ai sistemului:
1

Ce vrea s fac cu sistemul?

Va lucra cu informaie (introducere, tergere, etc)?

Va fi nevoie de a informa sistemul despre careva evenimente din afar?

Va fi nevoie ca sistemul s informeze utilizatorul despre careva evenimente?

Setul de variante de utilizare creat ajut la familiarizarea utilizatorilor cu funciile


sistemului la nivelul cel mai general, de aceea dac numrul lor este foarte mare elasticitatea i
uurina de percepere se pierde; de obicei un proiect are 20-50 de variante de utilizare. Pentru a
organiza schema mai bine variantele de utilizare pot fi adunate n pachete.
Variantele de utilizare atrag atenia asupra cererilor utilizatorilor ctre sistem. Fiecare
variant de utilizare prezint o tranzacie terminat ntre utilizator i sistem. Denumirile
variantelor de utilizare trebuie s fie alese din sfera de utilizare a sistemului, nu i din cea

tehnic, prin aceasta se ajunge la o mai bun nelegere a sistemului de ctre utilizatori. De obicei
variantele de utilizare sunt numite folosind verbe care descriu rezultatul tranzaciei respective.
Utilizatorul nu este curios s tie cum se va face una sau alt varianta de utilizare, pe el l
intereseaz doar rezultatul final al tranzaciei.
Pentru a fi sigur c orice variant de utilizare este prezent n modelul respectiv este
necesar de a:
1. controla ca orice cerin funcional s fie prezent cel puin ntr-o variant de
utilizare;
2. lua n consideraie cum va interaciona cu sistemul oricare din utilizatorii finali;
3. cunoate ce fel de informaie va introduce/scoate din sistem utilizatorii;
4. ti cine va porni/opri sistemul dat;
5. specifica toate sistemele din afar cu care va interaciona sistemul dat i ce fel de
informaie va fi trimis ntre ele.
O diagram a cazurilor de utilizare prezint o colecie de cazuri de utilizare i actori i este
folosit n general pentru a indica sau caracteriza funcionalitile i comportamentul ntregii
aplicaii a sistemului interacionnd cu unul sau mai muli actori. Utilizatorii i orice sistem ce
poate interaciona cu sistemul sunt actorii.
Atta timp ce actorii reprezint utilizatorii, ei ajut la delimitarea sistemului i ofer o
imagine clar a ceea ce se ateapt a se ntmpla n sistem. Cazurile de utilizare sunt construite pe
baza nevoilor pe care le au actorii (utilizatorii). Aceasta asigur faptul c sistemul va produce
ceea ce s-a dorit.
Diagramele cazurilor de utilizare conin elemente ce pot reprezenta actori, relaii de
asociere, relaii de generalizare, pachete i cazuri de utilizare. Se poate crea o diagram a
cazurilor de utilizare de nivel nalt, pentru a vizualiza limitele i comportamentul sistemului. De
asemenea, se pot crea una sau mai multe diagrame pentru a descrie o parte a aplicaiei
sistemului. Cazurile de utilizare pot include alte cazuri de utilizare ca o parte a comportamentului
su. O diagram a cazurilor de utilizare indic un set de actori externi i cazurile de utilizare ale
sistemului n care particip respectivii actori.
Cazuri de utilizare. Un caz de utilizare este o secven a tranzaciilor realizate de sistem
ca rspuns la evenimentele declanate de un actor al sistemului. Un caz de utilizare complet
trebuie s ofere o valoare msurabil unui actor, cnd actorul execut o sarcin anume. Un caz de
utilizare conine toate evenimentele care pot surveni n cadrul perechii actor - caz de utilizare, nu
neaparat unul ce va aparea n orice scenariu particular. Un caz de utilizare conine un set de
scenarii care explic diferitele secvene ale interaciunii din interiorul tranzaciei.

Un caz de utilizare poate de asemenea descrie comportamentul unui set de obiecte, ca de


exemplu o organizaie.
Reprezentarea grafic. Forma de baz a cazului de utilizare este o elips:

Un caz de utilizare poate avea un nume, care este caracteristic i nu un nume simplu.
Adesea este scris ca o descriere informativ a actorilor externi i a secvenelor evenimentelor
dintre obiecte care acoper tranzacia. Numele unui studiu de caz ncepe de obicei cu un verb.
Fiecare apariie a unui caz de utilizare n diagram indic un subset de informaii ale
modelului despre cazul de utilizare; toate aceste informaii ale modelului pot fi vizualizate n
specificaiile cazului de utilizare.
n diagramele cazurilor de utilizare se pot desena asocieri ntre cazuri de utilizare i actori,
respectiv generalizri ntre cazuri de utilizare.
Actori. Un actor este un stereotip al unei clase. Utilizatorii i orice sistem care poate
interaciona cu sistemul n cauz sunt actori. Astfel, un actor reprezint un rol jucat de o persoan
sau o entitate care interacioneaz cu sistemul.
Cum actorii reprezint utlizatorii sistemului, ei ajuta la delimitarea sistemului i ofer
claritate n ceea ce se va ntmpla n respectivul sistem.
Aceeai persoan fizic poate juca rolul mai multor actori, aa cum mai multe persoane pot
juca acelai rol, i astfel interaciona ca acelai actor.
Reprezentarea grafic. Actorii se reprezint sub forma unor mici personaje avnd propriul su
nume ca n figura:

Fiecare actor trebuie s aib un nume, iar numele acestuia descrie rolul jucat de ctre actor.
Exist trei tipuri primare de actori:
- utilizatorii sistemului - o persoan fizic, sau un utilizator. Aceti actori fiind cel
mai des utilizai, sunt prezeni n orice sistem. Un individ poate avea mai multe roluri,
de exemplu o persoan poate fi reprezentant al serviciului i n acelai timp client.
Utiliznd ca denumire a actorului rolul su vom obine o imagine mai stabil a actorilor
deoarece poziia se schimb n timp, iar rolurile trec de la o poziie la alta i nu va
aprea n viitor necesitatea de modificare a modelului.

- sisteme ce interacioneaz cu sistemul dat . De exemplu un sistem de rezervare a


biletelor va interaciona cu alt sistem de validare a cartelelor de credit. n acest caz
sistemul de validare a cartelelor de credit este un actor. El este alt sistem care nu va
necesita modificri, deci el se afl n afara proiectului dat, dar necesit interaciunea cu
sitemul nostru.
- timpul, care devine actor cnd la expirarea unei poriuni de timp vor avea loc
unele evenimente n sistem. De exemplu n sistemul de rezervare a biletelor exist
posibilitatea de a ctiga un bilet gratis. n fiecare zi la o or anumit sistemul
selecteaz automat un client ctigtor al biletului dat. Deoarece timpul se afl n afara
controlului nostru el este un actor.
n diagrama cazurilor de utilizare se pot desena asocieri de la actor la cazul de utilizare sau
generalizri ntre actori:
- reprezint asocierea unidirecional care presupune o legatur ntre obiecte
-

reprezint agregarea ce arat prile componente ale unui ntreg.

Asocieri. Definiie: O asociere reprezint o conexiune semantic ntre cazurile de utilizare


i actori. Asocierile sunt unidirecionale; ele sunt relaiile cele mai generale i cele mai slabe din
punct de vedere semantic.
Reprezentarea grafic: Asocierile se reprezint printr-o linie plasat ntre entitile de
asociat:

Numele asocierilor. O asociere poate avea nume i un stereotip care sa identifice tipul sau
semnificaia relaiei.
Relaiile de asociere se pot desena ntre cazuri de utilizare i actori. Fiecare apariie a unei
asocieri n diagram etaleaz un set de informaii ale modelului despre relaia de asociere n
cauz, aceste informaii fiind cuprinse n sp.
Generalizare. O generalizare ntre dou cazuri de utilizare indic faptul c cazul de
utilizare poate mprti comportamentul definit n unul sau mai multe cazuri de utilizare.
Deasemenea, generalizarea suport utilizatori i extinde stereotipuri.
O generalizare ntre actori arat c un actor motenete structura i comportamentul unui
actor sau mai multor actori.

Reprezentarea grafic:
Generalizarea se reprezint printr-o sgeat ce leag dou elemente (cazuri de utilizare i
actori):

Se folosete numele relaiei i a stereotipului pentru a identifica tipul sau semnficaiile


relaiei respective.
Relaia de generalizare de la cazul B spre A indic faptul c B este o specializare a lui A.
Notaia grafic de realizare cu ajutorul simbolului standart de generalizare.

Un exemplu de generalizare ntre cazurile de utilizare

Inchiere asigurare viata

Inchiere asigurare auto

Inchiere asigurare

Cazul de utilizare specializat trebuie s utilizeze n totalitate i cazul de utilizare mai


general, chiar dac ntr-o ordine n care aciunile celor dou se ntreptrund. Ca i pentru clase
exist i alte posibiliti de a defini i alte cazuri de utilizare abstracte. Spre exemplu, ncheierea
de asigurri pe via i de asigurri auto poate fi generalizat n cazul de utilizare ,,ncheiere
asigurare.
Cu ajutorul relaiei de generalizare noi accentum faptul c mai muli actori au caliti
comune. De exemplu clienii pot fi de dou tipuri: persoane fizice i persoane juridice.
De obicei acest tip de relaii este util cnd comportamentul unui tip de actori difer de cel a
altui tip ntr-aa fel nct cauzeaz aciunile sistemului. De exemplu dac un tip de actori poate
iniializa un fel de variant de utilizare, iar al doilea nu poate, atunci este bine s introducem
ambele tipuri ca fiind generalizri a unui tip comun. ns dac tipul A i tipul B iniializeaz
aceleai variante de utilizare cu mici diferene este mai preferabil s nu crem dou tipuri de
actori generalizai, ci s implementm prelucrarea n fluxul de evenimente a variantei de
utilizare.

Se pot desena relaii de generalizare ntre cazuri de utilizare i actori. Apariia unei
generalizri n cadrul unei diagrame indic un set de informaii ale modelului despre relaia de
generalizare. Aceste informaii reprezint specificaiile generalizrii.
Precedentele reprezint consecutivitatea aciunilor pe care le efectueaz actorul n
concordan cu sistemul pentru a cpta un anumit rezultat. Precedentele sunt reprezentate sub
form de elips. Denumirea precedentului poate fi amplasat n interiorul elipsei sau sub ea.
UML prevede i existena de legturi dintre diferite cazuri de utilizare extensia (se reprezint
printr-o sgeata trasat cu linie ntrerupt, notat cu cuvntul rezervat extensie). O relaie de
extensie cuprinde o condiie de autorizare i referine la unul sau mai multe puncte de extensie
din CU destinaie, n care extensia poate fi inserat. Extensia mai permite adugarea de cazuri de
utilizare aprute ulterior, n cursul dezvoltrii sistemului. Ca exemplu: s presupunem un market.
Personalul nu este obligat s prezinte fiecrui client catalogul mrfurile propuse spre vnzare.
Rezult o extindere a funciilor acordate de ctre personal; generalizarea (de la cazul B spre
cazul A, indic faptul c B este o specializare a lui A). Notaia grafic se realizeaz cu ajutorul
simbolului standard de generalizare. Ca exemplu poate servi o bibliotec electronic, avem
nevoie de o carte i dm la cutare. Prin intermediul relaiei de generalizare noi putem s cutam
prin mai multe moduri: dup numele autorului, fie dup denumirea crii, sau chiar dup ambele
mpreun. Cu alte cuvinte relaia de generalizare este o relaie de motenire i incluziunea (indic
faptul c o instan a unui caz de utilizare cuprinde i comportamentul specificat printr-un alt caz
de utilizare). Notaia grafic este folosit cea pentru extensie, etichetat ns cu cuvntul rezervat
include. Pentru acelai exemplu de mai sus: vnztorii sunt obligai s primeasc taxa de la
cumprtori, aceasta ar fi una din obligaiuni, rezult c acest serviciu este obligator inclus n
serviciile marketului.
Limbajul UML presupune un numr de legturi ntre actori i variante de utilizare. Aceste
legturi sunt de comunicaie (communication), de utilizare (uses), de extindere (extends) i de
generalizare (actor generalization). Legturile de comunicaie descriu legturile ntre actori i
variantele de utilizare. Cele de utilizare i de extindere numai ntre variantele de utilizare, iar
cele de generalizare ntre actori.
Legturi de comunicaie. Este legtura ntre un actor i o variant de utilizare. n limbajul
UML este prezentat sub forma unei sgei:

Direcia sgeii indic pe cel care a iniializat comunicaia.

Legturi de utilizare. O legtur de utilizare (Uses relationship) ofer posibilitatea ca o


variant de utilizare s folosesc funcionalitatea altei variante de utilizare. Cu ajutorul acestei
legturi se modeleaz comportamentul care se ntlnete n mai multe variante de utilizare.
Legtura de utilizare n limbajul UML este prezentat cu ajutorul unei sgei i a cuvntului
<<uses>>
Legturi de extindere. Legturi de extindere (Extends relations) sunt asemntoare celor
de utilizare, ns varianta concret de utilizare poate s nu foloseasc funcionalitatea variantei
de utilizare abstracte cu care este legat prin legtura de extindere. n limbajul UML astfel de
relaii se reprezint printr-o sgeat cu cuvntul <<extends>>
Relaiile ntre cazuri de utilizare
Extensia. O relaie de extensie arat c un caz de utilizare poate fi extins cu un
comportament adiional diferit, ntr-un alt caz de utilizare. O relaie de extensie cuprinde o
condiie de autorizare, referine i unul sau mai multe puncte de extensie din cazul de utilizare al
destinaiei, n care extensia poate fi inserat.

Client

Comanda produs

Livreaza produs

<<extend>>

Mai sus avem prezentat un caz de utilizare care poate extinde un alt caz de utilizare.
Extensia se reprezint printr-o sgeat trasat cu linie ntrerupt, notat cu cuvntul rezervat
<<extensie>>. Spre exemplu cazul de utilizare ,,Comand produs poate fi extins cu ,,Livreaz
produs, condiia ce autorizeaz extensia fiind existena produsului respectiv n stoc.
Prin relaiile de extensie pot fi introduse, sub form de cazuri de utilizare distincte,
prelucrri ce constituie excepii n utilizarea cazurilor de utilizare de baz. Spre exemplu,
preluarea (telefonic) de comenzi de vnzare pe baz de catalog poate fi nsoit de prelucrri
legate de clientul care face comanda: nregistrarea unui client nou, dac acesta este la prima
comand sau modificarea datelor personale, cum ar fi adresa sau numrul de telefon.

<<extend>>

Modificarea date client

Inregistrare client nou


<<extend>>

Functionar
comercial

Preluarea comanda

Fig.2.1. Diagrama cazurilor de utilizare pentru varianta de utilizare ,,Preluare comand

Cazul de utilizare ,,Preluare comand poate fi extins prin alte dou cazuri de utilizare:
,,nregistrarea clientului nou i ,,Modificarea datelor client. Extensia mai permite adugarea
cazurilor de utilizare aprute ulterior n cursul dezvoltrii sistemului.
Incluziunea Relaia de incluziune indic faptul c o instan a unui caz de utilizare cuprinde
i comportamentul specificat printr-un alt caz de utilizare.
Sistem Bancomat

Retragerea numerar
<<include>>
Client

Consultare sold

Fig.2.2. Diagrama cazurilor de utilizare pentru cazul de utilizare,,Retrage numerar


Cazul de utilizare ,,Retrage numerar include i cazul de utilizare, Consultare sold.
Notaia grafic este cea folosit pentru extensie, ns eticheta este cuvntul rezervat <<include>>.
Revenind la exemplul referitor la operaiile cu numerar din bancomat, un client poate solicita fie
o retragere de numerar fie o consultare a soldului contului respectiv. Retragerea include i
consultarea soldului (rmas dup efectuarea retragerii). n consecin ntre cele dou cazuri de
utilizare exist o relaie de incluziune ceea ce este artat n figura de mai sus.
Figura de mai jos prezint un alt exemplu de relaii de includere ntre cazurile de utilizare:
livrarea produselor comandate include expedierea produselor i emiterea facturii.

Expedierea produs

Facturare

<<include>>
<<include>>

Livrare produse

Functionar
comercial

Fig.2.3. Diagrama cazurilor de utilizare pentru cazul de utilizare Livrarea produselor


Relaiile de extindere i de includere ocazionate de vnzarea produselor.
Notele. Definiie: O not cuprinde ipotezele i deciziile aplicate n timpul analizei i a
reprezentrii grafice. Notele pot conine orice informaie, inclusiv textul planului, fragmente de

cod sau referine la alt document. O not conine un volum nelimitat de text. n consecin notele
pot fi dimensionate.
Notele se comport ca nite etichete. Ele se pot folosi n orice tip de diagram. Notele sunt
doar explicaii oferite acolo unde apar n diagram. Ele nu sunt considerate c fac parte din
model. Ele pot fi terse ca orice alt component a diagramei.
ancora notei
Ancora notei conecteaz o not la un element pe care l simuleaz. Aceste elemete pot lega
o not de un element sau mai multe elemente ale diagramei respective.
O not poate sa nu fie conectat, caz n care aceasta se refer la ntreaga diagram.
Reprezentarea grafic
Forma grafic a unei note este un dreptungi care are un col ndoit :

n diagram dac nota d explicaii unor anumite elemente, atunci folosim i ancore ale
notei care se reprezint printr-o linie punctat ce face legatura dintre element i not :

Elaborarea Diagramelor USE-CASE


Lucrul asupra proiectului n mediul Rational Rose ncepe cu analiza general a problemei
puse, apoi se construiete diagrama variantelor, USE-CASE. Diagramele cazurilor de utilizare au
rolul de a reprezenta ntr-o form grafic funcionalitile pe care trebuie s le ndeplineasc
sistemul informatic n faza sa final. USE-CASE reprezint o mulime de secvene de activiti
(inclusive variantele), ndeplinite de sistem cu scopul ca actorul s primeasc un rezultat bine
determinat. Actorul reprezint o mulime de roluri logic legate, jucate de diverse persoane sau
sisteme informatice i care interacioneaz cu sistemul informatic aflat n dezvoltare. Cazurile de
utilizare reprezint secvene de tranziie ce au loc n dialogul cu sistemul i care sunt nrudite din
punct de vedere comportamental. Un caz de utilizare modeleaz un dialog ntre un actor i
mulimea de cazuri de utilizare a unui sistem, reprezint toate modalitile n care sistemul poate
fi folosit. Sistemul nostru de analiz a microprocesorului va avea urmtoarele diagrame UseCase. Deci Use-Case reprezint contractul ntre sistem i actori.

Fig.2.4. Diagrama cazurilor de utilizare pentru un sistem de control al accesului

Fig.2.5. Diagrama cazurilor de utilizare pentru viramentul prin serviciul Internet


Deci diagrama Use Case reprezint interaciunea dintre cazurile de utilizare, care
sunt funcii ale sistemului i persoanele acestui sistem. Adic sunt reprezentai oameni
sau sisteme, care primesc sau transmit informaia n sistemul dat. n diagram sunt
prezente aciunile reciproce dintre variantele de utilizare i persoanele acestui sistem.
Astfel variantele de utilizare sunt funcii efectuate de sistem, iar persoanele sunt
persoane cointeresate n sistemul elaborat. Diagrama prezint care persoan iniiaz
sistemul i cnd persoanele cointeresate primesc datele necesare.
Cu alte cuvinte diagrama Use Case ilustreaz modul de utilizare a sistemului de ctre
actor, i reprezint secvene de tranzacii ce au loc n dialog cu sistemul i care sunt nrudite
din punct de vedere comportamental. Mulimea de cazuri de utilizare a unui sistem reprezint
toate modalitile n care sistemul dat poate fi utilizat.
Use Case (Cazurile de Utilizare) i actorii definesc scopurile sistemului dat.
Cazurile de utilizare includ

toate evenimentele din sistem, iar actorii includ toate

componentele externe sistemului dat.

Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor


Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor din meniurile:
Browse, Create, Model Properties, TOOLS din Logical View, componentele i operaiile de
manipulare (generare, modificare i salvare a modelului).
Meniul:

Browse.
Browser-ul este un instrument de navigare ierarhic care d posibilitatea de a vedea
pictogramele interaciunilor, claselor, variantelor de utilizare, activitilor, strilor, ct i altor
elemente ale modelului.
Use Case Diagram afieaz diagrama cazurilor de utilizare
Class Diagram afieaz diagrama claselor
Component Diagram afieaz diagrama componentelor
Deployment Diagram afieaz diagrama exploatrii
Interaction Diagram afieaz diagrama interaciunilor
State Machine Diagram afieaz diagrama de stare
Expand afieaz diagrama proprie pachetului selectat
Parent afieaz diagrama ce conine pachetul de componente a crui diagram este cea din
fereastra activ
Specification permite specificarea fiecrui element selectat
Top Level comanda dat este folosit pentru vizualizarea nivelului superior al unei diagrame a
claselor sau componentelor
Referenced Item afieaz diagrama referit de elementul selectat
Previous Diagram vizualizeaz diagrama afiat anterior.
Report
Show Usage afieaz lista locaiilor unde elementul selectat este folosit.
Show Instances afieaz lista tuturor diagramelor de colaborare unde este prezent instanierea
clasei selectate.
Show Acces Violations afieaz lista tuturor conflictelor ntre pachetele unei diagrame a
claselor.
Show Participants in UC afieaz lista tuturor participanilor la o preceden selectat.

Tools
Create este un submeniu ce reprezint o alternativ a barei de instrumente speciale.
Text adaug un text
Note adaug un comentariu
Note Anchor leag un comentariu de elementul (comentat)
Class adaug o clas
Parametrized Class adaug o clas parametrizat (ablon, temlate)
Class Utility adaug un utilitar pentru clase
Parametrized Class Utility adaug un utilitar parametrizat pentru clase
Association adaug o relaie de asociaie
Aggregate Association adaug o relaie de agregare
Unidirectional Association adaug o relaie de asociaie unidirecional
Unidirectional Aggregate Association adaug o relaie de agregare unidirecional
Generalization adaug o relaie de generalizare
Dependency adaug o relaie de dependen
Pachet adaug un pachet
Instantiated Class adaug o instan de clas
Instantiated Class Utility adaug o instan de utilitar pentru clase
Actor adaug un actor
Use Case adaug un caz de utilizare
Interface adaug o interfa
Realize adaug o relaie de realizare
Check Model permite gsirea referinelor nedeterminate ntr-un model. Rezultatul este pus n
jurnalul evenimentelor.
Model Properties
Edit schimb specificrile modelului deschis
Replace nlocuiete setul de proprieti a modelului cu un nou set dintr-un fiier
Export export setul de proprieti a modelului ntr-un fiier
Add actualizeaz proprietile modelului cu datele dintr-un fiier
Update actualizeaz datele dintr-un fiier cu proprietile modelului deschis
Options permite modificarea proprietilor aplicaiei Rational Rose
Open Script deschide un fiier surs a limbajului RoseScript
New Script creeaz un nou cod surs a limbajului RoseScript
Synchronize lanseaz Rational Suite Synchronizer

Window
Cascade aranjeaz ferestrele diagramelor deschise n cascad (una asupra alteia).
Title aranjeaz ferestrele diagramelor deschise astfel nct fiecare este vzut
Arrange Icons aranjeaz ferestrele minimizate a diagramelor deschise (doar cnd ele sunt
amplasate haotic)
Help
Contents and Index apeleaz ghidul de utilizare a aplicaiei Rational Rose
Search for Help on... caut informaiei cu privire la o anumit tem
Using Help informaie cu privire la modul de folosire a ghidului de utilizare
Extended Help obine informaii cu ajutorul Rational Unified Process
Contacting Technical Support apeleaz la suportul tehnic prin Internet precum i alte metode
(telefon, fax, e-mail)
Rational on the Web Pagina Web a companiei Rational Rose
About Rational Rose informaii cu privire la versiunea programului Rational Rose precum i a
componentelor sale standard i adiionale.
Diagrame Use Case. Diagramele cazurilor de utilizare au rolul de a reprezenta ntr-o
form grafic funcionalitile pe care trebuie s le ndeplineasc sistemul informatic n faza sa
final. De asemenea diagrama cazurilor de utilizare reprezint imaginea sistemului privit din
exterior.
Diagramele permit specificarea cerinelor ntr-o manier care ar permite o nelegere
uoar. Pe ea sunt prezentate relaiile dintre actori i cazurile de utilizare.
Cazurile de utilizare reprezint secvene de tranzacii ce au loc n dialog cu sistemul i care
sunt nrudite din punct de vedere comportamental. Practic, un caz de utilizare modeleaz un
dialog ntre un actor i sistemul informatic. Mulimea de cazuri de utilizare a unui sistem
reprezint toate modalitile n care sistemul poate fi folosit.
Bara de instrumente speciale proprie Diagramei Use Case

1 2

4 5

10

1. Comanda de selectare.
2. Comanda de scriere a unui text.
3. Comanda de adugare a unui comentariu.

4. Comanda de legare a comentariului de elementul pe care-l nsoete.


5. Comanda de adugare a unui pachet.
6. Comanda de adugare a unui precedent.
7. Comanda de adugare a unui actor.
8. Comanda de adugare a asociaiilor.
9. Comanda de adugare a dependenelor.
10. Comanda de adugare a generalizrilor.
Elaborarea diagramelor USE-CASE (variantelor) n mediul Rational Rose
Lucrul asupra proiectului n mediul Rational Rose ncepe cu analiza general a problemei
puse, apoi se construiete diagrama variantelor, USE-CASE.
Pentru elaborarea acestei diagrame este necesar de selectat diagrama dat din fereastra
diagramei. De deschis browserul, i de acolo de ales pictograma main ce semnific nsui
diagrama variantelor de utilizare.
Tot atunci pe interfaa de lucru ne apare setul special de instrumente specific pentru acest
tip de diagrame. n setul acesta sunt toate elementele necesare pentru construirea diagramei
variantelor de utilizare. Pentru adugarea unui nou element este necesar de selectat cu ajutorul
mouseului butonul cu imaginea elementului necesar, dup aceea tot cu ajutorul mouseului
elementul se depune pe diagram. Pe diagram apare imaginea elementului selectat cu
dimensiunile geometrice modificate i cu un nume aproximat.
Numele elementului poate fi schimbat de ctre eleboratorii proiectului, fie imediat dup
depunerea lui pe diagram, fie n cursul de elaborare a proiectului. Tastnd click dreapta pe
elementul dat se cheam meniul contextual al acestui element, printre opiunile cruia este i
punctul Open Specification. n acest caz se activeaz o fereastr de dialog cu casete speciale, n
cmpurile crora este posibil de a nscrie toat informaia despre elementul dat.
Diagrama variantelor de utilizare este reprezantarea modelului la un nivel nalt, i din
aceast cauz ea nu trebuie s conin multe variante de utilizare i actori. n continuare
diagrama poate fi modificat adugnd sau eliminnd diferite elemente din ea. Eliminarea
complet a unui element din diagram, adic toate legturile cu acest element s fie pierdute se
efectueaz tastnd edit->delete from model sau cu combinaia de taste Ctrl+D.
La folosirea legturilor este necesar de inut cont de semnificaia acestei legturi, n cazul
cnd dou elemente nu pot s fie legate cu un oarecare tip de legtur sistemul ne va informa
despre aceasta.

Fig.2.6. Diagrama cazurilor de utilizare privind Conectarea clientului la reelele electrice


n diagrama de mai sus avem urmtorii actori:
1. Conducere conducerea ntreprinderii Union Fenosa
2. Departament Tehnic reprezint un departament al Union Fenosa care se ocup cu
instalarea reelelor de distribuie, reparaia lor, instalarea contoarelor etc.
3. Departament control reprezint un departament al Union Fenosa care se ocup cu
citirea datelor de la contoarele consumatorilor, prelucrarea lor etc.
4. Contabilitatea reprezint contabilitatea Union Fenosa care se ocup cu gestionarea
resurselor financiare
5. Consumator consumatorii de curent electric fie persoane fizice, fie persoane juridice
6. Productor productorii de curent electric
7. Banca bncile prin intermediul crora se efectueaz transferuri de bani.
i urmtoarele cazuri de utilizare:
1. Conectarea conectarea consumatorului la furnizorul de energie
2. ntocmirea Facturii ntocmirea facturii consumatorului pe baza datelor citite de la
contor
3. Achitarea Facturii achitarea facturii de ctre consumator
4. ncheierea contractului ncheierea contractului ntre Union Fenosa i productorul de
energie.
Diagrame Interaction
Funcionalitatea unui caz de utilizare este dat de un flux de evenimente (specificat n
documentul de descriere al cazului de utilizare).

Un scenariu reprezint o cale (un drum) prin fluxul de evenimente al unui caz de utilizare.
Scenariile pot fi privite ca instane (sau realizri) ale cazurilor de utilizare: ele descriu o secven
de aciuni concrete care pot avea loc la un moment dat n sistem.
Determinarea scenariilor are rolul de a ajuta:
- nelegerea funcionalitii cazurilor de utilizare;
- specificarea modului n care responsabilitile unui caz de utilizare sunt distribuite obiectelor i
claselor din sistem;
- identificarea obiectelor i claselor;
- identificarea interaciunilor ntre obiecte, necesare pentru realizarea unei pri funcionale
concrete descris de un caz de utilizare;
- comunicarea pe baza specificaiilor proiectului.
Dac fluxul de evenimente al unui caz de utilizare este descris prin intermediul unui text
(documentul de descriere al cazurilor de utilizare), scenariile se descriu prin intermediul aanumitelor diagrame de interaciune. n Rational Rose avem dou tipuri de diagrame de
interaciune: diagramele de secven i de colaborare. Fiecare dintre aceste diagrame reprezint
o vedere grafic diferit a unui scenariu.
Diagrame Sequence
Diagramele de secven prezint interaciunile care au loc ntre diverse obiecte ale unui
sistem, ordonate cronologic. Ele determin obiectele i clasele implicate ntr-un scenariu i
secvenele de mesaje transmise ntre obiecte, necesare ndeplinirii funcionalitii scenariului.
Diagramele de secven sunt asociate unui caz de utilizare.
Fiecrui obiect, clas i corespunde o linie a timpului, reprezentat printr-o linie punctat
sub reprezentarea obiectului. Mesajele transmise ntre obiecte sunt reprezentate prin sgei
etichetate cu numele mesajului.
Bara de instrumente speciale proprie Diagramei Sequence

1 2

6 7

1. Comanda de selectare.
2. Comanda de scriere a unui text.
3. Comanda de adugare a unui comentariu .
4. Comanda de legare a comentariului de elementul pe care-l nsoete.

5. Comanda de adugare a unui obiect.


6. Comanda de adugare a unui mesaj transmis de un obiect altui obiect.
7. Comanda de adugare a unui mesaj transmis de un obiect lui nsui.
8. Comanda de adugare a unui mesaj de rspuns.
9. Comanda de adugare a punctului terminus a liniei timpului (proprie fiecrui obiect).

Fig.2.7. Diagrama secvenelor pentru cazul de utilizare ncheie contract


Productorul de energie electric propune gama sa de servicii i produse. Conducerea
ntreprinderii Union Fenosa analizeaz oferta apoi negociaz preurile i condiiile cu
productorul. n cazul cnd ajung la o nelegere comun este ncheiat contractul.

Fig.2.8. Diagrama secvenelor pentru cazul de utilizare Achit factura


O dat fiind ntocmit factura, contabilitatea o transmite consumatorului. Consumatorul
verific i el contorul i calculeaz consumul de energie. n cazul cnd calculele sale corespund
cu cele din factur el achit factura la banc.

Fig.2.9. Diagrama secvenelor pentru cazul de utilizare Conectare


O persoan sau o firm dac dorete s fie racordat la reelele Union Fenosa trebuie s
nainteze o cerere conducerii Union Fenosa. Aceasta consult Departamentul Tehnic n vederea
posibilitii conectrii persoanei date. Dac este posibil conectarea, persoana ce a naintat
cererea trebuie s achite taxa de conectare. Contabilitatea primind banii anun conducerea, care
d dispoziie de conectare. Departamentul Tehnic conecteaz solicitantul la reelele electrice.

Fig.2.10. Diagrama secvenelor pentru cazul de utilizare ntocmete factura


Un angajat al Departamentului control responsabil de citirea datelor de la contoare consult
contorul unui consumator. Datele citite sunt transmise altui angajat al aceluiai departament, care
calculeaz consumul curent. Datele prelucrate sunt transmise la contabilitate, unde este ntocmit
factura. Aceasta fiind transmis apoi consumatorului.

Diagrame Colaboration
Diagramele de colaborare prezint interaciunile dintre obiecte organizate relativ la acestea
i a legturilor dintre ele. Diagramele de colaborare conin:
- obiecte, n reprezentarea lor grafic sub form de dreptunghiuri;
- legturi ntre obiecte, reprezentate grafic prin linii de conectare;
- mesaje, reprezentate ca etichete ale legturilor, i care conin o sgeat ndreptat spre
obiectul server (receptor al mesajului).
Bara de instrumente speciale proprie Diagramei Collaboration

9 10 11 12

1. Comanda de selectare.
2. Comanda de scriere a unui text.
3. Comanda de adugare a unui comentariu.
4. Comanda de legare a comentariului de elementul pe care-l nsoete.
5. Comanda de adugare a unui obiect.
6. Comanda de adugare a unei instane de clas.
7. Comanda de adugare a unei legturi dintre dou obiecte.
8. Comanda de adugare a unei legturi a obiectului cu sine nsui.
9. i 10. Comanda de adugare a unei legturi dintre dou obiecte ntre care se transmit mesaje.
11. i 12. Comanda de adugare a unei legturi dintre dou obiecte ntre care se transmite fluxul
de informaie.

Fig.2.11. Diagrama de colaborare pentru cazul de utilizare ncheie contract

Fig.2.12. Diagrama de colaborare pentru cazul de utilizare Achit factura

Fig.2.13. Diagrama de colaborare pentru cazul de utilizare Conectare

Fig.2.14. Diagrama de colaborare pentru cazul de utilizare ntocmete factura


Spre deosebire de diagramele Collaboration care ne prezint doar interaciunile dintre
obiecte i mesajele transmise ntre ele, diagramele Sequence ne prezint evoluia lor n timp,
astfel ele sunt uor de citit i neles.

ntrebri de control:
1. Care sunt etapele metodologiei dezvoltrii soft-ului?
2. Cum nelegei modelul spiral al ciclului de via al sistemului?
3. Numii principalele etape utilizate la elaborarea unui sistem, conform metodologiei APOO.
4. Cte tipuri de artefacte cunoatei?
5. Ce reprezint diagrama cazurilor de utilizare? Caracterizai elementele de baz ale acestei
diagrame.
6. Care este diferena dintre extensie i incluziune?
7. Descriei diagramele de secven.

LUCRAREA DE LABORATOR NR. 3


TEMA: Analiza rezultatelor modelrii din diagrama cazurilor de utilizare i dezvoltarea n
diagramele Sequence i Collaboration n mediul Rational Rose
Scopul lucrrii:
1. Studierea prii teoretice i verificarea cunotinelor nsuite n mediul instrumentului
CASE Rational Rose.
2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea i
destinaia elementelor diagramelor Sequence i Collaboration din Rational Rose.
3. Dezvoltarea elaborrilor cu alte diagrame pentru modelul din domeniul propus n
precedenta lucrare de laborator. nsuirea tehnicilor de dezvoltare, modificare i salvare a
respectivelor modele elaborate n diagrame.
4. Studierea aprofundat i descrierea destinaiei funcionale a submeniurilor/opiunilor din
meniurile: Browse, Create, Model Properties, TOOLS din Logical View, componentele i
operaiile de manipulare (generare, modificare i salvare a modelului) pentru respectivele
diagrame.
5. Efectuarea diverselor manipulri n diagramele respective pentru evidenierea tehnicii
eficiente.
6. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n
procesul efecturii lucrrii de laborator.
Sarcina: Pentru un sistem concret realizai cte trei diagrame Sequence i Collaboration.

Consideraii teoretice generale.


Descriere general
O diagram ofer utilizatorului un mijloc de vizualizare i de manevrare a elementelor de
modelare. Diagramele pot art o parte sau toate caracteristicile elementelor de modelare,
conform nivelului de detaliu util n contextul unei diagrame date. Diagramele pot grupa
informaii interdependente, pentru a art caracteristicile respective n UML.
n UML Entitile de comportament (Behavioral things) sunt componente dinamice ale
limbajului UML i sunt verbe care descriu comportamentul modelului n timp i spaiu. Exist
doar dou tipuri de entiti de comportament: interaciunea i automatul.

Interaciunea (Interaction) reprezint comportamentul, esena cruia const n schimbul


de mesaje (Messages) dintre obiecte n cadrul unui context concret pentru atingerea scopului
dorit. Cu ajutorul interaciunii se poate descrie att o operaie aparte, ct i comportamentul unui
ansamblu de obiecte. Ea propune un alt set de elemente, aa ca comunicarea, consecutivitatea
faptelor i legturilor.
Diagrama interaciunii (Interaction) descrie un proces de prelucrare a informaiei din
varianta de utilizare.
Exist dou tipuri de diagrame de interaciune diagramele succesiunilor (Sequence) i
cele de colaborare (Collaboration). Primul tip de diagrame este organizat n jurul timpului.
Ambele tipuri de diagrame descriu aceeai informaie ns au dou diferene principale.
Diagramele succesiunilor atrage atenia asupra controlului, iar diagramele de colaborare asupra
fluxului de date.
Diagrama de interaciune este folosit pentru a modela comportamentul unei mulimi de
obiecte dintr-un anumit context care interacioneaz ntre ele pentru a ndeplini un anumit scop.
Scopul unei diagrame de interaciuni este de a specifica modul n care se realizeaz o operaie
sau un cadru de utilizatori.
Diagramele de interaciune prezint aceleai date care au fost introduse n fluxul
evenimentelor i o fac ntr-o form mai inteligibil. Principalul sunt obiectele care sunt create
pentru a realiza calitile funcionale ale sistemului. Este posibil de a plasa obiecte i clase pe
diagramele succesiunilor i cele de colaborare. Tot ce ne nconjoar este un obiect, practic acelai
lucru este obiectul din limbajul UML. Un obiect este o entitate care ncapsuleaz n structura sa
nite date i comporatamentul. Obiectul este un termen care descrie lucruri concrete. Datele
obiectului se numesc atribute (attributes), valoarea lor poate s se schimbe ns numrul i
proprietile sale nu pot fi schimbate. Comportamentul obiectului este determinat de operaiile
sale (operations). n mediul Rose obiectele sunt plasate pe diagramele de interaciune. n cazul
cnd un actor este stereotipul unei clase sau o clas este plasat pe diagram automat se creaz o
instan a acestei clase. Cu ajutorul diagramelor de interaciune programatorii definesc clasele
necesare modelrii sistemului, relaiile dintre ele, operaiile i resposabilitile fiecrei clase.
ntr-un fel diagramele de interaciune sunt baza oricrui proiect.
Diagramele succesiunilor sunt organizate n jurul timpului, i ajut s nelegem
succesiunea logic a evenimentelor. Dei informaia pe diagramele succesiunilor i cele de
colaborare este aceeai, totui diagramele succesiunilor sunt mai inteligibile.

Diagramele de colaborare sunt utile cnd este necesar de estimat valoarea schimbrilor unei
clase, unei operaii etc. nct diagrama dat arat ce obiecte sunt legate ntre ele, schimbnd unul
din obiecte vei nelege care obiecte vor fi atinse de aceast schimbare.
Diagramele de interaciune conin obiecte i mesajele (cu ajutorul mesajelor un obiect i
cere altui obiect s execute o operaie).
Obiectele de pe diagramele de interaciune au nite responsabiliti, acelai lucru se poate
spune i despre mesaje. Trebuie s controlai ca responsabilitile obiectelor i a mesajelor pe
care le trimit s corespund.
Diagramele succesiunilor sunt diagramele de interaciune organizate n jurul timpului. Ele
trebuie citite din sus n jos. Fiecare variant de utilizare poate avea un numr nelimitat de fluxuxi
alternative, fiecare din ele este prezentat printr-o diagram a succesiunilor.
Obiectele fluxului sunt prezentate n partea de sus sub forma unor dreptunghi.
Fiecare obiect are linie de via (lifeline) prezentat pe diagram de o linie vertical.
Mesajele dintre obiecte sunt prezentate prin sgei de la linia de via a obiectului care
iniializeaz activitatea la obiectul operaia cruia se execut. n etapele urmtoare fiecare mesaj
va fi o funcie a clasei respective. Mesajele pot fi reflexive obiectul execut funcia proprie.
Orice diagram de interaciune trebuie s aib un obiect-actor. El este acela care
iniializeaz procesul, el este instana actorilor de pe diagrama variantelor de utilizare.
Fiecare diagram de interaciune conine obiecte. Obiectele reprezint substantive n fluxul
evenimentelor.
Diagrama succesiunilor
Diagrama succesiunilor - reflect fluxul de evenimente care sunt efectuate n limitele
variantelor de utilizare a unui operand. Diagrama ne arat succesiunea aciunilor n timp i ne
ajut s nelegem succesiunea logic a evenimentelor. Adic diagrama de secven prezint
temporal obiectele i interaciunile lor. Tipurile de relaii folosite n aceast diagram sunt:
simple (sunt de cinci feluri: simple, sincrone, asincrone, timeout, balking) i frecventa (sunt de
dou feluri: periodic i aperiodic).
Mediul Rose accept urmtoarele tipuri de persisten pentru obiecte:
1.

Persistent: obiectul persistent este stocat ntr-o baz de date sau printr-un alt procedeu i

va continua s existe chiar i dup terminarea procesului ce l-a creat sau a programului.
1.

Static: obiecte statice exist pe tot parcursul executrii programului ns se pierd dup ce

programul este terminat.

1.

Temporar: acest tip de obiecte exist un timp foarte scurt i este distrus odat cu

terminarea procesului ce l-a creat.


Un mesaj (message) este legtura dintre obiecte unde unul din obiecte (client) cere altuia
(server) s execute o operaie. La generarea codului mesajele sunt schimbate la apelarea
funciilor. Diagramele succesive conin mesajele sub forma sgeilor trasate de la linia de via a
unui obiect la linia de via a altui obiect. n diagramele de colaborare mesajele sunt de-a lungul
legturior dintre obiecte.
Lucrul cu mesajele pe diagrama de colaborare difer de cel pe diagrama succesiv.
Mesajele pot fi transmise doar dac ntre obiecte exist o legtur (link).
A doua diferen principal dintre cele dou diagrame de interaciune este c pe diagramele
de colaborare este posibil de a arta fluxuri de date, ceea ce nu este posibil de artat pe
diagramele de secven.
Fluxurile de date se folosesc pentru a arta informaia trimis napoi dup ce un obiect i
trimite un mesaj altui obiect. De obicei nu este necesar de a aduga un flux de date unui mesaj,
aceasta va face dificil nelegerea diagramei.
n dependen de valoarea sincronizrii mesajului se va schimba i sgeata lui.
Sincronizarea mesajelor poate lua cinci valori:
Simpl (Simple) se folosete implicit. nseamn c toate mesajele sunt executate ntr-un
flux de control, se noteaz n felul urmtor:

Sincron (Synchronous) se folosete cnd clientul care a trimis mesaj ateapt rspunsul de
la server. Diagramele succesive i cele de colaborare noteaz mesajele sincrone n felul urmtor:

Fr intrarea n lista de ateptare (Balking) dac serverul nu poate executa mesajul


primit la momentul dat este pierdut. Acest mesaj se noteaz n felul urmtor:

Cu limit de timp (Timeout) clientul trimite mesaj i ateapt timpul predefinit, dac n
acest timp mesajul nu este prelucrat el este pierdut, se reprezint n felul urmtor:

Asincron (Asynchronous) clientul trimite mesaj i nu ateapt rspuns de la server, se


noteaz mesajele n felul urmtor:

Fig.3.1. Diagrama secvenelor cu gestionare asincron

Fig.3.2. Diagrama secvenelor cu flux procedural

Alt mod de reflectare a timpului de via al biletului la teatru:

Fig.3.3. Starea obiectului Object Message Sequence Chart n diagram


Diagramele de secven i diagramele de colaborare sunt reprezentri alternative pentru
interaciuni ntre obiecte.
Diagrama de colaborare
Diagramele de colaborare prezint interaciunile care au loc ntre diverse obiecte ale unui
sistem, punndu-se accentul pe organizarea obiectelor cooperante i nu pe ordonarea cronologic a
mesajelor, adic sunt reprezentri spaiale ale obiectelor, legturilor i interaciunilor.
Diagramele de colaborare sunt asemntoare celor succesive, ns atenia aici este asupra
realaiilor dintre obiecte.
Sunt mai uor detectabile relaiile dintre obiecte, ns este mai greu s percepi succesiunea
evenimentelor. Din aceast cauz de obicei n proiecte se creaz ambele tipuri i cele succesive
i cele de colaborare. Exist posibilitatea de a transforma o diagram a succesiunilor n cea de
colaborare i invers apsnd butonul F5.
Deci o diagram de colaborare este o diagram de interaciuni care arat secvenele de
mesaj ce implementeaz o operaie sau o tranzacie. O diagram de colaborare prezint obiectele,
legturile i mesajele dintre ele. De asemenea, diagramele de colaborare pot conine simple
instane de clase.
Fiecare diagram de colaborare ofer o imagine asupra interaciunilor sau a relaiilor
structurale care au loc ntre obiecte i a obiectelor ca entiti n modelul curent.

Diagramele de colaborare conin elemente reprezentnd obiecte. Se pot crea una sau mai
multe diagrame de colaborare care s prezinte interaciunile pentru fiecare pachet logic din
model; de asemenea, diagramele de colaborare sunt coninute la rndul lor de pachete logice care
cuprind obiectele prezente n diagrame.
O specificaie a unui obiect poate s indice i s modifice proprietile i relaiile
obiectului. Informaia n specificaie este prezentat textual; de asemenea, unele informaii pot fi
expuse n interiorul simbolurilor grafice reprezentnd obiecte n diagrama de colaborare. Dac
modificm specificaiile obiectului, propietile sau relaiile, diagrama de colaborare ce conine
respectivul obiect se va actualiza cu noile date. Dac modificrile proprietilor sau relaiilor
unui obiect se fac n cadrul diagramei, atunci se vor actualiza specificaiile obiectului.
Obiecte. Un obiect este caracterizat de stri, comportament i identitate. Structura i
comportamentul unor obiecte similare sunt definite n clasa lor comun. Fiecare obiect n
diagrame indic o instan a unei clase. Un obiect care nu este numit este referit ca o instan a
unei clase.
Dac ntr-o diagram de colaborare apar diferite obiecte cu acelai nume, ele se consider
c reprezint acelai obiect; altfel se consider c fiecare simbol grafic al obiectelor din diagram
reprezint obiecte distincte, obiectele ce apar n diagrame diferite sunt distincte, chiar dac
numele lor sunt identice.
Dac se specific numele clasei obiectului n specificaia obiectului, numele trebuie s
identifice o clas definit n model.
Reprezentarea grafic. Simbolul grafic pentru un obiect este similar cu cel al unei clase cu
diferena c numele obiectului este subliniat:

Legturi. Un obiect interacioneaz prin intermediul legturilor cu alte obiecte. O legatur


este o instan a unei asocieri, aa cum un obiect este o instan a unei clase.
O legatur trebuie s existe ntre dou obiecte, incluznd utilitile clasei, doar dac este o
relaie ntre clasele care corespund respectivelor obiecte. Existena unei relaii ntre dou clase
simbolizeaz o cale de comunicaie ntre instanele claselor: un obiect poate trimite mesaje spre
alt obiect.
Legturile pot susine mai multe mesaje n orice sens.

Reprezentarea grafic. ntr-o diagram de colaborare legturile se reprezint printr-o linie


ntre obiecte sau ntre obiecte i instane de clase. Pot exista i legturi de la un obiect la el
nsui.

n diagrama de colaborare pe legturile dintre obiecte se adaug mesajele corespunztoare


acestora.
Mesaje. Unitatea de comunicaie ntre obiecte se numete mesaj. Mesajul este suportul unei
relaii de comunicaie care leag, n mod dinamic, obiectele care au fost separate prin procesul de
descompunere. Ele permit interaciunea flexibil, fiind n acelai timp agent de cuplaj i agent de
decuplare.
Mesajul asigur delegarea sarcinilor i garanteaz respectarea constrngerilor. Mesajul este
un integrator dinamic care permite reconstituirea unei funcii a aplicaiei prin punerea n
colaborare a unui grup de obiecte.
Puterea sa de integrare se bazeaz pe polimorfism i pe legturile dinamice. Un mesaj
regrupeaz fluxurile de control i de date ntr-o entitate unic. Noiunea de mesaj este un concept
abstract care poate fi implementat n mai multe variante, cum ar fi:
a)
b)
c)
d)
e)

apel de procedur;
eveniment discret;
ntrerupere;
datagrama UDP;
cutare dinamic, etc.

Reprezentarea grafic. n diagramele de colaborare mesajele sunt reprezentate prin sgei


plasate n lungul legturilor care unesc obiecte, cronologia acestora fiind figurat prin plasarea
unui numr naintea mesajului.

unde k este numrul de ordine al mesajului.

Fig. 3.4. Diagrama de colaborare pentru cazul de utilizare a selectrii unui curs
Fereastra BROWSER-ului iniial este amplasat n partea stng a interfeei de lucru, mai
jos de setul de funcii standarde, i arat n felul urmtor:

Fig.3.5. Fereastra BROWSER-ului


Browser-ul organizeaz reprezentarea modelului ntr-o structur ierarhic, ce uureaz
navigarea i ne permite s gsim orice element a modelului din proiect. Orice element adugat n
model ndat se reprezint i n browser. Browserul deasemenea ne permite s organizm
elementele modelului n pachete i apoi cu uurin s le transportm dintr-o reprezentare a
modelului n alta. La dorin fereastra dat poate fi amplasat n alt parte a interfeei de lucru

sau n general poate fi ascuns, folosind din meniul principal VIEW. Se poate deasemenea de
modificat dimensiunile ferestrei date, cu ajutorul mouseul-ui.
Cu ajutorul Browserului putem efectua urmtoarele operaii:
Browse Class Diagram

evideniaz diagramele claselor din toate pachetele

Browse Use Case Diagram

evideniaz diagramele variantelor de utilizare din pachete

Browse Interaction Diagram evideniaz diagramele de interaciune din toate pachetele


Browse Component Diagram evideniaz diagramele componentelor din toate pachetele
Browse Expand

arat diagrama iniial elaborat pentru pachetul evideniat

Browse Parent

indic printele diagramei evideniate

Browse Specification

indic fereastra specificaiei obiectelor evideniate

Browse Top Level

indic diagrama etapei anterioare pentru a o modela pe cea

anterioar
Browse Referensed Item

arat diagrama principal a pachetului ce conine obiectul

evideniat
Browse Previous Diagram
Browse Units (98)

arat diagrama precedent


lucreaz cu elementul condus

Setul special de instrumente


Setul special de instrumente este amplasat n partea dreapt a BROWSERUL-ui, n partea
central a interfeei de lucru. Iniial este propus setul de instrumente pentru construirea diagramei
claselor modelului, acest set arat n felul urmtor:

Amplasarea acestui set de instrumente poate fi modificat cu uurin folosind mouse-ul.


Exist posibilitatea de adugare sau tergere a butoanelor din setul acesta.
Fereastra de diagrame este aria principal de lucru n care sunt vizualizate diferite viziuni
a diagramelor proiectului. Iniial aceast ferestr se afl n partea stng a interfeei de lucru, ns
pot fi modificate att amplasarea ct i dimensiunile acestei ferestre. La elaborarea unui proiect
nou, n cazul cnd nu a fost folosit masterul de proiecte, fereastra este curat, i nu conine nici
un element al diagramei.

Report:
Show Usage afieaz lista locaiilor unde elementul selectat este folosit;
Show Instances afieaz lista tuturor diagramelor de colaborare unde este prezent instanierea
clasei selectate;
Show Acces Violations afieaz lista tuturor conflictelor ntre pachetele unei diagrame a
claselor;
Show Participants in UC afieaz lista tuturor participanilor la o preceden selectat;
Check Model permite gsirea referinelor nedeterminate ntr-un model. Rezultatul este pus n
jurnalul evenimentelor.
Model Properties
Edit schimb specificrile modelului deschis;
Replace nlocuiete setul de proprieti a modelului cu un nou set dintr-un fiier;
Export export setul de proprieti a modelului ntr-un fiier;
Add actualizeaz proprietile modelului cu datele dintr-un fiier;
Update actualizeaz datele dintr-un fiier cu proprietile modelului deschis;
Options permite modificarea proprietilor aplicaiei Rational Rose;
Open Script deschide un fiier surs a limbajului RoseScript;
New Script creeaz un nou cod surs a limbajului RoseScript;
Synchronize lanseaz Rational Suite Synchronizer.
Window
Cascade aranjeaz ferestrele diagramelor deschise n cascad (una deasupra alteia);
Title aranjeaz ferestrele diagramelor deschise astfel nct fiecare este vzut.
Arrange Icons aranjeaz ferestrele minimizate a diagramelor deschise (doar cnd ele sunt
amplasate haotic)
Help
Contents and Index apeleaz ghidul de utilizare a aplicaiei Rational Rose;
Search for Help on... caut informaia cu privire la o anumit tem;
Using Help folosete informaie cu privire la modul de folosire a ghidului de utilizare;
Extended Help obine informaii cu ajutorul Rational Unified Process;
Contacting Technical Support apeleaz la suportul tehnic prin Internet precum i alte metode
(telefon, fax, e-mail);
Rational on the Web obine Pagina Web a companiei Rational Rose;
About Rational Rose obine informaii cu privire la versiunea programului Rational Rose
precum i a componentelor sale standard i adiionale.

Elaborarea diagramei interaciunilor n mediul Rational Rose


Aceast diagram poate fi activat prin una din metodele:
Tastai click pe butonul cu imaginea acestei diagrame pe panoul de instrumente standard din
meniul principal: Browse -> Interaction Diagram
Dup efectuarea operaiunilor de mai sus apare un loc liber pentru aranjarea elementelor
diagramei interaciunii, care sunt alese din setul de instrumente speciale specifice numai pentru
aceast diagram:

Construirea diagramei interaciunilor se reduce la adugarea i eliminarea obiectelor


separate i a mesajelor, ct i a specificaiei lor. Accesul la specificaia acestor elemente este
organizat prin meniul contextual, sau prin punctul browse->specification. La adugarea
mesajelor la diagram ele automat primesc un numr specific numai unui mesaj.
Diagrame Sequence. Diagramele de secven prezint interaciunile care au loc ntre
diverse obiecte ale unui sistem, ordonate cronologic. Ele determin obiectele i clasele implicate
ntr-un scenariu i secvenele de mesaje transmise ntre obiectele necesare ndeplinirii
funcionalitii scenariului. Diagramele de secven sunt asociate unui caz de utilizare.
Fiecrui obiect, clas i corespunde o linie a timpului, reprezentat printr-o linie punctat
sub reprezentarea obiectului. Mesajele transmise ntre obiecte sunt reprezentate prin sgei
etichetate cu numele mesajului.
Bara de instrumente special proprie Diagramei Sequence

1 2

6 7

1. Comanda de selectare.
2. Comanda de scriere a unui text.
3. Comanda de adugare a unui comentariu.
4. Comanda de legare a comentariului de elementul pe care-l nsoete.
5. Comanda de adugare a unui obiect.
6. Comanda de adugare a unui mesaj transmis de un obiect altui obiect.
7. Comanda de adugare a unui mesaj transmis de un obiect lui nsui.
8. Comanda de adugare a unui mesaj de rspuns.
9. Comanda de adugare a punctului terminus a liniei timpului (proprie fiecrui obiect).

Fig.3.6. Diagrama secvenelor pentru cazul de utilizare ncheie contract


Productorul de energie electric propune gama sa de servicii i produse. Conducerea
ntreprinderii Union Fenosa analizeaz oferta apoi negociaz preurile i condiiile cu
productorul. n cazul cnd ajung la o nelegere comun este ncheiat contractul.

Fig.3.7. Diagrama secvenelor pentru cazul de utilizare Achit factura


O dat ce factura este ntocmit, contabilitatea o transmite consumatorului. Consumatorul
verific i el contorul i calculeaz consumul de energie. n cazul cnd calculele sale corespund
cu cele din factur el achit factura la banc.

Fig.3.8. Diagrama secvenelor pentru cazul de utilizare Conectare


O persoan sau o firm dac dorete s fie racordat la reelele Union Fenosa trebuie s
nainteze o cerere conducerii Union Fenosa. Aceasta consult Departamentul Tehnic n vederea
posibilitii conectrii persoanei date. Dac este posibil conectarea, persoana ce a naintat
cererea trebuie s achite taxa de conectare. Contabilitatea primind banii anun conducerea, care
d dispoziie de conectare. Departamentul Tehnic conecteaz solicitantul la reelele electrice.

Fig.3.9. Diagrama secvenelor pentru cazul de utilizare ntocmete factura

Un angajat al Departamentului control, responsabil de citirea datelor de la contoare


consult contorul unui consumator. Datele citite sunt transmise altui angajat al aceluiai
departament, care calculeaz consumul curent. Datele prelucrate sunt transmise la contabilitate,
unde este ntocmit factura. Aceasta fiind transmis apoi consumatorului.
Elaborarea diagramei de colaborare n mediul Rational Rose
Diagrama de cooperare este un alt mod de reprezentare grafic a interaciunilor n model, la
fel ca i diagrama interaciunilor opereaz cu obiecte i mesaje. Specificul acestei diagrame n
mediul Rational Rose este c dup construirea diagramei interaciunilor la apsarea tastei F5
diagrama de colaborare se genereaz automat. Tot cu ajutorul acestei taste se face trecerea de la
diagrama interaciunilor la diagrama de cooperare i invers. Dup ce a fost activat diagrama
interaciunilor setul special de elemente primete urmtoarea form:

Fig.3.10. Setul special de elemente pentru diagrama de colaborare


Pe acest panou sunt amplasate butoanele cu imaginea elementului respectiv. Lucrul cu
aceast diagram n mare msur se aseamn cu celelalte diagrame, i const n adugarea i
eliminarea elementelor din ea i a specificaiei acestor elemente. Fcnd schimbri n diagrama
de cooperare totodat facem schimbri i n diagrama interaciunilor apsnd tasta F5
Diagramele de colaborare prezint interaciunile dintre obiecte organizate relativ la acestea
i a legturilor dintre ele. Diagramele de colaborare conin:
- obiecte, n reprezentarea lor grafic sub form de dreptunghiuri;
- legturi ntre obiecte, reprezentate grafic prin linii de conectare;
- mesaje, reprezentate ca etichete ale legturilor, i care conin o sgeat ndreptat spre
obiectul server (receptor al mesajului).
Bara de instrumente speciale proprie Diagramei Collaboration

9 10 11 12

1. Comanda de selectare.
2. Comanda de scriere a unui text.

3. Comanda de adugare a unui comentariu .


4. Comanda de legare a comentariului de elementul pe care-l nsoete.
5. Comanda de adugare a unui obiect.
6. Comanda de adugare a unei instane de clas.
7. Comanda de adugare a unei legturi dintre 2 obiecte.
8. Comanda de adugare a unei legturi a obiectului cu el nsui.
9. i 10. Comanda de adugare a unei legturi dintre 2 obiecte ntre care se transmit mesaje.
11. i 12. Comanda de adugare a unei legturi dintre 2 obiecte ntre care se transmite fluxul de
informaie.

Fig.3.11. Diagrama de colaborare pentru cazul de utilizare ncheie contract

Fig.3.12. Diagrama de colaborare pentru cazul de utilizare Achit factura

Fig.3.13. Diagrama de colaborare pentru cazul de utilizare Conectare

Fig.3.14. Diagrama de colaborare pentru cazul de utilizare ntocmete factura

Spre deosebire de diagramele Collaboration care ne prezint doar interaciunile dintre


obiecte i mesajele transmise ntre ele, diagramele Sequence ne prezint evoluia lor n timp,
astfel ele sunt uor de citit i neles.

ntrebri de control:
1. Numii deosebirile dintre diagrama succesiunilor i diagrama de colaborare.
2. Care sunt caracteristicile de baz ale diagramei interaciunii?
3. Cte tipuri de persisten pentru obiecte accept mediul Rose?
4. Ce valori poate lua sincronizarea mesajelor?
5. Cum transformm automat diagrama succesiunilor n diagrama de colaborare?
6. Descriei diagrama de colaborare.
7. Definii noiunile de obiect, legturi i mesaje.

LUCRAREA DE LABORATOR NR. 4-5


TEMA: Studiul i analiza abstraciilor, claselor, pachetelor i obinerea codului surs n
instrumentele CASE
Scopul lucrrii:
1. Studierea abstraciilor, claselor, pachetelor i obinerea codului surs la diverse nivele
n instrumentele CASE: Noiunile generale i exemplele lucrrii recente i din fiierul
Supliment1_2GenCod.doc. Analizai i descriei exerciiile propuse.
2. Efectuai punct. 2-6 i expunei scenariile i rezultatele cu analiza de rigoare i cte 3
exerciii din respectivele compartimente [1. Boggs]
3. Crearea i precizarea diverselor tipuri de clase: active, abstracte, concrete,
parametrizate i stereotipurilor pentru dezvoltarea propriilor modele din lucrrile (Ll) precedente.
4. Crearea, construirea exemplarelor claselor, categoriei claselor, metaclaselor i
descriptoarelor.
5. Analiza architecturii produsului software implementat n pachetele claselor.
6. Generarea codului surs n limbajul C++ pentru diverse cazuri.
7. Descrierea scenariilor efecturii fiecrui punct.
Sarcina: Pentru sistemul din lucrarea de laborator Nr.2 elaborai cte cinci diagrame a
claselor. Pentru 2 clase generai codul n C++.
Noiuni generale i exemple. Abstractizarea
Tipurile abstracte de date reprezint una din principalele noiuni n modelarea obiect
orientat, rolul principal n acest caz l joac noiunea de clase. Tendina spre elaborarea
mecanismelor adecvate de abstarctizare poate fi considerat ca impuls n dezvoltarea metodicilor
contemporane de modelare, ct i a limbajelor de programare. Deci absractizarea este rezultatul
creterii volumului de informaii necesar pentru proiectarea i elaborarea sistemelor mari,
corectitudinea algoritmilor fiind pe locul doi. Aadar sunt necesare mecanisme ce permit
accesarea datelor n form independent de reprezentarea concret a acestora. Astzi este practic
imposibil de creat o arhitectur (corect) a sistemului soft n ierarhia obiectual a cruia s nu
existe nivele de abstarctizare, ce permit descrierea comportamentului, necesitilor i
obligaiunilor sistemului soft. Abstarctizarea n diferite forme i sens este prezent pe parcursul
ntregului ciclu de proiectare i elaborare, ceea ce permite o analiz mai calitativ, n rezultat
contribuind la perfecionarea caracteristicilor sistemului.

Mecanismul ce permite accesarea entitilor n form independent de reprezentarea


concret a abstraciilor, care pot fi: clase, clasificatori, precedente, semnale, metode, atunci cnd
este posibil generalizarea. n cazul claselor, acestea nu pot avea instane (doar dac sunt
derivate), i n cazul metodelor lipsete realizarea concret, fiind prezent numai apelul (aa
metode se numesc virtuale).
Abstractizarea reprezint rezultatul necesitii proiectrii i implimentrii unor sisteme
enorme. Astfel atenia se concentreaz, considerabil, asupra formelor de informaie (pn ce date)
i nu asupra algoritmilor de realizare. Unul din avantajele aplicrii tipurilor abstracte de date
presupune identificarea, dar nu ntotdeauna. Modelul matematic ce permite descrierea formal a
comportamentului acestui tip, n sensul complex al analizei sistemelor, se dezice de metode
matematice deoarece devine imposibil de analizat masive enorme de informaie.
n diferite limbaje, conceptul de abstractizare (lund n consideraie necesitile timpului)
este realizat n mod diferit, principalul avantaj fiind ascunderea informaiei la trecerea de la un
nivel la altul. La nceput au fost propuse module (aa cum ele au fost realizate n Modula 2 i
Ada), dar ntruct acesta purta caracter pur sintactic (adic nu exist reguli ce ar rspunde la
ntrebarea cum programul trebuie s fie divizat pe pri ?), i nu semantic, se consider
neeficient n sensul secretizrii. Soluie eficient propune paradigma obiect orientat
ncapsularea, motenirea (determin flexibilitatea) i constructive n diverse limbaje ce permit
realizarea concret a tipurilor. Din punct de vedere formal realizarea abstraciei informaiei se
poate considera una din metodele de specificare i verificare ale sistemelor soft. Din alt punct de
vedere precum scrie Stroustrup, nafar de teoria matematic strict care st la baza acestora,
neajunsul tipurilor de date abstracte este flexibilitatea, adic lipsa flexibilitii n msura
necesar, ceea ce evideniaz necesitatea unor soluii.
Obiectul n UML poate fi neles prin prezena sa abstract. Fiecare obiect are stare,
comportament i individualitate. De exemplu, obiectul Proiect poate s aib 2 stri deschis
i nchis. Comportamentul obiectului determin, cum obiectul interacioneaz cu alte obiecte.
Individualitatea nseamn, c fiecare obiect este unic i difer de alte obiecte. Prin noiunea de
clas se nelege descrierea obiectelor, care posed proprieti comune (atribute), comportament,
interaciuni comune cu alte obiecte i semantic comun. Clasa poate fi privit ca un ablon
pentru crearea obiectelor noi.
Fiecare clas poate s aib atribute (clasa Customer Information (Informaie despre client)
are atributele Customer ID (identificatorul clientului), Name (nume) i Account (cont)). n afar
de aceasta, fiecare clas poate s aib metode (operations) anumite aciuni, care descriu
comportamentul obiectelor clasei, adic metoda Check Account.

Clasele pot s aib legturi (relationship), numite relaii. La notarea UML exist cteva
tipuri de relaii. Relaia de utilizare associations arat, c obiectul unei clase e legat cu unul sau
mai multe obiecte ale altei clase. Relaia de agregare (aggregation) este cazul particular a relaiei
de utilizare. Ea arat, c un obiect este partea altui obiect. La afectarea unui obiect, legat cu
relaia de agregare, unele operaii n mod automat pot afecta i alt obiect. De exemplu, Customer
Information (Informaie despre client) e legat prin relaia de agregare cu clasa Contract. La
distrugerea obiectului clasei Customer Information (Informaie despre client) trebuie s fie
distruse toate obiectele clasei Contract (Contracte ncheiate de clientul dat). Motenirea
(inheritance) descrie interlegtura ntre clase, cnd o clas (numit subclas, subclass) motenete
structura i/sau comportamentul unei sau mai multor clase. Subclasa VIP motenete
proprietile i comportamentul clasei Customer Information (Informaie despre client). Legtura
claselor n ierarhii de motenire se numete relaia de motenire (generalization).
Fiecare legtur poate fi caracterizat printr-o fraz anumit, numit numele rolului.
Legtura dintre clasele Customer Information (Informaie despre client) i Contract are nume
negotiates. Fiecare legtur poate s aib indicatorul de multiplicitate, care arat cte obiecte
dintr-o clas corespund obiectului din alt clasa (legtura negotiates are indicator 1..* (unu sau
multe)).
Clasele. O clas conine structura i comportamentul comun unui set de obiecte. O clas
este o abstracie a entitilor lumii reale. Cnd acestea exist n lumea real, ele sunt instane ale
clasei, i atribuite obiectelor. Pentru fiecare clas care are un comportament temporal
semnificativ, putem crea o diagram de stare care s descrie acest comportament.

O clas se reprezint grafic printr-un dreptunghi mprit n trei compartimente, n


compartimentul de sus se indic numele clasei, n cel din mijloc o list de atribute (cu tipuri
opionale i valori), i n ultimul o list de operaii (cu lista de argumente opionale i tipuri de
returnare). Compartimentele n care gsim atributele i operaiile pot fi ascunse (n cazul n care
coninutul acestora nu este semnificativ pentru contextul diagramei) pentru a reduce detaliile.
Ascunderea compartimentelor nu face nici o declaraie despre absena atributelor sau operaiilor,
dar desennd compartimentele goale se exprim explicit c nu exist elemente n acele pri
(atribute i operaii).

Numele claselor. Fiecare clas trebuie s aib un nume. n diagramele claselor, toate
simbolurile de clase cu acelai nume se consider c reprezint aceeai clas, indiferent de
diagrama n care apare.
Atribute i operaii. Atributele i operaiile pot fi prezentate complet sau nu n compartimentele
claselor. Prin convenie, din cele dou compartimente suplimentare ale clasei primul
compartiment conine atributele, iar al doilea compartiment conine operaiile. Sintaxa utilizat
pentru descrierea atributelor este:
Nume_Atribut: Tip_Atribut = Valoare_Initiala
Aceast descriere poate fi complet progresiv, de la analiz pn la proiectare. n faza
analizei cerinelor se poate specifica de ctre utilizator proprieti redundante, care pot fi
eliminate prin utilizarea atributelor derivate, indicnd clar faptul ca aceste proprieti sunt
derivate din alte proprieti deja atribuite. Sintaxa utilizat pentru descrierea operaiilor este:
NumeOperatie (NumeArgument: TipArg.=ValImplicita, ):TipReturnat
Totui, dat fiind faptul c lungimea specificaiei poate fi mare, argumentele operaiilor pot
fi suprimate n form grafic.
Vizibilitatea atributelor i a operaiilor. UML definete 3 nivele de vizibilitate pentru
atribute i operaii:

public - element vizibil tuturor clienilor clasei (interfaa pur) (simbol +);

protected - element vizibil subclaselor clasei (simbol #);

private - element vizibil n interiorul clasei (implementare pur) (simbol -).


Informaia privind vizibilitatea, chiar dac este definit n model, poate s nu fie

ntotdeauna figurat n mod explicit. Implicit, nivelul de vizibilitate este simbolizat prin
caracterele: +, #, - .

Fig.4-5.1. Vizibilitatea atributelor i operaiilor

Anumite atribute i operaii pot fi vizibile global, n toate expresiile lexicale ale clasei.
Aceste elemente denumite variabile i operaiile de clas, sunt reprezentate ca i obiectele prin
sublinierea numelor. Notaia se justifica prin faptul c o variabil de clas apare ca un obiect
partajat de instanele clasei. Prin extensie, operaiile clasei sunt de asemenea subliniate.
Reprezentarea atributelor i operaiilor din punct de vedere al vizibilitii acestora.

Fig.4-5.2. Atribute i operaii vizibile global


n UML exist 4 tipuri de legturi ntre clase:
1)

Asociere (association relationship)

Fig.4-5.3. Asocierea n notaie UML

Fig.4-5.4. Asociere multipl

Fig.4-5.5. Cardinalitatea asocierii

Fig.4-5.6. Asociere complex

Fig.4-5.7. Agregarea n notaie UML


2) Generalizare (generalization relationship);
3) Dependena (dependency relationship);
4) Realizare (realization relationship).

Asocierea spune despre existena unei relaii ntre clase. Dependena se folosete atunci
cnd se arat dependena ntre dou esene. Agregarea se aplic pentru a arta c o clas conine
n sine alt esen. Realizarea se utilizeaz pentru descrierea faptului c o clas motenete toate
proprietile clasei printe.
Asocierile sunt relaii structurale ntre clase de obiecte. O asociere simbolizeaz o
informaie a crui durat de via este neneglijabil n raport cu dinamica general a obiectelor
instane ale claselor asociate. Majoritatea asocierilor sunt binare, conectnd 2 clase. Asocierile
sunt reprezentate prin linii care unesc clasele asociate. Asocierile pot fi reprezentate prin trasee
rectilinii sau oblice, n funcie de preferinele utilizatorului. Experiena recomand utilizarea unui
singur stil de reprezentare a traseelor pentru simplificarea citirii diagramelor unui proiect.
Majoritatea asocierilor sunt binare, adic sunt relaii ntre dou clase. Totui pot exista
asocieri multiple reprezentate prin intermediul unui romb ctre care vin trasee de la diferitele
componente ale asocierii.
Asocierile multiple pot fi reprezentate n general avansnd asocierea la rang de clas i
adugnd constrngeri care bratele multiple ale asocierii se instaniaz toate simultan.
Ca i la asocierile binare, extremitile unei asocieri multiple sunt denumite roluri i pot purta un
nume. Dificultatea de a gsi un nume diferit fiecrui rol al unei asocieri multiple este adesea
semnul unei asocieri de multiplicitate inferioar.
Asocierile pot fi numite, numele asocierii fiind figurat cu litere italice (nclinate) la
mijlocul liniei care simbolizeaz asocierea.
Se recomand utilizarea unei faune verbale (limbaj verbal) pentru numirea asocierilor: activ i
pasiv. n ambele cazuri, sensul citirii numelui poate fi precizat prin intermediul unui mic
triunghi cu un vrf de unghi ndreptat ctre clasa indicat prin fauna verbala i plasat n
apropierea asocierii.
Pentru simplitate triunghiul poate fi nlocuit cu semnele < sau > disponibile tuturor font-urilor.
Asocierile ntre clase exprim n primul rnd structura static, fapt pentru care numele sub forma
verbal, care evoc mai degrab comportamentul, se gsesc puin n afara spiritului general al
diagramelor de clase. De aceea, numirea extremitilor relaiilor permite clasificarea diagramelor
ca i numirea asocierilor, dar ntr-o form mai pasiv, mai potrivit orientrii statice a
diagramelor de clase.
Numele rolurilor. O extremitate a unei asocieri poart numele de rol, astfel asocierile
binare cu dou roluri, au la fiecare extremitate cte unul. Rolul descrie modul n care o clas vede
o alt clas dincolo de o asociere. Rolul este numit prin intermediul unei forme nominale, vizual
deosebindu-se de asociere prin faptul c este figurat cu litere obinuite i este plasat la una din
extremitile unei asocieri.

Numirea asocierilor i a rolurilor nu se exclud reciproc, dei n practic cele dou


construcii rar se combin. De obicei se ncepe prin completarea unei asocieri printr-un verb, care
va servi mai trziu pentru a construi un substantiv verbal care denumete rolul corespunztor.
Atunci cnd dou clase sunt legate printr-o singur asociere, numele claselor este adesea
suficient pentru a caracteriza rolul, urmele rolurilor avnd eficien atunci cnd mai multe
asocieri leag dou clase, fiecare exprimnd un concept distinct.
Prezena unui numr mare de asocieri ntre dou clase poate fi suspect. Fiecare asociere
adaug un cuplaj ntre cele dou clase, iar cuplajul puternic indic o descompunere greit. Pe de
alt parte, acesta poate fi sensul figurrii de mai multe ori a aceleiai asocieri, numind fiecare
asociere cu numele mesajelor care circul ntre obiectele instan ale claselor asociate.
Sensul aplicrii claselor const n imitarea obiectelor lumii reale unificnd proprietile cu
comportamentul, ceea ce simplific i contientizeaz perceperea esenei problemelor reale ce
pot fi rezolvate aplicnd acest concept. Generalizarea comportamentului unui set de obiecte, ce
poart denumirea de exemplare ale clasei date ([1] poate fi tratat ca un template pentru obiecte).
n paradigma obiectual orientat, clasa este entitatea minimal ce posed denumire
(identificatorul clasei trebuie s fie unical), proprieti i comportament, proprietile se
numesc atributele clasei, iar comportamentul setul de operaii sau metodele clasei ce determin
cile de comunicare cu lumea extern (deci obiectele acestor clase prin intermediul metodelor
pot iniia schimb de informaii) aceasta se numete ncapsulare. Numele clasei numaidect
trebuie s poarte sens n contextul corespunztor (CRect class rectangle) deoarece aceasta
influeneaz asupra nelegerii locului i hotarelor clasei n ierarhie, aceasta este valabil i pentru
atributele (bottom, left, ... ce vor indica dimensiunile zonei) i metodele (BottomRight indic
coordonatele punctului bootom.reght).

Dac clasa intr n componena pachetului atunci numele clasei va fi precedat de numele
pachetului, de exemplu Package_name::CRect. Conceptul dat permite n baza unor clase
obinerea altor de generalizare sau de precizare, acest fenomen poart denumirea de motenire.
Am menionat despre necesitatea unor soluii ce ar nltura dezavantajul n privina lipsei
flexibilitii, referitor la clase aceast problem rezolv mecanismul de motenire (discuiile
despre corectitudinea i eficiena acestui mecanism i astzi sunt actuale, mai ales n sensul

motenirii multiple). Dac privim clasele ca tipuri, atunci motenirea este mecanismul de sintez
a tipurilor polimorfe. Deci o clas derivat din alt clas (numit clasa de baz), se consider
subtipul clasei de baz (ce este privit ca tip). n afar de aceasta exist nc un moment
important, existena mecanismelor de protecie a fragmentelor critice de informaie n cadrul
clasei, aa numitor specificatorilor de acces (printre altele suportul specificatorilor de acces
determin msura n care limbajul de programare susine paradigma obiect orientat).
Necesitatea acestui mecanism este evident n cazul sintezei unui subtip, cnd exist pericolul
afectrii contiente sau incontiente ale informaiei clasei de baz din partea celei derivate.
Clasele abstracte
Se numesc abstracte clasele ce nu posed instane, i se folosesc numai pentru sinteza
noilor subclase ce ncapsuleaz proprieti i comportament asemntor (n calitate de leaf
aceste clase nu sunt utile i se folosesc pentru susinerea ierarhiei) i n aa mod precizeaz cele
preluate din clasa de baz aceste subclase deja pot avea instane i pot fi utilizate direct. [2]
Clasele abstacte se creaz i atunci cnd exist un set de metode ce utilizeaz atributele i alte
metode numai din clasa dat, i acest set poate fi abstractizat (simplu de prezentat comportament
comun) pentru ncapsulare n subclase. Clasa abstract poate fi creat prin declararea unei
metode virtuale, de exemplu aceasta poate fi destructorul (i nici ntr-un caz constructorul), pe
cnd celelalte metode pot fi concretizate acele metode ce posed cod propriu i pot fi utilizate
n clasa derivat. Abstracte pot fi i precedentele acestea prezint comportament dependent,
adic intr n componena altor precedente prin utilizarea relaiilor de extindere (extend),
includere (include) sau generalizare. Acest principiu rmne valabil i pentru celelalte elemente
din model. Astfel putem ajunge la o claritate n proiectarea i analiza unui sistem soft.
Calss A
{
virtual ~A() = 0;
};
A::~A()
{
};

n privina exemplului CRect putem meniona c acesta poate fi n calitate de clas


abstract pentru toate subclasele (ce prezint de exemplu elemente grafice) la baza crora este

dreptunghiul cum sunt butoanele din windows (n realitate n windows toate elementele vizuale
de tip fereastr (de exemplu butoanele) iniial sunt motenite din CWnd).

Clasele root i clasele leaf


Leaf sunt subclase finite n sens c nu se folosesc pentru obinerea altor clase, adic ele
nu se utilizeaz pentru motenire ci sunt folosite direct prin crearea instanelor. Clasele leaf
se gsesc pe ultimele nivele (cele de jos) ale arborelui ierarhic, i deci sunt cele mai specializate
condiiilor concrete. Root sunt clasele generalizate ce sunt destinate pentru crearea altor clase
specificate ntr-o msur mai mare (n schema precedent dac presupunem c din clasa CButton
nu se vor deriva subclase, atunci Cbutton este leaf i CRect va fi root). De exemplu clasele
abstracte pot fi de tip root (nu numai pot fi dar i trebuie s fie ns aceasta este doar o
recomandare, nu se tie dinainte dac clasa dat rmne concret pn la finisarea proiectrii, n
practic aceasta se ntlnete des de exemplu din cauza divizrii sarcinilor clasei) atunci prin
motenire se creaz clase concrete, i nici ntr-un caz nu pot fi leaf, deoarece aceasta nu aduce
nici un folos clasele abstracte nu posed instane (cum am menionat se folosesc pentru
claritatea ierarhiei).

Clasele utilitare (utilite)


Ex
var SQL, selectClausem fromClause: string;
....
selectClause = SELECT * ;
fromClause = FROM ;

n descrierea claselor
abstracte

SQL = selectClause + fromClause + numeRelaie;


// primim: SELECT * FROM Staff

am

menionat

despre faptul c putem

crea clase abstracte [2] n cazul cnd exit set de atribute i operaii ce folosesc atribute numai
din clasa dat i totodat nu determin hotarele concrete, i pot fi ncapsulate total n diverse
clase cu comportament diferit i destinaie diferit. Exist i alt soluie elegant clasele utilite
(Utility class), ce prezint prin sine unificarea acesui set de operaii, apoi folosit n calitate de
extensie pentru alte clase sau chiar extensii ale limbajelor de programare. De exemplu avem set
de operaii destinat prelucrrii irurilor de caractere, i poate fi subset de operaii a mai multor
clase ce folosesc string-uri, cum este TSQLQuery din Delphi ce pstreaz i prelucreaz masiv
de string-uri fiecare fiind interogare SQL, i acest set de operaii simplific considerabil
manipularea interogrilor.
Clasele parametrizate, utilitele claselor parametrizate i clasele acumulatoare
Reprezint un tip special de clase ce se utilizeaz pentru
crearea familiilor de clase. Am menionat c o clas poate fi
tratat

ca

template

pentru obiecte,

clase parametrizate

(Parametrized class) deasemenea pot fi tratate ca template [1],


dar deja pentru alte clase (deoarece ele reprezint meta clase i
instanele lor sunt clase i nu obiecte. Din meta clase fac parte
clasele parametrizate i utilitele lor. De exemplu avem nevoie s
crem un tablou grafic, pentru aceasta putem utiliza clasa CRect,
care vor fi elemente ale tabloului (apoi clasa CTable poate fi
util pentru crearea Grid-ului, sau tabloului de butoane).
Argumentul acestei clase se indic n dreptunghiul punctat, n baza acestui argument se creaz
elementele clasei (n calitate de argument pot fi diverse elemente, att alte clase, ct i elemete
simple: structuri, iruri sau numere numrul de argumente nu este limitat).
Alt tip de clase parametrizate sunt clasele acumulatoare, argumentele acestora fiind valori
efective, astfel prelund valoarea argumentului putem determina sublista unor obiecte ce se
pstreaz n lista iniial. n UML clasele acumulatoare (Instantiated class) sunt vizual
aseamenea claselor simple, deosebirea fiind numele clasei (mpreun cu argumentele) plasat
ntre simbolurile <Numele clasei>. Clasele parametrizate deasemenea pot fi create n baza
claselor utilite, pentru aceasta sunt destinate clasele utilite parametrizate (parametrized class
utility), acestea reprezint template cu operaii pentru clasele parametrizate. Pentru clasele
acumulatoare deasemenea exist utilitele claselor acumulatoare (instantiated class utility),
parametrii acestora fiind valori efective.
Instanele i caracteristicele lor. Instan (instance), exemplar sau obiect (object)
reprezint descrierea unei entiti din lumea real (conform paradigmei obiect orientate) sau

abstract (abstract entity). Deci este o abstracie cu hotarele implicit (garantat) determinate, sens
i destinaie concret n contextul sistemului soft. Oricare ar fi obiectul din sistem, acesta posed
trei caracteristici necesare: stare, comportament, identificator.

Starea (state) este o succesiune de condiii ce determin existena obiectului, starea


obiectului se determin prin intermediul setului de atribute (valorilor acestor atribute) i
legturi cu alte obiecte i cu timpul pot fi supuse modificrii.

Comportamentul (behavior) cuprinde partea funcional a existenei (ciclului de via)


obiectului i determin reacia lui la interogrile din partea altor obiecte, adic interogri
din lumea extern, i se realizeaz prin intermediul operaiilor/metodelor.

Identificatorul (identity) semnific proprietatea unic a obiectului.

n UML obiectele sun prezentate prin


dreptunghi cu numele subliniat (mpreun
cu numele obiectului se indic i tipul).
Dac obiectul conine numai tipul i
numele fiind lips atunci obiectul se
numete anonim (din dreapta).

Mecanismele comune
UML definete un mic numr de mecanisme comune care asigur integritatea conceptual a
notaiilor. Aceste mecanisme comune cuprind: stereotipurile - specializeaz

clasele

metamodelului (ext.); etichetele - extind atributele claselor metamodelului (ext.); notele;


constrngerile - extind semantica metamodelului (ext.); relaia de dependen; dualitile (tip,
instana) i (tip, clasa).
1.Stereotipurile fac parte din mecanismele de extensibilitate prevzute de UML. Fiecare
element de modelare al UML poate avea un stereotip atunci cnd semantica elementului este
insuficient. Stereotipul:

permite metaclasificarea unui element al UML;

permite utilizatorului (metodologist, constructor de utilitare, analist, proiectant) s adauge


noi clase de elemente de modelare, n plus fa de nucleul predefinit de UML;

uureaz unificarea conceptelor apropiate, cum ar fi subsistemele sau categoriile, care


sunt exprimate prin intermediul stereotipurilor de mpachetare;

permite extinderea controlat a claselor metamodelului, de ctre utilizatorii UML, un


element specializat printr-un stereotip S fiind semantic echivalent cu o nou clas a
metamodelului, denumit ea nsi S.
De fapt, toat notaia UML poate fi construit pornind de la clasele Entitate i Stereotip,

celelalte concepte putnd fi derivate (specializate) prin aplicarea mecanismului Stereotip asupra
clasei Entitate. Creatorii UML au cutat un echilibru ntre:

clasele incluse de la nceput;

extensiile obinute prin stereotipizare, astfel nct:

doar conceptele fundamentale au fost exprimate sub form de clase distincte;

celelalte concepte, derivabile din cele de baz, au fost tratate ca stereotipuri.

O clas poate conine i un stereotip cu proprietile sale. UML definete urmtoarele


stereotipuri de clase:

<<signal>>, o situaie special care declaneaz o tranziie ntr-un automat;

<<interface>>, o descriere a operaiilor vizibile;

<<metaclass>>, clasa de clase (ca n Smalltalk);

<<utilitare>>, o clas redus la conceptul de modul i care nu poate fi instaniat.


De exemplu este necesar s crem forme (cum
este HTML Form) pentru diverse servicii ale
sistemului

nostru,

pentru

aceasta

introducem

stereotipul System Form, ce poate fi asociat clasei.


Exemple de stereotipuri sunt entitate (entity), hotar
(boundary), gestiune (control), excepie (exception),
domeniu (domain), interfa (interface), enumerare
(enum) uniune (union). [3] Stereotipurile divizeaz elemetele (comune) pe grupe cu
comportament comun, aceasta este foarte util n sisteme mari permite organizarea clar a
arhitecturii sistemului soft. n UML denumirea stereotipului se indic deasupra numelui
elementului (de exemplu deasupra numelui clasei) plasat ntre simbolurile <<>> (<<System
Form>>).
Stereotipul este un mecanism ce ne d posibilitatea de a mpri n categorii clasele. n
limbajul UML stereotipurile sunt de trei feluri : Boundary (Hotar), Entity (Obiect), Control
(Control).
Stereotipul clasa entitate (class entity). Clasele entitate modeleaz structura i
comportametul datelor, ce difer prin caracterul su stabil (de regul aceste clase sunt create la

etapa de planificare). Clasele acestui stereotip se utilizeaz pentru execuia funciilor interne ale
sistemului i cel mai important reflect calitatea entitilor (abstraciilor) lumii reale i aceste
clase sunt independente de mprejurri, adic nu sunt flexibile la faptul cum factorii externi
influeneaz asupra funcionrii sistemului. Pentru depistarea stereotipurilor este necesar
diferenierea sferelor de responsabilitate ale sistemului, n baza analizei fluxului de evenimente,
ce cuprinde anumite scenarii. Clasele entiti sunt necesare sistemului pentru susinerea funciilor
diferitor sfere de responsabilitate.
Stereotipul clas hotar (boundary class). Clasele hotare deservesc procesele de
interaciune dintre sistem i lumea exterioar (sunt acea parte a sistemului ce nemjlocit comunic
cu exteriorul adic clasele sunt necesare pentru modelarea mijloacelor de comunicare),
asigurnd interfaa pentru utilizator sau alt sistem (subiect activ). Pentru depistarea claselor
hotare se analizeaz perechile de tip subiect activ / scenariul. Aceste clase asemenea claselor
entiti se depisteaz la etapa de planificare, i de regul se deosebesc prin gradul de detaliere
sczut. Acum este de folos modelarea i documentarea funciilor interfeei grafice ce se privete
n complex (n complex nseamn descrierea generalizat i nu concret de exemplu diferite
butoane ale meniurilor i panourilor). n procesul proiectrii aceste clase se detalizeaz n
dependen de mecanismele alese pentru implementarea lor.
Stereotipul clas de gestiune (control class)
Clasele de gestiune se utilizeaz pentru realizarea caracteristicilor de comportament ale
sistemului ce sunt caracteristice unor scenarii i coordoneaz evenimentele, ce se produc pe
parcursul funcionrii sistemului n cadrul acestor scenarii. Aceste clase pot fi considerate
abstracii ce prezint dinamica scenariilor. Pentru depistarea lor asemenea claselor hotar se
analizeaz perechile de tip subiect activ / scenariul n primele stadii ale ciclului de via i
pentru fiecare pereche se creaz o clas de gestiune, sarcina lui fiind controlul fluxurilor de
evenimente ce se produc pe parcursul acestui scenariu.

CerereOptionala
Creare()

CerereCorecta
Creare()
Salvare()
Refuz()

OrganizareaCererei
Creare()
Setare()
Info()

Tranzactie
Comitere()
Salvare()
Cerere
Salvare()

Fig.4-5.8. Diagrama claselor prin stereotipuri

Din diagram se observ c CerereCorecta rspunde de corectitudinea ndeplinirii


cererii; CerereOptioanala permite opiuni adugtoare asupra cererii; Cerere este chiar
cererea; Tranzactia urmrete ca s se ndeplineasc tranzacia cererii; OrganizareaCererei
realizeaz cererea pentru a fi apoi transmis.
2. Etichetele. O etichet este o pereche (nume, valoare) care descrie o proprietate a unui element
de modelare. Proprietile permit extinderea atributelor elementelor metamodelului. O etichet
modific semantica (nelesul) elementului pe care l calific.
3.Notele. O not cuprinde ipotezele i deciziile aplicate n timpul analizei i reprezentrii grafice.
Notele pot conine orice informaie, inclusiv textul planului, fragmente de cod sau referine la alt
document. O not conine un volum nelimitat de text. n consecin, notele pot fi dimensionate.
Notele se comport ca nite etichete. Ele se pot folosi n orice fel de diagram. Notele sunt doar
explicaii oferite acolo unde apar n diagram. Ele nu sunt considerate ca facnd parte din model.
Ele pot fi terse ca orice alt component a diagramei.
4.Ancora notei. Ancora notei conecteaz o not la un element pe care l simuleaz. Aceste
elemete pot lega o not de un element sau mai multe elemente ale diagramei respective. O not
poate s nu fie conectat, caz n care aceasta se refer la ntreaga diagram.
5.Constrngerile {..}. O constrngere este o relaie semantic ntre elementele de modelare. UML
nu specific o sintax particular pentru constrngeri, care pot fi exprimate: n limbaj natural; n
pseudocod; prin expresii de navigare; prin expresii matematice.
6.Relaia de dependen. Relaia de dependen definete o relaie de utilizare unidirecional
ntre dou elemente de modelare, denumite sursa i inta relaiei. Notele i constrngerile pot fi de
asemenea surse ale unei relaii de dependen.
7.Dualitile (tip, instana) i (tip, clasa). Multe elemente de modelare prezint dualitatea (tip,
instana), n care: tipul denot esena elementului, iar instana cu valorile sale corespund unei
manifestri ale acelui tip. De asemenea, dualitatea (tip, clasa) corespunde separrii ntre: tipul,
clasa, care furnizeaz realizarea acestei specificri.

Diagrame de clase
Diagramele de clase exprim la modul general structura static a unui sistem, n termeni de
clase i de relaii ntre aceste clase. Aa cum o clas descrie un ansamblu de obiecte, o asociere
descrie un ansamblu de legturi: obiectele sunt instane ale claselor, legturile sunt instane ale
asocierilor.
Diagramele de clase i diagramele de obiecte sunt reprezentri alternative pentru modelele
obiectelor. Diagramele de clase conin clase i diagramele de obiecte conin obiecte, dar se pot
mixa clasele i obiectele atunci cnd este de vorba de diferite tipuri de metadate.
Diagramele de clas sunt mult mai relevante dect cele de obiecte. De obicei, se construiesc
diagramele de clase i ocazional diagramele de obiecte pentru a ilustra structuri de date
complicate sau transmiteri de mesaje.
Diagramele de clase conin simboluri grafice pentru clase. Se pot crea una sau mai multe
clase pentru a reprezenta clasele din nivelul de vrf al modelului curent. De asemenea, se pot crea
una sau mai multe diagrame de clase pentru a reprezenta fiecare pachet din model, clase care
sunt, coninute n pachetul ce cuprinde clasele de reprezentat.
Dac se modific proprietile sau relaiile unei clase prin editarea specificaiilor sale,
diagramele de clase ce conin aceste clase se actualizeaz conform acestor modificri. Dac
modificrile au loc n cadrul unei diagrame de clase, se vor actualiza specificaiile clasei i
celelalte diagrame de clase care conin aceast clas.
Diagramele de clase se utilizeaz pentru analiza, n care se arat rolurile i
responsabilitile comune ale entitilor ce descriu comportamentul sistemului i pentru
proiectare, unde se indic structura claselor ce formeaz arhitectura sistemului.
Construcia diagramelor de clase are loc n faza de elaborare a sistemului informatic fiind
cele mai importante din aceast faz.
Bara de instrumente speciale proprie Diagramei Class

9 10 11 12

1. Comanda de selectare.
2. Comanda de scriere a unui text.
3. Comanda de adugare a unui comentariu .
4. Comanda de legare a comentariului de elementul pe care-l nsoete.

5. Comand de adugare a unei clase.


6. Comand de adugare a unei interfee.
7. Comand de adugare a unei asociaii.
8. Comand de adugare a unei clase de asociere.
9. Comand de adugare a unui pachet.
10. Comand de adugare a unei dependene.
11. Comand de adugare a unei generalizri.
12. Comand de adugare a unei realizri.

Pachetele Esene de grup


Arhitectura presupune divizarea sistemului n elemente mai specifice (din punct de vedere
al apartenenei sau funcional) subsisteme, i relaiile dintre ele, acest scop poate fi atins prin
integrarea pachetelor n structur (conceptual). Deci sistemul poate fi divizat conform criteriului
(sau combinaiei de criterii) funcional, adic toate clasele ce posed rspundere funcional
asemntoare sunt plasate ntr-un pachet
aparte, i atunci putem obine o imagine mai
clar a funcionalitii. n calitate de exemplu
poate servi setul de clase ce sunt obligate s
gestioneze intrarea utilizatorului n baza de
date, conectarea, autentificarea, certificarea,
acordarea drepturilor, etc. Toate acestea pot fi
privite ca un serviciu unic al sistemului de
gestiune, adic subsistem, i deci prezint o
esen de grup (atragei atenia c sistemul
principal de asemenea este prezentat n form
de pachet). Alt criteriu de grupare este apartenena unui stereotip fapt evident din definiia
sensului stereotipurilor [3]. De exemplu avem clase ce sunt obligate s gestioneze evenimentele
din exteriorul sistemului dac interfaa este reprezentat n mai multe nivele atunci, acesta
poate fi prezentat ca subsistem pe unul din nivelele structurii interfeei grafice. Alt avantaj al
utilizrii pachetelor este posibilitatea imbricrii lor (nested packages), adic pe parcursul sau
chiar de la nceputul dezvoltrii sistemului pot fi depistate alte esene de grup i mai specifice ce
vor fi plasate ntr-un pachet care la rndul su se va gsi n interiorul altui pachet (de exemplu n
modelul nostru pachetul Forms poate fi imbricat n pachetul Grafics, deoarece Grafics este
motorul interfeei grafice i Forms sunt elemente ale acestei interfee la un nivel mai nalt).

Relaiile dintre esenele de grup


Cum se observ din modelul anterior ntre pachete sunt realizate relaii de dependen,
aceasta nseamn c clasele unui pachet numit client (n cazul nostru Forms sau DBMS)
utilizeaz serviciile claselor din alte pachete numite furnizori (Open conectivity, Grafics). Aceste
relaii (dintre pachete) se depisteaz la etapa de analiz a scenariilor de execuie i legturilor
dintre clasele (ce se conin n pachete) sistemului proiectat. Relaiile de dependen din modelul
nostru n alt context pot fi nlocuite cu relaiile de agregare ce semnific formarea sistemului
principal din subsisteme. Deoarece acest proces poart caracter iterativ, cu timpul relaiile sunt
supuse modificrilor, unele din ele dispar, altele apar.
Proiectarea subsistemelor
[Kendall Scott The Unified Process Explained] Acest tip de activitate include n sine
proiectarea subsistemelor de proiectare, care deja au fost menionate n procesul de proiectare al
arhitecturii. Scopul fiind subsistemele de prestare a interfeelor, claselor de proiectare i
realizarea precedentelor la nivel de proiectare, ce execut operaiile acestor interfee. Cu toate
acestea sistemul principal nu devine strns legat cu subsistemele (aceasta nseamn c
dependenele dintre subsisteme sunt reduse la minim). Evidena acestui tip de activitate o duce
elaboratorul componentelor, de dorit acela care a depistat pachetele de analiz.
Dac sistemul conine un numr mare de clase, atunci ele pot fi unite n pachete (package).

Generarea codului n limbajul C++


Unul din avantajele CASE-ului Rational Rose (se utilizeaz Rational Rose Enterprise
Edition v2001a) este posibilitatea generrii carcasului preventiv al sistemului soft din modelul
static (n unele cazuri pentru sistemele distribuite se permite generarea codului i din alte tipuri
de diagrame), la generare se iau n consideraie proprietile proiectului n ntregime, dar i
proprietile claselor, rolurile, atributele, operaiile, etc. Pe lng proprietile ce reglementeaz
caracteristicile proiectului propriu-zis, exist i denumirile fiierelor proiectului, denumirea
claselor container, parametrii ce indic deosebirile limbajelor n parte. Proprietile claselor
indic posibilitatea crerii constructorilor/destructorilor (nu este necesar fixarea implicit a
acestora n corpul claselor din diagrama claselor) de iniializare sau de copiere, proprietile
operaiilor permit precizarea (common, virtual, abstract, static, friend) sau asignarea statutului
constant. Rational Rose permite definirea/redactarea oricrui set de proprieti adecvat
necesitilor proiectului. Pentru fiecare clas se genereaz dou fiiere, fiierul antet (.h, .h~

pentru backup file) i fiierul de specificare (.cpp, .cp~ pentru backup file), aceti parametri
deasemenea pot fi modificai.
Etapele pregtirii proiectului pentru generarea codului surs
Procesul de generare const din ase etape de baz:
I. Verificarea modelului mediul conine serviciile ce permit verificarea modelului
independent de limbajul ales pentru generare, ce se utilizeaz pentru asigurarea calitii codului
generat, aceasta permite depistarea erorilor i neclaritilor ce nu permit generarea, acest serviciu
e de dorit s fie utilizat iterativ (de la nceputul modelrii elementelor statice), deoarece ntr-un
model aglomerat procesul depistrii erorilor este mai complicat (deci, verificarea se poate face
prin Check Model din meniul Tools). O alt opiune este Access Violation ce permite depistarea
dereglrilor specificaiilor de acces, atunci cnd exist relaii ntre clasele diferitor pachete
(opiunea este accesibil din meniu Report > Show Access Violation).
II. Crearea componentelor pentru realizarea claselor exist diferite forme de
componente de la fiiere surs pn la componentele ActiveX. Preventiv clasele pot fi asociate
unor componente, unde relaiile dintre ele vor reprezenta dependenele de compilare (pentru
cazul nostru acest pas poate fi omis deoarece pentru C++ aceasta se face n mod automat).
III. Asocierea claselor pe componente fiecare component reprezint un fiier cu codul
surs pentru unul sau mai multe clase, n C++ pentru fiecare clas se creaz dou fiiere unul
antet, cellalt corp ( pentru C++ aceasta se face automat).
IV. Setarea parametrilor de generare aceti parametri (pentru C++ se acceseaz din
meniul Tools>Options>C++) determin modul de generare a codului pentru clase, atribute,
operaii, pachete, componente, etc (de exemplu dac nu dorim manual n diagrama claselor s
definim pentru fiecare clas constructor i destructor, putem indica aceasta n opiuni i Rose o s
genereze specificri corespunztoare n mod automat).
V. Selectarea claselor, pachetelor sau componentelor codul poate fi generat n parte
pentru fiecare clas sau pentru toate mpreun (dac selectm pachet se vor genera toate clasele
din pachetul dat).
VI. Generarea codului pentru C++ generarea codului se poate face (dac nu este definit
default limbajul corespunztor) prin alegarea nemijlocit a opiunii Code Generation (Tools>C+
+>Code Generation). Preventiv selectm clasele (sau pachetele n care se afl clasele) ce vor fi
generate, sau putem determina iniial limbajul de programare din meniu Tools> Options /
Notation, pentru opiunea Default Language din list alegem C++, atunci codul poate fi generat
din meniul de context, alegem opiunea C++>Code Generation.

Exemplu de model pentru care se va genera codul n C++


Sunt prezentate dou pachete ce
reprezint

Graphic
primitives

subsistemul

grafic

(de

exemplu nucleul grafic al unui sistem


de operare) i un pachet cu primitive
grafice

ce

programarea

vor

fi

utile

pentru

diagramelor

ntr-o

aplicaie de contabilitate.
<<subsystem>>
Graphic device

<<subsystem>>
Integrafe

Pachetul Graphic device reprezint


clasele ce realizeaz dispozitivul grafic
mediul grafic abstractizat (asemenea

SO Windows).
Pachetul

Interface

este

subsistemul

ce

conine

controalele de gestiune (meniuri, butoane, etc).


n pachetul Graphic primitives de exemplu pot fi
realizate tipuri speciale de date (figuri geometrice).

CObject

<<geometric>>
CRectangle
left : int
top : int
right : int
bottom : int
color : COLORREF
m_hDC : CCD
m_hWnd : CWindow
<<constructor>> CRectangle()
<<destructor>> ~CRectangle()
<<function>> Move()
<<function>> GetColor()
<<procedure>> SetColor()
<<function>> Draw()

CDeviceContect
m_hAttribDC : HDC = m_hDC
m_hDC : HDC = m_hAttribDC
<<constructor>> CDC()
<<destructor>> ~CDC()
<<function>> CreateDC()
<<function>> DeleteDC()

Coninutul pachetului Graphic device

<<geometric>>
CEllipse
<<function>> Draw()

<<geometric>>
CCircle
<<const>> right : int = 0
<<const>> bottom : int = 0
radius : int
<<function>> Draw()

CDeviceContext conine stereotipul boundary deoarece clasa dat reprezint nivelul nalt al
interfeei grafice (ce deriveaz din clasa CObject).

Coninutul pachetului
<<window>>
CWindow
m_hWnd : HWND

Interface
CWindows reprezint clasa de
baz pentru elementele de control

<<constructor>> CWindow()
<<destructor>> ~CWindow()
<<function>> MoveWindow()

<<button>>
CButton

vizuale, cum sunt butoanele sau


meniurile.

<<include>>
0..n

<<bar>>
CToolBar

Coninutul pachetului
Graphic primitives
Acest pachet prezint figurile

geometrice necesare pentru desenarea elementelor grafice ale interfeei utilizatorului, de exemplu
pentru desenarea butonului se folosete dreptunghi (CRectangle), dar avem posibilitatea s
desenm i butoane circulare (CEllipse).
Generare
Dup formare nu uitm s verificm corectitudinea modelului, opiunile corespunztoare
sunt Check Model (Tools > Check Model) i Accesss Violation (Report > Access Violation).
Pentru generarea claselor n parte
Deoarece limbajul de programare (C++) este indicat implicit, codul poate fi generat din
meniul de context a ferestrei modelului, opiunea C++ > Code Genaration.
Pentru generarea tuturor pachetelor (preventiv selectm pachetele necesare) din meniul
Tools selectm opiunea C++ > Code Genaration.

Fig.4-5.9. Codul obinut dup generare (pentru clasa Ccircle)

Dup generare obinem trei directorii, fiecare avnd semnificaie de pachet, n interiorul
acestor directorii sunt fiiere de antet i corp pentru fiecare clas.

Modalitile de generare a codului n Rational Rose


Pentru a putea genera codul n Rational Rose trebuie s avem construite cel puin
diagramele de clas i de componente. Pentru fiecare clas de selectat limbajul n care trebuie de
generat codul (n exemplul de mai jos am folosit limbajul C++), aceasta se face n felul urmtor:
n diagrama de componente deschidem fereastra de specificaii a fiierului n care vom genera
codul i pe pagina General la opiunea Language alegem limbajul C++. Pentru ca clasa s se
genereze n fiierul respectiv n diagrama de clase deschidem fereastra de specificaii pentru
clasa respectiv, pe pagina Components executm un click cu butonul drept al mouse-ului pe
fiierul n care va fi plasat codul clasei i din meniu alegem opiunea Assign, codul poate fi
generat.

Fig.4-5.8. Specificarea fiierului n care trebuie plasat codul clasei


Generarea codului din diagrama de clase
Pentru a genera codul din diagrama de clase efectum un click cu butonul drept al mouseului pe clasa respectiv i alegem opiunea C++ / Code Generation, codul a fost generat i plasat
n mapa source din directorul programului Rational Rose .

Fig.4-5.9. Selectarea meniului Code Generation


Codul generat conine carcasa programului final, clasele ce conin atributele i metodele
declarate n model i o mulime de comentarii care ajut la dezvoltarea claselor.
n fiier au fost generate clasele ce au fost asociate lui, deci clasa Administratorul de
Procese i clasa Nucleul sistemului de operare, diagrama de clase arat n felul urmtor:
Sistem de Gestiunea Fisierilor
(f rom Use Case View)

tabelul_de_alocare : Double
Scrie_in_fisier()
deschide_fisier()
inchide_fisier()
ci teste_fi sier()
creaza_fisier()
sterge_fi sier()
cauta_fisier()
1..*
1
<<nucleu>>
Nucleul Sistemului Operational
(f rom Use Case View)

Procese

prelucrarea_datelor()
generare_comanda()
verifi ca_identitatea_utilizatorului ()
accepta_utili zatorului()
decli na_utili zator()
da_identitatea_util izatorului()
0..n

1
Administratorul de procese
1

<<Modul_al_sistemului_operationa...
GUI(graphic user interface)

(f rom U se Case View)

numarul_de_proces : Integer = 1

(f rom Use Case View)

Periferic

Memoria

prelucrare_eveniment()
genereaza_eveniment()
afiseaza_date()

comuta_context()
schimba_prioritate()
creaza_proces()
sterge_proces()
kil_proces()
stopeaza_proces()
executa_proces()

Fig.4-5.10. Diagrama de clase

Generarea codului din diagrama de Componente


Dup ce fiecare clas din diagrama de clase a fost asociat unui fiier se poate de generat
codul din diagrama de componente. Se efectueaz un click cu butonul drept al mouse-ului i
alegem C++ / Code Generation (Figura 4-5.11). Codul se genereaz ca i n cazul de mai sus (n

exemplu a fost generat componenta nucleu.exe n fiierul nucleu.exe.cpp i el arat ca listingul


de mai sus).

Fig.4-5.11. Generarea codului din diagrama de Componente


Generarea codului din pachete
n diagrama de clase se selecteaz pachetul necesar i din meniul principal se alege
opiunea Tools>C++>Code Generation:

Fig. 4-5.12. Generarea codului din pachete


A fost folosit pachetul procese ce conine urmtoarea diagram:

Proces
(from Logical View)

id_proces : int
prioritate : double
starea : int
tipul : int
spatiul_de_adrese : memoria_RAM

proces de sistem

proces utilizator

Fig. 4-5.13. Structura pachetului procese


n mapa Source se va crea mapa Procese cu fiierele: proces de sistem.h, proces de
sistem.cpp, proces utilizator.h, proces utilizator.cpp. n acest cod se psteaz ierarhia creat
mai sus, adic clasele proces de sistem i proces utilizator sunt derivate de la clasa proces.

ntrebri de control:

1. Numii principalele avantaje ale abstractizrii.


2. Ce numim clas?
3. Descriei tipurile de relaii utilizate n diagrama claselor.
4. Cte nivele de vizibilitate recunoate UML?
5. Cum nelegei noiunea de clas abstract?
6. Care este diferena dintre clasele root i leaf?
7. Cte tipuri de stereotipuri sunt folosite n limbajul UML?
8. Descriei diagramele de clase.
9. Enumerai etapele pregtirii proiectului pentru generarea codului surs.
10. Cum are loc generarea codului din diagrama de clase, diagrama de componente i
din pachete?

LUCRAREA DE LABORATOR NR. 6

TEMA: Dezvoltarea elaborrilor cu diagramele de stare (statechart diagram), activitilor


i Reverse Engineering n

mediul Rational

Rose

pentru modelele

precedente

cu

modificri, perfectri i completrile respective

Scopul lucrrii:
1. Studierea prii teoretice i verificarea cunotinelor nsuite n mediul instrumentului
CASE Rational Rose.
2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea i
destinaia elementelor Statechart, activitilor i Reverse Engineering
3. Dezvoltarea modelului precedent din domeniul respectiv. nsuirea tehnicii de creare,
modificare i salvare a respectivelor modele elaborate cu diverse automate i liste ale
sistemului real-propus.
4. Studierea i descrierea modelrii comportamentale, componentele i operaiile de
manipulare (generare, modificare i salvare a modelului).
5. Completarea codului surs obinut din Classe i Statechart, activitilor, fiind executabil,
pentru evidenierea specificului operaiilor necesare i tehnicii eficiente de testare i
reutilizare.
6. Verificarea codului surs completat n mediul limbajului C++, expunnd rezultatele,
crearea modelul n UML prin metoda Reverse Engineering i compararea cu cel precedent.
7. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n
procesul efecturii lucrrii de laborator/1/.
Sarcina: Pentru sistemul din lucrarea de laborator Nr.2 elaborai cte trei diagrame a strilor
i activitilor.

Consideraii teoretice generale.


Modelarea comportamentului
Alturi de evidenierea claselor i a relaiilor dintre ele, este necesar i descrierea laturii
dinamice, respectiv a interaciunilor care au loc ntre clase i obiecte. Dou dintre conceptele
abordrii obiectuale sunt n mod particular vizate aici: starea i comportamentul.
Precedentele i scenariile se ntrebuineaz pentru descrierea comportamentului sistemului,
adic relaiile dintre obiecte. Uneori este necesar de a urmri comportamentul n interiorul
obiectului. Diagrama de stare (statechart diagram) reprezint poziia unui obiect singular,
activitile sau mesajele, care creeaz schimbul de la o stare la alta. Aceast diagram nu este

necesar pentru fiecare clas a sistemului, ci numai pentru clasele cu o comportare dinamic
deosebit. Pentru a determina obiectele dinamice din sistem, adic obiectele ce trimit sau
primesc un numr mare de mesaje, se pot folosi diagramele interaciunilor.
Stare (state) este o poziie oarecare n viaa obiectului, pentru care el ndeplinete o
anumit cerin, o oarecare activitate, sau ateapt un oarecare eveniment. Strile obiectului se
pot descrie cu ajutorul valorilor unui sau mai multor atribute ale clasei. Diagrama de stare
include toate mesajele, pe care obiectul le primete i le transmite. Scenariul este parcurgerea
unic a ntregii diagrame. Intervalul dintre dou mesaje, transmise de obiect, de obicei reprezint
o stare. De aceea pentru a determina strile obiectului este necesar de studiat diagrama
secvenelor (privii intervalele dintre liniile de comunicaii, primite de obiect).
Starea poate evolua n timp. n consecin, valorile prin care trec, declanatorii tranziiilor
de la o stare la alta i condiiile necesare pentru ca aceasta s aib loc trebuie identificate i
reprezentate corespunztor. Diagrama de stri este cea care servete n acest scop.
Definirea comportamentului presupune identificarea modului n care obiectele, aparin
diverselor clase, interacioneaz ntre ele. Aa cum s-a menionat deja, aceast interaciune are
forma unui schimb de mesaje n care un obiect emitent adreseaz o solicitare altui obiect
destinatar. Pentru a putea face acest lucru emitentul trebuie s poat cunoate i s aib acces la
destinatar. Ceea ce nseamn, pur i simplu c ntre acestea respectiv ntre clasele
corespunztoare, trebuie s existe o cale, direct sau indirect. Aceast cale este constituit, n
marea majoritate a cazurilor de asocieri. O prim concluzie: este posibil ca definirea
comportamentului s impun adugarea de noi asocieri la ceea ce diagrama claselor conine deja.
Pentru a putea primi un mesaj, destinatarul trebuie s aib o operaie corespunztoare
acesteia. Mai mult dect att, destinatarul trebuie s reacioneze la mesajul primit. Aceast reacie
poate fi strict local, constnd, de exemplu, n modificarea coninitului unor atribute, direct ca
rezultat al unor calcule prealabile, sau poate presupune un rspuns ctre emitent. n acest caz
apare o nou problem: ce face emitentul dup ce a emis mesajul? Se blocheaz n ateptarea
rspunsului sau continu cu alte prelucrri, pn la sosirea acestuia. n unele sisteme aceste
aspecte pot fi nu att de importante i deci ignorate, totul reducndu-se la un model de funcionare
strict secvenial. Exist ns i cazuri n care rolul lor este important, i prin urmare trebuie
stabilite riguros i reprezentate. Revenind acum la prelucrarea presupus de primirea unui mesaj,
aceasta poate fi executat n totalitate de destinatar. La fel de bine este posibil ca aceasta s fie
necesar s cear ajutorul altui obiect, evident tot printr-un mesaj, cu respectarea tuturor celor
menionate nainte.

Exist diverse aspecte i situaii, pentru a cror reprezentare nu se poate folosi un singur tip
de diagram. UML propune, n consecin, trei reprezentri: diagrama de colaborri, diagrama
strii i diagrama de activiti. Fiecare dintre acestea este adaptat anumitor utilizri.
Alturi de simplitate aceste diagrame se mai caracterizeaz prin calitatea de a nu fi numai o
modalitate de reprezentare ci i un suport n identificare i definitivare a elementelor de
comportament. Anterior au fost menionate o serie de ntrebri. Dar nu a fost formulat cea mai
important: cum se poate stabili care sunt emitenii i destinatarii, ce mesaje trebuie schimbate
ntre acetia, care sunt operaiile necesare fiecrei clase de obiecte i ce trebuie s fac acetia
exact. Rspunsul se bazeaz pe cazurile de utilizare. Diagramele amintite vor fi ntocmite pentru
fiecare caz de utilizare i fiecare scenariu.
diagrama de
stari

diagrama de
activitati
caz de utilizare

diagrama de
secventa

scenarii din
descriere

diagrama de
colaborari

Fig. 6.1. Corelaiile dintre cazurile de utilizare i diagramele de comportament


Cu ajutorul diagramelor de secven i de colaborri pot fi identificate i reprezentate
configuraiile de obiecte i clase, interaciunile dintre acestea, necesare obinerii funcionalitilor
specifice fiecrui scenariu. Diagramele de activiti servesc pentru a completa descrierea cazului
de utilizare, iar diagrama de stri, pentru acele clase participante la cazul de utilizare ale cror
schimbri de stare sunt numeroase sau semnificative. Setul complet de operaii i de relaii
aferent fiecrei clase se obine, n cele din urm, prin reunirea acestora din toate cazurile de
utilizare i scenariile la care particip.
Diagramele de stare. Conceptul de stare deine un loc important n diagrama obiectual.
Schimbrile de stare pe care le poate suporta un obiect influeneaz comportamentul acestuia,
ceea ce justific suficient de convingtor necesitatea evidenierii i studiului lor. Aceasta
comport o dubl dimensiune: pe de o parte aceea a enumerrii strilor posibile i a eventualelor
reguli sau restricii care guverneaz ordinea nlnuirii lor, n ali termeni, a ciclului de via al
obiectului, i pe de alt parte, a stimulilor sau evenimentelor care declaneaz sau determin
trecerea de la o stare la alta. Diagrama de stri servete pentru a reprezenta ansamblul de stri
prin care poate trece un element de modelare fie acesta obiect sau interaciune n cursul
execuiei sale, ca reacie la evenimentele survenite din exteriorul su. Starea este definit n

aceast viziune, fie prin valorile sau combinaiile de valori luate de anumite atribute, fie printr-un
calificativ de natur abstract, conceptual, determinat de logica activitii de afaceri.
Diagramele de stare sunt destinate pentru modelarea diferitor stri n care poate s se afle
obiectul. n timp ce diagrama claselor arat imaginea static a claselor i legturile lor, diagrama
strilor se folosete la descrierea dinamic a comportamentului sistemului. Diagrama de stare
reflect comportamentul obiectului. Principalele stri ale diagramei sunt: nceput i sfrit.
nceputul grafic este reprezentat ca un cerc plin de culoare neagr, i corespunde strii obiectului
n momentul crerii. Starea final se reprezint grafic prin dou cercuri unu n altul. Cel din
mijloc este plin de culoare neagr. Sfritul corespunde strii obiectului nainte de distrugerea lui.
Diagrama de stare poate avea numai o stare de nceput, iar stri finale cte sunt necesare. Cnd
obiectul se afl ntr-o stare concret se pot ndeplini unele procese sau altele. Diagrama de stare
nu trebuie numaidect construit pentru fiecare clas. Ele se construiesc numai n cazuri
excepional de grele. Dac obiectul clasei poate exista n mai multe stri, i n fiecare se
comport diferit probabil va trebui o astfel de diagram. ns n multe proiecte nu se folosesc.
Dac totui diagramele de stare au fost construite, elaboratorii le pot folosi la crearea claselor.
Diagramele de stare sunt necesare n majoritatea cazurilor pentru documentare. La generarea
codului surs n Rose, la baza modelului nostru nu va fi nici un cod. Cu att mai mult la sistemele
ce lucreaz n regim real de timp le sunt accesibile diferite extensii Rose, care permite generarea
codului care se bazeaz pe diagramele de stare.
n Rose se poate crea o diagram de Stare pentru o clas. Pe ea sunt reprezentate toate
strile i trecerile acestei clase. Starea (State) se mai numete una din condiiile posibile, n care
poate exista un obiect. Pentru determinarea strii obiectului trebuie de cercetat dou regiuni ale
modelului: valoarea atributelor obiectului i legturile cu alte obiecte. Starea obiectului se alege
n dependen de faptul dac exist legtur sau nu.
Acest tip de diagram e folosit pentru a modela comportamentul unui singur obiect. Ea
specific o secven de stri prin care trece obiectul de-a lungul vieii sale ca rspuns la
evenimente. Un eveniment reprezint ceva atomic ce se ntmpl la un moment dat i are ataat
o locaie n timp i spaiu. Evenimentul modeleaz apariia unui stimul care poate conduce la
efectuarea unei tranziii ntre stri. Evenimentele pot include:
1.

semnale - un stimul asincron care are nume i este aruncat de un obiect i

recepionat de altul;
2.

apeluri de operaii (de obicei sincrone);

3.

trecerea timpului;

4.

schimbarea strii.

Starea are mai multe elemente:

nume indic n mod unic o stare;

aciuni de intrare/ieire aciuni ce se produc la intrarea, respectiv ieirea din

starea respectiv;

substri acestea pot fi disjuncte (secvenial active) sau concurente ( simultan

active);

tranziii interne;

O tranziie reprezint o relaie ntre dou stri indicnd faptul c un obiect aflat n prima
stare va efectua un ir de aciuni i apoi va trece n starea a doua cnd se va petrece un anumit
eveniment:
starea
sursa
eveniment[ conditia garda ] / actiune
starea
destinatie

Forma general a unei diagrame de stri este reprezentat n figura urmtoare. Aa cum se
poate observa, exist numai dou tipuri de componente: tranziiile i strile, printre acestea din
urm putndu-se evidenia dou tipuri particulare: stare iniial i stare final.

stare initiala

NewState

stare

tranzitie si
evenim...
NewState2

stare finala

Fig. 6.2. Modelul general al unei diagrame de stare

Tranziia constituie trecerea de la o stare la alta, asociat eventual cu executarea unei


aciuni. O tranziie este, cel puin instantanee. Este posibil ca cele dou stri implicate ntr-o
tranziie s fie identice.
Tranziia poate fi declanat de ncheierea aciunilor i activitilor interne strii curente sau
de producerea unui eveniment. Detaliile suplimentare privitoare la o tranziie pot fi furnizate prin
ataarea la simbolul su grafic a unui text cu urmtoarea structur:
Semntur-eveniment [ conditie-de-declansare] / expresie
Semntura evenimentului opional cuprinde numele evenimentului, urmat de o
eventual list de parametri, ncadrat n paranteze rotunde.
Este considerat drept eveniment orice schimbare notificabil care determin o modificare
de stare. Evenimentele pot consta din:

Verificarea unei condiii predefinite; UML propune pentru acest tip de evenimente o notaie
de tipul: when expresie condiional.

Scurgerea unui anumit interval de timp; UML propune pentru acest tip de evenimente o
notaie de tipul: after (durat) sau when (moment);

Primirea unui semnal de la un alt obiect (semnalul este el nsi un obiect);

Invocarea unei operaiuni de ctre un alt obiect sau de ctre acelai obiect.
Ultimele dou mai sunt numite evenimente mesaj.
Un eveniment este vizibil pentru toate obiectele din cadrul pachetului n care apare.
Condiia de declanare este evaluat numai la producerea evenimentului i autorizeaz sau

anuleaz producerea tranziiei. n oricare din aceste alternative, evenimentul este consumat i
nu mai poate produce efecte chiar dac ulterior condiia de declanare devine adevarat.
Expresia definete eventuala aciune de executat odat cu efectuarea tranziiei.
when (SfirsitAnUniversitar)
[Credite>=120 SI Medie >=6]
An II

An III

when (SfirsitAnUniversitar)
when (SfirsitAnUniversitar)

[Credite<120 SAU Medie<6]

[Credite>=120SI Medie >=6]

Nepromova
t

OptiuneAnSuplimentar

An II
suplimenta

after (30 zile)


when (SfirsitAnUniversitar)
Exmatricul
at

[Credite<120SAU Medie<6]

Fig.6.3. Diagrama de stare pentru promovarea studenilor n anul III de studii


Figura dat conine un exemplu de diagram de stare referitoare la studenii care ncheie
anul II de studii. Promovarea n anul III se face numai dac s-au acumulat cele 120 de puncte de

credit prevzute de planul de nvmnt i media general este de cel puin 6. n caz contrar, se
poate opta pentru un an suplimentar sau studentul este exmatriculat. La ncheierea anului II
suplimentar trebuie respectate aceleai condiii. Nendeplinirea lor atrage dup sine
exmatricularea.
Fig.6.4.
nu

nu

nu

demisie

transfer

joaca

da

joc

da

da

transferare

demisionare

Diagrama Statechart (strilor) pentru clasa jucator


n aceast diagrama totul este construit pe baza strrii juctorului. Dac juctroul joac n
acest club atunci el trece n starea joc, dac el se transfer atunci el trece n starea transferare etc.
Dac el are o alt stare atunci automat trece spre sfrit.
Starea surs reprezint starea din care se pleac. Evenimentul este cel care declaneaz
tranziia. Condiia de gard este o expresie boolean, aceasta se evalueaz la producerea
evenimentului care declaneaz tranziia. Tranziia poate avea loc numai dac e satisfcut
condiia. Aciunea se poate specifica opional, ea se execut odat cu efectuarea tranziiei. Starea
destinaie reprezint starea n care ajunge obiectul dup executarea tranziiei.

Diagramele activitilor. Diagramele de activitate servesc pentru descrierea dinamicii


sistemului n situaiile n care strile observate sunt reprezentate de aciuni sau
subactiviti, iar evenimentele care declaneaz tranziia de la o stare la alta, sunt n
totalitate sau n cea mai mare parte, constituite de ncheierea acestor aciuni sau
subactiviti. Acest tip de diagram folosete urmtoarele elemente: aciuni,
tranziii, puncte de decizie i bare de sincronizare.
Termenul de tranziie este folosit n accepiunea de stare constnd din efectuarea unei
anumite prelucrri; de altfel, numele folosit n UML este acela de stare - aciune. Finalizarea
prelucrrii este evenimentul implicit care declaneaz tranziia spre starea urmtoare. Dac exist
mai mult dect o singur stare ulterioar, se poate proceda n dou moduri: fie se alege doar una
din aciuni pe baza unei expresii condiionale, iar selecia ca atare este semnalat prin plasarea n
locul respectiv a unui punct de decizie, fie se execut simultan toate aciunile, dup care se
marcheaz sincronizarea indispensabil continurii prelucrrilor.
Documentaia UML precizeaz c o aciune se utilizeaz n mod normal pentru a modela
un pas din execuia unui algoritm, proceduri sau proces de gestiune.
n cele mai multe cazuri, diagramele de activitate sunt delimitate printr-un punct de start i
un punct final, care marcheaz iniierea, i respectiv, ncheierea secvenei de activiti sau aciuni
reprezentate. Pentru ilustare, n figura urmtoare este prezentat un model generic de diagram de
activitate.
punct initial
actiune 1
decizie
cond 1

actiune 3

cond 2
actiune 2

executie
simultana
actiune 4

actiune5

punct final

Fig.6.5. Modelul general al unei diagrame de activitate


Subactivitatea constituie o secven bine definit de aciuni. Plasarea unei subactiviti n
diagram nseamn execuia, n punctul respectiv, a aciunilor cuprinse de aceasta. Subactivitile
constituie un mod eficient de simplificare a diagramelor, prin semnalarea compact a grupului de
aciuni pe care-l reprezint. De asemenea, definirea de subactiviti permite s se evite repetarea
anumitor secvene comune din diagrame diferite. Subactivitile sunt reprezentate grafic sub
forma unei aciuni notate cu un simbol de imbricare.
Diagramele de activiti sunt cazuri particulare ale diagramelor de stri. n ele sunt
reprezentate trecerile fluxului de control de la o activitate la alta n cadrul sistemului. Acest tip de
diagram este folosit pentru a modela dinamica unui proces sau a unei operaii. Spre deosebire
de diagrama de interaciune care evideniaz controlul execuiei de la obiect la obiect, diagramele
de activiti scot n eviden controlul execuiei de la o activitate la alta. Aceste diagrame pot
conine:
-

Stri-activiti sau stri-aciune: sunt stri ale sistemului. Ele modeleaz ceva ce se ntmpl
(evaluarea unei expresii, apelul unei operaii a unui obiect, crearea sau distrugerea unui
obiect). O stare-aciune reprezint execuia unei aciuni. Ea nu poate fi descompus, strileaciune sunt atomice (nu pot fi ntrerupte) i au o durat nesemnificativ. Strile-activiti pot
fi descompuse, activitatea lor putnd fi reprezentat cu ajutorul altor diagrame de activiti.
Strile-activiti nu sunt atomice (ele pot fi ntrerupte de apariia unui eveniment) i
ndeplinirea lor se face ntr-un interval oarecare de timp.

Tranziii atunci cnd se termin execuia unei activiti sau aciuni, controlul este dat
urmtoarei aciuni sau activiti prin intermediul tranziiei

Obiecte
Exist posibilitatea ca mai multe activiti s se execute n paralel. Pentru sincronizarea

acestora se folosete aa-numita bar de sincronizare. Aceasta poate fi de 2 tipuri:


a) Fork - are o tranziie de intrare i una sau mai multe tranziii de ieire, fiecare tranziie
de ieire prezentnd un flux de control independent:

b) Join poate avea 2


sau mai multe tranziii de
intrare i una singur de ieire, n acest caz fiecare flux de control ateapt pn cnd toate
celelalte fluxuri de intrare ajung n acel punct:

registrul de deplasare

magistrala interna

UAL

Registrul general

start

selecteaza registrul care


contine operandul

transmite

inscrie
operandul

trece operandul modificat

citeste operatia
din registru

comanda deplasarea
stinga cu o pozitie

citeste
rezultatul

executa
deplasarea

transmite
rezultatul

selecteaza
registrul

inscrie
rezultatul

end

Fig.6.6. Diagrama de activitate


Bara de instrumente speciale proprie Diagramei Statechart

2 3

8 9

1. Comanda de selectare.
2. Comanda de scriere a unui text.
3. Comanda de adugare a unui comentariu .
4. Comanda de legare a comentariului de elementul pe care-l nsoete.

5. Comanda de adugare a unei stri.


6. Comanda de adugare a unei stri iniiale.
7. Comanda de adugare a unei stri finale.
8. Comanda de adugare a unei tranziii de la o stare la alta.
9. Comanda de adugare a unei tranziii de la o stare la ea nsi.
n continuare sunt prezentate diagrame de stare pentru modelarea elaborrii unui soft la
mod general de ctre o echip de IT-specialiti n baza diagramei claselor. n aceast diagram
avem prezentat componena echipei de IT specialiti. Astfel fiecare lucrtor intr n una sau alt
categorie de specialiti grupai n clase: de programatori, designeri, testeri i project manageri.
Fiecare clas face parte din clasa general, execut operaii din aceast clas precum i operaii
proprii.

Fig.6.7.
Diagrama
claselor ce
indic
componena
echipei de IT
specialiti

Fig.6.8. Diagrama de stare privind strile ProjectManagerului

Fig.6.9. Diagrama de stare privind strile programatorului

Fig.6.10. Diagrama de stare privind strile designerului

Fig.6.11. Diagrama de stare privind strile testerului


Reverse Engineering
De creat modelul n UML prin metoda Reverse Engineering dintr-un cod surs C++.
Fie c avem urmtorul cod de program care creaz clasa ca o ierarhie de tipuri main,
transport de cltori i autobus.
Pentru aceasta avem urmtorul cod de program n .cpp:
//#include<iostream.h>

//#include<string.h>

//#include<conio.h>

class Masina{
protected:
char m_marca[20];
int nr_usi;
int nr_roti;
int nr_locuri;
public:
Masina();
//implicit
Masina(char *marca, int nr_u, int nr_r, int nr_l); //de initializare
Masina(Masina & m);
//de copiere
~Masina() {};
Masina Init(char *marca, int nr_u, int nr_r, int nr_l);
void ShowMasina();
};
//--------------------------------------------------------------class Transport_Calatori:virtual public Masina{
protected:
char tc_ruta[30];
public:
Transport_Calatori();
//implicit
Transport_Calatori(char *ruta): Masina() {strcpy(tc_ruta,ruta);} //de initializare
Transport_Calatori(Transport_Calatori & tc);
//de copiere
virtual ~Transport_Calatori() {};
virtual Transport_Calatori SetRuta(char *ruta);
virtual Transport_Calatori GetRuta();
virtual void ShowTransport_Calatori();
};
//--------------------------------------------------------------class Autobus:virtual public Transport_Calatori{
public:
Autobus(): Transport_Calatori() {};
//implicit
Autobus(char marca, int nr_u, int nr_r, int nr_l, char ruta): //de initializare
Transport_Calatori() {};
virtual ~Autobus() {};
virtual Autobus Init(char *marca, int nr_u, int nr_r, int nr_l, char *ruta);
virtual void ShowAutobus();
};
//================== Descrierea claselor =================
//===================== MASINA ============================
Masina::Masina() {strcpy(m_marca,"Mazda"); nr_usi=4; nr_roti=4; nr_locuri=5;};
Masina::Masina(char *marca, int nr_u, int nr_r, int nr_l)
{ strcpy(m_marca,marca); nr_usi=nr_u; nr_roti=nr_r; nr_locuri=nr_l; }
Masina::Masina(Masina & m)
{
strcpy(m_marca,m.m_marca);
nr_usi=m.nr_usi;
nr_roti=m.nr_roti;

nr_locuri=m.nr_locuri;
}
Masina Masina::Init(char *marca, int nr_u, int nr_r, int nr_l)
{ strcpy(m_marca,marca); nr_usi=nr_u; nr_roti=nr_r; nr_locuri=nr_l; return *this;}
void Masina::ShowMasina()
{ cout<<"=== MASINA ==="<<endl;
cout<<"Marca:
"<<m_marca<<endl;
cout<<"Nr. usi: "<<nr_usi<<endl;
cout<<"Nr. roti: "<<nr_roti<<endl;
cout<<"Nr. locuri: "<<nr_locuri<<endl<<endl;
}
//=================== TRANSPORT_CALATORI ==========================
Transport_Calatori::Transport_Calatori() {strcpy(tc_ruta,"Chisinau <> Paris");}
Transport_Calatori::Transport_Calatori(Transport_Calatori & tc)
{ strcpy(tc_ruta,tc.tc_ruta); }
Transport_Calatori Transport_Calatori::SetRuta(char *ruta)
{ strcpy(tc_ruta,ruta); return *this; }
Transport_Calatori Transport_Calatori::GetRuta() { return tc_ruta;}
void Transport_Calatori::ShowTransport_Calatori()
{ cout<<"=== Transport de Calatori ==="<<endl;
cout<<"Ruta: "<<tc_ruta<<endl<<endl;
}
//===================== AUTOBUS =================================
Autobus Autobus::Init(char *marca, int nr_u, int nr_r, int nr_l, char *ruta)
{ strcpy(m_marca,marca); nr_usi=nr_u; nr_roti=nr_r; nr_locuri=nr_l;
strcpy(tc_ruta,ruta); return *this;
}
void Autobus::ShowAutobus()
{ cout<<"=== AUTOBUS ==="<<endl;
cout<<"Marca:
"<<m_marca<<endl;
cout<<"Nr. usi: "<<nr_usi<<endl;
cout<<"Nr. roti: "<<nr_roti<<endl;
cout<<"Nr. locuri: "<<nr_locuri<<endl;
cout<<"Ruta: "<<tc_ruta<<endl<<endl<<endl;
}
//====================== MAIN ===============================
void main()
{ Masina m1, m2("BMW",4,4,5), m3=m1;
Transport_Calatori tc1, tc2("Chisinau <> Madrid"), tc3=tc1;
Autobus a1,a2=a1;
clrscr();
cout<<"M1: "<<endl; m1.ShowMasina();
cout<<"M2: "<<endl; m2.ShowMasina();
cout<<"M3: - copia M1"<<endl; m3.ShowMasina();

cout<<"M3: - ReInit"<<endl;
m3.Init("Opel",4,4,5); m3.ShowMasina();
getch(); clrscr();
cout<<"TC1: "<<endl; tc1.ShowTransport_Calatori();
cout<<"TC2: "<<endl; tc2.ShowTransport_Calatori();
cout<<"TC3 - copia TC1: "<<endl; tc3.ShowTransport_Calatori();
cout<<"TC3: - ReInit"<<endl;
tc3.SetRuta("Chisinau <> Roma"); tc3.ShowTransport_Calatori();
getch(); clrscr();
cout<<"A1.ShowMasina: "<<endl;
a1.ShowMasina();
cout<<"A1.ShowTransport_Calatori: "<<endl; a1.ShowTransport_Calatori();
cout<<"A1 - copia A1: "<<endl;
a2.ShowMasina();
a2.ShowTransport_Calatori();
a1.Init("Mercedes-Benz",4,4,40,"Chisinau <> Berlin");
cout<<"A1.ShowAutobus: - ReInit"<<endl; a1.ShowAutobus();
getch();
}
Clasa dat conine:
1. modurile de acces:
-

public (pentru metode),

private (pentru variabile).

2. constructori i destructor
3. funcii de prelucrare a informaiei
n timpul modelrii inverse analizatorul utilizeaz informaia obinut din codul surs,
precum i valoarea parametrilor ai proiectrii inverse. Cu aceti parametri se stabilesc, n
particular, ceea ce se creeaz pentru fiecare construcie C++.
n timpul modelrii inverse analizatorul supune acest fiier recunoaterii gramaticale i
determin care clase, atribute i alte elemente ale modelului trebuie create.
n model sunt generate urmtoarele elemente:
- nsi clasa, creat n reprezentarea logic
- Atributele i operaiile clasei
- Pachetul reprezentrii logice care conine clasa. Numele acestui pachet devine numele
directoriului n care se conine fiierul surs.
- Diagrama claselor, pe care sunt reprezentate clasele care sunt supuse proiectrii inverse. n
mod implicit, numele acestei diagrame Reverse Engireered. Se poate de modificat numele
diagramei, modificnd proprietile proiectrii inverse n C++ Analyzer

- Diagrama pachetelor, n care sunt reprezentate pachetele claselor, supuse proiectrii


inverse. n mod implicit numele acestei diagrame este Reverse Engineered, dar el poate fi
modificat cu ajutorul proiectrii inverse.

Model de creare a modelului prin Reverse Engineering:


Procesul de modelare invers const din urmtoarele etape:
I.

Lansarea aplicaiei C++ Analyzer

II.

Crearea unui proiect nou

III.

Stabilirea antetului proiectului

IV.

Stabilirea listei de directorii

V.

Stabilirea listei extensiilor

VI.

Alegerea proiectului de baz

VII.

Alegerea fiierelor pentru proiectarea invers

VIII. Analiza fiierelor


IX.

Stabilirea parametrilor pentru export

X.

Exportarea n Rose

Etapa I: Lansarea aplicaiei C++ Analyzer


Proiectarea invers, n C++ se realizeaz cu ajutorul aplicaiei, extern n raport cu Rational
Rose. Utiliznd-o, se pot alege fiiere pentru proiectare invers, se pot seta proprieti de
proiectare revers i genera modelul Rose.
Mai nti alegem Tools -> Reverse Engineering, dup care se execut C++ Analyzer.
Etapa II: Crearea proiectului nou
Dup executarea C++ Analyzer urmtorul pas este crearea proiectului nou. Proiectul
reprezint un fiier al analizatorului, care conine un set de fiiere, care trebuie transferate n
modelul Rational Rose.
Alegem File > New, i proiectul nou al analizatorului este creat.

Etapa III: Stabilirea antetului proiectului


Antetul proiectului reprezint o caracterizare succint a destinaiei proiectului. Dac este
indicat antetul proiectului, iar apoi acest proiect se utilizeaz ca proiect de baz pentru un alt
proiect, atunci antetul se introduce n lista de baz. Antetul nu este obligatoriu pentru a-l seta,

alegem butonul Caption n fereastra project. Dup care se poate introduce antetul proiectului n
fereastra Caption.
Etapa IV: Stabilirea listei directoriilor
Aceast etap nu este obligatorie. La alegerea fiierelor din etapa a VII-a, lista directoriilor
se completeaz automat. Oricum, opional, aceast list poate fi modificat pn, sau dup
alegerea fiierelor.
n aceast list se prezint acele directorii, n care se conin fiiere C++, care vor fi supuse
proiectrii inverse. Alegerea directoriilor i adugarea lor n aceast list poate fi fcut cu
ajutorul butonului Directories n fereastra proiectelor.
Dup alegerea acestui buton apare fereastra Project Directory List. Alegem directoriul
necesar, i-l adugm tastnd pe butonul Add Current. Dac apsm pe butonul Add Subdirs,
atunci se adaug acest directoriu, subdirectorii si i subdirectorii acestora imediat urmtoare, iar
dac apsm pe Add Hierarchy, atunci se adaug acest directoriu i toi subdirecorii ultimilor.
Etapa V: Stabilirea listei extensiilor
Aceast etap nu este obligatorie. La alegerea fiierelor din etapa a VII-a n list automat
apar extensiile acestor fiiere. Oricum, aceast list poate fi stabilit opional. Aceasta este o list
de extensii a fiierelor surs, care vor fi supuse proiectrii inverse, precum i fiierele antet,
conectate la primele fiiere cu ajutorul operatorului #include. Extensiile adugate n aceast
list, devin filtre alese implicit la alegerea fiierelor ce vor fi supuse proiectrii inverse la etapa
VII. Spre exemplu, dac adugm n list extensia .cpp, atunci vor fi admise la proiectarea
invers doar fiiere cu extensia .cpp.
Etapa VI: Alegerea proiectului de baz
Proiect de baz se numete fiierul proiectului C++ Analyzer, care conine informaii
despre clasele de baz utilizate. Poate, spre exemplu, s existe proiectul analizatorului, n care se
pstreaz date despre careva clase de baz C++, create la organizare. n fiecare proiect al
companiei aceste clase vor fi considerate ca clase de baz. Proiectul analizatorului, unde se
conin date despre calea spre fiier, numele fiierelor i alte informaii despre clasele de baz,
devine pentru proiectul n cauz de baz.
La avantajele proiectelor de baz se refer posibilitatea reutilizrii. Aceasta permite
utilizarea repetat a componentelor n diferite proiecte, astfel asigurnd coordonarea proiectelor.
Pentru proiectarea invers proiectele de baz nu sunt obligatorii. Pentru a aduga un proiect
de baz n list, artm calea ctre fiier i a numelui su cu ajutorul cmpurilor Directories i

File name i executm click cu mouse-ul pe butonul Add. n fereastra proiectelor va aprea
proiectul de baz i antetul su.
Etapa VII: Alegerea fiierului pentru proiectarea invers
La aceast etap sunt alese toate fiierele C++ care vor fi supuse proiectrii inverse. Mai
nti alegem butonul File n fereastra proiectului. Apare fereastra fiierelor proiectului.
n ierarhia Directory structure alegem directoriul care conine fiierele necesare. n mod
implicit fiierele din directoriul curent cu extensia .h, .hh, .hxx, .cpp, .cxx, .cc, .c sunt prezente n
lista Files Not In List (Filtered). Dac n lista extensiilor au fost incluse careva extensii, atunci
se utilizeaz ultimele.
Pentru a alege fiierul, l alegem mai nti din lista Files Not In List(Filtered). Click pe
butonul Add Selected, mutnd-ul n lista Files In List (Flitered), sau pe butonul Add All, trecnd
astfel n list toate fiierele.
Repetm acest proces, alegnd directoriile i fiierele, pn cnd n lista Files In List
(Flitered) nu vor fi prezente toate fiierele, care vor fi supuse ulterior proiectrii inverse. Click pe
OK i toate fiierele vor aprea n fereastra proiectului.
Etapa VIII: Analiza fiierelor
La aceast etap informaia, necesar pentru proiectare invers, se analizeaz utiliznd
fiierele alese la etapa VII. La apariia erorilor acestea sunt introduse n fereastra registrului.
Pentru a trece la analiza fiierelor, alegei-le n lista Files. Pentru aceasta tastai Ctrl+A.
Pentru nceperea analizei alegem Action ->Analyze sau tastai F3. n procesul de recunoatere
gramatical i studierii fiierelor, rezultatele procesului vor fi scrise n registru.
n fereastra listei Files se afieaz i numrul de erori din fiecare fiier. Pentru a analiza
greelile fiierului, dublu click pe fiier din lista Files a ferestrei registrului. Ca rezultat pe ecran
vor fi afiate informaii despre erori.
Etapa IX: Stabilirea parametrilor pentru export
Dup analiza codului program, aceast informaie se utilizeaz pentru crearea modelului
Rose. n C++ Analyzer exist un set ntreg de parametri pentru proiectarea invers, la fel ca i
pentru generarea codului din modelul Rational Rose. Pentru selectarea parametrilor
coorespunztori alegei Edit -> Export Options sau tastai Ctrl+R.

Etapa X: Exportul n Rational Rose


Ultima etap reprezint exportul fiierelor n modelul Rational Rose. Pentru aceasta alegem
Action-> Export to Rose sau tastm F8. Apare fereastra de dialog Export to Rose.
n aceast fereastr de dialog se poate stabili numele modelului generat, antetul proiectului
i setul parametrilor pentru utilizarea ulterioar. n afar de aceasta aici se ofer viziunea
parametrilor n fereastra Summary of Options. Pentru generarea modelului efectuai click pe
butonul OK n aceast fereastr. Dac modelul cu numele fiierului indicat nu exist analizatorul
va oferi posibilitatea rescrierii acestuia.
Fiecare din elementele de date ale claselor n cauz devine sau atribut, sau legtur a
modelului generat. Dac tipul de date a elementului de date este alt clas a modelului, atunci se
creaz o legtur de agregare. Dac tipul de date nu este alt clas a modelului, el devine atribut.
Funciile membru se genereaz n modelul Rose numai n calitate de operaii.
Dac n calitate de tip de date pentru argument sau tip returnat se utilizeaz alt clas a
modelului, atunci se genereaz i legtura corespunztoare, ca i pentru elementele de date.
Declaraiile Friend din codul program C++ se genereaz n modelul Rose n calitate de
dependene.
Legturile de motenire n C++ se modeleaz n Rose cu ajutorul legturilor de
generalizare. Analizatorul execut proiectarea invers a clasei printe i celei copil, stabilindu-le
pe diagrama claselor.
n continuare se reprezint elementele generate de Rational Rose n tipmul Reengineeringului:
autobus

Fig.6.12. Pachetul cu numele modelului

autobus

Fig.6.13. Diagrama de componente (n cazul dat avem numai o component corp)

Masina
m_marca : char [20]
nr_usi : int
nr_roti : int
nr_locuri : int
Masina() : Masina
Masina(marca : char*, nr_u : int, nr_r : int, nr_l : int) : Masina
Masina(m : Masina&) : Masina
~Masina()
Init(marca : char*, nr_u : int, nr_r : int, nr_l : int) : Masina
ShowMasina() : void

Transport_Calatori
tc_ruta : char [30]
Transport_Calatori() : Transport_Calatori
Transport_Calatori(ruta : char*) : Transport_Calatori
Transport_Calatori(tc : Transport_Calatori&) : Transport_Calatori
~Transport_Calatori()
SetRuta(ruta : char*) : Transport_Calatori
GetRuta() : Transport_Calatori
ShowTransport_Calatori() : void

Autobus
Autobus() : Autobus
Autobus(marca : char, nr_u : int, nr_r : int, nr_l : int, ruta : char) : Autobus
~Autobus()
Init(marca : char*, nr_u : int, nr_r : int, nr_l : int, ruta : char*) : Autobus
ShowAutobus() : void

Fig.6.14. Diagrama de clase (avem o ierarhie de clase)


ntrebri de control:
1. Ce reprezint diagrama de stare, cnd se utilizeaz?
2. Care sunt caracteristicile de baz ale diagramei de colaborri, diagrama strii i diagrama de
activiti?
3. Caracterizai diagrama de activiti.
4. Cte tipuri de bare de sincronizare se folosesc n diagrama de activiti?
5. Descriei etapele procesului de modelare invers.

LUCRAREA DE LABORATOR NR. 7


TEMA: Dezvoltarea elaborrilor cu diagramele amplasrilor
Scopul lucrrii:
1. Studierea prii teoretice i verificarea cunotinelor nsuite n mediul instrumentului
CASE Rational Rose.
2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea i
destinaia elementelor diagramelor amplasrilor.
3. Dezvoltarea modelului precedent din domeniul respectiv.
4. Studierea i descrierea modelrii comportamentale, componentele i operaiile de
manipulare (generare, modificare i salvare a modelului).
5. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n
procesul efecturii lucrrii de laborator.
Sarcina: Pentru sistemul iniial elaborai cte trei diagrame ale componenetelor i
desfurrilor.
Consideraii teoretice.
Diagrama amplasrii
Diagramele amplasrilor prezint configuraia elementelor de procesare din timpul
execuiei i componentele, procesele i obiectele care le conin. Fiecare model al unui sistem
informatic are asociat o singur diagram de exploatare.

Instanele componentelor soft

reprezint manifestri a unor uniti de cod n cadrul execuiei. Componentele care nu exist ca
entiti de execuie nu apar n aceste diagrame, ci doar n diagramele de componente.
O diagram de exploatare este un graf de noduri conectate prin asocieri de comunicare.
Nodurile pot conine instane ale componentelor (componenta exist sau se execut pe nodul
respectiv). Componentele pot conine obiecte (acestea sunt localizate n componente).
Componentele sunt conectate cu alte componente sau interfeele acestora prin intermediul unor
relaii de dependen (sgei ntrerupte) ceea ce reprezint faptul c o component folosete
serviciile altei componente.

Pot fi utilizate stereotipuri pentru a preciza n detaliu tipul

dependenei dintre componente.


Un nod este o entitate fizic ce reprezint o resurs de procesare, avnd o memorie i
anumite capabiliti de procesare (dispozitive de calcul, resurse umane, resurse de procesare
mecanic).

Aceast diagram arat distribuirea tuturor nodurilor reelei, legturile dintre ele i
procesele care sunt efective la fiecre nod. Aici se folosesc doar relaiile de asociere.
NewPro
cessor

procesor- este numit orice main care are puterea de calcul, adic
este capabil s prelucreze datele. La aceast categorie se refer: serverele,
staiile de lucru, .a., echipamente care conin procesoare fizice.

- periferic este numit aparatajul care nu are proprieti de prelucrare a datelor. La aceast
NewDe
vice

categorie se refer: printerul, scanerul, terminale de intrare-ieire. Se folosete legtura de


asociere.
Exemplul acestei diagrame este pe pagina urmtoare.
Diagrama de componente
O diagram de componente prezint dependenele existente ntre diverse componente
software (cod surs, cod binar, fiiere executabile, librrii cu legtur dinamic etc) ce compun
un sistem informatic. Aceste dependene sunt statice (au loc n etapele de compilare sau linkeditare) sau dinamice (au loc n timpul execuiei).
O component este un modul soft (cod surs, cod binar, dll, executabil etc) cu o interfa bine
definit. Un tip de component reprezint o parte distinct, realocabil, a implementrii unui
sistem. Instana unei componente este o unitate de implementare n execuie i poate fi utilizat
pentru reprezentarea unitilor de implementare care au o identitate n momentul execuiei.
Crearea diagramei amplasrilor:
Adugarea nodurilor la diagrama Amplasrilor:
1. Dublu click pe Deployment View n browser, deschidem diagrama amplasrilor.
2. Acionm butonul Processor pe panoul de instrumente.
3. Click cu mouse-ul pe diagram, punem procesorul.
4. l numim Serverul bazelor de date.
5. Repetnd paii 2-4, adugm urmtoarele procesoare:
-

Serverul aplicaiei.

Staia de lucru client nr.1.

Staia de lucru client nr.2.

6. Pe panoul de instrumente acionm butonul Device.


7. Plasm dispozitivul pe diagram.
8. l numimPrinter.
Adugarea legturilor:

1. Acionai butonul Connection pe panoul de instrumente.


2. Click pe procesorul Serverul bazelor de date.
3. Tragem linia de legtur la procesorul Serverul aplicaiei.
4. Repetm paii 1-3, adugm urmtoarele legturi:
- de la procesorul Serverul aplicaiei la procesorul Staia de lucru client nr.1.
- de la procesorulServerul aplicaiei la procesorul Staia de lucru client nr.2. De la
procesorul Serverul aplicaiei la dispozitivul Printer.
Adugarea proceselor:
1. Click cu dreptul pe procesorulServerul aplicaiei n browser.
2. n meniul deschis alegem punctul New-Process.
3. Numim OrderServerExe.
4. Repetm paii 1-3, adugm procesele:
- procesul OrderClientExe pe procesorul Staia de lucru client nr.1
- procesul ATMClientExe pe procesorul Staia de lucru client nr.2.
Prezentarea proceselor pe diagram:
1. Click cu dreptul pe procesorul Serverul aplicaiei.
2. n meniul deschis alegem punctul Show Process.
3. Repetm paii 1,2, pentru vizualizarea proceselor pe procesoarele:
- Staia de lucru client nr.1
- Staia de lucru client nr.2.
Serverul bazelor
de date

Serverul
aplicatiei

Printer

OrderServerEXE

Statia de lucru
clint nr.2
Statia de lucru
client nr.1
ATMClientEXE

OrderClientEXE

Fig.7.1. Diagrama amplasrilor pentru sistemul de prelucrare a comenzilor


ntrebri de control:

1. Definii noiunea de diagrama amplasrii, caracterizai elementele componente ale acestei


diagrame.
2. Descriei paii parcuri la crearea diagramei amplasrii.
3. Ce prezint diagrama de componente?

Anexe:

Diagrama secvenelor care indic interaciunea dintre obiecte. Descrierea timpului de via a
obiectelor
Crearea obiectului n intervalul de timp descris de
diagram

n momentul transmiterii mesajului obiectul deja exist

tergerea obiectului n intervalul de timp descris de


diagram

Diagrama secvenelor care indic interaciunea dintre obiecte. Transmiterea mesajului obiectului
lui nsui. Recursia
Transmiterea de ctre obiect a mesajului update( ) lui nsui
Transmiterea recursiv a mesajului more()

Diagrama secvenelor care indic interaciunea dintre obiecte. Transmiterea condiional de


mesaje

Sincronizarea lucrului obiectelor.


Apelul procedural, sau transmiterea mesajului cu ateptarea terminrii reaciei la
mesaj
Apelul asincron al operaiilor
ntoarcerea din procedur. Aceast sgeat poate s nu fie artat, dac se vede
clar, c mesajul este ultimul n lanul de mesaje

Diagrama secvenelor care indic interaciunea dintre obiecte. Indicarea intervalelor temporare

Diagrama secvenelor care indic interaciunea dintre obiecte. Exemplu: renoirea grafului pe
diagram

Diagrama secvenelor care indic interaciunea dintre obiecte. Exemplu de folosire a diagramei
la descrierea ablonului de proiectare

Diagrama secvenelor care indic interaciunea dintre obiecte. Descrierea timpului de via a
obiectelor

Diagrama secvenelor care indic interaciunea dintre obiecte. Mesajul: apelul procedural i
eveniment
Mesajul-apelul procedural

Mesajul - eveniment. Apelul


procedural are loc dup primirea
mesajului

Bibliografie:

1. Saru Daniela, Ioni Anca D. Sisteme de programe orientate pe obiecte.Buc.All.2000,


/UTM:004.4:004.43; s24/.
2. Ioni Anca Daniela. Modelarea UML n ingineria sistemelor de programe. Buc.: All. 2003.
3.Analiza

gestiunea

sistemelor

informatice

complexe,

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/.
4.UML

Applied,Object

Oriented

Analysis

and

Design

Using

the

UML,

www.ariadnetraining.co.uk.
5. Craig Larman UML M.: 2001.
6. Booch G., Jacobson L., 1997, The UML specification Documents.
7. Booch G., 1994, Object Oriented Analysis and Design.
8. Beck and Cunningham W., 1989, A Laboratory for Object oriented Thinking.
9. Buschman F., Mennier R., Robert H, Sommerlad P and Stal M., 1996, Pattern-Oriented
Software Architecture : A System of Patterns , West Sussex, England :Wiley.
10. Boehm B., 1998, A Spiral Model of Software Development and Enhancement . IEEE
Computer, May 1988.
11. Ambler S., 2000, Whitepaper : The Design of a robust persistence, Layer For Relational
Databases.
12. W.Boggs, M.Boggs - Mastering UML with Rational Rose 2002, Sybex [2002].
13. J.Rambaugh, I.Jacobson, G.Booch - The Unified Modeling Language Reference Manual,
Addison Wesley [1999].
14. Ariadne Training - UML Applied (Object Oriented Analysis and Design Using the UML),
Ariadne Training [2001].
15. OMG Unified Modeling Language Specification, Object Management Group Inc [2003].
16. Dan Chiorean, Iulian Ober, Marian Scuturici, Dan Mircea Suciu, Present and Perspectives in
the Object-Oriented Analysis & Design - The RO-CASE Experience, The Third International
Symposium in Economic Informatics, Bucharest, mai 1997.
17. D. Bozga, D. Chiorean, A. Frentiu, B. Rus, V. Scuturici, D. M. Suciu, D. Vasilescu, Rocase CASE Tool for Object-Oriented Analysis and Design, Research Seminars, Seminar on Computer
Science, Univ. "Babes-Bolyai" Cluj-Napoca, 1994.
18. Michael Boggs, Wendy Boggs, UML Rational Rose, Editura Lori, Moscova, 2001 (vezi pe
harddisk versiunea electronic: cap.5, 6 (p.146-179), cap.7 (p.223-257), cap.11,12 (p.287-359),
cap.20 (p.519-549).
19. Grady Booch, -
++ , Rational Santa-Clara, California,
. . .

20. Chiorean D, Metode de analiz i proiectare orientat-obiect, PC-REPORT, 46, iulie 1996.
21. Fowler, M. and Scott, K. UML Distilled: Applying the Standard Object Modeling Language
(1997) Addison-Wesley.
22. Ambler, S.W Building Object Applications That Work: Your Step-by-Step Handbook for
Developing Robust Systems With Object Technology. (1997, 1998) Cambridge University
Press/SIGS Books.
23. Booch, G. et. al.Unified Modeling Language User Guide (1998) Addison-Wesley.
24. Larman, C Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
Design (1998) Prentice-Hall.
25. UML 2001.
26. M. Boogs, W. Boogs Mastering UML with Rational Rose, 2002.
27. T. Cvartani Modelarea n Rational Rose, 2002.
28. . UML. . .: . 2002.
29.UML Applied,Object Oriented Analysis and Design Using the UML,
30. www.ariadnetraining.co.uk.
31. http://lci.cs.ubbcluj.ro/
32. http://www.citforum.ru/programming/oop_rsis/glava2_2.shtml
33. http://www. omg.org/gettingstarted/what_is_uml
34. http://www.interface.ru/fset.asp?Url=/rational/suite/Suite.htm
35. http://www.omg.org/technology/documents/formal/uml.htm
36. www.PC-report.ro
37. www.CodeNet.ru

Cuprins
Introducere.........................................................................................................................3

Ce reprezint Rational Rose? .....................................................................................3

Lucrarea1. Familiarizarea cu

tehnologiile, metodologiile i principiile elaborrii


modelelorn baza blocurilor constructive ale limbajului UML i CASE

Rational Rose ................7


Consideraii teoretice generale. Cerinele generale fa de metodologii i
tehnologii n ingineria softului...7
Limbajul UML..14
Sistemul de notaii grafice18
Blocurile constructive n UML...19
Relaiile...23
Diagramele UML...24

Lucrarea2. Analiza sistemului n baza metodologiei APOO i elaborarea modelelor


prin diagramele cazurilor de utilizare n mediul Rational Rose i
dezvoltarea lor n alte diagrame......................................................................32
Consideraii teoretice generale. Descriere general....................................................32
Determinarea i definirea scopului proiectului ..35
Modelul sistemului..35
Modelul conceptual.....36
Diagramele cazurilor de utilizare..................................................................................41
Elaborarea Diagramelor USE-CASE...49
Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor...51
Diagrame Interaction.55
Diagrame Sequence....56
Diagrame Colaboration..59

Lucrarea 3. Analiza rezultatelor modelrii din diagrama cazurilor de utilizare


i dezvoltarea n diagramele Sequence i Collaboration n mediul
Rational Rose.................................................................................................62
Consideraii teoretice generale. Descriere general...................................................62
Diagrama succesiunilor.64
Diagrama de colaborare...67
Elaborarea diagramei interaciunilor n mediul Rational Rose73
Elaborarea diagramei de colaborare n mediul Rational Rose.76

Lucrarea 4,5. Studiul i analiza abstraciilor, claselor, pachetelor i obinerea


codului surs n instrumentele CASE.....................................................80
Noiuni generale i exemple. Abstractizarea..............................................................80
Clasele abstracte...........................................................................................................88
Clasele root clasele leaf........................................................................................89
Clasele utilitare (utilite)90
Clasele parametrizate, utilitele claselor parametrizate i clasele acumulatoare.90
Mecanismele comune ....92
Diagrame de clase......95
Pachetele Esene de grup.......................................................................................96

Generarea codului n limbajul C++.97


Exemplu de model pentru care se va genera codul n C++...99
Modalitile de generare a codului n Rational Rose.....101

Lucrarea 6. Dezvoltarea elaborrilor cu diagramele de stare (statechart diagram),


activitilor i Reverse Engineering n mediul Rational Rose pentru
modelele precedente cu modificri, perfectri i completrile
respective105
Consideraii teoretice generale. Modelarea comportamentului....105
Reverse Engineering..............................................................................................117

Lucrarea 7. Dezvoltarea elaborrilor cu diagramele amplasrilor....125


Consideraii teoretice. Diagrama amplasrii..125
Diagrama de componente......................................................................................126

Bibliografie.........................................................................................................................133

ANALIZA I MODELAREA SISTEMELOR


INFORMAIONALE

ndrumar metodic
pentru lucrri de laborator

Autori:

t. Marin

Redactor:

Bun de tipar 00.00.09


Hrtie offset.Tipar RISO
Coli de tipar 3,5

Formatul hrtiei 60x84 1/16


Tirajul 100 ex.
Comanda nr.

UTM, 2004, Chiinu, bd.tefan cel Mare, 168.


Secia Redactare i Editare a UTM
2068, Chiinu, str. Studenilor, 9/9