Dezvoltarea sistemelor informatice

Ce este un model?
Simplificri sau abstractizri ale unor elemente reale

sau care se proiecteaz.

Evideniaz numai acele elemente care sunt

importante pentru analist.

Sunt specificate folosind notaii grafice sau textuale

precise, cu ajutorul unui anumit limbaj de simboluri.

O colecie de imagini i text care are o anumit

semnificaie i intenioneaz s reprezinte ceva.

Metodologii de dezvoltare software

Instrumente de tip CASE

CASE = Computer Aided Software Engineering
Necesitate:
lucrul cu modele vizuale poate fi o activitate dificil i

consumatoare de timp
nevoia unui suport informatic atunci cnd vrem s
meninem integritatea modelelor
posibilitatea de a genera cod
Visual Paradigm 11.2
http://www.visual-paradigm.com/download/archive/

Ce este UML?
UML = Unified Modeling Language
Limbaj de notaii pentru specificarea, construirea, vizualizarea i

documentarea sistemelor software.

Combin cele mai bune practici n domeniul construirii diagramelor

din ultimii 50 de ani.

Standardizeaz notaiile, dar nu stabilete modul n care acestea s fie

folosite.

Nu este o metodologie, poate fi folosit ca vocabular pentru

metodologii.

Ofer flexibilitate dezvoltatorilor, asigurnd n acelai timp

consisten.

Este un standard dezvoltat i ntreinut de Object Management Group.

Elemente de baz ale UML

2.

Tipuri de diagrame

Perspective asupra sistemului

Static
Diagrame de:
Clase
Obiecte
Structur compus
Componente
Desfurare

Funcional
Diagrame de:
Cazuri de utilizare
Activiti
Interaciuni de ansamblu

Dinamic
Diagrame de:
Stare
Secven
Comunicare
Timp

Diagrama de pachete structurare/modularizare

Diagrama de profile - extinderea limbajului

Pasi pentru dezvoltarea unui SI

1.
2.
3.
4.
5.
6.

Specificarea cerintelor
Analiza
Proiectarea
Implementarea
Desfasurarea
Generarea de cod

1. Specificarea cerintelor
Modelul cazurilor de utilizare
Reflecta o viziune din exterior asupra sistemului, dpdv al

utilizatorului
Ilustreaza functionalitatile pe care le va realiza sistemul
Scop:
Delimitarea ariei de cuprindere a SI
Baza de discutii cu beneficiarul
Specificarea completa si detaliata a cerintelor

Elemente componente:
Cazul de utilizare
Actorul
Relatiile

Caz de utilizare
Specific un set de aciuni executate de ctre un

sistem sau un subiect i care conduc la un anumit

rezultat.
Rezultat, n mod normal, este important pentru un
actor sau un beneficiar.
Trebuie verificata aparitia suprapunerilor sau
duplicatelor.
Trebuie verificata completitudinea modelului.

Actori
Un actor interacioneaz cu sistemul n contextul unui caz

de utilizare.
Actorii reprezint roluri care pot include factori umani,
hardware extern sau alte sisteme.
Rspunde la ntrebri de genul:
CINE solicit informaii din sistem
CINE modific informaiile din sistem
CINE interacioneaz cu sistemul

Se reprezint folosind simbolul specific al unui omule.

Diagrama cazurilor de utilizare

Descrie relaiile dintre un set de cazuri de utilizare i

actorii care particip la realizarea acestor CU.

Diagramele de CU nu descriu comportamente sau
fluxuri.
Poate delimita graniele sistemului analizat prin
includerea CU n interiorul unui dreptunghi.

Relaii ntre actori

Sunt de tipul generalizare/specializare, ntre un actor

abstract i unul sau mai muli actori concrei

Relaii ntre actori i cazuri de utilizare -1

Asocierile simple sunt folosite pentru a conecta un

actor cu un caz de utilizare.

Aceasta reprezint o cale de comunicare ntre cei doi.
Comunicarea poate fi i unidirecional.

Relaii ntre actori i cazuri de utilizare -2

La acest nivel sunt permise multiplicitile.
multiplicitatea mai mare dect unu la captul:
corespunztor CU actorul este implicat n mai multe cazuri de utilizare de
acel tip i poate iniia cazuri de utilizare: n paralel (concurent), la diferite
momente de timp sau mutual exclusiv n timp.
corespunztor actorului mai multe instane ale actorului sunt implicate n
iniierea cazului de utilizare putnd realiza aciuni simultane sau succesive.
UML nu are notaii standard pentru situaiile de mai sus.

Relaii ntre cazuri de utilizare -1

ntre dou cazuri de utilizare care se refer la acelai subiect

(sistem) nu pot exista relaii simple. Fiecare descrie un mod de

utilizare complet al sistemului.
1. Generealizare
Se folosete cnd exist dou sau mai multe CU care au n comun

comportament, structur i scop.

Comportamentul CU printe poate fi suprascris.
Se specific numai diferenele dintre cele dou n CU specializat.

Relaii ntre cazuri de utilizare -2

2. Includere
Are ca scop integrarea unui CU n alt CU, primul devenind astfel o parte logic din acel CU. CU
care l include pe un altul nu este complet.
Se folosete atunci cnd:

exist pri de comportament comune n mai multe CU.

pentru a simplifica CU mari.

Este echivalent cu apelul unei subrutine n programare.

Denot un comportament obligatoriu, nu opional.
Nu se motenesc proprieti de la un CU la altul.
Se evit redundana prilor cu comportament identic.

Relaii ntre cazuri de utilizare -3

3. Extindere
Este folosit atunci cnd un CU are loc doar n anumite condiii sau
opional.
CU extins este complet i independent de cel care l extinde.
Extinderea are loc n unul sau mai multe puncte de extindere, definite
n cazul de utilizare extins.
Se pot asocia note sau constrngeri pe aceast relaie pentru a ilustra
condiiile n care comportamentul extins trebuie executat.

Descrierea textual a unui CU

Element al cazului de
Descriere
utilizare
Cod
Un identificator unic asociat cazului de utilizare
Stare
Stadiul de finalizare n care se gsete, de exemplu: schi,
finalizat sau aprobat
Scop
Sistemul (parte a sistemului) sau aplicaia creia i aparine
Nume
Numele cazului de utilizare, ct mai scurt i reprezentativ
Actor principal
Beneficiarul care iniiaz cazul de utilizare i care urmrete un
anumit scop
Descriere
Prezentare scurt, in text liber, a cazului de utilizare
Precondiii
Ce condiii trebuie satisfcute pentru ca scenariul s poat
ncepe
Postcondiii
Ce condiii trebuie ndeplinite pentru a garanta un final reuit al
scenariului
Declanator
Un eveniment sau o succesiune de evenimente care iniiaz
cazul de utilizare
Flux de baz
Fluxul de baz descrie niruirea evenimentelor atunci cnd
totul se petrece conform unui scenariu prestabilit; nu exist
excepii sau erori
Fluxuri alternative
Cele mai semnificative alternative i excepii ale scenariului de
baz
Relaii
Ce relaii are cu alte cazuri de utilizare (de tipul includes sau
extends)
Frecvena utilizrii
Ct de des se estimeaz c va fi folosit aceast funcionalitate
a sistemului
Reguli ale afaceri
Ce reguli guverneaz cazul de utilizare; ce prerogative trebuie s
aib actorii

Lucru la seminar
S se ntocmeasc diagrama de cazuri de utilizare i descrierea textual a unui caz de
utilizare pentru scenariul de mai jos.
Scopul proiectului este realizarea aplicaiei informatice pentru gestiunea activitii unei uniti
hoteliere. n vederea cazrii, un client poate solicita rezervarea uneia sau mai multor camere
prin e-mail sau telefonic. Pentru aceasta furnizeaz recepionerului informaii privind perioada
de cazare i tipurile de camere solicitate. Clienii vor beneficia de reduceri dac rezerv cel
puin 3 camere sau dac perioada de cazare depete 5 zile. Recepionerul verific
disponibilitatea camerelor i l ntiineaz pe client de acest lucru precum i de costul estimat
al cazrii. Dac nu exist camere disponibile conform solicitrii, recepionerul poate oferi
clientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau nu),
iar recepionerul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerul
hotelului. n situaia n care clientul este de acord cu preul propus, se va proceda la realizarea
rezervrii. Pentru clienii noi, recepionerul solicit datele de identificare, pe care le introduce
n aplicaie.
Odat ajuns la hotel, i dac a fcut n prealabil o rezervare, clientul va furniza datele de
identificare ale sale i/sau ale rezervrii i se face cazarea. Dac nu exist o rezervare, se va
verifica disponibilitatea camerelor pentru perioada cerut. Atunci cnd se gsete o astfel de
camer, se face cazarea. La finalul sejurului, recepionerul ntocmete o list cu toate serviciile
solicitate de client i preul acestora. Lista trebuie validat de client, dup care se ntocmete
factura final. Factura poate fi pltit parial sau integral, prin transfer bancar, numerar sau
folosind un card bancar. Totodat, nainte de a prsi hotelul, clientul este rugat s completeze
un formular prin care s evalueze serviciile oferite de unitatea hotelier.

Diagrama claselor UML

Definirea unei clase

Ansamblu de obiecte care au aceleai caracteristici i contrngeri.

Caracteristicile unei clase sunt atributele i operaiile.

Clasele abstracte nu pot fi instaniate. Rolul lor este de a permite altor

clase s le moteneasc, n vederea reutilizrii caracteristicilor.

O interfa descrie un set de caracteristici i obligaii publice. Specific,
de fapt, un contract. Orice instan care implementeaz interfaa
trebuie s ofere serviciile furnizate prin contract.

Exemple de clase stereotipe uzuale

entitate (<<entity>>) o clas pasiv, care nu iniiaz

interaciuni;
control (<<control>>) iniiaz interaciuni, conine o
component tranzacional i este separator ntre entiti i
limite;
limit (<<boundary>>) este aflat la periferia sistemului, dar
n interiorul su. Reprezint limita de legtur cu actorul sau
cu alte sisteme informatice;
enumerare (<<enumeration>>) - este folosit pentru definirea
tipurilor de date ale cror valori sunt enumerate.
primitiv (<<primitive>>) - o form de clas care reprezint
tipuri de date predefinite, cum ar fi tipul Boolean.

Atribute -1
Fiecare atribut este descris cel puin prin numele su.
Se pot aduga i informaii adiionale, iar forma general a

unui atribut este:

[vizibilitate][/]nume[:tip][multiplicitate][=valoare implicit] [{proprietate}]
Vizibilitatea poate fi:
+ public: poate fi vzut i folosit de oricine
- private: numai clasa nsi poate avea acces

# protected: au acces clasa i subclasele acesteia

~ package: numai clasele din acelai pachet pot avea acces

/ simbolizeaz un atribut derivat

Atribute -2
UML permite specificare multiplicitilor pentru atribute, atunci cnd dorim s

definim mai mult de o valoare pentru un atribut. Au urmtoarea semnificaie:

Multiplicitate
1
2
1..4
3, 5
1..*
*
0..1

Sens
Exact 1 (implicit)
Exact 2
De la 1 la 4 (inclusiv)
3 sau 5
Cel puin unul sau mai muli
Nelimitat (inclusive 0)
0 sau 1

Proprietate indic o proprietate suplimentar care se aplic atributului:

{readonly}: atributul poate fi citit, dar nu modificat
{ordered}, {unordered}: o mulime ordonat sau neordonat
{unique}, {nonunique}: mulimea poate conine sau nu elemente identice

Operaii
Forma general a unei operaii este:
[vizibilitate] nume ([direcie] lista parametri) [:tip returnat] [{proprietate}]
Vizibilitatea aceeai ca i la clase
Direcie - 'in' | 'out' | 'inout' | 'return'
Tip returnat dac operaia returneaz ceva, adic este o funcie
Un exemplu de proprietate a unei operaii: {query} - nu are efecte secundare,

nu schimb starea unui obiect sau a altor obiecte, exemplu operaiile de tip
get.

Exemple de atribute:

Exemple de operaii:

- varsta: Integer {varsta>18}

+ setVarsta (out varsta: Integer)

# nume:String[1..2]=Ioana

+ getVarsta(in Id:String): Integer {query}

~ Id:String {unique}

- schimbaNume(inout nume:String)

/ sumaTotala:Real=0

Constrngeri
O constrngere este o expresie care restricioneaz un anumit element al

diagramei de clase.
Aceasta poate fi o expresie formal (scris n Object Constraint Language
- OCL) sau o formulare semi-formal sau informal.
Acestea sunt reprezentate ntre acolade.
Pot fi scrise imediat dup definirea elementului sau ca un comentariu.
O constrngere poate avea i un nume, astfel:
{nume : expresie boolean }

Exemple de constrngeri OCL:

context Organizatie
inv: self. departamenteisUnique (nume)
inv: departamante.angajatiisUnique (cod)

Relaii ntre clase -1

1. Relaia de asociere implic stabilirea unei relaii ntre clase.
Este caracterizat prin:
denumire (opional)
multipliciti se trec la cele 2 capete ale asocierii;
roluri ale asocierii: se trec la fiecare capt al asocierii i conin o

descriere scurt i reprezentativ de (1 2 substantive)

direcie de navigare

tipuri de asocieri:
unare
binare
ternare

Relaii ntre clase -2

Tipuri de asocieri:
Unare: conecteaz o clas cu sine nsi.

Binare: se realizeaz ntre dou clase.

Ternare: sunt transformate, de obicei, n asocieri binare.

Relaii ntre clase -3

Asocierea modelat ca o clas permite relaiei de asociere s

aib artibute i operaii.

2. Relaia de agregare este o form de asociere binar

reprezentnd o relaie de tip parte/ntreg.
Poate fi de doua tipuri:
Agregare partajat (agregare)
Agregare compus (compunere)

Relaii ntre clase -4

Agregarea partajat este o form slab de agregare n care

instanele prilor sunt independente de ntreg, astfel:

Aceleai pri partajate pot fi incluse n mai multe clase ntreg.
Dac clasa ntreg se terge, clasele parte vor exista n
continuare.
Se reprezint sub forma unui romb gol plasat la captul clasei
ntreg.

Relaii ntre clase -5

Agregarea compus este o form puternic de agregare n care

instanele prilor sunt independente de ntreg, astfel:

Dac clasa ntreg se terge, clasele parte vor vor fi terse i ele.
Se reprezint sub forma unui romb plin plasat la captul clasei
ntreg.
Atunci cnd se folosete pentru modelarea obiectelor dintr-un
anumit domeniu, tergerea poate fi interpretat la figurativ, ca
terminare, i nu ca o distrugere fizic.

Relaii ntre clase -6

Asociere
Obiectele tiu unele de existaa celorlalte i pot lucra mpreun.
Agregare
1. Protejeaz integritatea configuraiei.
2. Funcioneaz ca un tot unitar.
3. Control prin intermediul unui singur obiect.
Compunere
Fiecare parte poate fi membr a unui singur obiect agregat.

Relaii ntre asociere, agregare i compunere

Relaii ntre clase -7

3. Relaia de generalizare este folosit pentru a indica motenirea
dintre o clas general (superclas) i o clas specific (subclas).
Se mai numete informal i relaie de genul este un tip de.
Se reprezint sub forma unui tringhi gol plasat la captul
superclasei.
Subclasele motenesc caracteristicile i constrngerile superclasei.
Este permis motenirea multipl.

Relaii ntre clase -8

4. Relaia de dependen este folosit pentru a arta o gam larg de
dependene ntre elementele unui model.
n atapa de analiz, tipul de dependen poate s nu fie specificat.
n proiectare, dependenele vor fi personalizate cu stereotipuri sau vor

fi nlocuite cu conectori specifici tehnologiei folosite.

Se reprezint sub forma unei linii punctate de la clasa dependent

client, pan la clasa furnizor, cu o sgeat la captul clasei

furnizor.
n diagramele de clase, cele mai importante dependene sunt relaiile

de utilizare i de abstractizare.

Lucru la seminar
S se ntocmeasc diagrama de clase pentru scenariul de mai jos.
Scopul proiectului este realizarea aplicaiei informatice pentru gestiunea activitii unei uniti
hoteliere. n vederea cazrii, un client poate solicita rezervarea uneia sau mai multor camere
prin e-mail sau telefonic. Pentru aceasta furnizeaz recepionerului informaii privind perioada
de cazare i tipurile de camere solicitate. Clienii vor beneficia de reduceri dac rezerv cel
puin 3 camere sau dac perioada de cazare depete 5 zile. Recepionerul verific
disponibilitatea camerelor i l ntiineaz pe client de acest lucru precum i de costul estimat
al cazrii. Dac nu exist camere disponibile conform solicitrii, recepionerul poate oferi
clientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau nu),
iar recepionerul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerul
hotelului. n situaia n care clientul este de acord cu preul propus, se va proceda la realizarea
rezervrii. Pentru clienii noi, recepionerul solicit datele de identificare, pe care le introduce
n aplicaie.
Odat ajuns la hotel, i dac a fcut n prealabil o rezervare, clientul va furniza datele de
identificare ale sale i/sau ale rezervrii i se face cazarea. Dac nu exist o rezervare, se va
verifica disponibilitatea camerelor pentru perioada cerut. Atunci cnd se gsete o astfel de
camer, se face cazarea. La finalul sejurului, recepionerul ntocmete o list cu toate serviciile
solicitate de client i preul acestora. Lista trebuie validat de client, dup care se ntocmete
factura final. Factura poate fi pltit parial sau integral, prin transfer bancar, numerar sau
folosind un card bancar. Totodat, nainte de a prsi hotelul, clientul este rugat s completeze
un formular prin care s evalueze serviciile oferite de unitatea hotelier.