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)
Î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)
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.