Metodologii de dezvoltare

software
(TMISI)
 Metodologii de dezvoltare software

Modelarea: parte esentiala in orice proiect software, in special in proiectele mari.

Modelele: reprezentari abstracte ale sistemului

- create in etapele care preced codificarea:
-analiza si specificarea cerintelor
-proiectarea arhitecturala
-proiectarea de detaliu

- utilizate:
-inainte de codificare: pentru a verifica daca toate cerintele utilizatorilor
sunt acoperite, daca functiile prevazute sunt complete si corect modelate, daca arhitectura este
robusta si extensibila.

- dupa codificare: pentru verificarea si validarea sistemului.

Modelele de definitie si analiza a cerintelor:
•exprima cerintele impuse sistemului
•corespund unei vederi externe asupra sistemului
•se folosesc de catre client, viitorii utilizatori ai sistemului, experti ai domeniului
aplicatiei, analisti, echipa de verificare si validare a sistemului.

Modelele de proiectare:
•redau arhitectura sistemului, alocarea cerintelor pe subsisteme, distributia
proceselor in sistem, sincronizarea lor
•realizarea fizica a sistemului, echipamentele din componenta sa si repartitia
componentelor program pe diferite componente hardware
UML - Unified Modelling Language
UML ( The Unified Modeling Language for Object-Oriented Development)
•este un limbaj de modelare obiect si nu o metoda obiect.
•UML este independent de procesul de dezvoltare folosit.

•Aparut din necesitatea unei standardizari a elementelor de modelare folosite in

metodele de dezvoltare orientata obiect
•Prima versiune UML a fost publicata in 1996 (rezultatul colaborarii intre cei trei
lideri recunoscuti in domeniul metodologiilor orientate obiect: Booch, Rumbaugh,
and Jacobson).
UML este un limbaj pentru:

•Vizualizare si comunicare
•Specificare si construire
•Documentare

Elementele de modelare definite in UML pot fi impartite in 3 categorii:

Modelare comportamentala Modelare structurala Modelare arhitecturala

-Cazuri de utilizare -Clase -Componente

-Diagrame de cazuri de utilizare -Diagrame de clase -Diagrame de componente
-Diagrame de interactiune -Diagrame de obiecte - Diagrame de distributie
-Diagrame de stari -Interfete
-Diagrame de activitati -Pachete
Elemente de modelare UML folosite in Specificarea Cerintelor

➢ Cazuri de utilizare
➢ Diagrame de cazuri de utilizare pentru delimitarea sistemului in mediul sau de operare ,
➢ Diagrame de secventa pentru descrierea scenariilor de utilizare a sistemului,
➢ Diagrame de stari
➢ Diagrame de clase conceptuale

Cazuri de utilizare

- Se elaboreaza in fazele initiale ale procesului de definire a cerintelor utilizator

- Exprima interactiunea
SISTEM <->UTILIZATOR sau SISTEM<->componenta EXTERNA
Modelul cazurilor de utilizare include:
•actorii
•scenarii
•cazurile de utilizare
•diagramele de cazuri de utilizare

ACTOR

Un actor este un rol pe care o entitate externa il joaca in raport cu un sistem:

-Utilizatorii directi ai sistemului (un utilizator poate juca mai multe roluri)
-Un echipament extern sau alt sistem cu care sistemul analizat comunica
UN SCENARIU (de utilizare):
- o secventa de pasi care descrie o posibila interactiune dintre un sistem si un actor

CAZ DE UTILIZARE:
-abstractizare a dialogului dintre un actor si sistem
-descrie interactiuni potentiale fara a intra in detalii ale fiecarui scenariu

STUDIU DE CAZ: Sistem de gestiune electronica a cartilor din mai multe biblioteci
-Sistemul urmeaza sa fie utilizat de doua categorii de utilizatori: bibliotecarii si abonatii.
-Bibliotecarii acceseaza sistemul pentru a inregistra abonati si carti noi sau
pentru a elimina carti din evidenta.
-Abonatii pot cere informatii despre diferite carti si pot cere imprumutarea unei carti.
-Sistemul trebuie sa pastreze evidenta abonatilor, a cartilor imprumutate de fiecare
abonat si alte informatii.
-Deoarece sistemul realizeaza o gestiune centralizata, pentru accesul sau se
propune o interfata Web.
Actorii: abonatul si
bibliotecarul.

Cazurile de utilizare:
SCENARII ale cazului de utilizare “Imprumut”:

(1)
• Un utilizator care doreste sa imprumute o carte completeaza rubricile afectate
numelui si prenumelui sau apoi apasa butonul “Submit”.
• Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
• Utilizatorul primeste mesajul:
„Nu sunteti inregistrat ca abonat. Efectuati procedura de inregistrare”.

(2)
• Un utilizator care doreste sa imprumute o carte completeaza rubricile afectate
numelui si prenumelui sau apoi apasa butonul “Submit”.
• Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
• Utilizatorul primeste mesajul:
„Ati depasit numarul maxim de carti imprumutate. Restituiti o parte dintre ele”.
(3)
• Un utilizator care doreste sa imprumute o carte completeaza rubricile afectate
numelui si prenumelui sau apoi apasa butonul “Submit”.
• Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
• Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
• Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele
autorului si codul ISBN al cartii apoi apasa butonul “Submit”.
• Sistemul preia datele si cauta cartea.
• Utilizatorul primeste mesajul: „Cartea nu exista in bibliotecile noastre”.
Un caz de utilizare este o abstractizare a unui set de scenarii corelate.

Este descris prin secventa tipica de pasi si alternativele la secventa tipica:

Cazul de utilizare :”Imprumut”

1. Un utilizator care doreste sa imprumute o carte completeaza rubricile afectate numelui
si prenumelui sau apoi apasa butonul “Submit”.
1. Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
2. Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
3. Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele
autorului si codul ISBN al cartii apoi apasa butonul “Submit”.
1. Sistemul preia datele si cauta cartea.
2. Sistemul inregistreaza imprumutul.
3. Sistemul afiseaza datele necesare imprumutului.

Alternativa “Acces ne-autorizat”:

La pasul 2: Utilizatorul nu este inregistrat ca abonat si atunci sesiunea este incheiata
de sistem cu un mesaj in care utilizatorul este invitat sa se inregistreze.
Alternativa “Imprumutul nu este posibil”
La pasul 5:
5a) Cartea nu este gasita. Sistemul afiseaza un mesaj si sesiunea este incheiata.
5b) Cartea este gasita dar abonatul a imprumutat deja numarul maxim admis de carti.
Sistemul afiseaza un mesaj si incheie sesiunea.

➢UML admite variatii in privinta descrierii cazurilor de utilizare

Descrierea unui caz de utilizare trebuie sa precizeze:

✓cum si cand incepe si se termina cazul de utilizare –

evenimente care marcheaza inceputul si sfarsitul cazului;
✓cand au loc interactiunile cu actorii si informatiile schimbate
(comunicate intre actori – sistem) in timpul fiecarei interaciuni;
✓fluxul de baza (comportamentul de baza) si alternativele fiecarei interactiuni;
✓repetarile de comportament, care pot fi descrise prin formulari de tipul:
ciclu
-----------
sfarsit ciclu
sau
cat timp
sfarsit cat timp
 Diagramele de cazuri de utilizare se folosesc pentru:

(1)
A defini relatiile dintre diferitele cazuri de utilizare ale unui sistem:
- generalizare
- includere
- extindere
(2) A defini contextul sistemului in mediul sau de operare
Cand si cum se foloseste modelul cazurilor de utilizare?

➢Ca mijloc de comunicare intre analist si client,experti ai domeniului,

pentru determinarea contextului sistemului si pentru desprinderea cerintelor.
Se construieste in etapa de definire a cerintelor utilizator.

➢Pentru definirea cerintelor software

➢Pentru validarea arhitecturii software
➢Pentru definirea testelor de acceptare a sistemului
 Diagrame de clasa

• Class diagram este un tip de diagrama utilizată pentru descrierea structurii

statice, adica a entitatilor sau claselor existente intr-un sistem.

• utilizat de catre dezvoltatori pentru specificarea claselor dar poate fi foarte

util si pentru specificarea structurii unor sisteme sau subsistem dintr-un
business real.

• arata relatiile dintre clase de tipul: mostenire, agregare si asociere, precum si

operatiile si atributele aferente fiecareia.

• clasa are instante, sau realizari. Aceste instante sunt obiectele clasei. Prin
conceptul de clasa se descriu structura si comportarea obiectelor clasei.
Structura contine atributele fiecarui obiect din clasa.
 Diagrama de clasa
Element Descriere Notaţie
O clasă este reprezentată printr-un dreptunghi cu trei
compartimente: în cel de sus se trece numele clasei, în mijloc
Clasă
se trec atributele clasei iar jos se trec operaţiile specifice
clasei.

Moştenirea este o relaţie care indică faptul că o clasă

Moştenire
moşteneşte caracteristicile unei clase părinte.

Asocierea este o relaţie generică între două clase. Aceste

Asociere relaţii pot fi de tipurile unu la unu, unu la mulţi, mulţi la
mulţi.

Atunci când o clasă depinde de o altă clasă, în sensul că

Dependenţă utilizează acea clasă ca şi atribut al său, se foloseşte relaţia
de dependenţă.

Agregarea indică o relaţie de tip întreg-parte (se poate spune

Agregare despre clasa părinte că are clase de tip copil). În această
relaţie, clasa copil poate exista şi fără clasa părinte.

Această relaţie derivă din agregare dar se utilizează atunci

Compoziţie când o clasă copil nu poate exista decât în cazul existenţei
clasei părinte.
 Diagrama de clasa
• In reprezentarea clasei atributele si operatiile sunt declarate in
compartimentele speciale:
– atributele: numele atributului: tipul atributului = valoare
implicita
– operatiile: numele operatiei (parametri): tipul valorii
returnate

• Se pot folosi tipurile de date specifice business-ului, ca de

exemplu: unitati monetare, unitati de timp, unitati de greutate
etc.
Vizibilitatea: pentru a specifica vizibilitatea unui atribut sau a unei
operatiuni/metode, vom utiliza inaintea acestora urmatoarele notatii:
➢+ Public – orice clasa poate avea acces la informatie
➢# Protejat – numai clasa respectiva si succesorii sai pot accesa
informatia
➢- Privat – numai clasa respectiva poate avea acces la informatie.
Mostenirea este o relatie prin care se indica faptul ca o clasa copil mosteneste
caracteristicile clasei parinte. In plus, clasa copil poate avea propriile
caracteristici.
Asocierea arata existenta unei relatii intre clase. Asocierile de tip binar
(cu doua capete) sunt reprezentate in mod obisnuit printr-o linie care
face legatura intre doua clase. Asocierile de ordin mai mare pot fi
reprezentate ca avand mai mult de două capete.
•O asociere poate primi un nume iar capete pot avea diverse roluri, grad
de multiplicitate, vizibilitate si alte proprietati.

Ex. O universitate este condusa de un singur rector si un rector conduce o

singura universitate.

Ex. O universitate are mai multe facultăți.

Exemplu: intre persoana si card bancar putem avea urmatoarea relatie:
o persoana poate avea zero, unul sau mai multe carduri.
Un tip special de asociere este indicat printr-o clasă de asociere. Ca si
clasele, asocierile pot avea atribute si operatii. Pentru a arata grafic
acest lucru, o clasa de asociere se conecteaza printr-o linie intrerupta.
Altfel spus, relatia in sine este o clasa.

Exemplu: relatia de asociere dintre Banca si Persoana este intermediata

de existenta unui card Bancar.
• Dependenta indica faptul ca o clasa depinde de alta clasa, in sensul
in care o modificare a celei de-a doua clase produce modificari in
clasa dependenta. Verbul folosit este „a utiliza”.
Agregarea indica faptul ca o clasa parinte are elemente de tipul clasei
copil. Dacă in cazul asocierii utilizam verbul „a avea” pentru a exprima
legatura dintre doua clase, in cazul agregarii vom folosi verbul „a
contine”.
Exemplu: Catalogul poate avea mai multe Produse in acelasi timp, un
Produs poate exista chiar si daca acel catalog nu exista.

•Intr-o relatie de tip compozitie clasa copil nu poate exista decat

dacă exista o instanta a clasei parinte. O componenta nu poate
apartine decat unui singur intreg si daca acesta dispare, in mod
automat dispare si componenta. Exemplu: instanta clasei Comisie
exista atata timp cat exista instanta clasei Examen.
Restrictii si note:
Restrictiile pot fi atasate sub forma de nota pe care o ancoram de
asocierea careia ii apartine. Restrictiile mai pot fi atasate
caracteristicii la care fac apel.

Exercitiu: Sa se realizeze diagrama de clase pentru o aplicatie

ce simuleaza asignarea de proiecte in cadrul unei companii in
care avem urmatoarele clase: angajat, departament, proiect.
Avem urmatoarele doua restrictii:
fiecare angajat poate lucra la mai multe proiecte cu conditia
ca proiectul sa apartina departamentului in care lucreaza;
bugetul proiectului nu trebuie să depaseasca bugetul
departamentului.
Diagrame de interactiune

-Diagrame de secventa
-Diagrame de colaborare

Se folosesc in mai multe etape ale dezvoltarii:

definirea cerintelor, proiectare arhitecturala, proiectare de detaliu

In etapa de definire a cerintelor, redau:

- Interactiunile dintre actori si sistem (scenarii)

-Interactiunile dintre obiectele din universul problemei
Reprezentarea scenariilor prin diagrame de secventa
➢Se poate reda perioada de activitate a unui obiect printr-o banda rectangulara
suprapusa pe linia sa de viata
Concluzie:
Diagramele de secventa: pun accentul pe aspectul timp
(scurgerea timpului in timpul unei interactiuni)

Diagramele de colaborare

-Sunt echivalente cu diagramele de secventa dar

evidentiaza relatiile structurale intre obiecte (legaturile dintre ele)
 Echivalenta Diagrame de secventa – Diagrame de colaborare

s:Subject o1:Observer o2:Observer

3: Notify o1:Observer
4: update()
1: attach(o1)
2: attach(o2)
5: getState()
s:Subject 1: attach(o1)
3: Notify
6: update()
4: update()
5: getState()
7: getState()
6: update() 2: attach(o2)
7: getState() o2:Observer
Diagramele de interactiune in UML sunt:

➢Diagrame de secventa
➢Diagrame de comunicare, care corespund diagramelor de
colaborare din versiunile anterioare
➢Diagrame de evolutie in timp (Timing diagrams)
➢Diagrame de interactiune generale – descriu fluxul controlului
intr-o maniera generala.
-utilizeaza notatii specifice diagramelor de activitate
Diagrama de secventa in UML .
Diagrama de comunicare
Diagrama de comunicare care refera colaborarea “getPerformances”.
 Diagrama activitatilor
• Activity Diagram reprezinta o modalitate de modelare vizuala
a fluxurilor.

• Cu ajutorul activity diagram pot fi modelate foarte bine use

case-urile, dar, in aceeasi masura, aceste diagrame pot fi
folosite pentru modelarea proceselor de business (fara legatura
cu sistemul informatic).

• Notatiile sunt foarte asemanatoare cu cele din diagrama de

stare deoarece activity diagram nu sunt altceva decat o variatie
a statechart diagram.
Element Descriere Notaţie
Prin activitate vom desemna întreaga activitate modelată
Activitate prin diagramă (formată dintr-o succesiune de acţiuni). -
Aceasta corespunde unui task de business.
Teoretic, acţiunile sunt numite activity states şi reprezintă
Acţiune o acţiuni desfăşurate în cadrul unui task, sau, privite altfel,
acţiuni ale unui obiect.
Reprezintă punctul de intrare în activitatea respectivă.
Stare iniţială Punctul iniţial este unic şi din el porneşte întotdeauna o
singură tranziţie.
Reprezintă punctul de ieşire din activitate. Pot fi mai
Stare finală
multe puncte de ieşire dintr-o activitate.
La încheierea unei acţiuni se trece întotdeauna la o altă
Tranziţie acţiune sau la starea finală. Tranziţia reprezintă trecerea
de la o acţiune la alta.
Printr-o decizie (sau punct de decizie) se modelează un
punct din cadrul fluxului unde se face o alegere, pe o
anumită ramură din flux. În acest caz tranzacţiile de ieşire
Decizie
trebuie să fie de tip condiţie. Aceeaşi notaţie se foloseşte
şi pentru reunirea fluxurilor după o decizie precedentă
(caz în care nu mai sunt necesare condiţiile).
Este un tip special de tranziţie, utilizată la fiecare dintre
Condiţie ieşirile posibile dintr-o decizie. Se marchează ca un text
(guard) pe săgeată şi arată condiţia care trebuie îndeplinită pentru
a urma acel flux.
Este folosită pentru cazurile în care anumite acţiuni se pot
desfăşura în paralel. Într-un asemenea punct poate avea
loc fie separarea fluxurilor, fie reunirea lor, după o
Bara de separare anterioară. Reunirea a două fluxuri înseamnă, de
sincronizare fapt, introducerea unei condiţii, prin care o activitate nu
poate începe decât după terminarea activităţilor finale din
fluxurile ce trebuie sincronizate (de aici termenul de
sincronizare).

Culoarele sunt reprezentări care permit separarea

Culoar
activităţilor din flux după criteriul responsabilităţii
(swimlane)
realizării activităţii.
• Punctele de decizie sunt puncte din fluxul de activitati in care se
face o anumita alegere intre mai multe variante posibile.
• Actiunile paralele (asincrone) sunt actiuni care pot desfasura in
paralel. In viata reala, aceste actiuni sunt actiuni care nu depind una
de cealalta. Paralelizarea actiunilor se reprezinta pe diagrama in
felul urmator:
• Aceasta reprezentare ne arata ca actiunile „Verificare stoc” si
„Verificare bonitate client” sunt declansate de aparitia unei comenzi
de la client si ca aceste actiuni sunt independenta intre ele (inceperea
uneia nu depinde de rezultatul celeilalte).
• Revenirea la fluxul unic (cu actiuni sincronizate) se face in felul
urmator:

• Aceasta reprezentare ne arata ca livrarea la client depinde de

finalizarea actiunilor independente "Verificare stoc" si
"Verificare bonitate client", astfel ca actiunea "Livrare la
client" nu poate incepe decat dupa finalizarea ambelor actiuni.
• Pentru a adauga pe diagrame informatia privind responsabilitatea
executarii actiunilor se folosesc elementele denumite swimlanes,
plasandu-se fiecare actiune pe "culoarul" actorului care executa acea
actiune.
 Diagrama de stare
Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stari prin care
poate trece un obiect si modul in care se poate trece de la o stare la alta (modelare
work-flow-uri, modelare fluxuri de documente, diagrame de stari).
O stare reprezinta o etapa din comportamentul unui obiect; astfel, putem avea stari
initiale si stari finale.
– Starea initiala: cea in care se regaseste obiectul atunci cand a fost creat pentru
prima data;
– Starea finala: nu mai trece prin nicio tranzitie.

Trecerea de la o stare la alta este determinata de tranzactiile intermediare - acestea

corespund Actiunilor pe care le-am intalnit la Activity Diagram (pana la urma,
Statechart Diagram reprezinta un alt mod de a vedea un flux ce poate fi modelat
exclusiv prin Activity Diagram, inventata pentru a exprima mai elocvent trecerile de
la o stare la alta).

Exemplu o comanda primita de la un client poate fi initial in stare de asteptare, pentru

ca un operator sa verifice bonitatea clientului si stocul si sa accepte comanda. Dupa
acceptare, se poate produce livrarea produselor comandate si comanda trece in starea
de „comanda livrata” dupa care urmeaza facturarea si inchiderea comenzii.
 Diagrama de stare
Element Descriere Notaţie

Stare Indică starea în care se găseşte obiectul la un moment dat.

Stare Reprezintă punctul de intrare sau punctul în care obiectul

iniţială este iniţiat. Punctul iniţial este unic.
Stare Reprezintă punctul de final când starea obiectului nu se mai
finală modifică.
Tranziţia reprezintă trecerea de la o stare la alta, provocată
Tranziţie
de apariţia unui anumit eveniment.
Exemplu de folosire a
elementelor specifice
statechart diagram,
pentru cazul unei
comenzi: