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 n model, pentru crearea rapoartelor i 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 criteriile i regulile, care se folosesc pentru aprecierea rezultatelor de ndeplinire a (fig. 1); 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. 2.

Tehnologia ar trebui s acorde suport deplin ciclului vital al softului; Tehnologia ar trebui s asigure realizarea scopurilor garantat de dezvoltarea sistemului informaional cu calitatea fix i n timpul stabilit; 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;

3.

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

2.

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 Regulile de folosire a tastaturii i a mouse-ului; Regulile de oformare a textelor de ajutor; Setul de mesaje standarde; Regulile de prelucrare a reaciei utilizatorului.

plasarea ferestrelor i elementelor de rulare;2.

3. 4. 5.

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 ignorate; b) clientul schimb cerinele;

c) o firm concurent lanseaz un program rival pe pia; d) un dezvoltator/arhitect prsete echipa de dezvoltare; e) 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. 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

OMG (Object Management Group)

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

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: 12

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

3

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 2 3 4 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.Ne w De vice

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 exi sta seri a

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 2 3 4

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) 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. sunt foarte importante pentru

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.t a se r nf r

d p z ae e o it r sh br P c imae I N c n lie t oit rb n a f e ac r

d c nae eo t r p t laa v r ic r b n eif ae ila t s d ce it is e r d

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.

otn i f r ae b en mi i o t ds r cet ep l n ei

cer a ni r a uu e c nnu ot o

cn ot

s t r lm d e ei i a e a t cei rd t

r v ues r ei ir i t ie z o dc d er i et cn ot r s in ep s cn ot ac p t cet a sm r ene a dcm t ou e e n

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.clie t n acce ta ca p rd c ste n ca ite r rd in itializ re e a cran d sch e con e id t c ere P IN in du PN tro ce I ce tra z re n actia se lecta tra z ctie re n a cere su a m in d ce c tita a tro u an te d c ta e on re v rifica b n e r ai ex ge tra d istribu ca ie sh distrib iece u c sco tere ca a rd v rific PN e a I card re de a r A Me n T cra co t n em to b n ita r a i

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 in d c PN : tro u e I 9 s le ta tra z c : e c re n a tie 1 : in d c c n te 1 tro u e a tita a AM T e ra c n

c n lie t

5 c rePN : e I 8 c retra z c : e n a tia 1 : c re s m 0 e u a 3 in liz re e ra : itia a c n 1 a c p c rd : c e ta a 2 c s n c rd : ite te r a

7 v rific P : e a IN 1 : d c n re 2 e o ta 1 : v rific r b n 3 e a ai 1 : e tra e 4 x g

4 d s h ec n : e c id o t c rd a re d r ae

cn ot

1 : s o te c rd 7 c a re a 1 : d trib iec s 5 is u a h 1 : d trib iec c 6 is u e

e ita r m to bn ai

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.cr r a r a ee d d na r r cd a ea cr ( c pr a ) ct e d s a cr ( ct a) oe d c s cr ( ieea ) t t d A ea T cn Mr cr ( e) e a ea ta a c p i rr ( c t n e)

cn o t no r n ct P I N bn ia l t d cd ) e he si ( d oa ( e nr ) ct e s a b i) c t a( oe n v ii ao( e c cn r f t) eiar a mo n tt b i b na ia cs l t h dti u cs ) i r i a( s be h dti u cc i r i e) s be (

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.d c nae b n 0] e o t r [ ila t < d sh e e c id c ng l ot o

cr r d eee e in h eea c id r c nu i lie t lu

d p s [b n< ] e o it ila t 0

v ric r b a t b n 0p n u3 ze] ef ae il n[ ila t < e t 0 il r

in h c is

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.AMx T. e e

n diagram:

cr r ae a edr d

d ti uocs i rbi r ah s t

d ti uocs is bi r ah r t AMc n T er a c r r ae a edr d

AMc n T er a

Fig.1.9. Diagrama componentelor pentru ATM client 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. de dezvoltare a Soft-ului se realiza n concordan cu

Un timp ndelungat procesul

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 (consultanii potenialii 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 arhitectura s fie simpl: se folosesc abstracii, mecanisme comune etc. Elaborarea sistemului trebuie s fie iterativ, elaborarea iterativ reprezint modificarea

efectua fr a se schimba interfaa;

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

-

Exist dou tipuri de precedente:-

-

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:

12 3

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?

4

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 r