|
|
|
PROIECTAREA ORIENTATA OBIECT A SISTEMELOR INFORMATICE
1 Concepte utilizate in abordarea obiectualaa proiectarii sistemelor informatice
Dintre conceptele care stau la baza modelarii orientata obiect cele mai importante sunt:
obiectul;
incapsularea;
persistenta;
tipul;
clasa;
mostenirea;
polimorfismul;
identitatea.
Obiectul
Obiectul este o abstractizare a entitatii lumii reale si se caracterizeaza prin:
stare;
comportament.
Starea unui obiect este definita de valorile atributelor sale. Un atribut este definit printr-un nume si poate lua valori elementare (numeric, alfanumeric, etc.) sau complexe (structuri de multiple referinte spre alte obiecte, tipuri utilizatori etc.). Comportamentul unui obiect este definit de setul de operatii si metode aplicabile obiectului respectiv.
Fiecare obiect are un nume care coincide, de obicei, cu numele entitatii reprezentate. Metodele si atributele nu sunt vizibile din exteriorul obiectului.
Un obiect raspunde la mesaje. Mesajul este unitatea de comunicatie dintre obiecte. Mesajele cuprind: numele mesajului, numele obiectului tinta si argumentele necesare, daca exista. Cand un obiect primeste un mesaj una din procedurile sale este apelata. Procedura realizeaza apoi o operatie care poate returna un rezultat. Mesajele sunt implementate prin intermediul metodelor.
Incapsularea
Incapsularea consta in capacitatea obiectelor de a contine la un loc atat date cat si operatii dintre care numai o parte sunt vizibile din exterior.
Un obiect este compus din doua parti:
interfata - permite unui utilizator extern sa solicite obiectului executarea unei actiuni;
o parte ascunsa, de implementare - reprezentata de starea interna si de metodele obiectului.
Incapsularea ascunde utilizatorului complexitatea unui obiect, oferind o imagine simplificata care ii permite sa rezolve mai usor problemele complexe.
Persistenta
Persistenta este proprietatea obiectelor care determina existenta mai indelungata a acestora fata de procesul care le-a creat; este proprietatea prin care starea bazei de date asigura executia unui proces pentru a fi refolosit ulterior in alt proces.
Tipul
Tipul sintetizeaza elementele comune ale unui set de obiecte cu aceleasi caracteristici.
Tipul abstract de date are doua componente:
interfata - este vizibila utilizatorului si consta intr-o lista de operatii
implementarea - presupune descrierea structurii interne a datelor obiectului si realizarea procedurilor de implementare a operatiilor interfetei.
Clasa
Notiunea de clasa are aceeasi semnificatie cu cea de tip, insa este deosebita de aceasta, prin faptul ca este asociata cu faza de executie. O clasa este un tip abstract de date care defineste atat structura obiectelor din clasa respectiva, cat si multimea metodelor existente pentru aceste obiecte.
Obiectele din aceeasi clasa au aceleasi atribute si aceleasi metode si raspund la acelasi mesaj.
Clasele sunt organizate ierarhic. Orice subclasa mosteneste metodele si structura clasei din care face parte.
Mostenirea
Mostenirea este procesul prin care toate atributele si metodele unei clase sunt preluate de o alta clasa inrudita, numita subclasa. Clasa de la care atributele si metodele sunt mostenite se numeste supraclasa.
Prin intermediul mostenirii se pot exprima relatii deosebit de utile intre clase: clasificarea, generalizare, specializare.
Mostenirea poate fi implementata:
static - presupune concatenarea campurilor mostenite in clasele respective;
dinamic - presupune parcurgerea legaturilor de mostenire si se realizeaza fara recopierea campurilor mostenite.
Polimorfism
Polimorfismul semnifica posibilitatea unui obiect, instanta a unei clase, sa raspunda diferit la primirea aceluiasi mesaj.
Polimorfismul se poate asigura prin doua cai:
redefinirea metodelor mostenite in clasele derivate;
crearea unor metode cu acelasi nume dar cu parametrii deferiti.
Identitatea
Identitatea unui obiect este proprietatea acestuia care il distinge de alte obiecte. Astfel, spre deosebire de modelul relational in care datele sunt identificate prin valori ale cheii primare desemnate de utilizator, in modelul orientat obiect identificarea obiectelor este asigurata automat de sistem si este transparenta utilizatorului.
Doua obiecte a si b sunt identice daca au acelasi identificator, adica egalitatea obiectelor este de fapt o egalitate de pointeri (se scrie a = b).
Doua obiecte sunt egale daca au aceleasi valori (a = b). Asadar
a = = b implica a = b, reciproca este falsa
2 Nivele de modelare in proiectarea orientata obiect
Un model orientat obiect are la baza obiecte. Un obiect incapsuleaza atat date cat si comportament, ceea ce inseamna ca analistul poate folosi abordarea orientata obiect atat pentru modelarea datelor, cat si pentru modelarea proceselor. Pentru ca permite analistului de sistem sa surprinda ambele aspecte intr-o singura reprezentare si pentru ca ofera si alte beneficii, cum ar fi mecanismul mostenirii si reutilizarea codului, modelarea orientata obiect ofera un mediu puternic pentru dezvoltarea sistemelor complexe. Teoria obiectelor, incapsularea, mostenirea si polimorfismul stau la baza dezvoltarii obiectuale a sistemelor.
Referitor la consistenta modelelor, in alte abordari - cum ar fi analiza si proiectarea -, structurata - modelele care se dezvolta nu folosesc notatii comune si sunt slab conectate intre ele, tranzitia de la un model la altul facandu-se in mod abrupt. Abordarea orientata obiect ofera continuitate in ceea ce priveste tranzitia intre modelele analizei, proiectarii si ale implementarii. De exemplu, trecerea de la analiza orientata obiect la proiectarea orientata obiect presupune imbogatirea modelului de analiza cu detalii referitoare implementare si nu dezvoltarea unui nou model.
Modelarea domeniului (mediului) - Domain Model
Pentru a aprofunda intelegerea contextului in care va functiona sistemul se utilizeaza modelul mediului (domeniului). Acest model cuprinde cele mai importante clase intalnite in domeniul economic pentru care se realizeaza sistemul informatic si are un caracter de generalitate. Clasele se identifica fie din cerintele exprimate de beneficiar, fie din intervievarea unor experti in domeniu. Este unul dintre primele modele utilizate n analiza orientata obiect si are menirea de a sistematiza expertiza din domeniul analizat si a o transmite sistemului informatic ce urmeaza a fi proiectat.
Sunt trei tipuri de clase care pot fi puse in evidenta in acest model:
clase ce modeleaza obiecte sau concepte utilizate in cadrul sistemului informational analizat, cum ar fi comanda, contract, factura;
obiecte sau concepte din lumea reala pe care sistemul trebuie sa le inregistreze si sa tina cont de ele, cum ar fi cursul de schimb al monedei de referinta;
evenimente ce intervin si afecteaza starea sistemului, cum ar fi plasarea unei comenzi, plata unei facturi.
Pentru descrierea acestui model vom utiliza preponderent diagrama claselor, dintre instrumentele puse la dispozitie de UML.
Scopul principal al acestui model este intelegerea contextului sistemului. De aceea la realizarea modelului mediului (domeniului) este de preferat si participe atat specialisti in modelare, cat si experti din domeniul analizat. Din acest punct de vedere se remarca asemanarea cu etapa de analiza specifica metodologiilor structurate Asa cum stim deja, conform unui vechi principiu al analizei sistemelor, in acest proces este de preferat sa fie implicati cei mai buni specialisti in domeniu (expertii). Modelul mediului va contine cele mai importante clase ale domeniului. Odata cu intocmirea diagramei claselor se intocmeste si un dictionar al claselor in care se va preciza semnificatia fiecarei clase pentru a se folosi o terminologie unitara. Se prefera aceasta formula pentru a se evita obtinerea unui model prea mare si greu de utilizat.
Modelul mediului, format din diagrama claselor domeniului si dictionarul de termeni, poate fi utilizat atat la dezvoltarea modelului cazurilor de utilizare, cat si la identificarea claselor sistemului in etapa de analiza.
Modelarea proceselor afacerii (prelucrarilor) - Business Model
Aceasta este o tehnica de modelare utilizata pentru a aprofunda intelegerea proceselor specifice unei organizatii. Utilizand UML, modelarea afacerii se poate face din doua perspective: fie prin modelul cazurilor de utilizare, fie prin modelul obiectelor.
In cadrul modelarii cazurilor de utilizare (business use-case model) se surprinde functionarea sistemului din perspectiva utilizatorilor acestuia.
Modelul obiectelor (business-object model) surprinde prelucrarile din interiorul sistemului. Descrie in detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de utilizare se poate evidentia cu ajutorul diagramelor de interactiune (diagrama de secventa, diagrama de colaborare) sau al diagramei de activitate.
O entitate a sistemului existent (a afacerii) reprezinta un lucru pe care utilizatori, acceseaza, consulta, manipuleaza, realizeaza sau utilizeaza in cadrul unui caz de utilizari. O unitate de lucru este un set de astfel de entitati care formeaza un intreg pentru utilizatorul final. Entitatile si unitatile de lucru sunt utilizate pentru a reprezenta aceleasi concepte ca si clasele din modelul mediului (comanda, produs, factura, cont).
Fiecare utilizator, entitate sau unitate de lucru poate participa la realizarea mai multor cazuri de utilizare.
Un astfel de model se dezvolta in doi pasi:
Realizarea modelului cazurilor de utilizare
Detalierea modelului prin specificarea utilizatorilor, entitatilor si a unitatilor lucru, dar si a regulilor care guverneaza anumite procese sau obiecte.
Scopul este crearea unor utilizatori, entitati si unitati de lucru care sa rezolve problema evidentiata de cazul de utilizare, eficient - bine, rapid si la cel mai scazut cost posibil.
Modelarea mediului si modelarea afacerii par intrucatva asemanatoare, mai ale daca ne gandim ca entitatile si unitatile de lucru corespund claselor din modelul mediu.
Cele doua abordari difera in primul rand prin modul de documentare. Una se bazeaza pe cunostintele unui expert in domeniu sau pe cunostintele despre sisteme similare, in timp ce a doua are in vedere cerintele beneficiarului. Orice clasa a modelului domeniului isi regaseste originea in experienta cunoscatorilor domeniului. Orice element al modelului afacerii (entitate sau unitate de lucru) isi regaseste originea intr-o cerinta a beneficiarului. Acesta este si motivul principal pentru care utilizand cele doua abordari, in mod normal, se obtin clase, atribute, metode si asocieri diferite.
O alta deosebire ar fi ca pornind de la analiza domeniului vom obtine mai multe informatii despre atributele claselor si mai putine despre comportamentul acestora
Evident, in cazul modelarii afacerii se vor identifica atat entitatile si unitatile de lucru (clasele), cat si utilizatorii (si operatiile pe care acestia le intreprind).
Si nu in cele din urma, modelul afacerii fiind mult mai detaliat, va fi mai bine valorificat in etapele ce vor urma. Se pot identifica mai bine actorii si cazurile de utilizare ale sistemului proiectat, si fiecare dintre acestea va putea fi mai bine pus in corespondenta cu cerintele sistemului.
Daca modelul mediului abordeaza cu precadere functionarea sistemului in contextul acestuia, modelul afacerii isi focalizeaza atentia asupra utilizatorilor si a modului cum sistemul ii deserveste.
Modelarea cazurilor de utilizare
Un model al cazurilor de utilizare este format din actori si cazuri de utilizare
Un actor este o entitate externa ce interactioneaza cu sistemul (similar unei entitati externe dintr-o diagrama de flux a datelor). Actorul este ceva sau cineva care schimba informatie cu sistemul. Un actor nu este obligatoriu sa fie un utilizator uman. El poate fi si un alt sistem sau un dispozitiv hardware (exemplu, monitorul) cu care sistemul nostru interactioneaza sau schimba informatii.
Un caz de utilizare este o secventa de actiuni initiate de un actor, surprinzand un anumit mod de a folosi sistemul. Nu trebuie facuta confuzie intre actor al sistemului si utilizator al sistemului. Un utilizator este oricine foloseste sistemul. Un actor este un rol pe care utilizatorul il poate juca. Numele actorului trebuie sa indice acest rol. Un actor este un tip sau o clasa de utilizator. Acelasi utilizator poate juca mai multe roluri.
Actorii, fiind entitati externe sistemului, nu pot fi descrisi in detaliu. Identificarea actorilor ajuta la identificarea cazurilor de utilizare - intrucat un caz de utilizare este initiat de un actor. Iata cateva intrebari la care analistul de sistem trebuie sa raspunda pentru a identifica cazurile de utilizare:
Care sunt principalele actiuni executate de fiecare actor?
Actorul va citi sau va actualiza informatia din sistem?
Actorul va informa sistemul despre modificarile petrecute in afara acestuia?
Actorul va fi informat de modificarile din sistem?
Sa consideram cazul unui sistem de inregistrare a studentilor la cursurile oferite de un centru de instruire. Entitatile externe sistemului sunt studentul care se inscrie la curs, secretara care face inscrierea studentilor la cursuri, casiera care incaseaza contravaloarea cursurilor si instructorul care preda cursurile
Un caz de utilizare este initiat intotdeauna de un actor si poate interactiona si cu alti actori, nu numai cu cel care 1-a initiat. Cazul de utilizare trebuie sa redea o functionalitate completa si nu numai o anumita actiune a unei functionalitati. Transmiterea unui formular de inscriere la un curs este parte a procesului de inregistrare la curs, deci va fi inclus in cazul de utilizare "inregistrare la curs' si nu se va construi un caz separat pentru actiunea transmitere formular de inscriere.
Diagrama cazurilor de utilizare arata care sunt toate cazurile de utilizare din sistem. dar nu indica modul in care acestea sunt realizate de catre actori. Modelul cazurilor de utilizare este completat de o descriere textuala a fiecarui caz de utilizare, accentul punandu-se pe interactiunea cu alti actori si mai putin pe modul in care este executat in cadrul sistemului.
Modelarea cazurilor de utilizare permite analiza cerintelor functionale ale sistemului, insistand asupra a CE trebuie sa faca un sistem existent sau un nou sistem, fara sa considere si CUM o sa faca. Modelul cazurilor de utilizare este dezvoltat in faza de analiza a ciclului de viata al sistemelor orientate obiect, avand rolul de a ajuta dezvoltatorii sa inteleaga cerintele functionale ale sistemului. Procesul este iterativ iar, stabilirea cerintelor se face in urma discutiilor cu beneficiarul sistemului. Cazurile de utilizare controleaza toate celelalte modele. Daca cerintele utilizatorului se modifica in timpul dezvoltarii, aceste modificari sunt vizibile mai intai in modelul cazurilor de utilizare. Modificarile in cazurile de utilizare implica modificari si in celelalte modele. Si reciproca este valabila, adica in momentul in care se fac modificari in modele, acestea trebuie sa se reflecte si la nivelul cazurilor de utilizare.
Modelarea structurii statice (diagrama claselor, diagrama obiectelor)
Diagrama claselor documenteaza structura statica a sistemului; mai exact precizeaza clasele care exista si relatiile dintre acestea, nu si modul in care interactioneaza pentru a asigura un anumit comportament. Diagrama claselor poate, de asemenea, evidentia si alte aspecte ale structurii statice, cum ar fi pachetele.
Construirea diagramei claselor presupune in primul rand identificarea claselor din sistem, acest proces reprezinta o parte esentiala a proiectarii sistemelor orientate obiect, de succesul acestuia depinzand in mare parte succesul proiectului.
Criteriile de apreciere a unui model al claselor sunt:
obiectele claselor din model trebuie sa poata furniza intregul comportament cerut sistemului;
un bun model al claselor contine (pe cat posibil) clase stabile din domeniul obiectual, care nu depind de functionalitatea particulara ceruta la momentul proiectarii.
Poate fi utilizata orice tehnica de obtinere a claselor atata timp cat modelul obtinut respecta criteriile enuntate. Implicit, daca modelul obtinut nu respecta criteriile, nu va fi nimeni interesat de tehnica utilizata, oricat de profesionista ar fi aceasta.
In literatura de specialitate se propun doua metode:
modelarea orientata pe date (data driven design);
modelarea orientata pe functiuni (responsibility driven design).
Primul tip de metode presupune identificarea tuturor datelor din sistem si impartirea Ior pe clase, inainte de a considera functiunile acestor clase. Tehnica identificarii substantivelor este cea mai utilizata astfel de metoda. Al doilea tip de metode, orientate pe functiuni, presupune identificarea tuturor functiunilor sistemului si impartirea lor pe clase, inainte de a considera datele acestor clase.
Tehnica identificarii substantivelor presupune doua etape:
Identificarea claselor candidate, selectand din specificarea cerintelor sistemului toate substantivele si frazele substantivale (se considera substantivele la singular si nu se aleg fraze ce contin "sau' ca unici candidati).
Se elimina candidatii considerati nepotriviti din diverse motive si se redenumesc clasele ramase daca este necesar.
Unele dintre motivele pentru care o clasa candidata ar putea fi considerata nepotrivita sunt:
Redundanta - o clasa e prezenta sub mai multe denumiri. Este important sa ne amintim insa ca obiecte similare pot sa nu fie identice. Proiectantul decide daca lucrurile sunt suficient de diferite pentru a merita clase diferite.
De exemplu, daca a fost selectata o pereche de genul "imprumut' si "imprumut pe termen scurt', acestea sunt diferite, dar numai la nivelul valorii atributelor. Se recomanda in acest caz alegerea unui nume care sa desemneze intreg continutul clasei.
Imprecizia - cand nu se poate spune precis care e realitatea descrisa de substantivul respectiv. Desigur, trebuie indepartata ambiguitatea inainte de a putea spune daca substantivul reprezinta o clasa.
Eveniment sau operatie - cand substantivul se refera la ceva ce este facut de sistem. Uneori aceasta situatie este bine modelata de o clasa, dar nu este acesta cazul obisnuit.
Metalimbaj - unde substantivul face parte din modul de definire a cerintelor. Vom utiliza substantive ca "cerinte' sau "sistem' ca parte a limbajului de modelare si nu pentru a reprezenta obiecte din domeniul problemei.
Extern sistemului - atunci cand substantivul este relevant pentru a descrie functionarea sistemului, dar nu se refera la ceva din interiorul sau.
Atribut - atunci cand este clar ca substantivul desemneaza o realitate simpla, fara un comportament interesant, care este de fapt un atribut al altei clase.
Diagrama obiectelor
Diagramele obiectuale contin obiecte si legaturi. Ca si celelalte diagrame, pot contine note si restrictii. Mai pot contine anumite pachete sau subsisteme, fiecare fiind folosite pentru a grupa elementele modelului.
Aceste diagrame se folosesc pentru modelarea statica a unui sistem, ca diagramele de clase, dar din perspectiva unor instante reale sau prototip.
Crearea unei diagrame conceptuale se face intr-un singur mod, modeland structura obiectelor. Modelarea structurii obiectelor implica fotografierea obiectelor din sistem la un anumit moment.
Modelarea dinamicii sistemului
Pentru modelarea dinamicii sistemului, UML furnizeaza doua tipuri de diagrame si anume, diagramele de interactiune (diagrama de secventa si diagrama de colaborare) si diagramele de comportament (diagrama de stare si diagrama de activitate). Principala menire a acestor diagrame este de a arata cum realizeaza sistemul un caz de utilizare sau un scenariu particular dintr-un caz de utilizare. Pentru fiecare caz de utilizare se pot realiza mai multe scenarii (din descrierea cazului de utilizare). Pentru fiecare astfel de scenariu se pot intocmi, nu este obligatoriu, o diagrama de secventa sau o diagrama de colaborare (unele dintre instrumentele CASE pot obtine o diagrama din alta).
Acest tip de diagrame inlesneste intelegerea cazurilor de utilizare mai dificile. Ele pot, de asemenea, sustine comunicarea in cadrul echipei de proiectare, in cazul in care de o aceeasi interactiune se ocupa mai multe persoane sau grupuri de persoane. Nu e de asteptat sa se dezvolte astfel de diagrame pentru fiecare caz de utilizare sau pentru fiecare operatie, doar daca beneficiile depasesc costurile. In cazul in care se dispune de un CASE ce poate utiliza aceste diagrame la generarea de cod, atunci devine profitabil sa dezvoltam diagrame de interactiune si diagrame de comportament.
Diagramele de secventa descriu modul in care obiectele interactioneaza si comunica intre ele. Aceste diagrame permit focalizarea atentiei asupra secventelor de mesaje, mai precis asupra mesajelor care sunt trimise si receptionate de catre obiecte.
Avantajul major al diagramelor de secventa, fata de diagramele de colaborare, este posibilitatea de a reprezenta grafic trecerea timpului, fiind deci indispensabile in cazul proiectarii de sisteme in timp real.
Diagramele de colaborare permit evidentierea atat a interactiunilor, cat si a legaturilor dintre un set de obiecte care colaboreaza. Atat diagramele de secventa, cat si cele de colaborare vizualizeaza interactiunile, dar diagrama de secventa ia in considerare timpul, pe cand cea de colaborare, spatiul.
Ca si diagramele de secventa, diagramele de colaborare pot fi utilizate pentru inscrierea executiei unei operatii, a unui caz de utilizare sau a unui scenariu de interactiune in cadrul sistemului. In acest tip de diagrama nu pot fi descrise mesajele concurente si asincrone.
Pana acum nu am amintit nimic despre modelarea "deciziei' unui obiect despre ceea ce sa faca la primirea unui mesaj. Diagramele de interactiune pot reprezenta obiecte diferite ale aceleiasi clase care primesc acelasi mesaj, dar raspund diferit. Acest comportament este rezonabil de cele mai multe ori, intrucat comportamentul unui obiect poate fi afectat si de valorile atributelor sale. Pentru a putea implementa, intretine sau testa o clasa este necesar sa intelegem relatiile de dependenta care exista intre starea unui anumi: obiect si reactiile sale la mesajele primite sau la alte evenimente. Diagramele de stare sunt acelea care inregistreaza aceste dependente.
Pornind de aici, se pot folosi aproximativ aceleasi notatii pentru a descrie activitat complexe. Se considera ca trecerea de la o activitate la alta atunci cand prima activitate s-a incheiat este similara cu trecerea unui obiect dintr-o stare intr-alta, semnificativ diferita de prima, atunci cand acesta primeste un mesaj. Diagramele de activitate sunt o variatiune a diagramelor de stare, adaptate pentru a evidentia conexiunile si dependentele dintre activitati. Ele sunt extrem de folositoare atunci cand se apreciaza ca o activitate trebuie sa execute o serie de task-uri diferite si dorim sa modelam dependentele esentiale dintre acestea, inainte de a decide in ce ordine sa se execute.
Diagramele de stare au rolul de a captura ciclul de viata al obiectelor, subsistemelor si sistemelor, prin specificarea starilor in care se poate gasi un obiect si a evenimentelor (mesaje primite, erori, conditii care devin adevarate) care-i afecteaza starea de-a lungul executiei. O diagrama de stare poate fi atasata oricarei clase care are stari clar identificabile si un comportament complex.
O diagrama de activitate constituie o varianta a diagramei de stare, cu un scop putin diferit, acela de a evidentia actiuni si rezultate ale acestor actiuni. De fapt, diagramele de activitate constituie o cale alternativa de descriere a interactiunilor.
Diagramele de activitate pot fi utilizate si pentru a descrie cum se desfasoara cazuri de utilizare individuale si cum depind de alte cazuri de utilizare.
Diagramele de activitate pot fi folosite in mai multe scopuri, si anume:
Ilustrarea actiunilor care vor fi realizate atunci cand este executata o operatie. Acesta este si cel mai comun caz de utilizare a acestui tip de diagrama.
Prezentarea activitatii interne a unui obiect.
Identificarea actiunilor care pot fi realizate in mod legat si stabilirea modului in care aceste seturi de actiuni afecteaza obiectele din jur.
Ilustrarea modului in care instanta unui caz de utilizare poate fi realizata in termenii actiunilor sau modificarilor intervenite in starea obiectului.
Ilustrarea modului in care este organizata munca actorilor, care este organizarea si obiectele folosite.
3 Dezvoltarea sistemelor informatice folosind procesul unificat (UML)
Proiectarea orientata obiect isi gaseste justificarea in cerinta imperioasa de a face fata si a oferi solutii superioare calitativ in special sistemelor informatice de mari dimensiuni si nivel ridicat de complexitate.
Interesul manifestat fata de abordarea obiectuala, in programare mai intai si, prin forta lucrurilor, in proiectare si apoi in analiza au condus, odata cu acumularea de suficienta experienta practica, la definirea de metode de dezvoltare orientate obiect. Printre acestea, cele care s-au bucurat de cele mai bune aprecieri din partea utilizatorilor au fost OMT(Object Modeling Tehnique), OOSE(Object-Oriented Software Engineering), UML(Unified Modeling Language).
UML este rezultatul unui efort de unificare la care au contribuit elemente dezvoltate de numeroase cercetari si metode. De altfel, documentul oficial defineste UML drept o colectie a celor mai bune practici aplicate in modelarea sistemelor informatice de mari dimensiuni si complexitate.
UML a fost definit pornind de la rolul esential pe care-l joaca modelarea in conceperea si realizarea de sisteme software. Un model este formulat intr-un limbaj de modelare. Limbajul de modelare include un ansamblu de concepte si semantici fundamentale, o notatie si un set de reguli de utilizare. Pentru un plus de rigoare si claritate a definirii, conceptele de baza sunt, la randul lor modelate in UML. Aceasta definire recursiva este denumita metamodelare. Metamodelele ofera o descriere formala a tipurilor de elemente care pot participa la modelare (sau din care pot fi compuse modelele) - numite simplu "elemente de modelare" - impreuna cu sintaxa si semantica notatiei prin care sunt referite si folosite acestea. In alti termeni, fiecare metamodel defineste elementele de modelare si regulile dupa care se compun acestea in modele.
Notatia folosita este formata din simboluri grafice. Aceasta conduce la utilizarea sintagmei de modelare vizuala pentru UML si justifica declararea sa drept "limbaj de vizualizare". Paradigma obiectuala, printre altele, avantajul ca ofera un set de concepte ce pot fi aplicate uniform pe toate nivelele de abstractizare, incepand cu viziunea schematica initiala si pana la viziunea terminala, suficient de detaliata pentru a oferi toate amanuntele necesare traducerii directe in program sursa. Aplicate in acest context, rigoarea si consistenta cu care sunt definite conceptele sale au facut din UML baza mai multor instrumente CASE, asa cum este Rational Rose. Acestea nu numai ca asista analiza si proiectarea prin mijloace specifice, dar sunt capabile si de generarea automata a unei parti din codul sursa, in mai multe limbaje la alegere. Exista, prin urmare, posibilitatea, demonstrata practic, de a defini reguli si euristici de trecere de la structurile UML la constructiile specifice unui limbaj de programare sau altul.
Diversele metode obiectuale, inclusiv cele care ua stat la originea UML, preconizeaza diferite procese de dezvoltare a sistemelor. Procesul este cel care prescrie activitatile si ordinea in care trebuie realizate, rezultatele de obtinut din fiecare activitate, criteriile de evaluare a calitatii si de masurare si control a progresului proiectului etc. Dincolo de specificitatea oferita de o metoda sau alta, procesul trebuie adaptat de asemenea, la natura problemei de rezolvat, la cultura manageriala a utilizatorului, la caracteristicile echipei implicate in realizare s.a.m.d. UML nu este o metoda de dezvoltare obiectuala. Poate accepta si poate fi insa folosit in diverse metode, chiar daca acestea aplica procese diferite. A fost astfel definit si un proces de aplicare a UML in dezvoltarea de sisteme informatice, denumit, la randul sau, unificat.
Procesul unificat poate fi caracterizat prin urmatoarele trasaturi cheie:
este iterativ si incremental;
este dirijat de cazurile de utilizare;
este centrat pe arhitectura;
este pilotat de riscuri.
Conform primei trasaturi, dezvoltarea are loc prin mai multe iteratii succesive, in fiecare dintre acestea abordandu-se doar o portiune a sistemului sau doar anumite aspecte ale proiectari si realizarii. In felul acesta se renunta la ideea de a defini in totalitate detaliile aferente unei anumite etape inainte de a trece la urmatoarea. De aceasta data, se accepta o definire partiala, pe baza careia se construieste un produs la care se revine, intr-o noua iteratie, cu modificari sau cu noi detalii sau functii - aspectul incremental - pana la obtinerea sistemului final. Progresul proiectului poate fi mai bine controlat, iar experienta acumulata in cursul unei iteratii poate fi utilizata in cele care urmeaza.
Cazurile de utilizare constituie punctul central al edificiului: in stadiul initial, ele definesc utilizatorii si cerintele acestora sub forma actorilor si a interactiunilor dorite ale acestora cu sistemul. Aceleasi cazuri de utilizare vor constitui punctul initial in definirea cerintelor si referinta pentru proiectare si realizare, iar setul de teste prin care este verificat sistemul se va defini tot pe baza lor. Prin posibilitatea de a regasi permanent legatura cu cazul de utilizare in cursul intregului ciclu de dezvoltare, se raspunde si cerintei de asigurare a trasabilitatii.
Inlantuirea diagramelor UML
Arhitectura se refera aici la structura de ansamblu a sistemului sub aspectul organizarii sale in subsisteme, a interactiunii dintre acestea, a celor mai semnificative cazuri de utilizare etc. Pe baza arhitecturii este posibila planificarea si lucrul in paralel a mai multor echipe diferite. Existenta este indispensabila pentru a putea aplica dezvoltarea iterativa.
Riscul desemneaza in contextul de fata, tot ceea ce ar putea impiedica realizarea sistemului. Pot fi evidentiate doua categorii primare de risc: tehnice si functionale. Sintagma "pilotat de riscuri" exprima faptul concret ca definirea si ordonarea iteratiilor se face astfel incat riscurile identificate sa fie abordate si elimanate cat mai devreme in cadrul ciclului de dezvoltare, incepand cu cele mai grave.
Balize de evaluare
Fazele ciclului de dezvoltare
Ciclul de dezvoltare
Ciclul de dezvoltare este compus din patru faze. Fiecare faza produce un anumit set de rezultate care sunt elemente de intrare pentru urmatoarea, ceea ce confera ansamblului un caracter de confidentialitate. Pentru fiecare faza, anumite rezultate sunt folosite drept balize de evaluare si servesc pentru a masura progresul inregistrat de proiect.
Fazele ciclului de dezvoltare sunt urmatoarele: studiul preliminar, elaborarea, constructia, si tranzitia.
Studiul preliminar ("inception" in terminologia de origine) urmareste definirea amplasarii viitorului sistem in cadrul activitatii organizatiei. Aceasta include delimitarea ariei de cuprindere, stabilirea obiectivelor, studiul fezabilitatii in contextul unuia sau mai multor modele de afaceri. Rezultatul cheie al fazei este viziunea sistemului, care contine o descriere foarte sintetica in care se precizeaza ce este sistemul, cine il va utiliza, ce facilitati trebuie sa asigure si la ce restrictii trebuie sa raspunda. Viziunea constituie si principala baliza de evaluare a studiului preliminar.
Elaborarea asigura colectarea si precizarea cerintelor functionale si nefunctionale ale viitorului sistem. Cum utilizatorii sistemului si cerintele acestora sunt specificate prin intermediul cazurilor de utilizare, modelul detaliat al acestora constituie unul dintre "artefactele" de baza si, in acelasi timp, baliza de evaluare a fazei. Un alt rezultat esential, strans legat de precedentul si inclus in balizele de evaluare de baza, este reprezentat de arhitectura sistemului.
Constructia asigura obtinerea sistemului, incluzand deci analiza, proiectarea, programarea si testarea. Rezultatele ce servesc drept principale balize de evaluare cuprind intregul set de modele de analiza si proiectare, impreuna cu totalitatea programelor elaborate.
Tranzitia asigura introducerea in exploatare a sistemului la utilizator. Aici se regasesc configurarea, instalarea, furnizarea documentatiei, instruirea si eventual formarea personalului. Principala baliza de evaluare este versiunea finala a sistemului.
Sistemul informatic obtinut in urma parcurgerii celor patru faze poate solicita modificari ulterioare pentru asigurarea evolutiei sale. Pentru referirea la asemenea stadii evolutive, se foloseste termenul de generatie. In consecinta, la terminarea primului ciclu de dezvoltare, rezulta generatia 1 a produsului software respectiv. Obtinerea unei noi generatii presupune reluarea ciclului, cu parcurgerea celor patru faze.
Activitati si iteratii
Structurarea in cele patru faze ale ciclului de dezvoltare corespunde perspectivei manageriale asupra procesului, in care atentia este concentrata asupra aspectelor financiare, strategice, de personal. Aspectele tehnice legate de conceperea si realizarea sistemului sunt proprii unei alte perspective a aceluiasi proces, structura in activitati si iteratii.
O activitate se realizeaza prin combinarea mai multor pasi. Pasul este componenta elementara si foloseste anumite elemente de intrare pe care le modifica sau pe baza carora realizeaza alte elemente noi. Aceste intrari si iesiri sunt produse intermediare constand din documente, modele, programe etc.
Exista cinci activitati de baza: definirea cerintelor, analiza, proiectarea, implementarea si testarea.
Definirea cerintelor se concentreaza asupra identificarii cerintelor functionale si nefunctionale ale sistemului. Aceasta etapa furnizeaza imaginea exterioara a sistemului, adica imaginea perceputa de catre utilizatorii sai.
Analiza urmareste obtinerea unui model al problemei de rezolvat, asa cum apare aceasta la nivelul activitatii reale de afaceri. Modelul este insa formulat in termeni informatici, prin clase de obiecte, operatii, interactiuni etc. si ignora orice detaliu tehnic sau de implementare.
Proiectarea extinde sau adapteaza modelul anterior pentru a raspunde cerintelor tehnice si restrictiilor configuratiei de calcul in care va functiona sistemul. Este etapa in care sunt luate in considerare si rezolvate problemele de persistenta, de intefata, de comunicare etc. pastrand insa neschimbata structura si comportamentul definite anterior, care exprima logica domeniului.
Implementarea consta in scrierea, compilarea si documentarea programelor pentru proiectul definit in etapa precedenta.
Testarea asigura verificarea programelor realizate in etapa anterioara pentru a stabili masura in care acestea corespund cerintelor functionale si nefunctionale, sunt sigure in functionare.
Activitatile enumerate se bucura de o acceptiune aproape unanima. Cu toate acestea numerosi autori le combina sau le completeaza.
Fiind vorba despre acelasi proces privit din perspective diferite, exista o suprapunere a fazelor si activitatilor. Deosebit de semnificativ este faptul ca activitatile se pot regasi in totalitate, chiar daca in proportii diferite, in fiecare din cele patru faze. Spre exemplu, sunt posibile activitati de implementare si testare chiar si in faza de studiu preliminar, pentru care metoda recomanda, de altfel, recurgerea la prototipaj, ceea ce indivizualizeaza suficient de clar demersul aplicat.
