Analiza si gestiunea sistemelor informatice  complexe
Curs 2

Objectory. UML. Diagrame de cazuri de utilizare

Back Up Next

 

Objectory

        Procesul Objectory de dezvoltare a unui sistem informatic este structurat pe două dimensiuni:
                - dimensiunea temporală: diviziunea ciclului de viaţă al sistemului informatic în faze şi iteraţii
               
- componentele procesului – producerea unei mulţimi specifice de elemente (documente, diagrame, etc) şi a unor activităţi bine definite

        Componentele procesului au fost detaliate in cursul precedent, acestea fiind: culegerea de specificatii (analiza functionala), analiza, proiectarea, implementarea si testarea.

        Structurarea unui proiect în funcţie de dimensiunea temporala induce următoarele faze:
            -         Lansare – specificarea succintă a proiectului
            -         Elaborarea – planificarea activităţilor necesare şi a resurselor necesare. Specificarea caracteristicilor şi proiectarea arhitecturii
            -         Construcţie – construirea produsului printr-o serie de iteraţii incrementale
            -         Tranziţie – furnizarea produsului comunităţii (distribuire, instruire etc)

Figura 1. Procesul de dezvoltare a sistemelor informatice (Rational Objectory) 

 

UML (Unified Modeling Language)

        În anii ’90 a apărut o serie de metode de dezvoltare a aplicaţiilor, fiecare dintre acestea introducând notaţii (grafice sau formale) particulare.  Printre cele mai populare metode se numărau:
   
         - OMT (Object Modeling Technique) – James Rumbaugh
   
         - OOD (Object Oriented Design) – Greedy Booch
   
         - OOSE (Object-Oriented Software Engineering) – Ivar Jacobson

        Fiecare dintre aceste metode avea puncte ‘tari’ şi ‘slabe’. OMT era potrivit pentru etapa de analiză, OOD pentru etapa de proiectare iar OOSE avea în vedere în special etapa de analiză comportamentală.  Anii ’90 sunt caracterizaţi de aşa-numitul 'război al metodelor', în care fiecare dintre autori (numiţi şi guru) încerca să impună propria metodă de analiză şi proiectare a aplicaţiilor.

        Limbajul UML s-a născut din dorinţa de a unifica cele mai importante concepte introduse de fiecare dintre aceste metode precum şi pentru a găsi o notaţie standard de modelare a acestor concepte.

        În  septembrie 1997 'războiul metodelor' ia sfârşit prin adoptarea de către OMG a limbajului UML ca limbaj standard de modelare a aplicaţiilor.  OMG (Object Management Group) reprezintă un consorţiu internaţional al cărui obiectiv principal îl constituie promovarea abordării orientate obiect în cadrul ingineriei softului.

        Limbajul UML s-a format având la bază cele trei metode amintite mai sus, la care se adaugă contribuţii notabile în diverse faze ale etapelor de analiză şi proiectare: clasificare – Odell, hărţi de stări – David Harel, ciclu de viaţă al obiectelor – Shlaer-Mellor, şabloane de proiectare – Gamma ş.a. etc.

        UML reprezintă un standard de notaţie. Introduce un număr de 9 diagrame de descriere a unui sistem informatic şi semantica acestor diagrame. UML nu propune şi un proces de utilizare a acestor diagrame în construcţie unei aplicaţii.  

Cele nouă tipuri de diagrame propuse de UML sunt:
            - de activităţi,
            - de cazuri de utilizare,
            -  de clase,
            -  de colaborare,
            -  de componente,
            -  de exploatare,
            -  de obiecte,
            -  de secvenţă,
            - de stări.

Aceste diagrame pot fi împărţite în 3 categorii:
           -  diagrame statice – descriu structura şi responsabilitaţile sistemului informatic (diagramaele de cazuri de utilizare, clase, obiecte)
   
        - diagrame dinamice – descriu comportamentul şi interacţiunile care au loc între diverse entităţi în cadrul sistemului informatic (diagrame de activităţi, colaborare, secvenţă, stări, cazuri de utilizare)
           - diagrame arhitecturale – descrie componentele executabile ale sistemului şi determină loacaţiile fizice de execuţie şi nodurile de stocare a datelor (diagrame de componete, exploatare)

Diagrame de cazuri de utilizare

        Una dintre condiţiile ce trebuiesc indeplinite ca un proiect sa aibă succes este aceea ca cerinţele proiectului să fie definite într-o manieră care să permită o uşoară înţelegere, indiferent de nivelul de pregătire informatica al celui care este implicat în proiect. De asemenea, modificările ce apar pe parcurs în cerinţe trebuie să fie cu uşurinţă asimilate de către membrii echipei de dezvoltare.  Diagramele de cazuri de utilizare au rolul de a reprezenta intr-o forma grafica functionalitatile pe care trebuie sa le indeplineasca sistemul informatic in faza sa finala.  De aceea modelul realizat de diagramele de cazuri de utilizare alaturi de documentele de descriere succinta a fiecarui caz de utilizare determinat poarta numele de model al cerinţelor.

        Diagramele de cazuri de utilizare sunt formate din doua categorii de entitati (actori si cazuri de utilizare) si relatii intre acestea.

        Actorii sunt roluri jucate de diverse persoane sau sisteme informatice şi care interacţionează cu sistemul informatic aflat în dezvoltare.  Este important de retinut faptul ca o persoană poate juca mai multe roluri şi un rol poate caracteriza mai multe persoane. Reprezentare grafica a actorilor in UML este un omulet stilizat avand la subsol un text ce reprezinta rolul jucat de actor (figura 2).


Figura 2. Reprezentarea grafica a actorilor in UML

Determinarea actorilor se face răspunzand la întrebările: 
            - cine ce este interesat, 
            - cine modifica date, 
            - cine se interfaţează, sau 
            - cine doreşte informaţii de la sistem. 

Raspunsurile concrete la cele patru intrebari de mai sus se introduc intr-o asa-numita tabelă de evenimente cu 4 coloane: Subiect(actor), Verb, Obiect, Frecvenţă.  Aceasta tabela de evenimente permite de asemenea detectarea tuturor cazurilor de utilizare a sistemului.

Cazurile de utilizare reprezintă secvenţe de tranzacţii ce au loc în dialog cu sistemul şi care sunt înrudite din punct de vedere comportamental.  Practic, un caz de utilizare modeleaza un dialog intre un actor si sitemul informatic.  Multimea de cazuri de utilizare a unui sistem reprezinta toate modalitatile in care sistemul poate fi folosit.

Cazurile de utilizare : 
        -  sunt unităţi de sine stătătoare, bine delimitatate (începutul şi sfârşitul unui caz de utilizare sunt cuprinse în acesta).  
       
-  trebuie să fie iniţiate de un actor şi terminarea lor să fie 'văzută' de un actor
        - trebuie să îndeplinească anumite scopuri de de logica a problemei (dacă nu se poate găsi un astfel de obiectiv atunci cazul de utilizare trebuie regândit)
        - trebuie să lase sistemul într-o stare stabilă (nu poate fi îndeplinit doar pe jumătate)

Cazurile de utilizare sunt orientate pe scop: reprezintă ceea ce sistemul trebuie să facă şi nu cum.  Ele sunt neutre din punct de vedere tehnologic, potand fi utilizate în orice proces sau arhitectură de aplicaţie. 

Reprezentarea grafica a cazurilor de utilizare in UML se realizeaza prin intermediul unui oval avznd la baza numele cazului de utilizare (figura 3).


Figura
3. Reprezentarea grafica a cazurilor de utilizare in UML

Fiecare caz de utilizare ce apare in una din diagramele ce modeleaza functionalitatea sistemului informatic trebuie sa fie insotite de un document de descriere a sa ce va respecta urmatorul sablon:

Nume
Descriere
Autori
Stare
Prioritate
Precondiţii
Postcondiţii
Calea principală (
sau BCE - Basic Course of Events)
Căi alternative (
sau ACE - Alternate Course of Events)
Căi de excepţie

Relatii între actori şi cazuri de utilizare: 
            - relatia de asociere (comunicare) (figura 4) - directia de navigare a relatiei (sageata) sugereaza cine initiaza comunicarea.  In general comunicare intre actor si caz de utilizare este bi-directionala


Figura 4. Reprezentarea grafica
relatiei de comunicare intre
actori si cazuri de utilizare

Relaţii între cazuri de utilizare (figura 5): 
        - relatia de utilizare: are loc intre un caz de utilizare si oricare alt caz de utilizare ce utilizeaza functionalitatea acestuia. Se reprezinta grafic printr-o linie avand la capatul corespunzator cazului de utilizare folosit un triunghi si este etichetat cu stereotipul <<Uses>> (stereotipul este un concept introdus in UML care permite extinderea elementelor de modelare de baza pentru a creea noii elemente).
        - relatia de extindere: este folosita pentru a sugera un comportament optional, un comportament care are loc doar in anumite conditii sau fluxuri diferite ce pot fi selectate pe baza selectiei unui actor. Reprezentarea grafica este similara cu cea a relatiei de utilizare, dar eticheta este <<Extends>>. 


Figura 5
. Reprezentarea grafica a
relatiilor de extindere si utilizare
intre cazuri de utilizare

Relaţii între actori (figura 6): 
        - relatia de generalizare: semnifica faptul ca un actor poate interactiona cu sistemul in toate modalitatile prin care interactioneaza un altul.  Se reprezinta ca o relatie de extindere intre doua cazuri de utilizare fara a avea stereotip.
        - relatia de dependenţă: semnifica faptul ca, pentru a interactiona cu sistemul informatic prin intermediul unui caz de utilizare, un actor depinde de alt actor. Se reprezinta printr-o linie franta avand la un capat o sageata.


Figura 6. Reprezentarea grafica a relatiilor de generalizare si dependenta
intre actori

Observatie: Exista o serie de cazuri de utilizare asa-zis 'ascunse' care nu sunt identificate intotdeauna in fazele analizei functionale (in special din cauza faptului ca interlocutorii nu sunt familiarizati cu informatica): securitate, arhivare, infrastructura arhitecturală, verificare.  Se recomanda introducerea acestor cazuri de utilizarea in toate modelele de cerinte. 

 

Back Up Next