| CATEGORII DOCUMENTE |
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.
Exista o varietate larga de metodologii si tehnici utilizate de catre un analist de sistem in procesul de analiza si proiectare orientata obiect.
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 la implementare si nu dezvoltarea unui nou 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 in 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. Asa cum am vazut in capitolul anterior diagrama claselor reprezinta atat entitatile domeniului (clasele) cat si relatiile dintre acestea (asocierile), figura 7.42.
Asa cu am mai precizat scopul principal al acestui model este intelegerea contextului sistemului. De aceea la realizarea modelului mediului (domeniului) este de preferat sa 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.
Uneori, pentru sistemele de mici dimensiuni, se renunta chiar la diagrama claselor pentru modelul mediului, intocmindu-se doar acest dictionar de termeni.
Dictionarul este deosebit de important si pentru asigurarea unui limbaj comun in cadrul proiectului. Cu totii intuim problemele ce pot apare in comunicare datorita utilizarii unei terminologii necunoscute de toti cei implicati in proiect.
In final trebuie sa atragem atentia ca la acest nivel analistul nu trebuie sa insiste prea mult pe clasele interne sistemului, acest model fiind destinat identificarii si intelegerii cerintelor ce deriva din contextul sistemului. Modul in care sistemul va trata aceste probleme, logica interna, urmeaza sa fie detaliate in alte etape, cu ajutorul altor modele.
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.
Aceasta este o tehnica de modelare utilizata pentru a aprofunda intelegerea proceselor specifice unei organizatii. Desi denumirea ar putea parea intrucatva limitativa se foloseste acelasi termen si pentru sistemele care nu informatizeaza o "afacere", cum ar fi un sistem de alarma sau un controler hardware.
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. Procesele se modeleaza prin cazuri de utilizare, iar initiatorii acestor procese prin actori (figura 7.43).
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 utilizatorii il acceseaza, consulta, manipuleaza, realizeaza sau utilizeaza in cadrul unui caz de utilizare. 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 a mai multor cazuri de utilizare. De exemplu in figura 7.43. "Utilizatorul" participa la realizarea a doua cazuri de utilizare, la fel si "Administratorul".
Un astfel de model se dezvolta in doi pasi:
Realizarea modelului cazurilor de utilizare
Detalierea modelului prin specificarea utilizatorilor, entitatilor si a unitatilor de lucru, dar si a regulilor care guverneaza anumite procese sau obiecte.
Scopul este crearea unor utilizatori, entitati si unitati de lucru care rezolva problema evidentiata de cazul de utilizare eficient - bine, rapid si la cel mai scazut cost posibil.
Modelarea mediului si modelarea afaceri par intrucatva asemanatoare, mai ales daca ne gandim ca entitatile si unitatile de lucru corespund claselor din modelul mediului. Exista totusi o serie de diferente, dintre care evidentiem trei.
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 diferite clase, atribute, metode si asocieri.
O alta deosebire ar fi ca pornind la analiza domeniului vom obtine mai multe informatii despre atributele claselor si mai putine despre comportamentul acestora (clasele domeniului vor fi sarace in metode). 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.
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 ne este obligatoriu sa fie un utilizator uman. El poate fi si un alt sistem sau un dispozitiv hardware (ex. 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. De exemplu, daca domnul Y joaca doua roluri, unul de instructor iar celalalt de consultant, va fi reprezentat ca instanta a unui actor numit Instructor si ca instanta a unui alt actor numit Consultant.
Actorii fiind entitati externe sistemului, ei 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. Cazurile de utilizare asociate sistemului sunt redate in figura 7.44.
Un caz de utilizare este initiat intotdeauna de un actor si poate interactiona si cu alti actori, nu numai cu cel care l-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.
Observam in exemplul anterior etichetarea cu simbolul <<extends>> a asocierii dintre cele doua cazuri de utilizare ceea ce semnifica faptul ca optional cazul de utilizare "inregistrare la curs special" extinde cazul "inregistrare la curs", adaugandu-i noi actiuni si comportamente. Inregistrarea unui student la un curs special necesita si permisiunea instructorului (actiune suplimentara), pe langa pasii normali de inscriere la orice curs.
Este evidentiata si o relatie de utilizare prin etichetarea cu simbolul <<uses>> a asocierii dintre cazul "inregistrare la curs" si cazul "nepromovare cursuri obligatorii" ceea ce semnifica faptul ca un caz de utilizare foloseste celalalt caz de utilizare atunci cand se executa. Inscrierea la cursul Y nu este posibila decat daca studentul a promovat cursurile pregatitoare acestuia. Cazul "inregistrare la curs" foloseste cazul "nepromovare cursuri obligatorii" pentru a verifica daca studentul a promovat cursurile pregatitoare cursului Y.
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. Descrierea cazului de utilizare "Inregistrare la curs" sub forma unei succesiuni de pasi se face ca in figura 7.45:
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 se ia in seama si CUM o sa se 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 fara sa intereseze in aceasta faza cum vor fi implementate acestea. 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.
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 care insa vor fi prezentate mai tarziu in cadrul acestui capitol.
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.
In acest sens, 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 practica e putin probabil sa reusesti din prima. Clasele selectate in modelul de proiectare se vor modifica pe parcursul desfasurarii procesului iterativ de dezvoltare a sistemului.
In literatura de specialitate se propun doua metode: proiectarea orientata pe date (data driven design) si proiectarea orientata pe functiuni (responsibility driven design). Primul tip de metode presupune identificarea tuturor datelor din sistem si impartirea lor 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 ce 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. "Numele" unui client ar putea fi un astfel de exemplu.
Diagrama obiectelor modeleaza instantele elementelor continute in diagramele de clase. O diagrama obiectuala arata un set de obiecte si relatiile dintre acestea la un anumit moment.
Diagramele obiectuale contin obiecte si legaturi. Ca si celelalte diagrame, poate 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.
In figura 7.46. se prezinta o posibila diagrama a claselor pentru un sistem de gestiune a comenzilor. Unii dintre clienti pot beneficia de credit comercial, dar altii trebuie sa achite inainte de livrarea comenzii (aceia pentru care operatia ClientEvaluareSituatie returneaza valoarea "slaba").
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.
In figura 7.47 este reprezentat un scenariu al cazului de utilizare "Comanda articole" dintr-un sistem de comert electronic. Scenariul presupune ca validarea utilizatorului se finalizeaza cu succes si ca exista un stoc nelimitat de produse.
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 descrierea 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. Pentru a putea realiza o comparare a celor doua tipuri de diagrame in figura 7.48. a fost reprezentat acelasi scenariu ca si in figura 7.47.
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 c1asa este necesar sa intelegem relatiile de dependenta care exista intre starea unui anumit 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 activitati 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 c1ar identificabile si un comportament complex.
Presupunand ca este vorba despre un sistem contabil, diagrama ce descrie comportamentul clasei "Factura" este reprezentata in figura 7.49.
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, cu posibilitatea de specificare a actiunilor care se vor realiza, prin precizarea urmatoarelor elemente:
Ce fac actiunile? (modificarile starilor obiectului),
Cand au loc actiunile? (secventa de actiuni) si
Unde au loc actiunile?
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.
Activitatile realizate la biroul de receptie a unui hotel se pot modela cu ajutorul diagramei de activitate astfel (figura 7.50.):
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 5140
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
