ANALIZA sI PROIECTAREA SISTEMULUI INFORMATIC UTILIZÂND UML
v Principii de baza ale metodei
Unified Modeling Language (UML) este un limbaj standard pentru scrierea de schite software. În acest context, scopul UML este vizualizarea, specificarea, construirea si documentarea artefactelor unui sistem software-intensiv, orientat-obiect. UML este numai un limbaj, si prin urmare este numai o parte a unei metode de dezvoltare software. Cu toate ca UML este independent de proces, în mod normal el ar trebui utilizat în procese conduse de cazurile de utilizare, centrate pe arhitectura sistemului.
v Obiective
Limbajul Unificat de Modelare (UML) este succesorul metodelor de analiza si proiectare orientate-obiect (OOA&D) de la sfârsitul anilor '80 si începutul anilor '90. Initial s-a pornit de la unificarea metodologiilor lui Booch, Rumbaugh si Jacobson, dar aria de cuprindere a fost marita incluzând si alte elemente: Shlaer-Mellor (Object Lifecycles), Odell (Classification), Wirfs-Brock (Responsibilities), Embley (Singelton classes and high-level view), HP Fusion (Operation descriptions and message numbering), Gamma (Frameworks and Patterns), Harel (Statecharts), Meyer (Before and after conditions).
În momentul de fata, UML a devenit standard de modelare recunoscut de catre OMG (Object Management Group). Standardizarea a avut loc în noiembrie 1997, iar limbajul a continuat sa fie imbunatatit.
UML este numit limbaj de modelare si nu de metodologie. De obicei o metodologie consta, cel putin în principiu, atât dintr-un limbaj de modelare, cât si dintr-un proces de modelare. Limbajul de modelare este notatia grafica folosita pentru descrierea modelului, iar procesul este succesiunea de pasi ce trebuie urmati pentru a realiza efectiv modelul.
UML poate fi definit, pe scurt, ca un limbaj de vizualizare, specificare, construire si documentare a modelelor. Valoarea lui consta în urmatoarele:
o este un standard deschis
o realizeaza întreg ciclul de viata al dezvoltarii software-ului
o acopera multe tipuri de aplicatii
o este bazat pe marea experienta a celor care l-au realizat
o este implementate de mai multe produse de tip CASE
UML este un limbaj de modelare vizuala, care foloseste notatii grafice standard. Rumbaugh spunea ca "modelarea surprinde partea esentiala a unui sistem ". Se poate continua idea spunând ca UML surprinde si descrie în limbaj grafic sistemul.
Realizarea unui model este la fel de importanta ca realizarea proiectului unei cladiri pe care arhitectul doreste sa o construiasca. Fara aceasta schita nu se poate construi cladirea. Un model bun trebuie sa identifice cerintele si sa comunice informatii, sa se concentreze asupra modului cum interactioneaza elementele modelului si sa nu se împotmoleasca în detalii, sa permita vizualizarea relatiilor dintre componente si sa îmbunatateasca comunicarea între cei care participa la realizarea proiectului, pe baza limbajului grafic.
Modelarea vizuala are cinci caracteristici principale:
Sunt amintite aici si principalele concepte ale UML, urmând ca ulterior sa fie detaliate. Astfel, UML poate fi folosit pentru:
v Concepte de baza
Pentru a intelege UML, trebuie întelese trei elemente majore: blocurile constructive ale UML, regulile care dicteaza modul în care aceste blocuri pot fi combinate, precum si mecanismele generale utilizate de UML.
Blocurile constructive.
În UML exista trei categorii de blocuri constructive si anume: elemente, relatii si diagrame.
Elementele sunt abstractiuni care reprezinta piesele fundamentale intr-un model. Ele se împart în patru categorii: elemente structurale, elemente comportamentale, elemente de grupare si elemente de adnotare.
Elementele structurale reprezinta substantivele modelelor UML, formând în cea mai mare parte componente statice ale modelului:
Clasa→este cel mai important bloc constructiv al oricarui sistem orientat-obiect. O clasa este o descriere a unui set de obiecte ce partajeaza aceleasi atribute, operatii, relatii si semantica, putând implementa una sau mai multe interfete. Clasele pot include abstractizari ale unor parti din domeniul problemei precum si implementari ale solutiei si pot fi folosite pentru a reprezenta elemente pur conceptuale, elemente software sau elemente hardware.
Elementele constitutive ale unei clase sunt:
Atributele→ un atribut este o proprietate, cu nume, a unei clase, descriind o plaja de valori pe care instantele acelei proprietati le pot lua.
Operatiile→ o operatie este implementarea unui serviciu ce poate fi solicitat de catre orice obiect al clasei pentru a-i afecta comportamentul. Cu alte cuvinte, o operatie este o abstractizare a unei prelucrari ce se poate aplica unui obiect, partajata de catre toate obiectele acelei clase.
Responsabilitatile→ o responsabilitate este o obligatie a unei clase.
O clasa bine structurata trebuie sa îndeplineasca urmatoarele conditii:
Sa ofere o abstractizare clara a unei entitati ce apartine vocabularului domeniului problemei sau al domeniului solutiei;
Sa încorporeze o multime, restrânsa si bine definita, de responsabilitati.
Sa ofere o separare clara a abstractizarilor si a implementarilor.
Sa fie inteligibila si simpla, dar în acelasi timp extensibila si adaptabila.
Simbolul utilizat pentru o clasa este prezentat în figura urmatoare:
Instanta→reprezinta o manifestare concreta a unei abstractizari asupra careia se poate aplica un set de operatii si care are stare ce stocheaza efectele operatiilor. Instantele pot fi:
-concrete→reprezinta instante ale unor clase concrete;
-prototipice→reprezinta instante potentiale ale claselor concrete care sunt subclase ale claselor abstracte, sau ale claselor concrete care realizeaza interfete.
3. Interfata →reprezinta o colectie de operatii care specifica un serviciu al unei clase sau al unei componente.
Nume interfata
Colaborarea→defineste o interactiune; o colaborare este un ansamblu de elemente ce lucreaza împreuna pentru a oferi un comportament cooperativ mai important decât suma componentelor elementelor.
Cazul de utilizare→reprezinta o descriere a seturilor de secvente de actiuni pe care le executa un sistem , conducând la un rezultat observabil ce prezinta importanta pentru un anumit actor.
6. Clasa activa→o clasa ale carei obiecte poseda unul sau mai multe procese sau fire de executie si prin urmare pot initia controlul activitatilor.
7. Componenta→ o parte fizica, înlocuibila, a unui sistem, care ofera implementarea unui set de interfete.
8. Nodul
→element fizic care exista la momentul executiei si
reprezinta o resursa de calcul, are cel putin memorie si
adesea capacitate de procesare.
Ultimele trei categorii de elemente sunt asemanatoare claselor, ele descriind multimi de obiecte cu aceleasi atribute, operatii, relatii si semantica, fiind totusi suficient de diferite si destul de utilizate în modelarea unui sistem orientat obiect.
De asemenea, ultimele doua elemente sunt si ele diferite, în sensul ca ele reprezinta elemente fizice, în timp ce toate celelalte elemente reprezinta elemente logice sau conceptuale.
Elementele comportamentale→sunt partile dinamice ale modelului UML, reprezentând comportamentul modelului în timp si spatiu. Ele sunt verbele modelului. Exista doua categorii de elemente comportamentale:
Semantic, aceste elemente sunt de obicei conectate la diverse elemente structurale, în primul rând clase, colaborari si obiecte.
Elemente de grupare→sunt partile organizationale ale modelelor UML. Exista un singur tip de elemente de grupare, pachetele. Un pachet este un mecanism general pentru organizarea elementelor în grupe. Într-un pachet pot fi plasate elemente structurale, elemente comportamentale si chiar alte elemente de grupare.
Elemente de adnotare→ sunt partile explicative ale modelelor UML. Exista un singur astfel de tip de element, nota→ un simbol pentru marcarea de restrictii sau de comentarii atasate unui element sau a unei colectii de elemente.
Relatii→abstractiuni ce leaga elementele între ele. O relatie este o conexiune între elemente. În modelarea orientata obiect, exista patru tipuri de relatii: dependentele, generalizarile, asocierile si realizarile.
dependenta→este o relatie semantica între doua elemente în care o schimbare a unui element (elementul independent) poate afecta celalalt element (elementul dependent). Dependentele se utilizeaza atunci când se doreste indicarea faptului ca un element este folosit de un altul.
asocierea→este o relatie structurala care descrie un set de legaturi, o legatura fiind o conexiune între obiecte.
Dincolo de forma de baza a asocierilor, se mai folosesc si urmatoarele notiuni:
Nume→folosit pentru a descrie natura relatiei;
Rol→atunci când o clasa participa într-o asociere, ea are un rol specific pe care îl joaca în acea relatie;
Multiplicitate→indica numarul de obiecte ce pot fi conectate prin intermediul unei instante a unei asocieri;
Agregare→este un tip de asociere ce modeleaza o relatie de tipul "are un", ceea ce înseamna ca un obiect al întregului are (contine) obiectele partii.
Generalizarea se foloseste pentru a arata existenta unor relatii de tip parinte/copil. Ea este o relatie de specializare în care obiectele elementului specializat (copil) pot fi substituite pentru obiecte ale elementului generalizat (parinte).
Realizarea este o relatie
semantica între clasificatori, unde un clasificator specifica un
contract pe care un alt clasificator garanteaza si îl executa.
Atunci când se modeleaza relatii UML se recomanda:
Folosirea dependentelor numai atunci când relatia modelata nu este structurala;
Folosirea generalizarii numai când exista o relatie de tipul " este de tipul "; mostenirea multipla se poate înlocui adesea prin agregare;
Evitarea introducerii de relatii de generalizare ciclice;
Pastrarea relatiilor de generalizare cât mai balansate; laticele de mostenire nu trebuie sa fie prea "adânci" si nici prea "late";
Folosirea asocierilor în primul rând acolo unde exista relatii structurale între obiecte.
Diagramele→sunt prezentari grafice ale unui set de elemente, cel mai adesea exprimate ca un graf de noduri (elementele) si arce (relatiile).
Reguli UML
Blocurile constructive UML nu pot fi grupate oricum, în maniera aleatoare, existând reguli detaliate pentru definirea modelelor bine formate. Un model bine format este unul auto-consistent semantic si în armonie cu modelele sale înrudite. În UML exista reguli semantice pentru nume, domeniul de reprezentare, vizibilitate, integritate si executie.
Sunt admise însa si modele mai putin decât bine formate, în sensul ca se pot admite si modele cu elemente ascunse, modele incomplete sau modele inconsistente, cel putin pentru iteratiile preliminare ale procesului de dezvoltare.
Mecanisme generale UML
Dezvoltarea modelelor UML este simplificata prin prezenta a patru mecanisme generale, aplicate uniform în întreg limbajul: specificatii, adnotari, diviziuni generale si mecanisme de extensie.
Specificatii→pentru fiecare parte a notatiei grafice UML exista o specificatie ce ofera o descriere textuala a sintaxei si semanticii acelui bloc constructiv; în timp ce notatia grafica UML se foloseste pentru vizualizarea unui sistem, specificatiile UML se folosesc pentru specificarea detaliilor sistemului.
Adnotari-Notele sunt cel mai important tip de adnotare. O nota este un simbol grafic pentru reprezentarea constrângerilor sau comentariilor atasate unui element sau unei colectii de elemente.
Notele se folosec numai pentru acele cerinte, observatii si explicatii care nu pot fi facute în mod simplu sau inteligibil folosind celelalte elemente UML.
Diviziuni generale→exista doua astfel de tipuri de diviziuni generale:
Mecanisme de extensie→permit extinderea limbajului în modalitati controlate. Aceste mecanisme includ stereotipuri, valori etichetate si constrângeri.
Un stereotip extinde vocabularul UML, permitând crearea de noi tipuri de blocuri constructive derivate din cele existente, dar care sunt specifice unei anumite probleme.
O valoare etichetata extinde proprietatile unui bloc constructiv UML, permitând crearea de noi informatii în cadrul specificatiei elementului.
O constrângere extinde semantica unui bloc constructiv UML, permitând adaugarea de noi reguli sau modificarea unora existente.
Atunci când se extinde un model folosind stereotipuri, valori etichetate sau constrângeri:
o Se standardizeaza numai un numar restrâns de mecanisme de extensie, si se evita sa se permita dezvoltatorilor individuali sa creeze extensii suplimentare;
o Se aleg nume scurte si inteligibile pentru stereotipuri sau valorile etichetate;
o Acolo unde precizia poate fi mai redusa, se foloseste text liber pentru a specifica constrângerile. Daca este nevoie de mai multa precizie, se foloseste OCL pentru a scrie expresii de constrângere.
v Modalitati de reprezentare
Prin modelarea unei aplicatii, se realizeaza o simplificare a realitatii, în asa fel încât sa se poata întelege mai bine sistemul dezvoltat. Folosind UML, modelele sunt construite din blocurile constructive de baza, cum ar fi clasele, interfetele, colaborarile, componentele, nodurile, dependentele, generalizarile si asocierile.
Diagramele sunt mijloacele prin intermediul carora aceste blocuri constructive sunt vizualizate. O diagrama este o prezentare grafica a unei multimi de elemente, cel mai adesea reprezentate ca un graf conex de noduri (elemente) si arce (relatii).
Diagramele UML se împart în doua clase distincte:
A. Diagrame structurale→sunt folosite pentru a vizualiza, specifica, construi si documenta aspectele statice ale sistemului. Acestea sunt organizate în jurul grupelor majore de elemente ce pot fi gasite în modelarea unui sistem:
Diagrame de clase→contin o multime de clase, interfete si colaborari, precum si relatiile dintre ele. Sunt cele mai folosite diagrame în modelarea sistemelor orientate obiect si ilustreaza vederea statica de proiectare a unui sistem.
Diagrame de obiecte→contin o multime de obiecte si relatiile dintre ele. Sunt folosite pentru a ilustra structurile de date, imagini statice ale instantelor elementelor din diagramele de clase.
Diagrame de componente→contin o multime de componente si relatiile dintre ele. Se folosesc pentru a ilustra vederea statica de implementare a unui sistem.
Diagrame de amplasare→contin o multime de noduri si relatiile dintre ele, ilustrând vederea statica de amplasare a unei arhitecturi.
Diagramele de pachete→care pot grupa în pachete elemente de acelasi tip (statice sau dinamice) sau chiar alte pachete.
B. Diagrame de componente→sunt folosite pentru a vizualiza, specifica, construi si documenta aspectele dinamice ale unui sistem. Acestea sunt organizate în jurul modalitatilor principale de a modela dinamica unui sistem:
O diagrama bine structurata:
Este focalizata pe comunicarea unui aspect al sistemului;
Contine numai acele elemente care sunt importante pentru întelegerea acelui aspect;
Furnizeaza detalii consistente cu nivelul sau de abstractizare (nu expune decât acele parti care sunt esentiale pentru întelegere);
Nu este atât de redusa încat sa dezinformeze cititorul asupra elementelor semantice relevante.
v Diagrama de clase (DC)
O diagrama de clase reprezinta un set de clase, interfete, colaborari si relatiile dintre ele. La fel ca toate celelalte diagrame, diagramele de clase pot contine note si constrângeri. De asemenea pot contine pachete, acestea având rolul de a grupa elementele modelului. Câteodata pot fi plasate si instante, în special când se doreste vizualizarea tipului acestora.
Pentru o clasa se pot specifica urmatoarele:
Aceste proprietati se indica prin notatiile si sub numele clasei.
Atributele si operatiile pot fi reprezentate într-o forma extinsa sau restrânsa, dupa cum urmeaza:
Sintaxa folosita pentru descrierea atributelor are urmatoarea forma:
nume_atribut: tip_atribut=valoare_initiala
Sintaxa folosita pentru descrierea operatiilor are urmatoarea forma:
Nume_operatie(lista_argumente):tip_returnat
Lista argumentelor reprezinta lista argumentelor operatiei, fiecare argument fiind descries astfel:
Nume_argument:tip_argument=valoare_implicita.
Pentru atributele si operatiile unei clase se specifica vizibilitatea, dupa cum urmeaza:
O operatie sau un atribut pot fi publice ) →orice alta clasa poate folosi proprietatea sau poate invoca operatia;
O operatie sau un atribut pot fi protejate ( # ) →sunt vizibile numai pentru descendentii clasei respective;
O operatie sau un atribut pot fi private ( - ) →numai clasa respectiva poate folosi proprietatea sau operatia.
În plus operatiile pot fi:
o Abstracte→sunt operatii incomplete pentru care clasele copii trebuie sa furnizeze o implementare (sunt specificate cu caractere italice);
o Operatii de tip frunza ( ) →nu pot fi suprascrise;
o Polimorfice→sunt specificate, într-o ierarhie de clase, cu aceeasi semnatura în diferite puncte ale ierarhiei. Operatia invocata, în momentul executiei, este aleasa în functie de tipul obiectului caruia îi apartine.
Relatiile care apar în diagramele de clase sunt: asocieri, relatii de generalizare, de dependenta si relatii de realizare. În general traversarea asocierilor se poate face în ambele directii. Câteodata, însa, poate fi necesara limitarea navigarii la o singura directie. Grafic se reprezinta printr-o sageata la unul din capetele asocierii.
O asociere poate fi calificata. Calificatorul este un atribut al asocierii având rolul partitionarii setului de obiecte de la celalalt capat al asocierii.
Un caz special de asociere este agregarea. Cu ajutorul agregarii se modeleaza o relatie de tip parte / întreg. Exista doua tipuri de relatii de agregare si anume:
o Simpla→este în întregime conceptuala si nu face altceva decât sa distinga între un "întreg" si o "parte";
o Compozitie→semnifica faptul ca partile pot fi create dupa obiectul compus, dar odata create traiesc si sunt distruse odata cu obiectul compus;
Diagramele de clase se folosesc pentru modelarea aspectelor statice ale unui sistem. În general, cu ajutorul lor, se modeleaza vocabularul sistemului si colaborarile (aspectele statice ale colaborarilor).
Modelarea vocabularului unui sistem implica luarea de decizii în ce priveste abstractizarile care fac parte din sistemul aflat în constructie si cele care ramân în afara granitelor sistemului. Cu ajutorul diagramelor de clase se vor specifica aceste abstractizari si responsabilitatile lor.
Pentru modelarea vocabularului se procedeaza astfel:
o Se identifica acele elemente pe care utilizatorii si implementatorii le folosesc pentru a descrie problema sau solutia;
o Pentru fiecare abstractizare se identifica un set de responsabilitati; trebuie sa existe o distributie echilibrata a acestora între clase;
o Se vor specifica toate atributele si operatiile necesare pentru îndeplinirea responsabilitatilor de catre fiecare clasa.
O clasa trebuie sa faca un anumit lucru bine. Daca o clasa este prea mare devine prea greu de de schimbat si de refolosit. Daca o clasa este prea mica, vor exista prea multe abstractizari de gestionat, iar modelul va fi greu de înteles.
Iata si diagrama de clase pentru evidenta clientilor de la Electrica S.A.:
v Diagrama de obiecte
Diagramele de obiecte modeleaza instante ale elementelor continute în diagramele de clase. Se folosesc pentru modelarea aspectelor statice ale unui sistem. Aceasta implica surprinderea unui instantaneu al sistemului.
O diagrama de obiecte surprinde aspectele statice ale unei interactiuni, constând din obiecte care interactioneaza, dar fara a trimite mesaje.
Elementele principale continute într-o diagrama de obiecte sunt obiectele si legaturile. De asemenea, la fel ca celelalte diagrame, pot contine note si constrângeri. Se pot folosi pachete si subsisteme pentru gruparea elementelor.
Atunci când se modeleaza un sistem diagramele de clase specifica complet semantica abstractizarilor si a relatiilor dintre ele. Cu diagramele de obiecte nu este posibil ss se specifice complet structura de obiecte a sistemului: pentru o clasa individuala pot exista o multime de instante, iar pentru un set de clase aflate în relatie una cu cealalta pot exista o multitudine de configuratii posibile. Pentru construirea unei diagrame de obiecte se recomanda urmatorii pasi:
Identificarea mecanismului care se doreste a fi modelat. Un mecanism reprezinta anumite functii sau comportamente ale unei parti a sistemului, care rezulta în urma interactiunii unui grup de clase, interfete, etc.
Pentru fiecare mecanism se identifica elementele participante (clase, interfete, etc.)
Se considera un scenariu care foloseste aceste mecanisme; se considera un anumit moment în timp si se identifica obiectele care participa la scenariu;
Se reprezinta starile (cu valorile atributelor) pentru fiecare obiect, necesare pentru întelegerea scenariului;
Similar se reprezinta legaturile între obiecte, reprezentând instante ale asocierilor.
v Diagrama de pachete
Vizualizarea, specificarea, constructia si documentarea sistemelor mari implica manipularea unui numar mare de clase, interfete, componente, noduri, diagrame si alte elemente. Apare astfel necesitatea organizarii elementelor în partitii mai mici. Acesta este rolul pachetelor, care constituie un mecanism care are ca scop organizarea elementelor de modelare în grupuri.
Un pachet bine proiectat grupeaza elemente apropiate din punct de vedere semantic. Pachetele bine structurate sunt slab cuplate între ele si au un control al accesului la continutul lor bine definit.
Prin organizare cu ajutorul pachetelor, modelele devin usor de înteles. UML permite construirea de diagrame de pachete. Fiecare pachet din diagrama trebuie sa aiba un nume care îl distinge de celelalte (numele trebuie sa fie unic) . Numele poate fi "nume simplu" sau "nume de cale", atunci când este prefixat cu numele pachetului care contine pachetul respectiv (daca este cazul).
Un pachet poate cuprinde elemente cum sunt: clase, interfete, componente, noduri, colaborari, cazuri de utilizare si chiar alte pachete. Posedarea acestor elemente constituie o relatie de compozitie, însemnând ca elementul este declarat în pachet. Daca pachetul este distrus, atunci este distrus si elementul. Fiecare element este continut în mod unic de un singur pachet.
Deoarece unele pachete pot contine alte pachete, înseamna ca modelele se pot descompune ierarhic. În practica este de dorit sa se evite o ierarhie prea mare, doua sau trei niveluri fiind suficiente.
Continutul unui pachet poate fi reprezentat textual sau grafic. Vizibilitatea elementelor din interiorul unui pachet se poate controla exact în acelasi mod ca pentru atributele si operatiile claselor. Un element poate fi public, protejat sau privat. Un pachet declarat "friend" pentru un alt pachet poate vedea toate elementele din interiorul acestuia, indiferent de vizibilitate.
Între pachete pot exista urmatoarele relatii:
Import / export → presupunând doua pachete, A si B, daca pachetul A importa pachetul B, atunci elementele din A vor vedea elementele publice din B. Partea publica a lui B reprezinta exportul pachetului B. Grafic se reprezinta printr-o relatie de dependenta stereotipizata cu stereotipul <<import>>:
Generalizare → este asemanatoare cu generalizarea claselor. Pachetele mai specializate mostenesc elementele publice si protejate de la pachetul mai general. La fel ca si în cazul claselor, pachetele mai specializate pot inlocui pachetele mai generale oriunde sunt folosite acestea:
Diagrama pachetelor pentru sistemul informatic de evidenta a personalului si calcul al salariilor este urmatoarea:
v Diagrama cazurilor de utilizare
Caz de utilizare (USE CASE)
În natura nu exista sisteme izolate. Orice sistem interactioneaza cu actori umani sau automati, care folosesc sistemul cu un scop si se asteapta ca sistemul sa se comporte într-un mod previzibil. Cazul de utilizare specifica comportamentul sistemului sau a unei parti din sistem si este o descriere a unui set de secvente de actiuni, incluzând variante, pe care, un sistem le executa pentru a produce un rezultat observabil pentru un actor.
Cazul de utilizare implica interactiunile dintre actori si sistem. Actorii pot fi oameni sau sisteme automate.
Grafic, un caz de utilizare se reprezinta printr-o elipsa. Fiecare caz de utilizare trebuie sa aibe un nume distinct de al celorlalte cazuri de utilizare. Numele este format dintr-un sir de caractere si se numeste "nume simplu". "Nume de cale" este numele cazului de utilizare prefixat de numele pachetului din care face parte acesta.
Actorul reprezinta un set de roluri pe care utilizatorul le foloseste când interactioneaza cu cazurile de utilizare. Un actor reprezinta uin rol uman, un dispozitiv hardware sau orice alt sistem. O instanta a unui actor reprezinta o interactiune individuala cu sistemul. Actorii nu fac parte din sistem. Ei se afla în afara sistemului si pot fi conectati la cazuri de utilizare prin asocieri.
Comportamentul unui caz de utilizare se poate specifica prin descrierea fluxului de evenimente. Când se scrie fluxul de evenimente, trebuie sa se indice cum si când începe si se încheie cazul de utilizare, când interactioneaza cu actorii, ce obiecte sunt schimbate, fluxul de baza si alternative al comportamentului.
În primul rând, se descrie fluxul de evenimente (text liber) pentru un caz de utilizare, apoi, pentru a specifica grafic aceste fluxuri se foloseste diagrama de interactiune.
Deoarece un caz de utilizare foloseste un set de secvente, este de preferat ca descrierea acestuia sa fie separata pe fluxuri alternative. Fiecare varianta poate fi exprimata în secvente diferite. Aceste secvente se numesc scenarii.
Un caz de utilizare surprinde comportamentul unui sistem, fara a se specifica cum este implementat acest comportament. Aceasta separare este importanta deoarece analiza sistemului nu trebuie sa fie influentata de aspectele de implementare. Implementarea cazului de utilizare se poate face creând o societate a claselor si a elementelor care lucreaza împreuna.
Societatea elementelor, incluzând deopotriva structura statica si cea dinamica, se numeste colaborare.
Cazurile de utilizare pot fi utilizate prin gruparea lor în pachete, în aceeasi maniera în care sunt organizate clasele, existând relatii de generalizare, de incluziune si de extindere:
Generalizarea cazurilor de utilizare se realizeaza asemanator ca în cazul claselor. Prin aceasta, cazul de utilizare "copil" mosteneste comportamentul si întelesul cazului de utilizare "parinte"; copilul poate adauga sau suprascrie comportamentul "parintelui" si îl poate substitui în orice loc în care apare acesta.
Incluziunea între cazuri de utilizare semnifica faptul ca un caz de utilizare de baza încorporeaza comportamentul altui caz de utilizare, într-o locatie specificata în cazul de utilizare de baza.
Extinderea între cazuri de utilizare specifica faptul ca un caz de utilizare de baza încorporeaza comportamentul unui alt caz de utilizare, într-o locatie specificata indirect, prin extinderea cazului de utilizare.
Diagrama cazurilor de utilizare (DCU)
Este una din cele cinci diagrame din UML, ea modelând aspectele dinamice ale sistemului. Aceasta diagrama este utilizata pentru modelarea comportamentului sistemului, subsistemului sau clasei.
DCU este o diagrama care contine un set de cazuri de utilizare, actori si relatiile dintre acestea (relatii de dependenta, de generalizare si de asociere). De asemenea, DCU poate contine restrictii si pachete, folosite pentru a grupa elementele.
Forma generala a unei DCU arata astfel:
Când se modeleaza un caz de utilizare static al sistemului, DCU se poate aplica în doua moduri:
o Modelarea contextului unui sistem → presupune trasarea de linii în jurul întregului sistem si asertiunea prin care actorii aflati în afara sistemului interactioneaza cu linia.
o Modelarea cerintelor sistemului → implica specificarea a ceea ce trebuie sa faca sistemul, indifferent de modul in care acesta va realize cerintele.
Cu ajutorul DCU se poate modela continutul sistemului, punând în evidenta actorii din afara acestuia. Este important sa se decida cu exactitate actorii care vor fi inclusi în sistem si care vor fi eliminati, alegându-se numai aceia care sunt necesari în viata sistemului. Acest lucru se realizeaza în felul urmator :
Se identifica actorii care înconjoara sistemul, alegând acele grupuri care necesita ajutor din partea sistemului pentru a-si îndeplini sarcinile; care sunt necesare pentru a executa functiile sistemului sau cele care interactioneaza cu hardware-ul extern sau cu alte produse software precum si acele grupuri care executa functii secundare pentru administrare si întretinere.
Actorii care sunt identici se organizeaza sub forma unei ierarhii folosind relatii de generalizare si specializare.
Acolo unde este necesar, se identifica un stereotip pentru fiecare tip de actor.
Se populeaza DCU cu acesti actori si se specifica caile de comunicare de la fiecare actor catre cazurile de utilizare ale sistemului.
Cerintele sistemului pot fi exprimate în diverse forme, de la text nestructurat la expresii într un limbaj formal. Majoritatea cerintelor functionale pot fi exprimate ca fiind cazuri de utilizare, facând astfel ca DCU-urile sa fie esentiale pentru managementul acestor cerinte.
Pentru stabilirea cazurilor de utilizare se procedeaza astfel
Se stabileste contextul sistemului prin identificarea actorilor care îl înconjoara;
Comportamentul fiecarui actor este considerat previzibil;
Se identifica comportamentele obisnuite ca fiind cazuri de utilizare;
Se transforma comportamentul obisnuit într-un caz de utilizare, iar comportamentul variabil se transforma într-un nou caz de utilizare care extinde mai multe linii de flux principale;
Se modeleaza cazurile de utilizare, actorii si relatiile dintre ei într-o DCU;
Se adauga cazurilor de utilizare cerintele nonfunctionale (o cerinta este o trasatura, proprietate sau comportament al sistemului ).
Pentru evidenta clientilor de la Electrica
v Diagrama de interactiune(DI)
Diagrama de interactiune este folosita pentru modelarea aspectelor dinamice ale sistemului dar si pentru construirea unui sistem executabil prin inginerie inversa. Ea este alcatuita dintr-un set de obiecte si relatiile dintre ele, incluzând si mesaje pe care obiectele le trimit de la unul la altul.
Diagrama de interactiune este asemanatoare cu celelalte tipuri de diagrame din punct de vedere al numelui si al modalitatilor de reprezentare grafica (obiecte, legaturi, mesaje), conîinând, de asemenea, observatii si restrictii, dar difera din punct de vedere al continutului. Exista doua tipuri de diagrame di interactiune si anume diagrama de secventa (DS) si diagrama de colaborare (DC). Cele doua diagrame sunt echivalente din punct de vedere semantic si se pot transforma una în alta fara pierderi de informatii.
Diagrama de secventa este o diagrama de interactiune care subliniaza ordinea mesajelor în functie de timp. Grafic, o diagrama de secventa este o tabela care arata obiectele (aranjate pe axa OX) si mesajele ordonate în functie timp (pe axa OY).
Diagrama de colaborare este o diagrama de interactiune care subliniaza organizarea structurala a obiectelor care trimit si primesc mesaje. Grafic, o diagrama de colaborare este o colectie de vârfuri si arce.
Diagrama de secventa subliniaza ordinea, în functie de timp, a mesajelor. Pentru a realiza o DS se plaseaza obiectele care participa la interactiune la marginea de sus a diagramei, de-a lungul axei OX. Obiectele care încep interactiunea se aseaza la stânga iar obiectele care urmeaza în partea dreapta. Mesajele se plaseaza de a lungul axei OY, in ordinea timpului, de sus în jos, pentru a putea vizualiza mai usor fluxul de control, din punct de vedere al timpului.
Diagrama de secventa contine doua elemente specifice
Linia de viata a obiectelor → linie verticala care reprezinta existenta unui obiect de-a lungul unei perioade de timp. Majoritatea obiectelor care apar în DI exista pe toata durata interactiunii, având linia de viata trasata de la vârful diagramei pâna la baza. Alte obiecte pot fi create pe parcursul interactiunii. Liniile lor de viata încep la primirea mesajului numit "creare". De asemenea, exista obiecte care pot fi distruse pe parcursul interactiunii, ele având linia de viata încheiata odata cu primirea mesajului "distrugere".
Punctul de control →este un dreptunghi înalt si subtire care indica perioada de timp în care obiectul realizeaza o actiune. Capatul de sus al dreptunghiului este aliniat la începutul actiunii iar capatul de jos la sfârsitul actiunii.
Diagrama de colaborare subliniaza organizarea obiectelor care participa la interactiune. Acestea sunt plasate primele, ca vârfuri ale unui graf, se traseaza legaturile care conecteaza obiecte, ca arcuri în acest graf, apoi se adauga acestor legaturi, mesajele pe care obirctele le primesc sau le trimit.
Diagrama de colaborare contine doua elemente specifice:
Calea → pentru a indica faptul ca un obiect este legat cu un altul trebuie sa existe o cale ("local", "parameter", "global" sau "self")
Numarul de secventa → pentru a indica ordinea, mesajul trebuie prefixat cu un numar, începând de la 1 si crescând. Se pot modela mesaje imbricate, astfel 1 este primul mesaj, 1.1 este primul mesaj în mesajul 1, 1.2 este al doilea, etc.
v Diagrama de activitati (DA)
Este o schema logica care prezinta fluxurile de control dintre activitati. Ea este folosita pentru a modela aspectele dinamice ale sistemului si presupune modelarea unui proces pas cu pas. Cu acest tip de diagrama se poate modela fluxul unui obiect care trece din stare în stare.
Grafic, diagrama de activitati este o colectie de vârfuri si arce. Ea contine stari de activitate si stari de actiune, tranzitii si obiecte.
Pentru reprezentarea grafica se
foloseste simbolul 
.
În interior se poate scrie orice expresie.
Starile de actiune nu pot fi descompuse. Ele sunt atomice si nu pot fi întrerupte. Starile de actiune nu pot fi descompuse. Ele sunt atomice si nu pot fi întrerupte.
Starile de activitate pot fi descompuse, activitatea putând fi reprezentata de alta diagrama. Ele nu sunt atomice si pot fi întrerupte.
Starea de actiune este un caz particular al starii de activitate. Între ele exista anumite diferente de notatie starea de activitate are parti în plus actiuni de intrare si de iesire precum si specificarea submasinii pe care se desfasoara activitatea.
si o stare finala 
. Pe fiecare tranzitie care
pleaca din acest simbol, se plaseaza o expresie booleana
care se evalueaza numai când se intra în ramura.v Diagrama de tranzitie a starilor 323i86d
O diagrama de tranzitie a starilor 323i86d arata o masina de stare. Ca si diagramele de activitati, ele sunt utile în modelarea ciclului de viata a unui obiect. Ele pot fi atasate claselor, cazurilor de utilizare sau întregului sistem, pentru a vizualiza, specifica si documenta aspectele dinamice ale acestora.
O masina cu stari este un comportament care specifica secventa de stari prin care trece un obiect, pe parcursul vietii sale, ca raspuns la evenimente. O stare este o conditie sau o situatie în viata unui obiect, când acesta satisface anumite conditii, realizeaza anumite activitati sau asteapta anumite evenimente. Un eveniment reprezinta specificarea unei aparitii semnificative care are o locatie în spatiu si timp. O activitate este o executie nonatomica în derulare într-o masina de stare. O actiune este o operatie atomica, executabila, care duce la schimbarea unei stari sau returneaza o valoare.
O diagrama de tranzitie contine în mod obisnuit stari simple si compuse, precum si tranzitii, inclusiv evenimente si actiuni.
În esenta, o diagrama de stare este o proiectie a elementelor care se gasesc într-o masina de stare. Diagramele de activitati pot fi considerate un cay special de diagrame de stari, în care cele mai multe dintre stari sunt stari activitati iar cele mai multe tranzitii sunt cauzate de completarea unor din starea sursa.
O masina cu stari este un comportament ce specifica secventa de stari prin care trece un obiect pe parcursul vietii sale, ca raspuns la evenimente, împreuna cu raspunsul lor la evenimente. Masinile cu stari se folosesc pentru a modela aspectele dinamice ale sistemului. Când se produce un eveniment, are loc o activitate, în functie de starea curenta a obiectului. Activitatile se concretizeaza în cele din urma într-o actiune care conduce la o schimbare a starii modelului sau la returnarea unei valori.
O masina cu stari modeleaza un singur obiect, fie ca este instanta a unei clase, un caz de utilizare sau chiar întregul sistem. Pe parcursul vietii, un obiect este expus la o varietate de evenimente ca: un semnal, invocarea unei operatii, crearea sau distrugerea unui obiect, trecerea timpului.
Masinile cu stari pot fi vizualizate în doua moduri:
o Folosind diagramele de activitati: ne concentram pe activitatile care au loc în obiect
o Folosind diagramele de stare, ne concentram pe comportamentul ordonat de evenimente al obiectului.
Elementele unei diagrame de tranzitie a starilor 323i86d se descriu si se reprezinta dupa cum urmeaza:
Stare→o stare are mai multe parti:
Nume: o stare poate fi si anonima
Actiuni de intrare / iesire, executate la intrarea / iesirea dintr-o stare
Tranzitii interne: realizate fara a cauza o schimbare de stare
Substari: structura imbricata a unei stari implica substari disjuncte sau concurente
Evenimente amânate: sunt recunoscute într-o stare dar puse într-o coada pentru a fi rezolvate de obiect într-o alta stare.
O stare initiala indica locul implicit de start pentru o masina de stare sau o substare. O stare finala indica executia unei masini de stare sau faptul ca starea de finalizare a fost completata.
În momentul schimbarii unei stari se spune ca "are loc" o tranzitie. Pâna când tranzitia are loc, obiectul este într-o stare sursa. Dupa ce tranzitia are loc, este într-o stare destinatie.
O tranzitie are cinci parti:
q Starea sursa
q Eveniment declansator → a carui receptare de catre obiect face posibil sa aiba loc evenimentul, asigurând satisfacerea conditiilor. Evenimentele pot fi semnale, apeluri, trecerea timpului, schimbarea de stare. Un semnal sau un apel poate avea parametrii ale caror valori sunt disponibile tranzitiei, inclusiv expresii pentru conditii sau actiuni. Pot exista tranzitii fara declansare, adica neavând element declansator si având loc în momentul în care starea sursa si-a terminat activitatea.
q Conditii → o expresie booleana care este evaluata când are loc tranzitia; daca are valoare de adevar, atunci tranzitia poate avea loc. Este redata ca o expresie booleana inclusa în paranteze patrate si plasata dupa evenimentul declansator si este evaluata doar dupa ce are loc evenimentul declansator al tranzitiei. Conditia se evalueaza o singura data pentru fiecare tranzitie, la momentul la care are loc evenimentul, dar poate fi evaluata din nou daca trantitia este repetata.
q Actiunea → o operatie atomica, executabila, care poate actiona direct asupra obiectului care detine masina de stari si indirect asupra altor obiecte care sunt vizibile obiectului. Actiunea poate include apeluri de operatii, crearea si distrugerea unui alt obiect sau trimiterea unui semnal unui obiect. O actiune este atomica, aceasta însemnând ca nu poate fi întrerupta de un eveniment si ruleaza pâna la terminare, spre deosebire de o activitate, care poate fi întrerupta de alte evenimente.
q Starea destinatie
Stari si tranzitii avansate
q Actiuni de intrare / iesire: se folosesc atunci când se doreste ca aceeasi actiune sa aiba loc ori de câte ori se intra într-o stare / se paraseste o stare, indiferent de tranzitia care conduce la acea stare. În simbolul pentru stare se va include, în acest caz, o actiune de intrare (marcata de evenimentul cuvânt-cheie entry) respectiv o actiune de iesire (marcata de evenimentul exit).
q Tranzitii interne: se folosesc atunci când se doreste rezolvarea unor evenimente fara a parasi starea. Acestea sunt subtil diferite de tranzitiile spre sine. Într-o tranzitie spre sine, un eveniment declanseaza o tranzitie, se paraseste starea, eventual are loc o actiune, si apoi se reintra în acea stare, deci se realizeaza actiunea de iesire, actiunea tranzitiei si apoi actiunea de intrare în starea respectiva. Presupunând ca se doreste manipularea unui eveniment fara sa se execute actiunile de intrare / iesire, se poate include o tranzitie interna marcata de un eveniment. Ori de câte ori obiectul se afla în acea stare si are loc evenimentul, are loc si actiunea respectiva, fara a se parasi starea.
q Activitati: când obiectul este într-o stare, în general ramâne inactiv, asteptând aparitia unui eveniment. Uneori, aflat într-o stare, un oviect va realiza o sarcina si o va continua pâna când este întrerupt de un eveniment. În UML se foloseste pentru aceasta o tranzitie speciala do.
q Evenimente amânate: în unele situatii de modelare, se doreste recunoasterea unor evenimente, dar amânarea raspunsului la acestea . Deci un eveniment amânat este o lista de evenimente a caror aparitie în stare este amânata pâna când devine activa o stare în care evenimentele acestea nu sunt amânate, moment în care ele se declanseaza si pot conduce la o tranzitie, ca si cum atunci s-ar fi întâmplat. Acest lucru se specifica prin listarea unui eveniment cu actiunea speciala defer.
Substari
O substare este o stare care este imbricata într-o alta stare. O stare care are substari se numeste stare compusa si poate contine substari secventiale sau concurente.
a. Substari secventiale sau disjuncte
Fiind dat un set se stari secventiale, obiectul se afla în starea compusa si doar într-und din substarile sale la un moment dat. tranzitie dintr-o alta stare poate avea ca tinta o stare compusa sau o substare a acesteia. Daca tinta este starea compusa, atunci masina cu stari din interiorul sau trebuie sa contina o stare initiala. Daca tinta este o substare, atunci controlil îi este predat acesteia, dupa executia actiunii de intrare pentru starea compusa si si a actiunii de intrare pentru substare.
Câteodata se doreste modelarea unui obiect astfel încât sa se memoreze ultima substare care a fost activa înainte de parasirea starii compuse. Pentru aceasta se folosesc "istorii ale starilor" (history states). Daca se doreste ca o tranzitie din afara obiectului compus sa activeze ultimei substari care a fost activa, atunci tranzitia va fi reprezentata catre "history states".
b. Substari concurente aceste substari care specifica doua sau mai multe masini de stare care se executa în paralel, în contextul obiectului care le include. Date fiind doua sau mai multe substari concurente la acelasi nivel, un obiect va fi într-o stare secventiala din fiecare din starile concurente. O masina cu stari imbricata concurenta nu are stare initiala sau finala.
Iata diagrama de tranzitie a starilor 323i86d pentru entitatea factura
v Diagrame de desfasurare(DD)
Diagramele de desfasurare reprezinta un tip de diagrame folosit în modelarea aspectelor fizice ale unui sistem orientat obiect. O astfel de diagrama arata configuratia nodurilor de procesare si a componentelor lor în momentul executiei aplicatiei.
Se pot utiliza diagrame de desfasurare pentru a modela viziunea asupra desfasurarii statice a sistemului. În mare parte, aceasta înseamna modelarea topologiei hardware pe care se executa sistemul. Diagramele de desfasurare se focalizeaza asupra nodurilor sistemului.
Pentru alocarea componentelor la noduri se poate alege una din variantele urmatoare
o Alocarea nu este vizibila (se gaseste în specificaaia fiecarui nod)
o Se folosesc relatii de dependenta pentru conectarea componentelor la nodurile de care apartin
o Se reprezinta componentele în nod, într-un compartiment separat
Diagramele de desfasurare nu sunt importante numai pentru vizualizarea, specificarea si documentarea sistemelor distribuite, client/server, ci si pentru directionarea sistemelor executabile prin inginerie directa si inversa.
În UML se utilizeaza diagrame de desfasurare ca în figura urmatoare
O diagrama de desfasurare se distinge de celelalte tipuri de diagrame prin continutul ei particular. De obicei contine noduri, dependente si relatii de asociere. În plus, mai poate contine note si reguli poate contine de asemenea componente, care exista în noduri, pachete sau subsisteme. Uneori, se pot plasa inclusiv instante, în special atunci când se doreste vizualizarea unei instante dintr-o familie de topologii hardware.
Diagramele de desfasurare nu sunt necesare întotdeauna. Daca se dezvolta software care rezida pe o masina care este directionata de un sistem de operare gazda, atunci diagramele de desfasurare pot fi ignorate. Pe de alta parte, daca se dezvolta software care interactioneaza cu dispozitive pe care de obicei nu le directioneaza sistemul de operare sau care sunt distribuite fizic pe mai multe procesoare, atunci este de ajutor utilizarea diagramelor de desfasurare.
Diagramele de desfasurare se folosesc în urmatoarele scopuri:
Pentru modelarea sistemelor cu software implementat hardware → un astfel de sistem este o colectie software-intensiva de hardware care interactioneaza cu lumea fizica; aceste sisteme implica software care controleaza dispozitive precum motoare, display-uri si care sunt controlate de stimuli externi precum senzori de intrare, miscare, temperatura. Se pot utiliza diagrame de desfasurare pentru a modela dispozitivele si procesoarele care compun un astfel de sistem.
Pentru modelarea sistemelor client/server → un astfel de sistem este o arhitectura focalizata pe realizarea unei separari clare între interfata cu utilizatorul a sistemului (de pe client) si datele permanente ale sistemului (de pe server).
Pentru modelarea sistemelor complet distribuite → un astfel de sistem are în compunere multe versiuni de componente software, unele dintre ele putând migra din nod în nod. Gestionarea unui astfel de sistem înseamna luarea de decizii care sa permita continua schimbare a topologiei sistemului.
v Diagrame de componente
Diagramele de componente reprezinta un alt tip de diagrame utilizat în modelarea aspectelor fizice ale sistemelor orientate-obiect. O astfel de diagrama arata organizarea si dependentele din cadrul unui set de componente. Ele se pot folosi pentru modelarea viziunii asupra implementarii statice a unui sistem. Aceasta implica modelarea elementelor fizice care pot exista într-un nod, cum ar fi programele executabile, biblioteci, tabele, fisiere si documente. Diagramele de componente sunt diagramele claselor esentiale care se orienteaza pe componentele unui sistem.
Diagramele de componente nu sunt importante doar pentru vizualizare, ci si pentru construirea sistemelor executabile prin inginerie directa si inversa. O diagrama de componente descrie un set de componente si relatiile dintre ele. Grafic, este o colectie de noduri si arce.
Diagrama se utilizeaza în unul din urmatoarele scopuri
o Pentru a modela codul sursa → cu limbajele de programare curente, se foloseste putin cod deoarece se utilizeaza medii de dezvoltare integrate, care stocheaza codul sursa în fisiere; de aceea prin utilizarea diagramelor se modeleaza managementul configurarii acestor fisiere.
o Pentru a modela produse executabile → în acest context, un produs se focalizeaza pe parti necesare pentru furnizarea sistemului în lucru; astfel, utilizând diagrame de componente, se vizualizeaza, specifica si documenteaza deciziile referitoare la partile fizice care formeaza software-ul.
o Pentru a modela baze de date fizice → modelarea acestora înseamna stocarea informatiilor în tabelele unei baze de date relationale sau pe paginile unei baze de date orientate-obiect se folosesc diagramele de componente pentru a repreyenta aceste baze de date.
o Pentru a modela sisteme adaptabile → unele sisteme sunt statice, altele sunt dinamice, avand componente mobile care migreaza în functie de schimbarile aparute; se folosesc diagramele de componente împreuna cu alte diagrame UML pentru a modela comportamentul unor astfel de sisteme.
v Comparatii cu alte metode
Paradigma orientarii obiect s-a concretizat într-un numar mare de metode. Treptat, însa, s-au evidentiat pe baza experientei acumulate, un numar relativ restrâns de metode importante
Metoda lui G. Booch
OOSE (Object-Oriented Software Engineering), a lui I. Jacobson
OMT (Object Modelling Technique), a lui J. Rumbaugh
Fiecare din acestea era o metoda completa, având însa puncte tari si puncte slabe, unanim recunoscute. Spre exemplu, metoda lui Booch era folositoare în special pentru fazele de proiectare si constructii ale proiectelor, OOSE oferea un sprijin excelent pentru cazurile de utilizare, ca un mod de a coordona identificarea cerintelor, analiza si proiectarea de nivel înalt, în timp ce OMT -2 era folositoare pentru analiza si pentru aplicatii informaice având de prelucrat masive de date. Procesul de unificare a metodelor a început sa prinda contur la mijlocul anilor '90, când Gradz Booch, Ivar Jacobson si James Rumbaugh au început sa introduca în propriile metode si concepte utilizate de catre ceilalti. Este evident ca limbajul unificat a preluat elementele semnificative din aceste metode. Obiectivele principale ale unificarii metodelor au fost stabilite dupa cum urmeaza
Sa se permita modelarea, de la concept si pâna la artefactele executabile, folosind tehnici orientate obiect.
Sa fie abordate aspectele de scala, inerente sistemelor complexe, cu functionalitati critice
Sa fie creat un limbaj de modelare utilizabil atât de oameni cât si de calculatoare.
Unificarea limbajelor de modelare a fost urmata de elaborarea unei metodologii cadru cunoscuta sub denumirea de Unified Software Development Process → USDP. Un produs al firmei Rational Software care este derivat din aceasta metodologie cadru este Rational Unified Process → RUP.
|
