| CATEGORII DOCUMENTE |
Rational Unified Process (RUP) este un proces general pentru dezvoltarea orientata obiect de produse informatice. Este un ghid care arata cum se poate utiliza practic UML (Unified Modeling Language) pentru a dezvolta un sistem informatic.
Asa cum a fost prezentat si in capitolul 2, in RUP ciclul de viata al proiectului este descompus in patru faze, fiecare avand asociat un rezultat final (determinarea obiectivelor, definirea arhitecturii, implementarea functionalitatii si lansarea finala). La sfarsitul fiecarei faze este efectuata o analiza pentru a determina daca obiectivele au fost indeplinite. Trecerea la urmatoarea faza se realizeaza numai in momentul satisfacerii obiectivelor fazei curente. Fazele descrise de RUP sunt: explorarea initiala, elaborarea, constructia si tranzitia (figura 7.56.). Pe parcursul fiecarei faze se desfasoara procese primare (identificarea cerintelor, analiza sistemului, proiectarea sistemului, implementarea si testarea) si procese suport (managementul proiectului, managementul schimbarii, controlul mediului). In ceea ce priveste procesele primare, in fazele initiale predomina procesele de identificarea cerintelor si analiza. Pe masura dezvoltarii iterative a fazelor accentul se muta succesiv pe proiectare, implementare si testare. Procesele suport sunt prezente intr-o proportie constanta pe parcursul ciclului de dezvoltare, cu exceptia procesului de management al schimbarii. Acesta este mai scazut in fazele initiale (cand modificarile nu sunt cazuri de exceptie, ci mai degraba regula) dar isi intensifica prezenta in final, cand necesitatea unei modificari trebuie atent analizata si integrata pentru a nu periclita succesul proiectului (cu cat proiectul este mai avansat cu atat este mai dificil de realizat modificari).
Un proces este un o succesiune ordonata de pasi necesari pentru atingerea unui obiectiv. In cazul industriei software scopul este realizarea unui nou produs software sau dezvoltarea unuia existent. RUP descrie o familie de subprocese corelate care folosesc o structura si o arhitectura comuna. Scopul procesului este acela de a asigura crearea unui sistem informatic robust care indeplineste criteriile impuse de utilizator, intr-un orizont de timp predictibil si in limitele bugetului alocat. Din acest punct de vedere UP respecta intocmai teoria clasica a managementului proiectelor care insista asupra acestor trei restrictii: calitate, timp si buget. RUP surprinde cele mai bune practici folosite in industria software (dezvoltarea iterativa, managementul cerintelor, arhitectura bazata pe componente, modelarea vizuala, verificarea continua a calitatii, controlul schimbarilor ) intr-o forma care poate fi adaptata pentru o plaja foarte larga de proiecte si organizatii. De asemenea, UP imbunatateste comunicarea in cadrul echipelor descriind un limbaj si un proces comun pentru toate persoanele implicate in proiect.
Unified Process descrie cum pot fi aplicate efectiv practici care s-au dovedit a fi eficiente pentru echipele de dezvoltare software. Am utilizat acest termen de "cele mai bune practici" nu atat pentru ca ar fi usor de cuantificat valoarea lor, ci pentru ca sunt practici utilizate in mod obisnuit de organizatiile de succes din industria software.
Dezvoltarea iterativa. Abordarea traditionala in care se parcurg secvential etapele de definire a problemei, analiza, proiectare, realizare si testare pare sa nu mai fie cea mai potrivita data fiind complexitatea actuala a sistemelor informatice. Este necesara dezvoltarea iterativa care asigura o mai buna cunoastere si intelegere a problemei pe masura ce solutia efectiva se dezvolta pe parcursul a mai multor iteratii. UP suporta o astfel de abordare iterativa care permite tratarea elementelor cu un grad ridicat de risc la fiecare etapa a ciclului de dezvoltare al proiectului, ceea ce reduce semnificativ riscul intregului proiect. Riscul pe ansamblu este combatut prin realizarea frecventa de versiuni executabile ale sistemului prin care se poate obtine implicarea si feedback-ul beneficiarului. Intrucat fiecare iteratie se finalizeaza cu o aplicatie executabila echipa ramane concentrata pe rezultate, iar verificarile frecvente de stare asigura incadrarea in timp. Dezvoltarea iterativa asigura si o mai buna integrare a modificarilor care apar ulterior in cerinte, functionalitate sau planificare.
Managementul cerintelor. UP descrie cum se pot obtine, organiza si documenta cerintele functionale si restrictiile, cum se pot urmari negocierile si deciziile, cum se pot identifica si comunica cu usurinta cerintele procesului de afaceri. Notiunile de caz de utilizare si scenariu s-au dovedit instrumente deosebit de eficiente in identificarea cerintelor functionale si transmiterea acestora la nivelul proiectarii, implementarii si testarii produsului software, ceea ce a crescut considerabil sansele ca produsul final sa corespunda nevoilor beneficiarului. Cu ajutorul cazurilor de utilizare se pot verifica atat pe parcurs cat si in final respectarea cerintelor formulate de beneficiar.
Arhitectura bazata pe componente. Procesul se concentreaza pe realizarea cat mai devreme a unei arhitecturi robuste executabile, inainte de alocarea tuturor resurselor pentru dezvoltarea aplicatiei. Structura dezvoltata in fazele initiale va constitui nucleul pe care se va dezvolta sistemul in continuare. UP descrie cum se poate dezvolta o arhitectura flexibila, adaptabila, usor de inteles si care sa sustina utilizarea efectiva a reutilizarii. UP suporta dezvoltarea orientata pe componente. Componentele sunt module non-triviale, subsisteme ce indeplinesc o functie clara. UP ofera posibilitatea definirii unei arhitecturi pe baza componentelor existente si a altora noi. Acestea sunt asamblate intr-o arhitectura bine definita ad-hoc sau intr-o infrastructura bazata pe componente cum ar fi Internet, CORBA si COM (pentru care exista o industrie infloritoare de componente reutilizabile).
Modelarea vizuala. UP promoveaza modelarea vizuala a structurii si comportamentului arhitecturii si componentelor sistemului. Mediile speciale de proiectare asistata (CASE) ofera posibilitatea verificarii continue a consistentei si completitudinii modelului proiectat. Utilizarea standardului UML, creat de Rational Software, reprezinta certitudinea unei modelari vizuale de succes.
Verificarea calitatii. Performante si fiabilitate scazuta a aplicatiilor este motivul principal pentru care proiectele software sunt refuzate. Astfel calitatea trebuie verificata pe parcurs cu insistand asupra fiabilitatii, functionalitatii, performantelor aplicatiei (software si hardware). UP asista dezvoltatorul in planificarea, proiectarea, implementarea, executia si evaluarea acestor teste. Evaluarea calitatii este integrata in proces, in toate activitatile, implica toti membrii echipei, utilizeaza obiective masurabile si criterii, ea nu este tratata ca o activitate separata ce trebuie sa se desfasoare la final de catre un grup restrans de oameni.
Controlul schimbarilor. Posibilitate de gestiune eficienta a schimbarii - asigurarea unui mediu in care orice schimbare e posibila si posibilitatea de a urmari schimbarile facute - este esentiala intr-un mediu in care schimbarea e inevitabila. UP asigura controlul, urmarirea si monitorizarea schimbarilor.
Dintre toate cele mentionate mai sus, procesul unificat de dezvoltare de software este individualizat de trei sintagme - orientat pe cazuri de utilizare, centrat pe arhitectura sistemului, iterativ si incremental.
Proces orientat pe cazuri de utilizare
Scopul central al unui sistem informatic il reprezinta satisfacerea cerintelor utilizatorilor. Fie ca acesta aduce noi functionalitati sau doar imbunatateste functionalitati existente el se dezvolta pornind de la cerintele utilizatorilor. Daca dorim un sistem care sa fie apreciat drept performant trebuie sa acordam o atentie deosebita identificarii acestor cerinte.
In cazul acesta termenul de utilizator nu se refera strict la utilizatorul uman. Orice alt sistem care interactioneaza cu sistemul pe care urmarim sa-l construim este un utilizator din punctul de vedere al sistemului nostru. Un exemplu de astfel de interactiune ar putea fi considerata efectuarea unei rezervari prin intermediul unui sistem de rezervari on-line. Persoana interesata solicita o rezervare, in urma unui schimb de informatii intre utilizator si sistem (persoana isi defineste mai precis cererea, sistemul de rezervare prezinta mai multe optiuni posibile), dar si in urma unei verificari a cartii de credit (verificare ce este facuta de un alt sistem specializat, utilizator al sistemului de rezervare) se obtine confirmarea de rezervare. O astfel de interactiune poarta denumirea de caz de utilizare. Un caz de utilizare reprezinta o functionalitate a sistemului care furnizeaza un rezultat utilizatorului. Cu ajutorul cazurilor de utilizare se surprind cerintele functionale ale sistemului. Totalitatea cazurilor de utilizare formeaza modelul cazurilor de utilizare, care descrie intreaga functionalitate a sistemului. Acest model inlocuieste traditionala specificare a cerintelor functionale, dar nu numai atat. Se obtine cu ajutorul modelului cazurilor de utilizare o mai buna focalizare pe client si cerintele acestuia si nu doar o identificare a functiunilor pe care ar fi bine sa le ofere sistemul. Daca in trecut cerintele se identificau ca raspuns la intrebarea: Ce trebuie sa faca sistemul?, acum accentul cade pe: Ce trebuie sa faca sistemul pentru fiecare dintre utilizatorii sai?
Este important de precizat faptul ca modelul cazurilor de utilizare nu este doar un instrument de identificare a cerintelor, ci el urmeaza sa dirijeze intreg procesul de dezvoltare software, controland proiectarea, implementarea si testarea sistemului. Pe parcursul intregului proces modelul cazurilor de utilizare ramane ca un model de referinta, proiectantii dezvolta modele care implementeaza cazurile de utilizare, verifica modelele succesive si conformitatea acestora cu modelul cazurilor de utilizare, iar testerii se asigura ca modelul de implementare respecta functiunile cazului de utilizare. In acest mod cazul de utilizare nu este doar un punct de pornire ci este elementul de legatura al procesului unificat de dezvoltare. Cazurile de utilizare sunt specificate, apoi proiectate si in final sunt sursa de construire a modelelor de testare. La fel de adevarat este insa ca ele nu sunt alese independent ci in corelatie cu arhitectura sistemului. Cazurile de utilizare impun o anumita arhitectura, iar arhitectura sistemului influenteaza selectarea cazurilor de utilizare, astfel cele doua se dezvolta in tandem pe masura parcurgerii ciclului de viata al sistemului.
Proces centrat pe arhitectura
Rolul arhitectului de sistem este similar aceluia de arhitect intr-un proiect de constructii. Arhitectul surprinde cladirea din mai multe puncte de vedere: structura, amenajari, detalii, instalatii si toate acestea permit constructorului sa aiba o imagine de ansamblu asupra cladirii inainte ca aceasta sa fie construita. In mod similar arhitectul de sistem descrie din diferite puncte de vedere sistemul ce urmeaza a fi construit.
Arhitectura de sistem cuprinde cele mai semnificante aspecte statice si dinamice ale sistemului. Arhitectura sistemului isi are originea in cerintele utilizatorilor, reflectate in cazurile de utilizare, dar este influentata de mult mai multe aspecte, cum ar fi: platforma software pe care va rula aplicatia (arhitectura calculatoarelor, sistemul de operare, sistemul de gestiune a bazei de date, protocoale de retea si de comunicatie utilizate), blocuri reutilizabile disponibile (GUI, DAO), consideratii de structura, reglementari legale, cerinte nefunctionale (performanta, fiabilitate). Arhitectura este o imagine a intregului proiect ce evidentiaza partile esentiale, ignorand detaliile. Cum identificarea a ceea ce este esential se face in mod subiectiv, calitatea arhitecturii sistemului depinde de experienta celor implicati in realizarea ei. Cu toate acestea, procesul unificat stabileste obiective de urmat pentru a optimiza calitatea arhitecturii sistemului (lizibilitate, usurinta in modificare, reutilizare).
Asa cum am mai evidentiat in paragraful precedent, cazurile de utilizare si arhitectura sunt puternic legate. Orice produs are o functiune si o forma, in cazul produselor informatice cazurile de utilizare reprezinta functionalitatea produsului, iar arhitectura, forma acestuia. Cele doua parti trebuie armonizate pentru a obtine un produs calitativ. Functiunea insa, poate determina o anumita forma (in cazul proiectului de constructii daca se doreste realizarea unei sali de sport aceasta implica o forma predefinita) si forma poate restrictiona functiunea (dupa 1989 multe spatii de locuit au fost amenajate ca spatii pentru birouri, faptul ca ulterior a existat o cerere semnificativa de cladiri cu destinatie de birouri sustine faptul ca reamenajarea, modificarea superficiala a formei, nu a sustinut modificarea functiunii). In aceeasi masura in cazul unui sistem software, cazurile de utilizare trebuie sa se potriveasca in arhitectura, iar arhitectura trebuie sa ofere cadrul general de utilizare al tuturor cazurilor de utilizare, nu numai a celor initiale ci si a cazurilor de utilizare posibile viitoare. Pentru a identifica acea forma care sa permita sistemului sa evolueze se practica identificarea functiunilor cheie ale sistemului, a cazurilor de utilizare cheie. Chiar daca de cele mai multe ori acestea nu reprezinta decat 5-10% din totalul cazurilor de utilizare, ele reprezinta esenta sistemului.
Proces iterativ si incremental
Procesul de dezvoltare al aplicatiilor complexe din zilele noastre poate dura pana la cativa ani, motiv pentru care se practica in mod uzual impartirea proiectelor in subproiecte. Un subproiect reprezinta o iteratie si fiecare iteratie aduce un plus de valoare (un increment) produsului final. De la o iteratie la alta produsul se imbogateste, fie sub aspect calitativ (mai ales in fazele initiale ale proiectului, cand se poate trece de la o abordare superficiala la o abordare mai in detaliu), fie cantitativ (in fazele finale ale proiectului, cand produsul dobandeste noi functiuni).
Fiecare iteratie trateaza un set de cazuri de utilizare care impreuna sporesc gradul de utilizare al produsului, dar si riscurile specifice asociate proceselor respective. In cadrul fiecarei iteratii se vor identifica si specifica in detaliu cazurile de utilizare corespunzatoare, se va trece la proiectare luand in considerare si arhitectura sistemului, se va implementa proiectul in componentele sistemului si in final se vor testa componentele daca indeplinesc cerintele surprinse de cazurile de utilizare de la care s-a pornit.
Avantajele unui astfel de proces iterativ sunt multiple. Dintre acestea amintim:
reducerea costurilor de neconcordanta cu cerintele initiale; daca la un moment dat este necesara reluarea unei iteratii, atunci pierderile sunt limitate la costurile iteratiei respective;
reducerea riscului de a lansa / finaliza produsul cu intarziere, prin identificarea din timp a riscurilor majore. In abordarea traditionala abia in momentul testelor finale erau identificate probleme pentru a caror rezolvare proiectul era intarziat;
accelerarea in ansamblu a ritmului de dezvoltare al proiectului; echipa este mai bine focalizata pe rezultate si pe respectarea unui plan pe termen scurt;
o mai buna implicare a beneficiarului, precum si rafinarea iterativa a cerintelor acestuia. In plus acest mod de abordare permite un mai bun control al schimbarilor datorate atat mediului proiectului cat si modificarii specificatiilor acestuia.
Iteratiile se planifica initial si rareori suporta modificari (stiut fiind ca orice abatere de la un plan initial implica costuri suplimentare). Acest mod de abordare nu reprezinta o scuza pentru un management haotic si nu implica o dezvoltare aleatoare. Dezvoltare iterativa nu inseamna reproiectarea la infinit a aceluiasi modul pana cand in sfarsit se "nimereste" o varianta care functioneaza. Aceasta reprezinta, din contra, un instrument de planificare ce reduce, inca din fazele initiale, riscurile ce ar putea afecta buna desfasurare a proiectului. Versiunile intermediare permit obtinerea unui feedback din partea tuturor celor interesati de proiect si corectarea din timp a eventualelor abateri inregistrate.
Daca am reprezenta evolutia riscului intr-o abordare iterativa, fata de evolutia riscului in cazul modelului de dezvoltare in cascada, se observa ca in abordarea iterativa riscurile majore sunt eliminate inca din fazele initiale ale proiectului, in timp ce in cazul modelului in cascada riscurile scad substantial abia in momentul integrarii si testarii aplicatiei figura 7.57.
Conform RUP, pentru realizarea unui sistem informatic, trebuiesc parcurse in cadrul unei iteratii urmatoarele procese primare: identificarea cerintelor, analiza, proiectarea, implementarea si testarea. In cele ce urmeaza vom prezenta mai pe larg continutul proceselor de identificarea cerintelor, analiza si proiectare. Pentru exemplificarea diagramelor si tehnicilor de modelare UML a fost ales un sistem simplu de rezervare a biletelor pentru o linie aeriana. Au fost atinse urmatoarele probleme:
organizarea sistemului utilizand pachete;
identificarea cerintelor sistemului cu ajutorul cazurilor de utilizare;
modelarea cu diagrame de secventa si de colaborare;
analiza si proiectarea cu diagrama claselor si utilizarea tehnicii fiselor CRC;
modelarea comportamentului cu diagrame de stare si de activitate;
modelarea componentelor software, distribuirii si implementarii;
extinderea UML-ului cu diagrama entitate asociere pentru proiectarea bazelor de date relationale.
Principalele activitati ce trebuiesc parcurse in aceasta etapa sunt:
Identificarea cerintelor candidate (in documentatia de initiere a proiectului, care in acest caz poarta denumirea de viziune);
Structurarea sistemului (utilizand pachetele);
Aprofundarea intelegerii contextului (utilizand fie modelul mediului, fie modelul afacerii);
Identificarea cerintelor functionale (utilizand modelul cazurilor de utilizare);
Identificarea cerintelor non-functionale.
Identificarea cerintelor candidate
In documentatia de initiere a proiectului (viziune) se identifica cerinte posibilie pentru sistemul respectiv. Acestea se completeaza fie pe baza experientei, fie din notele de interviu sau alte documente. Cel mai important document pentru identificarea acestor cerinte candidate ramane viziunea. In cazul sistemului de rezervare cerintele candidate ar putea fi: rezervarea de bilete direct la companie sau prin intermediari (agenti de turism), calculul automat al celei mai avantajoase rute (din punct de vedere al costului sau al timpului), gestiunea automata a situatiilor speciale (anularea unei curse).
Organizarea sistemului utilizand pachete
Una dintre sarcinile cheie ale modelarii sistemelor software de mari dimensiuni este impartirea acestora in arii de mici dimensiuni, mai usor de manevrat. Fie ca se numesc domenii, categorii sau subsisteme, ideea de baza e aceeasi: impartirea sistemului in arii ce impartasesc o problematica similara.
UML introduce notiunea de pachet ca entitate de grupare a elementelor, permitand proiectantilor sa imparta si sa clasifice sistemele complexe. Pachetele pot fi utilizate la orice nivel, de la cel mai inalt, unde sunt utilizate pentru a imparti sistemul in domenii, pana la cel mai de jos nivel, unde se utilizeaza pentru a grupa cazuri de utilizare, clase sau componente. In RUP, ca si in cazul altor metodologii orientate pe cazuri de utilizare, aceasta poate constitui o prima etapa. Sistemul de rezervare a fost structurat in cinci subsisteme (reprezentate printr-o diagrama a pachetelor, figura 7.58.): intretinerea flotei, sistem de urmarire a zborurilor, sistem de rezervare, sistem contabil, personal.
Identificarea cerintelor sistemului cu ajutorul cazurilor de utilizare
Modelarea cu ajutorul cazurilor de utilizare este tehnica cea mai usoara si mai eficienta pentru identificarea cerintelor din perspectiva utilizatorului. Cazurile de utilizare sunt folosite pentru a modela modul de functionare al sistemului actual sau modul de functionare al sistemului dorit de utilizatori. Nu utilizeaza o abordare orientata obiect, este mai degraba o modelare a proceselor, dar cu toate astea este o tehnica excelenta de initiere a analizei orientata obiect a sistemului. Cazurile de utilizare sunt in general punctul de pornire in analiza orientata obiect utilizand UML.
Diagrama cazurilor de utilizare consta din actori si cazuri de utilizare. Actorii reprezinta utilizatorii si alte sisteme ce interactioneaza cu sistemul analizat. Ele reprezinta in fapt un tip de utilizator si nu o instanta a acestuia. Cazurile de utilizare reprezinta comportamentul sistemului, scenariile pe care acesta le executa ca raspuns la stimulii din partea actorilor. Acestea se reprezinta prin elipse.
In cazul exemplului nostru cazurile in care se face apel la sistemul de rezervare sunt atunci cand un pasager doreste sa faca o rezervare sau atunci cand acesta doreste sa anuleze o rezervare facuta anterior. O prima diagrama a cazurilor de utilizare este reprezentata in figura 7.59. Intr-o iteratie ulterioara aceasta diagrama va putea fi rafinata, fiind identificate si alte cazuri de utilizare, cum ar fi confirmarea unui zbor.
Fiecare caz de utilizare este documentat printr-o descriere a scenariului. Descrierea poate fi textuala sau pe pasi. In figura este prezentata si o descriere sub forma unei succesiuni de pasi pentru cazul de utilizare "Rezervare zbor". Fiecare caz de utilizare poate avea si alte proprietati, cum ar fi pre- sau post- conditii ale scenariului - conditii care trebuie indeplinite inainte de inceperea executiei scenariului sau conditii care trebuie indeplinite dupa executarea scenariului. Diagrama de activitate reprezinta un instrument grafic pentru modelarea proceselor cazurilor de utilizare. Aceasta va fi detaliata intr-o sectiune ce urmeaza.
Obiectivul final al oricarui proiect software este o aplicatie care raspunde tuturor cerintelor beneficiarului. Prin identificarea si verificarea cerintelor se urmareste ca toate cerintele sa fie luate in considerare si sistemul sa fie proiectat conform cerintelor beneficiarului. Cel mai adesea cerintele sunt cuprinse intr-un document (documentatia de initiere a proiectului sau viziunea), iar cazurile de utilizare sunt folosite pentru a corela fiecare scenariu cu cerinta pe care o trateaza. Modelarea sistemului cu ajutorul cazurilor de utilizare ajuta la identificarea cerintelor, daca acestea nu au fost identificate anterior.
Principalele activitati ce trebuiesc parcurse in aceasta etapa sunt:
Rafinarea diagramei cazurilor de utilizare;
Modelarea dinamicii sistemului (utilizand diagrama de secventa sau diagrama de colaborare);
Modelarea structurii statice (utilizand diagrama claselor).
Rafinarea diagramei cazurilor de utilizare
In aceasta etapa se pot identifica si alte cazuri de utilizare si alti actori, la un alt nivel de detaliu. In exemplul nostru am identificat in plus agentia de voiaj, ca intermediar intre pasager si companie. Odata cu introducerea acestui nou actor am mai luat in calcul si necesitatea achitarii biletului pentru validarea rezervarii si alte situatii speciale care ar trebui acoperite (achitare prin carte de credit, plata neacceptata). De asemenea in cursul analizei proceselor de afaceri se poate dezvolta modelul al cazurilor de utilizare pentru intreg sistemul si se pot construi mai multe pachete pentru reprezentarea unor diverse arii ale afacerii. Fiecare pachet poate fi apoi descompus si reprezentat printr-o diagrama ce contine cazurile de utilizare corespunzatoare domeniului si interactiunile cu actorii.
Scopul este de a construi cate o diagrama a cazurilor de utilizare pentru fiecare scenariu al sistemului. Fiecare scenariu descrie o succesiune diferita de interactiuni intre actori si sistem, fara conditii "SAU".
Modelarea structurii alternative prin relatii de tip "Extends"
In mod obisnuit fiecare caz de utilizare se construieste dintr-o secventa de actiuni, dupa care pentru fiecare pas se construiesc conditii de tip 'what if' si se realizeaza noi cazuri de utilizare pe baza acestor activitati alternative. Secventele alternative sunt cuprinse in cazuri de utilizare distincte conectate printr-o relatie de tip 'Extends' de cazul de utilizare initial. Relatia de tip 'Extends' poate fi privita ca relatie de mostenire intrucat cazul de utilizare ce extinde un alt caz de utilizare mosteneste si suprascrie comportamentul acestuia. Presupunand ca achitarea biletului se face implicit prin numerar, dar optional plata se poate face si prin carte de credit, cazul de utilizare "Achitare prin carte de credit" extinde cazul de utilizare "Achitare zbor" (figura 7.60.).
Eliminarea comportamentului redundant cu ajutorul relatiilor de tip "Uses
Pentru a elimina o secventa de comportament redundant ce apare in cazuri de utilizare diferite se poate modela acea secventa intr-un caz de utilizare distinct conectat de cazurile de utilizare initiale prin relatii de tip "Uses". Relatia de tip 'Uses' poate fi privita ca fiind echivalenta cu relatia de agregare. In exemplul nostru, fie ca rezervarea se face direct la linia aeriana sau printr-o agentie de voiaj, o rezervare trebuie achitata pentru a fi validata. Cazul de utilizare "achitare zbor" este utilizat atat de "Rezervare zbor", cat si de "Rezervare zbor prin agent" figura
Cazurile de utilizare sunt folosite si pentru a construi scripturi de testare pentru a verifica satisfacerea cerintelor beneficiarului de catre aplicatie. Cand se atinge nivelul cel mai fin de descompunere, pentru fiecare caz de utilizare se poate realiza o diagrama de secventa. Cu diagramele de secventa si de colaborare se modeleaza implementarea scenariului.
Modelarea dinamicii sistemului - Diagramele de secventa
Diagrama de secventa este una dintre cele mai potrivite pentru a modela interactiunile intre obiectele sistemului. Se realizeaza cate o diagrama de secventa pentru fiecare caz de utilizare. In timp ce cazul de utilizare modeleaza un scenariu din puntul de vedere al utilizatorului, diagrama de secventa contine detalii de implementare ale scenariului, incluzand clasele si obiectele ce vor implementa scenariul si mesajele transmise intre obiecte. In mod obisnuit se analizeaza descrierea cazului de utilizare pentru a determina care sunt obiectele necesare pentru implementarea scenariului. Daca descrierea a fost facuta sub forma unei succesiuni de pasi obiectele se determina prin parcurgerea acestor pasi. Intr-o diagrama de secventa obiectele implicate in scenariu sunt reprezentate prin linii punctate verticale, iar mesajele transmise intre acestea prin vectori orizontali. Mesajele se reprezinta cronologic de sus in jos, spatierea pe orizontala a obiectelor fiind arbitrara. Pentru cazul de utilizare descris mai sus prin pasi ("Rezervare zbor") diagrama de secventa este prezentata in figura 7.61. Se observa ca pasii din descrierea cazului de utilizare se regasesc in secventa de sus in jos.
In cursul analizei mesajul poarta denumirea din sistemul existent. Mai tarziu, in cursul proiectarii acesta este inlocuit cu denumirea metodei obiectului apelat. Metoda apelata sau invocata apartine clasei instantiate de obiectul ce receptioneaza mesajul.
Modelarea dinamicii sistemului - Diagramele de colaborare
Diagrama de colaborare reprezinta o alternativa la diagrama de secventa pentru modelarea interactiunilor intre obiectele sistemului. In timp ce in diagrama de secventa accentul cade pe succesiunea cronologica a mesajelor, in diagrama de colaborare accentul cade pe identificarea si intelegerea tuturor efectelor pe care scenariul le are asupra unui obiect (figura 7.62). Obiectele sunt conectate, fiecare legatura fiind o instanta a asocierii intre clasele implicate. Legatura evidentiaza mesajul transmis intre obiecte, tipul mesajului (sincron, asincron, simplu, optional -balking sau time-out) si vizibilitatea obiectelor unele fata de altele.
Modelarea structurii statice cu ajutorul diagramei claselor
Diagrama claselor este instrumentul principal de analiza si proiectare a structurii statice a sistemului. In ea se precizeaza structura claselor sistemului, relatiile intre clase si structurile de mostenire. In timpul analizei diagrama este construita urmarind obtinerea unei solutii ideale. La proiectare se utilizeaza aceeasi diagrama si se modifica pentru a fi conforma cu detaliile de implementare.
Dezvoltarea diagramei claselor pe parcursul analizei
Abordarea orientata pe cazuri de utilizare
In cazul analizei orientata pe cazuri de utilizare, diagrama claselor se construieste pe baza informatiilor furnizate de cazurile de utilizare, diagramele de secventa si diagramele de colaborare. Obiectele identificate pe parcursul analizei sunt modelate in termenii claselor instantiate de acestea, iar interactiunile intre obiecte sunt transpuse in relatii intre clasele instantiate (figura 7.63).
Abordarea orientata pe responsabilitati
Tehnica fiselor CRC este utilizata uneori ca extensie a UML-ului pentru o analiza orientata pe responsabilitati. Definitiile claselor sunt rafinate pe baza responsabilitatilor lor si a altor clase cu care acestea colaboreaza pentru a indeplini aceste responsabilitati. Pentru fiecare clasa se intocmeste o fisa pe care se evidentiaza responsabilitatile clasei si care sunt clasele cu care ea colaboreaza pentru a indeplini aceste responsabilitati. Aceste informatii se transpun direct intr-o diagrama a claselor, responsabilitatile corespund metodelor, iar colaborarile corespund asocierilor dintre clase (figura 7.64.).
Exista doua obiective principale pe care le urmarim in proiectarea unui sistem informatic:
obtinerea cat mai rapida a sistemului care sa respecte toate cerintele actuale la un pret cat mai scazut;
construirea unui sistem usor de intretinut si adaptat pentru a raspunde unor viitoare cerinte.
Aceste obiective sunt vazute in mod traditional ca fiind conflictuale; unul dintre motivele pentru care tehnicile de proiectare orientate obiect au cucerit cu rapiditate piata este si concilierea acestor obiective conflictuale.
Ca si in cazul analizei principalele activitati ce trebuiesc parcurse in aceasta etapa sunt:
Modelarea structurii statice (utilizand diagrama claselor);
Modelarea dinamicii sistemului (utilizand diagrama de stare sau diagrama de activitate);
Rafinarea diagramei cazurilor de utilizare (utilizand diagrama de activitate);
Modelarea arhitecturii sistemului (utilizand diagrama componentelor si diagrama de desfasurare);
Proiectarea bazei de date.
Accentul cade de aceasta data pe detaliile concrete ale implementarii sistemului. Fiecare dintre modele abordate vin sa completeze diagrama claselor / obiectelor care in final va sta si la baza proiectarii bazei de date.
Proiectarea sistemului cu ajutorul diagramei claselor
Pe parcursul proiectarii diagrama claselor este modificata pentru a lua in considerare detalii concrete ale implementarii sistemului.
Diagrama claselor poate fi dezvoltata intr-o maniera iterativa, printr-o succesiune repetata a analizei, proiectarii si implementarii. Acest proces este adesea referit ca "round-trip engineering". Utilizarea unui CASE poate facilita acest proces oferind posibilitatea implementarii intr-un limbaj de programare cum ar fi C++ sau Java si invers, reactualizarea diagramei claselor pornind de la cod (reverse engineering).
O preocupare esentiala pe parcursul proiectarii este stabilirea arhitecturii sistemului. Se poate opta intre o aplicatie simpla ce va rula pe o singura masina, un sistem client-server sau un sistem multi-tier cu obiecte specializate pentru interfata cu utilizatorul, logica aplicatiei si pentru baza de date, fiecare putand potential sa ruleze pe o alta platforma. O posibilitate de a gestiona o astfel de arhitectura complexa este impartirea diagramei claselor in trei sectiuni diferite care sa evidentieze clasele ce descriu interfata cu utilizatorul (business layer), clasele responsabile de logica aplicatiei (application layer) si clasele pentru stocarea datelor (data layer). Aceasta se poate realiza fizic fie prin segmentarea diagramei claselor si utilizarea unei diagrame distincte pentru fiecare sectiune sau prin adaugarea unei proprietati fiecarei clase, proprietate care sa identifice carei sectiuni (tier) apartine clasa.
O componenta este un grup de obiecte sau componente care interactioneaza cu scopul de a furniza un serviciu. O componenta este similara unei cutii negre pentru care serviciile sunt specificate prin interfata sau interfetele sale, fara a se preciza nimic despre componenta sau implementarea interna a componentei. Dezvoltarea bazata pe componente este procesul care urmareste asamblarea componentelor celor mai potrivite in configuratia cea mai buna pentru a obtine functionalitatea dorita pentru sistem. Componentele sunt reprezentate in diagrama claselor din UML prin specificarea interfetei clasei sau pachetului. Exista doua posibilitati de reprezentare pentru interfata, ca o clasa cu stereotipul <<interface>> si lista operatiilor suportate de interfata in sectiunea destinata metodelor sau in varianta prescurtata, ca un mic cerc atasat printr-o linie continua de clasa si precizand denumirea interfetei in dreptul cercului.
Exemplul din figura 7.66. arata ca interfata Afisabil a clasei Pasager pune la dispozitie o operatie muta(x coord, y coord) pentru afisarea in GUI. Sunt evidentiate ambele modalitati de reprezentare. Interfata Persistent a clasei Pasager ofera o operatie salveaza(store at) care ar putea fi folosita de o clasa sau componenta de acces la baza de date.
Modelarea comportamentului cu diagrame de stare
In timp ce diagramele de interactiune si de colaborare modeleaza comportamentul dinamic reprezentat de o secventa de actiuni intre grupuri de obiecte ale sistemului, diagrama de stare este utilizata pentru a modela comportamentul dinamic al unui singur obiect sau clasa de obiecte. Se realizeaza cate o diagrama de stare pentru fiecare clasa cu comportament dinamic semnificativ. Intr-o astfel de diagrama se surprinde secventa starilor pe care le parcurge un obiect al clasei pe parcursul intregului sau ciclu de viata ca raspuns la stimulii primiti, dar si propriile raspunsuri si actiuni ale obiectului. Mai concret, comportamentul unui obiect este modelat pornind de la starea sa initiala si determinand care sunt starile pe care le tranziteaza atunci cand intervin diverse evenimente. Se urmaresc si actiunile pe care obiectul le efectueaza atunci cand se afla intr-o anumita stare. Starile reprezinta suma conditiilor obiectului la un moment dat. Evenimentele sunt intamplari care determina trecerea unui obiect dintr-o stare in alta. Starile de tranzitie caracterizeaza miscarea dintr-o stare in alta. Fiecare stare de tranzitie (reprezentata printr-o linie continua ce leaga cele doua stari intre care se efectueaza tranzitia) este etichetata cu evenimentul care determina tranzitia. Actiunile sunt efectuate de obiect atunci cand acesta soseste intr-o stare (figura 7.67.).
Diagrame de activitate
Diagrama de activitate este o diagrama de flux utilizata pentru a modela comportamentul sistemului. Ea poate fi folosita in mai multe situatii: pentru a modela un caz de utilizare, o clasa sau o metoda mai complicata. Asa cum am mai spus ea este similara unei diagrame de flux, diferenta esentiala fiind accea ca o diagrama de activitate poate reprezenta procese paralele. Acest lucru este deosebit de important atunci cand diagramele de activitate sunt utilizate pentru a modela procesele de afaceri (multe din acestea executandu-se in paralel) sau pentru a modela fire multiple de executie in programarea concurenta.
Utilizarea diagramelor de activitate pentru a modela cazuri de utilizare
Diagrama de activitate ofera un instrument grafic pentru a modela procesele unui caz de utilizare. Aceasta poate fi folosita in completarea, sau in locul, unei descrieri textuale / liste de pasi a cazului de utilizare. O descriere textuala, cod sau o alta diagrama de activitate poate prezenta mai multe detalii.
Utilizarea diagramelor de activitate pentru a modela clase
Pentru modelarea comportamentului unei clase diagrama de stare este utilizata atunci cand predomina evenimentele asincrone. Diagrama de activitate se foloseste cand toate sau majoritatea evenimentelor sunt urmare a unor actiuni interne. Intr-o astfel de diagrama activitatile trebuiesc atasate claselor (figura 7.68.).
Modelarea componentelor software
Diagrama componentelor este utilizata pentru a modela structura software-ului, incluzand dependentele intre componentele software, componentele in cod binar si componentele executabile. In diagrama componentelor se modeleaza componentele sistemului, grupate uneori in pachete, si dependentele care exista intre componente (si pachete de componente) (figura 7.69.).
Modelarea distribuirii si implementarii
Diagrama de desfasurare este utilizata pentru a modela configuratia elementelor de procesare la momentul executiei si distributia componentelor software, proceselor si obiectelor pe aceste elemente de procesare. Se porneste de la identificarea nodurilor fizice si a comunicatiilor ce exista intre acestea. Pentru fiecare nod se precizeaza instantele componentelor care se stocheaza sau se executa pe nodul respectiv. Se pot evidentia si obiectele componentei respective. Diagrama de desfasurare modeleaza doar componentele existente la momentul executiei, ea nu surprinde si componentele folosite doar la compilare sau linkeditare. Se pot modela si componentele care migreaza dintr-un nod in altul, sau obiectele ce migreaza dintr-o componenta intr-alta, utilizand relatia de dependenta cu stereotipul <<becomes>> (figura 7.70).
Proiectarea bazelor de date relationale - o extensie UML
Diagrama claselor prezinta un mecanism neutru de implementare pentru modelarea aspectelor ce tin de stocarea datelor sistemului. Clasele persistente, atributele acestora si relatiile dintre ele pot fi implementate direct intr-o baza de date orientata obiect. Cu toate acestea, in prezent, bazele de date relationale raman modalitatea de stocare a datelor cea mai uzuala. Diagrama claselor din UML permite modelarea unor aspecte specifice proiectarii bazelor de date relationale, dar nu acopera in intregime aceasta problematica, de notat faptul ca nu prevede notiunea de atribute cheie care sunt mecanismul principal de relationare a tabelelor. Pentru a surprinde mai bine aceste aspecte este bine sa se apeleze la diagrama entitate asociere (ER), in completarea setului de diagrame propus de UML. Diagrama claselor poate fi utilizata pentru a modela logic baza de date, independent de faptul ca se alege o implementare relationala sau orientata obiect, prin clase reprezentandu-se tabelele, iar prin atribute coloanele acestora. Daca se alege pentru implementare un mediu relational, atunci diagrama claselor poate fi usor translatata intr-o diagrama logica entitate asociere. Claselor persistente si atributelor acestora le corespund entitatile logice si atributele lor, iar relatiilor dintre clase le corespund relatii intre entitati (figura 7.71).
Odata intocmita aceasta diagrama se poate trece la proiectarea bazei de date relationale conform tehnicii normalizarii (prezentata intr-un alt capitol).
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 2667
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
