INGINERIA SISTEMELOR INFORMATICE

 Condiţionări şi cunoştinţe prerechizite

Cursul nu are condiţionări prerechizite. Cunoştinţele prerechizite care pot facilita asimilarea
materialului sunt legate de programare la nivel de bază şi obiectuală, reţele de calculatoare. Sugerăm ca
înainte de parcurgerea materialului să se identifice următoarele cunoştinţele prerechizite:
 programare structurată; noţiuni de bază;
 reţele de calculatoare,
 noţiuni legate de proiectarea şi implementarea sistemelor informatice.

 Descrierea cursului

Ingineria software este o activitate de inginerie, nu este algoritmică. Se cere experienţă, reutilizarea
soluţiilor şablon şi evoluţia incrementală a sistemului faţă de soluţia care este acceptată de system.
Dezvoltarea software-ului orientat obiect include cinci activităţi: cerinţele elicitation analiza,
design-ul sistemului, design-ul obiectului şi implementarea. În timpul acestor cerinţe şi analize inginerii
software formulează problema clientului şi creează modelul domeniului de aplicare. Cerinţele
elicitation şi analiza corespund paşilor 1 şi 2 din metoda ingineriei. Pe parcursul design-ului sistemului
inginerii software analizează problema, o descompun şi selectează strategii pentru design-ul sistemului.
Pe parcursul design-ului obiectului, ei selectează soluţiile pentru fiecare piesă şi decide asupra soluţiei
potrivite. Design-ul sistemului şi obictului rezultă în modelul domeniului soluţiilor. Design-ul
obiectului şi sistemului corespunde paşilor 3 şi 4 ale metodei ingineriei. Pe parcursul implemetării
inginerii software realizează sistemul prin transformarea modelului domeniului soluţiilor într-o
reprezentare executabilă. Implementarea corespunde pasului 5 al metodei. Ceea ce deosebeşte ingineria
software de alte ştiinţe în ceea ce priveşte problem solving este că schimbarea are loc în aplicaţii şi în
domeniul soluţiilor timp în care problema este rezolvată.
Dezvoltarea software include activităţi a căror scop este de a evalua potrivirea modelelor
respective. În timpul revizualizării analizei modelul domeniului de aplicaţie este comparat cu realitatea
clientului care poate fi schimbată ca un rezultat al modelării. În timpul revizualizării design-ului
modelul domeniului soluţiilor este evaluat faşă de scopurilor proiectului.
În timpul testării sistemul este validat faţă de modelullui domeniului soluţiilor care poate fi schimbat
prin introducerea unor noi tehnologii. În timpul conducerii proiectului, managerii îşi compară modelele
proceselor de dezvoltare cu realitatea.

 Organizarea temelor în cadrul cursului

MODULUL I . Noţiuni de bază

1.1. Istoric şi evoluţie

1.2. Scopul Ingineriei Sistemelor Informatice
1.3. Domenii de aplicare şi domenii conexe
1.4. Definiţii clasice
1.5. Activitate de modelare (modeling)
1.6. Activitate de rezolvare de probleme (problem-solving)
1.7. Activitate de achiziţionare de cunoştinţe (knowledge acquisition)
1.8. Activitate de raţionare (rationale)
MODULUL II. Managementul Ingineriei Sistemelor Informatice

2.1. Concepte de bază

2.2. Activităţi de dezvoltare
o Participanţi şi roluri
o Sisteme şi modele
o Activităţi, Task-uri şi Resurse
2.3. Activităţi de dezvoltare a Ingineriei Sistemelor Informatice
 Analiza problemei
 Proiectarea sistemului
 Proiectarea obiectelor
 Implementarea
 Testarea
2.4. Dezvoltarea administrării Ingineriei Sistemelor Informatice

MODULUL III. Modelarea

3.1. Noţiunea de modelare

3.2. Modelarea V
3.3.Modelul Incremental
3.4.Modelul Spirală
3.5.Extreme Programming

MODULUL IV. Modelarea cu UML-urile

4.1. Modelare utilizând UML-urile

4.2.Noţiunea de UML
4.3.Diagrame
4.4.Concepte de Modelare
4.5.Aprofundarea diagramelor

MODULUL V. Modul liber la dispoziţia studenţilor

Bibliografie obligatorie

Pentru paginarea temelor, recomandăm consultarea cuprinsului din partea a doua a materialului de faţă.

 Materiale bibliografice obligatorii

[Cockburn,2001] A. Cockburn, Agile Software Development, Addison-Wesley, Reading, MA,

2001.
[Conradi, 1998] R. Conradi, B. Westfechtel, Version models for software configuration
management, ACM Computing Survey, vol.30, no2, June 1998.
[Akram, 2002]Akram I. Salah, Engineering an Academic Program in Software Engineering Mills,
Harlan D., J. R. Newman, and C. B. Engle, Jr., An Undergraduate Curriculum in Software Engineering

2
[Budgen,2004] David Budgen, Pearl Brereton, Barbara Kitchenham, Stephen Linkman (2004-12-
14). Realizing Evidence-based Software Engineering
[Pecht, 1995] Pecht, Michael (1995). Product Reliability, Maintainability, and Supportability
Handbook.

 Materiale şi instrumente necesare pentru curs

Calculator, materialul bibliografic, software licenţiat şi free necesar cursului;

 Politica de evaluare şi notare (orientativ - 1 pagină)

Evaluare practică – 50% din notă:
Conţinut:
Dezvoltarea unui proiect care să parcurgă toate modulele. Proiectul va conţine:
 O parte de modelare a unui sistem economic la alegere;
 Realizarea unor diagrame pentru sistemul ales;
 Prezentarea în faţa colectivului a unor subiecte din cadrul modulelor

Evaluare teoretică – 50% din notă

Conţinut:
Test grilă cu întrebări, de dificultate şi pondere în notă echitabile.
Nivelul minim pentru promovarea examenului este dat de obţinerea notei 5 la fiecare din cele două
părţi (practic şi teoretic).

Obiectivele cursului/disciplinei:

Inginerii software se confruntă cu provocări la fel ca biologii şi fizicienii. În primul rând inginerii
software trebuie să înţeleagă mediuil în care sistemul trebuie să funcţioneze. Pentru un sistem de control
al traficului trenurilor inginerii software trebuie să cunoască procedurile de semnalizare a trenurilor.
Pentru un sistem de comerţ al acţiunilor, inginerii software trebuie să ştie regulile comerţului. Inginerul
software nu trebuie să devină un adevărat dispecer al trenurilor sau un broker; ei trebuie numai să înveţe
conceptele domeniului de aplicare care sunt relevante sistemului, în alţi termeni ei treuie să creeze un
model al domeniului de aplicare.
În al doilea rând inginerii software trebuie să înţeleagă sistemele pe care le pot crea şi să
evalueze soluţii diferite. Majoritatea sistemelor sunt prea complexe pentru a fi înţelese de orice
persoană şi majoritatea sistemelor sunt costisitoare pentru elaborare. Pentru a face faţă acestor
provocări, inginerii software descriu aspecte importante ale sistemelor alternative pe care ei le
investighează.
Metodele orientate pe obiect combină activităţile din domeniul de aplicare şi modelarea
domeniului soluţiilor într-unul singur. Domeniul de aplicare este primul modelat ca un set de obiecte de
relaţii.
Ideea metodelor orientate obiect este că modelul domeniului de soluţii este o transformare a
modelului de aplicaţii. Dezvoltarea software transformă în activităţi necesare de identificare a
sistemului ca un set de modele care adresează finalul problemei utilizatorului

3
 MODULUL I . Noţiuni de bază

Concepte de bază:

Istoric şi evoluţie
Scopul Ingineriei Sistemelor Informatice
Domenii de aplicare şi domenii conexe
Definiţii clasice
Activitate de modelare (modeling)
Activitate de rezolvare de probleme (problem-solving)
Activitate de achiziţionare de cunoştinţe (knowledge acquisition)
Activitate de raţionare (rationale)

Obiective:

1. Familiarizarea cu conceptele folosite în ISI (Ingineria Sistemelor Informatice).

2. Inţelegerea scopului ISI
3. Stabilirea legăturii dintre domeniile de aplicare si conexe.
4. Asimilarea noţiunilor de bază
5. Fixarea activităţilor de bază

Recomandări privind studiul:

Studierea conceptelor prezentate în vederea utilizării lor pe parcursul celorlalte

capitole.

Rezultate aşteptate:

 Asimilarea conceptelor de bază legate de domeniile de bază şi de domeniile

conexe ale ISI.
 Studenţii trebuie să înţeleagă şi să asimileze pricipiile de bază ale Ingineriei
Sistemelor Informatice

Întrebări recapitulative:

1. Prezentaţi istoricul ISI?

2. Care este scopul ISI?
3. Definiţi noţiunea de ISI?
4. Care sunt domeniile de aplicare?
5. Care sunt domeniile conexe?
6. Ce înţelegeţi prin activitatea de modelare?
7. Ce înţelegeţi prin activitatea de rezolvare de probleme?
8. Ce înţelegeţi prin activitatea de achiziţionare de cunoştinţe?
9. Ce înţelegeţi prin activitatea de raţionare?

4
 Ce este Software Engineering?

Def: Software engineering este o activitate de modelare: Inginerii software fac faţă problemelor
complexe din modelare, concentrându-se asupra problemelor importante şi ignorându-le pe celelalte. În
cursul dezvoltării, inginerii software crează multe modele ale sistemului şi ale domeniului de aplicaţie.

Def: Software engineering este o activitate de rezolvare a problemei (problem solving): Modelele sunt
utilizate pentru adoptarea soluţiei optime, fapt ce necesită o anumiă experienţă. Inginerii soft nu deţin
resurse inepuizabile şi sunt constrânşi de buget şi termene limită, iar lipsa unei teorii fundamentale îi
determină să se bazeze pe metode empirice în evaluarea diferitelor alternative.

Def: Software engineering este o activitate de knowledge acquisition (acumulare a cunoştinţelor). În

modelarea aplicaţiilor şi domeniul soluţiilor, inginerii soft colecţionează date, le organizează în
informaţii şi le transformă în cunoştinţe. Knowledge acquisition nu este un process separat, ca parte a
unor date suplimentare ar genera modele necorespunzătoare.

Def: Software engineering este o activitate rationale-driven. Când dobândesc cunoştinţe şi iau decizii
despre sistem sau domeniul său de aplicare, inginerii software au de asemenea nevoie să înţeleagă
contextul în care deciziile au fost luate dar şi partea raţională din spatele acestor decizii. Informaţia
raţională, reprezentată ca un set de modele ale problemei, îi ajută pe inginerii software să înţeleagă
implicarea unei schimbări propuse când revizuies o decizie.
În această secţiune descriem în detaliu ingineria software din perspectivele modelării rezolvării
problemelor, dobândirii cunoştinţelor şi raţională. Pentru fiecare din aceste activităţi inginerii software
trebuie să lucreze sub presiunea oamenilor, a timpului şi a constrângerii bugetului. De altfel ne asumăm
că schimbările se pot produce oricând.

Modeling - Modelare

Scopul ştiinţei este de a descrie şi de a înţelege sistemele complexe, de exemplu sistemul

atomilor, societatea oamenilor sau sistemul solar. În mod tradiţional este făcută o deosebire între
ştiinţele naturale şi ştiinţele sociale pentru a deosebi aceste două tipuri de sisteme. Obiectivul ştiinţelor
naturale este de a înţelege natura şi subsistemele sale. Ştiinţele naturale includ biologia, chimia, fizica şi
paleontologia. Ţinta ştiinţei sociale este de a înţelege fiinţele umane. Ştiinţele sociale includ psihologia
şi sociologia.
Există un alt tip de sistem pe care noi îl numim sistem artificial. Exemple de sisteme artificiale
care includ ”spaţiul suveică“ (shuttle), sisteme de rezervare pe liniile aeriene. Herbert Simon a precizat
că obiectivul ştiinţelor artificialului este de a descrie ştiinţele care se confruntă cu sistemele artificiale.
Pe când ştiinţele naturale şi sociale există de secole, ştiinţele artificialului sunt decente. Computer
science, de exemplu, ştiinţa de a înţelege sistemele de computer este “copilul” secolului XX.
Multe metode care au fost aplicate cu succes în ştiinţele naturale şi umane pot fi aplicate în
ştiinţele artificiale de asemenea. Cercetând alte ştiinţe putem învăţa câte ceva. Una dintre metodele de
bază ale ştiinţei este modelarea. Un model este o reprezentare abstractă a sistemului care ne oferă
puterea de a răspunde întrebărilor despre system. Modelele sunt folositoare când ne confruntăm cu
sisteme care sunt prea mari, prea mici , prea complicate sau prea scumpe de ale experimenta la
îndemână. Modelele ne permit să vizualizăm sau să înţelegem sistemele care fie nu mai există sau
despre care se pretinde că există.
Biologii specializaţi în fosile au descoperit câteva oase şi dinţi păstrate de la câţiva dinozauri
necunoscuţi. Din fragmenete ale oaselor ei au făcut modelul unui animal urmând regulile anatomiei. Cu
cât au descoprit mai multe oase cu atât era mai clară ideea lor despre cum ar trebui să se potrivească
piesele şi cu atât era mai mare încrederea lor că modelul creat de ei se potrivea cu dinozaurul original.

5
Dacă ei găsesc un număr suficient de oase, dinţi şi gheare, ei pot fi aproape siguri că modelul lor
reflectă realitatea şi că ei pot găsi părţile lipsă. Picioarele, de exemplu, există în pereche. Dacă piciorul
stâng este găsit, iar dreptul nu, biologii au imagine foarte corectă despre cum ar trebui să arate piciorul
lipsă şi unde este locul lui în model. Acesta este un exemplu de model de sistem care nu mai există.
Fizicienii specialişti sunt într-o poziţie similară cu biologii care au găsit majoritatea oaselor. Ei
construiesc un model al materiei şi energiei şi cum funcţionează acestea împreună la nivelul cel mai de
bază, sub atomic. Mulţi ani de experimente cu acceleratori de particule au oferit fizicienilor suficientă
încredere că modelele lor reflectă realitatea şi că piesele rămase, negăsite se vor potrivi în aşa numitul
model standard. Acesta este un exemplu de model pentru un sistem presupus a exista.
Atât biologii cât şi fizicienii se confruntă cu două tipuri de entităţi: sistemul lumii reale, observat
în termenii unui set de fenomene, şi modelul domeniului de aplicaţie reprezentat ca un set de concepte
interdependente. Sistemul lumii reale este un dinozaur sau particule subatomice. Modelul domeniului
de aplicaţie este o descriere a acelor aspecte ale sistemului lumii reale care sunt relevante problemei
considerate.
Inginerii software se confruntă cu provocări la fel ca biologii şi fizicienii. În primul rând
inginerii software trebuie să înţeleagă mediuil în care sistemul trebuie să funcţioneze. Pentru un sistem
de control al traficului trenurilor inginerii software trebuie să cunoască procedurile de semnalizare a
trenurilor. Pentru un sistem de comerţ al acţiunilor, inginerii software trebuie să ştie regulile comerţului.
Inginerul software nu trebuie să devină un adevărat dispecer al trenurilor sau un broker; ei trebuie
numai să înveţe conceptele domeniului de aplicare care sunt relevante sistemului, în alţi termeni ei
treuie să creeze un model al domeniului de aplicare.
În al doilea rând inginerii software trebuie să înţeleagă sistemele pe care le pot crea şi să
evalueze soluţii diferite. Majoritatea sistemelor sunt prea complexe pentru a fi înţelese de orice
persoană şi majoritatea sistemelor sunt costisitoare pentru elaborare. Pentru a face faţă acestor
provocări, inginerii software descriu aspecte importante ale sistemelor alternative pe care ei le
investighează.
Metodele orientate pe obiect combină activităţile din domeniul de aplicare şi modelarea
domeniului soluţiilor într-unul singur. Domeniul de aplicare este primul modelat ca un set de obiecte de
relaţii.
Ideea metodelor orientate obiect este că modelul domeniului de soluţii este o transformare a
modelului de aplicaţii. Dezvoltarea software transformă în activităţi necesare de identificare a
sistemului ca un set de modele care adresează finalul problemei utilizatorului.

Problem solving – Rezolvarea de probleme

Inginerii caută o soluţie potrivită deseori prin încercări şi erori evaluând alternativele empirice
cu resurse limitate şi cunoştinţe incomplete.
În forma sa cea mai simplă metoda cuprinde 5 paşi:

1. formularea problemei
2. analiza problemei
3. căutarea soluţiilor
4. deciderea soluţiei potrivite
5. specificarea soluţiilor

Ingineria software este o activitate de inginerie, nu este algoritmică. Se cere experienţă, reutilizarea
soluţiilor şablon şi evoluţia incrementală a sistemului faţă de soluţia care este acceptată de system.
Dezvoltarea software-ului orientat obiect include cinci activităţi: cerinţele elicitation analiza,
design-ul sistemului, design-ul obiectului şi implementarea. În timpul acestor cerinţe şi analize inginerii
software formulează problema clientului şi creează modelul domeniului de aplicare. Cerinţele
elicitation şi analiza corespund paşilor 1 şi 2 din metoda ingineriei. Pe parcursul design-ului sistemului
inginerii software analizează problema, o descompun şi selectează strategii pentru design-ul sistemului.
Pe parcursul design-ului obiectului, ei selectează soluţiile pentru fiecare piesă şi decide asupra soluţiei

6
potrivite. Design-ul sistemului şi obictului rezultă în modelul domeniului soluţiilor. Design-ul
obiectului şi sistemului corespunde paşilor 3 şi 4 ale metodei ingineriei. Pe parcursul implemetării
inginerii software realizează sistemul prin transformarea modelului domeniului soluţiilor într-o
reprezentare executabilă. Implementarea corespunde pasului 5 al metodei. Ceea ce deosebeşte ingineria
software de alte ştiinţe în ceea ce priveşte problem solving este că schimbarea are loc în aplicaţii şi în
domeniul soluţiilor timp în care problema este rezolvată.
Dezvoltarea software include activităţi a căror scop este de a evalua potrivirea modelelor
respective. În timpul revizualizării analizei modelul domeniului de aplicaţie este comparat cu realitatea
clientului care poate fi schimbată ca un rezultat al modelării. În timpul revizualizării design-ului
modelul domeniului soluţiilor este evaluat faşă de scopurilor proiectului.
În timpul testării sistemul este validat faţă de modelullui domeniului soluţiilor care poate fi schimbat
prin introducerea unor noi tehnologii. În timpul conducerii proiectului, managerii îşi compară modelele
proceselor de dezvoltare cu realitatea.

Knowledge aquisition – Achiziţionarea de cunoştinţe

O greşeală comună pe care inginerii software şi managerii o fac este de a presupune că

dobândirea cunoştinţelor necesare dezvoltarii sistemelor este constantă. Această greşeală nu este făcută
doar de managerii software; poate găsită şi în alte domenii. În secolul al XVII-lea a fost publicată o
carte era utilizată pentru predare, care ajuta studenţii să înveţe poemele germane, în şase ore “băgându-
le cu pâlnia”. Idea utilizării pâlniei pentru învăţare este bazată pe o presupunere răspândită, şi anume că
mintea noastră este o “găleată”, care iniţial este goală, dar care poate fi umplută constant. În mintea
noastră intră informaţii prin simţuri, sunt accumulate şi sunt digerate. Popper numeşte acest model de
dobândire constantă a cunoştinţei : “Teoria găleţii minţii”. Printre multe alte lucruri care sunt greşite în
această teorie este presupunerea că şi cunoştinţa este concepută ca o sumă de lucruri care pot umple o
găleată.
Knowledge acquisition este un proces variabil. Adăugare unor noi piese de informaţii pot
invalida toate cunoştinţele pe care le-am dobândit pentru înţelegerea sistemului. Chiar dacă am
argumentat această înţelegere în documente şi cod, trebuie să fim pregătiţi mental să începem de la
notiţe. Aceasta are implicaţii importante asupra setului de activităţi şi interacţiunile lor pe care le
definim în dezvoltarea sistemului software. Echivalentul “Teoriei găleţii minţii ” este modelul
secvenţial de tip cascadă pentru dezvoltarea software în care toţi paşii metodei ingineriiei sunt
îndepliniţi secvenţial.
Există câteva procese software care se confruntă cu această problemă prin evitarea
dependenţelor secvenţiale inerente în modelul cascadă. Dezvoltarea bazată pe risc încearcă să anticipeze
surprizele târzii din proiect prin identificarea componentelor de mare risc. Dezvoltarea bazată pe
problemă încearcă să înlăture liniaritatea în întregime. Orice activitate de dezvoltare-analiză,design-ul
sistemului, obiectului, implementare testare sau livrare- pot influenţa orice altă activitate. În dezvoltarea
bazată pe problemă toate aceste activităţi sunt executate în parallel. Dificultatea modelelor dezvoltate
nesecvenţial este că sunt greu de condus.

Rationale - Raţionare

Când descriem dobândirea sau evoluţia cunoştinţei suntem mai puţin dotaţi decât atunci când
descriem cunoştinţele unui sistem existent. Cum un matematician determină provenienţa unei
demonstraţii. Cărţile de matematică sunt pline de demonstraţii dar rareori furnizează indicii despre
provenienţa demonstraţiei. Asta pentru că matematicienii nu cred că acest aspect este important. Odată
ce axiomele şi regulile deducţiei au fost stabilite, demonstraţia este iminentă. Pentru inginerii software
situaţia este diferită. Presupunerile pe care cercetătorii le fac asupra unui sistem se schimbă constant.
Chiar dacă modelele domeniilor de aplicaţii sunt stabilite cercetătorii dobândesc o înţelegere adecvată
asupra problemei, modelele domeniului soluţiilor sunt într-un flux constant. Greşelile de implementare
şi de design descoperite în timpul testărilor şi problemele de utilizare descoperite pe parcursul evaluării
interogărilor, schimbă modelele soluţiilor. Schimbările pot fi cauzate şi de noi tehnologii.

7
 Schimbarea tradusă de noile tehnologii permite deseori formularea unor cerinţe funcţionale noi
sau nefuncţionale. O sarcină tipică a inginerilor software este de a schimba sistemul software
operaţional curent pentru a incorpora această nouă tehnologie. Pentru a schimba sistemul nu este
suficient să înţelegi componentele actuale şi comportamentul. Este de asemenea necesar să înţelegi şi să
pricepi contextul în care fiecare decizie de design este făcută. Această cunoştinţă este numită rational of
the system.
Priceperea şi accesarea raţionalului sistemului nu este trivială. În primul rând pentru fiecare
decizie luată, câteva alternative pot fi considerate evaluate şi argumentate. Rationale reprezintă o gamă
mai largă de informaţii decât modelele de soluţii. În al doilea rând rational information nu este deseori
explicită. Cercetătorii iau multe decizii bazate pe experienţă şi intuiţie fără evaluarea explicită a
diferitelor alternative. Când li se cer explicaţii asupra unor decizii, cercetătorii pot petrece mult timp în
descoperirea raţionalului. Pentru a face faţă sistemelor în schimbare, inginerii software trebuie să
înfrunte provocările.

8
 MODULUL II. Managementul Ingineriei Sistemelor Informatice

Noţiuni :

Concepte de bază
Activităţi de dezvoltare
o Participanţi şi roluri
o Sisteme şi modele
o Activităţi, Task-uri şi Resurse
Activităţi de dezvoltare a Ingineriei Sistemelor Informatice
 Analiza problemei
 Proiectarea sistemului
 Proiectarea obiectelor
 Implementarea
 Testarea
Dezvoltarea administrării Ingineriei Sistemelor Informatice

Obiective:

1. Inţelegerea noţiunii de participanţi şi roluri.

2. Stabilirea activităţilor şi a task-urilor problemei pe baza resurselor.
3. Studierea şi înţelegerea etapelor de rezolvare a problemelor.

Recomandări privind studiul:

Studierea conceptelor prezentate în vederea utilizării lor pe parcursul celorlalte

capitole. Asimilarea conceptelor de bază legate de activităţile de dezvoltare a ISI şi
dezvoltarea administrării ISI care stau la baza noţiunilor prezentate în capitolele
următoare

Rezultate aşteptate:

1. Studenţii trebuie să fie capabili să îşi prezinte cunoştinţele teoretice de natură

coerentă şi consistentă.
2. Studenţii trebuie să poată analiza, proiecta, implementa şi testa un sistem.

9
Întrebări:

a. Ce se înţelege prin noţiunea de Participant?

b. În ce constă un rol?
c. Definiţi noţiunea de sistem.
d. Definiţi noţiunea de model.
e. Ce presupune analiza unei problrme?
f. Ce presupune proiectarea sistemului?
g. Ce înseamnă proiectarea obiectelor?
h. Cum se realizează implementarea soluţiei problemei?
i. Cum se face testarea sistemului?

Conceptele Ingineriei Soft

S-a prezentat a imagine de ansamblu a Ingineriei Soft din perspectiva modelării, rezoolvarea
problemelor , achizitionarea de cunoştinţe, şi raţionale. Ia acestă secţiune descriem principalalele
concepte şi noţiuni pe care le folosim pe parcursul cursului. Un proiect al cărui scop principal este
dezvoltarea unui sistem soft, este alcătuit dintr-un număr de activităţi. Fiecare activitate este la rîndul ei
alcătuită dintr-un număr de operaţiuni.O operaţiune consumă resurse şi realizează un produs. Un produs
poate fi sistem, model sau un document. Resursele sunt participanţii, timpul şi echipamentul. O
reprezentare grafică a acestor concepte o avem în cadrul alăturat. Fiecare dreptunghi reprezintă un
concept. Liniile dintre dreptunghiuri reprezintă diferitele relaţii dintre concepte. Spre exemplil rombul
reprezintă agregarea, un proiect inlclude un număr de activităţi, care includ un număr de operaţiuni.
Triunghiul indică o relaţie generală; participanţii, timpul, echipamentul sunt tipuri speciale de resurse.
Avem prezentat şi UML-ul.

Participanţi şi roluri

Dezvoltarea unui soft cere colaborarea mai multor persoane cu diferite bagaje de cunostinţe şi
cu interese diferite. Clientul cere şi plăteşte pentru sistem. Programatorii realizează sistemul.
Managerul de proiect planifică bugetele de proiect şi coordonează programatorii. Ne referim la toate
persoanele implicate în proiect ca şi participanţi. Ne referim la un set de responsabilităţi în cadrul
proiectului sau sitemului ca şi un rol. Un rol este asociat cu un set de operaţiuni şi este atribuit unui
participant. Acelaşipartiicipant poate avea mai multe roluri.

Maşina de bilete: este o maşină care distribuie bilete pentru trenuri. Călătorii au posibilitatea de a
selecta un bilet pentru o singură călătorie ssau pentru mai multe călătorii sau să selecteze un
abonament pentru o zi sau pentru o săptămană.. Maşina de bilete stabileşte preţurile a biletelor cerute în
conformitate cu yona unde va avea loc călătoria sau dacă călătorul este adult sau copil. Maşina de bilete
trebuie să poată să accepte o serie ce excepţii , precum cea în care călătorii nu ralizează o tranzacţie
completă, călătorii care obişniuiesc să plătească cu facturi mari precum şi cazuri excepţionale de a
rămane fără bilete, rest, energie.
Exemplu în tabelul următor:

Rol Responsabilitãţi Exemple

________________________________________________________________________
Client Clientul este responsabil sã furnizeze Compania de trenuri care
Cerinţele sistemului şi sã defineascã solicitã maşina de bilete

10
 scopul proiectului (data limitã, bugetul
nivelul calitativ)
________________________________________________________________________
Utilizator Utilizatorul este responsabil cu furnizarea Cãlãtorii
domeniului de cunoştinţe referitor la
operaţiunile curente.

________________________________________________________________________
Managerul Este responsabil cu organizarea muncii. Alice(şefa)
Aceasta constã în angajarea personalului,
Trasarea sarcinilor, asigurarea progresului,
parcurgerea training-ului, iar în general
conducerea resurselor oferite de client
pentru o comandã îndeplinitã.
________________________________________________________________________
Specialistul Este responsabil cu testarea sistemului ZOe (specialistul în
intereacţiunea)
fatori umani
________________________________________________________________________
Programatorul Un programator este responsabil pentru John(analist),Mark (programtor),
construirea sistemului, incluzând specificaţii, Zoe(tester)
design, testare. În proiectele mari programatorul
are un rol specializat.
________________________________________________________________________
Tehnicianul tehnicianul este responsabil cu documentaţia John
trimisã clientului. Un tehnician intervieveazã
programatorii, managerii, şi utilizatorii pentru
ca aceştia sã înteleagã sitemul
________________________________________________________________________

Sisteme şi modele

Folosim termenul de sistem ca şi o colecţie de elemente interconectate.

Modelarea este o manierã de a trata complex ignorând detaliile irelevante. Folosim noţiunea de model
pentru a referii orice abstractizare a sistemului. Un "distribuitor de bilete" pentru un metrou este un
sistem.
Planurile pentru Distribuitorul de Bilete , schemele şi modelele de obieccte ale softului sunt modele a
Distribuitorului de Bilete. Un proiect dezvoltat este un sistem care poate fi modelat. Programul
proiectului, bugetele şi datele limitã sunt modele a proiectul dezvoltat.

Produsele realizate

Un produs realizat este un artifact care este realizat pe parcursul procesului, precum un
document sau o bucatã soft pentru alţi programatori sau pentru client.Un produs realşizat este un produs
construit în urma unui proces intern. Un produs realizat se presupune cã trenuie livrat clientului ca şi o
comandã.
Comenzile sunt de obicei stabilite la începutul proiectului şi specificate de un contract ce leagã
programatorii de clienţi. Tabelul de mai jos este un exemplul de produs realizat pentru Distribuitorul de
Bilete:

________________________________________________________________________
Produsul realizat Tipul Detalii

11
Speificaţii Comandã
Specificaţiile descriu sistemul din
punctul de vedere al utilizatorului.
Este folosit ca un document contractual
între proiect şi client. Specificaţiile
Distribuitorului de BIlete descriu în detaliu
cum ar trebui sã aparã sistemul
cãlãtorului.
Operaţie manuală Comandã Operaţia manualã pentru D.B este
folositã de personalul companiei feroviare
responsabil cu
instalarea şi configurarea D.B. Un
asemenea manual desrie de exemplu, cum
sã schimbi preţul
biletelor şi structura reţelelor din zonã.
________________________________________________________________________
Raportul stãrii Produs intern realizat Descrie la un anumit timp
operaţiunea care a fost efectuatã şi
operaţiunile care sunt încã în curs.Rapotul
de stare este fãcut de manager, Alice, şi de
obicei nu este vãzutã de compania feroviarã
________________________________________________________________________
Testarea manualã Produs intern realizat Planul de test şi rezultatele sunt
realizate de tester, Zoe.Aceste documente
depisteazã erorile din prototipul D.B
.Aceste documente nu sunt de obicei
arãtate clientului.
________________________________________________________________________

Activitãţi , operaţiuni, şi resurse

O activitate este un set de operaţiuni ce sunt efectuate pentru un scop specific. De exemplu,
obtinerea cerinţelor este o activitate a cãrui scop este sã defineascã împreunã cu clientul ce anume va
face sistemul.
Livrarea este o activitate a carei scop este sã instaleze sistemul la o locaţie operaţionalã.
Managementul este o activitate a cãreiscop este sã monitorizeze şi sã controleze proiectul astfel încât
sã-şi atingã scopurile (data limitã, calitate, buget). Activitãţile pot fi combinate cu alte activitãţi.
Activitatea de livrare include o activitate de instalare a soft-ului şi o activitate de training pentru
operare.

Activitãţile sunt uneori numite şi faze:

O operaţiune reprezintã o unitate atomicã a muncii care poate fi condusã: Un manager le atribuie
programatorior, programatorii o îndeplinesc, şi managerii urmãres progresul şi îndeplinesc sarcinile.
Operaţiunile consumã resurse ,rezultatele în muncã, şi depind de alte operaţiuni.
Resursele sunt bunuri folosite pentru îndeplinirea proiectului. Resursele presupun timp, echipement, şi
muncã.Când planificãm un proiect,, un manager împarte munca în mai multe operaţii şile atribuie
resurse.

Tabel desriind activitãţi, resurse şi operaţii pentru Distribuitorul de Bilete:

________________________________________________________________________
Exemplu Tipul Descriere

12
Obţinerea cerinţelor Activitate Obţinerea cerinţelor include obţinerea şi
validarea cerinţelor şi domeniul de cunoştinţe a
clienţilor şi a utilizatorilor. Obţinerea de cerinţe
produce specificaţiile produsului realizat.
________________________________________________________________________
Proces "Lipsei restului" Operaţiune Aceastã operaţiune specificã lui Zoe,
testerul, test pentru D.B se axeazã pe verificarea
comportamentelor pentru
D.B când rãmâne fãrã bani şi nu poate returna
restul corect utilizatorului.
Aceastã activitate include specificaţii ale situaţiei
testate, secvenţa de intrãri şi ieşirile aşteptate.
________________________________________________________________________
Revizuire "Accesare meniului HELP" Operaţiune
Aceastã operaţiuni atribuitã lui John, specialistu
Folosirea cazului în testare în factori umani,
urmãreşte detectarea erorilor în utilizare meniului
HELP online.
________________________________________________________________________
Taxa bazei de date Resursã Include un exemplu în structura tarifului
într-un plan de reţea de trenuriAcest exemplu este o
resursã asiguratã de client pentru cerinţe şi testãri.
________________________________________________________________________

Cerinţele funcţionale şi nefuncţionale

Cerinţele specificã un set de competenţe pentru care un sistem trebuie sã le aibã. O cerintã
funcţionalã este o specificaţie a unei funcţii pe care sistemul trebuie sã o suporte, în timp ce o cerinţã
nonfuncţionalã este o constrângere pe operaţia sistemului care nu are legãturã directã cuo funcţie a
sistemului.
De exemplu utilizatorul trebuie sã poatã sã-şi obtinã biletul and sã poatã sã acceseze informaţia tarifalã
cerinţe ce sunt funcţionale.
Utilizatorul trebuiã sã primeascã rãspunsul în mai piţin de o secundã şi culorile folosite în interfaţã ar
trebui sã corespundã cu cele ale companiei cerinţe care sunt non-funcţionale. Alte cerinţe non-
funcţionale pot include anumite elemente hard-ware, cerinţe de securitate. cum sistemul ar trebui sã
trateze erorile, şi cum sã interacţioneze cu un sistem mai slab pe care clientul nu vrea sã-l schimbe.

Notaţii, metode şi metodologii

O notaţie este un set grafic sau textual de reguli pentru reprezentarea unui model. Alfabetul
roman este o notaţie care reprezintã cuvintele.UML este notaşia pe care noi o folosim în acest curs este
o notaţie de reprezentare modelului orientat pe obiect. Folosirea notaţiei în Ingineria Soft este mai la
indemânã pentru cã foloseşte conceptele modelului orientat pe obiect. Diagramele data flow este o
notaţie de reprezentare
a sistemelor.
O metodã este o tehnicã ce se repetã şi specificã paşii ce trebuie urmaţi în rezolvarea unei
anumite probleme.
O reţetã este o metodã pentru gãtit. Un algoritm sortat este o metodã pentru ordonarea elementelor într-
o listã.
Managementul raţional este o metodã pentru justificarea schimbãrii.
O metodologie este o colecţie de metode pentru rezolvarea unei clase de probleme si aratã cum
şi când ar trebui folositã fiecare metodã .

13
Metodologiile de dezvoltare software descompun procesele în activitãţi. OMT oferã metode pentru 3
activitãţi.
Analizã, care se axeazã pe formalizarea cerinţelor sistemelor într-un model obiect, Designul de sistem
se axeazã pe deciziile strategice, şi Designul de Obiect transformã analiza modelului într-un obiect
model care poate fi impolementat. Metodologia OMT presupune cã cerinţele au fost deja stabilite şi nu
oferã metode pentru obţinerea de cerinţe. Procesul de dezvoltare soft include deasemenea o activitate
de analizã şi de tratare a designului de sitem şi a designului de obiectca pe o singurã activitate numitã
Design. Procesele unificate spre deosebire de OMT include o activitate de analizã a cerinţelor pentru
obţinerea şi modelarea lor.
Toate aceste metodologii se axeazã pe lucrul cu sisteme complexe.

Activităţile de dezvoltare în ingineria soft

În acestă secţiune vom face o prezentare a activităţilor legate de ingineria software orientată
obiect. Activitătile de dezvoltare confruntă complexitatea construind şi validând modele ale domeniului
aplicaţiei sau ale sistemului. Activităţile de dezvoltare includ:
 obţinerea cerinţelor
 analiza
 designul sistemului
 designul obiectelor
 implementarea
 testarea

Figura 1.2 descrie relaţiile dintre aceste activităţi şi finalităţile acestora. In secţiunea 1.5 sunt
prezentate activităţile manageriale care sunt asociate cu ingineria soft. In capitolul 14, Managementul
Proiectelor, şi în capitolul 15, Ciclul de viaţă al soft-ului, se vor detalia modelarea, planificarea şi
activităţile ingineriei soft.

Figura 1.2 Prezentarea activităţilor de dezvoltare în ingineria soft orientată obiect şi finalităţile lor. Această diagramă
prezintă doar dependenţele logige dintre componente. Ingineria soft orientată obiect este iterativă; aceasta înseamnă că
activităţile se pot desfăşura în paralel şi de mai multe ori.

14
Obţinerea cerinţelor

Pe parcursul obţinerii cerinţelor, clientul şi dezvoltatorul definesc scopul sistemului. Rezultatul

acestei activităţi este o descriere a sistemului în ceea ce privesc actorii şi situaţiile de utilizare. Actorii
reprezintă entităţile externe care interacţionează cu sistemul. Actorii pot fi utilizatori finali, alte
calculatoare cu care sistemul trebuie să interacţioneze (ex. computerul unei banci, o reţea) şi mediul(ex.
un proces chimic). Situaţiile de utilizare sunt succesiuni generale de evenimente care descriu toate
interacţiunile posibile dintre un actor şi sistem pentru o anumită funcţionalitate. Figura 1.3 descrie o
situaţie de utilizare a exemplului TicketDistributor ce s-a discutat anterior. Obţinerea cerinţelor, precum
şi situaţiile de utilizare sunt detaliate in capitolul 4, Obţinerea cerinţelor.

Situaţia de utilizare CumpărareBiletDus

Actor implicat
Flux de evenimente
Condiţie de intrare
Condiţie de ieşire
Cerinţe de calitate
Acţiune iniţiată de Călător
1. Călătorul selectează zona în care se află staţia de
destinaţie
2. DistribuitorulDeBilete afişează preţul biletului
3. Călătorul introduce o sumă de bani care este cel puţin
egală cu preţul biletului
4. DistribuitorulDeBilete emite biletul corespunzător şi
returnează eventualul rest
Călătorul se află lângă DistribuitorulDeBilete, care se poate
afla in staţia de plecare sau în oricare altă staţie
Călătorul deţine un bilet valid şi un eventual rest
Dăcă tranzactia nu este efectuată după un minut de
inactivitate, DistribuitorulDeBilete returnează suma introdusă
de Călător

Figura 1.3 Exemplu de situaţie de utilizare, CumpărareBiletDus

Analiza

Pe parcursul analizei, dezvoltatorii încearcă să realizeze un model al sistemului care să fie correct,
complet, consistent si clar. Dezvoltatorii transformă situaţiile de utilizare rezultate în urma obţinerii
cerinţelor într-un model bazat pe obiecte care să descrie complet sistemul. Pe parcursul acestei
activităţi, dezvoltatorii descoperă ambiguităţile şi inconsistenţele din situaţiile de utilizare create
împreună cu clientul. Rezultatul analizei este un model al sistemului adnotat cu atribute, operaţii şi
asocieri. Modelul sistemului poate fi descris prin prisma structurii sale şi a interacţiunilor dinamice.
Figura 1.4 reprezintă un exemplu de model dinamic pentru DistribuitorulDeBilete. Figura 1.5 reprezinta
un exemplu de model obiectual pentru DistribuitorulDeBilete.

15
 :DistribuitorulDeBilete :Zona :Balanţa

:Călător
selecteazăZona() iaPreţ()

sumăDatorată

introduceBani() actualizeazăBalanţa()

sumăDatorată

introduceBani() actualizeazăBalanţa()
confirmare

<<crează>>
bilet :Bilet
Fig
ura 1.4 Un model dinamic pentru DistribuitorulDeBilete (diagramă de secvenţe UML). Această diagramă descrie
interacţiunea dintre actor şi sistem pe parcursul situaţiei de utilizare CumparareBiletDus şi obiectele care participă.

Tranzacţie Bilet Zona

se transformă în valid pentru

Monedă

Balanţă
sumă plătită
Bancnotă

Figura 1.5 Un model obiectual pentru DistribuitorulDeBilete (digrama de clasă UML). In situaţia de utilizare
CumpărareBiletDus, Călătorul iniţiază o tranzacţie din care va rezulta un billet. Un bilet este valid doar pentru o anumită
zonă. Pe parcursul tranzacţiei sistemul ţine evidenţa balanţei numărând monedele şi bancnotele introduce.

Se va descrie analiza, inclusiv modelele obiectuale, mai detaliat in capitolul 5, Analiza. Se va

descrie în detaliu notaţia UML pentru reprezentarea modelelor in capitolul 2, Modelarea folosind UML.

Designul sistemului

Pe parcursul proiectări sistemului dezvoltatorii definesc scopurile designului pentru proiectul

respectiv şi descompun sistemul în subsisteme mai mici care pot fi realizate pe echipe. Dezvoltatorii
selectează şi strategiile de construire a sistemului, cum ar fi hardware-ul şi platforma pe care urmează să

16
ruleze sistemul, strategiile de management al datelor, controlul fluxului global, politicile de control al
accesului şi limitele condiţilor. Rezultatul designului sistemului este o descriere clară a fiecărei din
aceste strategii, o descompunere în subsisteme şi o diagramă de desfăşurare reprezentând maparea
hardware/software a sistemului. In timp ce atât analiza cât şi designul sistemului realizează modele ale
sistemului aflat în construcţie, doar analiza foloseşte entităţi ce pot fi înţelese de client. Designul
sistemului foloseşte modele mult mai rafinate care includ entităţi care sunt dincolo de limita de
înţelegere(şi interes) a clientului. Figura 1.6 descrie un exemplu de descopunere a sistemului pentru
DistribuitorulDeBilete. Se vor descrie designul sistemului şi conceptele sale esenţiale detaliat in
capitolul 6, Designul sistemului: Descompunerea sistemului, şi în capitolul 7, Designul sistemului:
Tratarea scopurilor designului.

InterfaţăCălător Actualizator

TarifLocal TarifCentral

Figura 1.6 Descompunerea pe subsisteme pentru DistribuitorulDeBilete(diagrama de clase UML, pachetele

reprezentând subsistemele iar liniile punctuate, relaţiile). Subsistemul InterfaţăCălător este responsabil cu colectarea datelor
de intrare venite de la Călător şi să furnizeze feedback(ex. afişarea preţului unui billet, returnarea restului). Subsistemul
TarifLocal calculează preţul diferitor bilete folosind baza de date locală. Subsistemul TarifCentral, aflat pe un computer
central, ţine o copie de referinţă a bazei de bate a tarifelor. Subsistemul Actualizator este responsabil cu actualizarea bazei de
date locale afiecărui DistribuitorDeBilete folosind reţeaua atunci când preţul biletelor se modifică.

Designul obiectelor

Pe parcursul proiectării obiectelor, dezvoltatorii definesc obiectele domeniului soluţiei pentru a

acoperii golul dintre modelul analizei şi platforma hardware/software definită in timpul proiectării
sistemului. Aceasta include descrierea exactă a obiectelor şi a interfeţelor subsistemelor, restructurarea
modelului obiectual pentru a atinge unele scopuri ale proiectării, cum ar fi extensibilitatea şi înţelegerea
facilă şi optimizarea modelului obiectual pentru performanţă. Rezultatul activităţii de proiectare a
obiectelor este un model detaliat al obiectelor adnotat cu constrângeri şi descrieri precise ale fiecărui
element. Se vor descrie designul obiectelor şi conceptele legate de acesta mai în detaliu în capitolul 8,
Designul obiectelor: Reutilizarea soluţiilor standard, şi în capitolul 9, Designul obiectelor:
Specificarea interfeţelor.

Implementarea

Pe parcursul implementării dezvoltatorii transpun modelul domeniului soluţiei în cod sursă.

Aceasta cuprinde implementarea atributelor şi a metodelor pentru fiecare obiect şi integrarea tuturor
obiectelor astfel încât acestea să funcţioneze ca un sistem unitar. Activitatea de implementare acoperă
golul dintre(span de gap) modelul obiectual detaliat şi setul complet de cod sursă ce poate fi compilat.
Se va desrie maparea modelelor UML in cod in capitolul 10, Maparea modelelor în cod. Se presupune

17
că cititorul este deja familiarizat cu conceptele de programare şi ştie cum să creeze structuri de date şi
algoritmi folosind un limbaj orientat obiect cum ar fi Java sau C++.

Testarea

Pe parcursul testării dezvoltatorii găsesc diferenţe între sistem şi modelul său prin utilizarea
sistemului folosind date de intrare de probă. In timpul testării dezvoltatorii compară designul modelului
obiectelor cu fiecare obiect şi subsistem. In timpul testării integrate, combinaţii de subsisteme sunt
comparate cu designul modelului sistemului. Pe parcursul testării sistemului, situaţii tipice şi
excepţionale sunt rulate prin sistem iar rezultatele sunt comparate cu modelul ceriţelor. Scopul testării
este de a găsii cât mai multe erori pentru a putea fi reparate înainte de a livra produsul. Planificarea
fazelor de testare are loc în paralel cu alte activităţi de dezvoltare: testarea sistemului se planifică pe
parcursul obţinerii cerinţelor şi a analizei, testarea integrată se planifică atunci când se crează designul
sistemului, iar testarea unităţilor se planifică în timpul designului obiectelor.

3. Managementul dezvoltării software

Ce este Software Engineering(SE)?

SE este o activitate de modelare. Inginerii se confruntă cu greutăţi în activitatea de modelare, ei

trebuind să fie atenţi la orice moment doar pe detaliile relevante şi ignorând toate celalalte. Pe parcursul
procesului de dezvoltare, inginerii programatori construiesc diverse modele ale sistemului şi ale
domeniului de aplicare

SE este o activitate de rezolvare a unor probleme. Modelele sunt utilizate pentru a căuta soluţii
acceptabile. Inginerii nu au resurse infinite şi sunt constrânşi de buget şi de termenele limită. Datorită
slabelor cunoştinţe, ei de multe ori trebuie să se bazeze pe metode empirice pentru a evalua avantejele
diferitelor metode.

SE este o activitate de acumulare a cunoştinţelor.În modelarea aplicaţiilor şi a soluţiilor domeniului,

inginerii colectează date, le organizează în informaţii şi le dau forma de cunoştinţe.

SE este o activitate de conduită raţională. Când adună cunoştinţe şi iau decizii despre sistem sau
domeniile lui de aplicare, inginerii trebuie de asemena să se încadreze în contextul în care aceştia iau
deciziile. Informaţiile raţionale, reprezentate ca un set de modele, le permit inginerilor să înţeleagă
implicaţiile unei presupuse schimbări când se revizuieşte o problemă.

Managementul dezvoltării software

În această secţiune, descriem pe scurt activităţiile implicate în managementul unui proiect de

inginerie software. Activităţile de management se concentrează pe planificarea proiectului,
monitorizarea şituaţiei, urmarirea schimbărilor, şi coordonarea resurselor în aşa fel încât un produs de
înaltă calitate să fie livrat la timp şi în limitele bugetului. Activităţile de management nu implică doar
existenţa managerilor, ci şi marea majoritate a participanţilor la proiect. Activităţiile de management
includ:
 comunicare
 management relaţional
 management de configurare software
 management de proiect

18
  ciclul de viaţă al software-ului

Mentenanţa software, care nu este tratată în aceasta carte, include activităţile de dezvoltare care
apar dupa livrarea sistemului la client. În mod tradiţional, mentenanţa software-ului a fost diferentiata
de alte activităţi de dezvoltare întrucat este foarte deschisă spre schimbări şi este realizată de o altă
echipă diferită de echipa care l-a dezvoltat iniţial. Deoarece proiectele moderne de inginerie software
devin din ce în ce mai deschise spre schimbări, distingerea activităţilor de construcţie de cele de
întreţinere devin tot mai neclare. Multe din activităţile descrise în aceasta carte pot trece la mentenanţă,
inclusiv designul de obiecte, implementarea, testarea, management raţional, şi managementul de
configurare software.

1 Comunicarea
Comunicarea este cea mai critică activitate şi care consuma cel mai mult timp în ingineria
software. Neînţelegerile şi omisile duc deseori la greşeli şi întârzieri a căror corectare costă mult în
procesul de dezvoltare ulterior. Comunicarea include schimbul de modele şi documente despre sistem şi
domeniul de aplicare a acestuia, raportarea situaţiei al produsului în lucru, oferirea de feedback în
legatură cu calitatea produsului aflat în lucru, enunţarea şi rezolvarea problemelor, şi comunicarea
deciziilor. Comunicarea este greoaie datorită diversitatii situatiilor participanţilor, distribuirea
geografică şi volumul, complexitatea şi evoluţia informaţiei schimbate.
Pentru a trata problemele legate de comunicare, participanţii la proiect au multe unelte la
dispoziţie. Cea mai bună este convenţia: când participanţii se pun de acord cu anumite notaţii pentru a
reprezenta informaţii, cu uneltele folosite la manipularea informaţiei, şi procedurile de ridicare şi
rezolvare a problemelor, elimină o mare parte din sursele cauzatoare de neînţelegeri. Exemplele de
notaţii includ diagramele UML, template-uri pentru scrierea documentelor şi a discursurilor, şi
identificarea schemelor pentru numirea componentelor software. Exemplele de unelte includ Computer
Aided Software Engineering (CASE), unelte pentru mentenanţa modelelor, procesoare de cuvinte
pentru generarea documentelor, şi transformarea formatelor pentru publicarea informaţiei. Exemplele
de proceduri includ întâlnirea procedurilor de organizare, conducere, şi salvarea unei întâlniri, proceduri
de revizuire pentru revizuirea documentelor şi oferirea de feedback, şi inspectarea procedurilor pentru
detectarea defectelor în modele sau în codul sursă. Convenţiile alese nu trebuie să fie cele mai bune;
trebuie doar să fie impărţite şi acceptate de toţi.

2 Managementul Rational
Raţionarea este justificarea deciziilor. Raţiunea unei decizii luate include problema careia i se
adreseaza, alternativele care develop-erii le-au luat în considerare, criteriul folosit de develop-eri pentru
evaluarea deciziilor, dezbaterea realizată de develop-eri pentru obţinerea consensului, şi a deciziilor.
Rationarea este cea mai importantă informaţie de care au nevoie developerii cand schimbă sistemul.
Dacă un criteriu se schimbă, developerii pot reevalua toate deciziile care depind de acest criteriu. Daca
apare o nouă alternativă, poate fi comparată cu toate celelălte alternative care au fost deja evaluate.
Daca decizia nu este clară, pot apela la raţiune pentru a o justifica.
Din păcate, raţiunea este de asemenea cea mai complexă informaţie cu care au de-a face
developerii în procesul de dezvoltare, şi deci, este cel mai greu de înnoit şi întreţinut. Pentru a face faţă
acestei provocări, developerii prind raţiunea în timpul întîlniriilor şi a discuţiilor on-line, prezintă
raţiunea cu modele problematice, şi accesează raţiunea în timpul schimbărilor.

3. Managementul de configurare software

Managementul de configurare software este procesul care monitorizeaza şi controlează
schimbăriile din produsele aflate în lucru. Shimbările îngreunează dezvoltarea programelor. Cerinţele se
schimbă în momentul în care clientul cere noi elemente când pe masură ce developerii înteleg mai bine
domeniul de aplicare. Platforma hardware/software pe care sistemul este construit se schimbă îndată ce
apar noi tehnologii. Schimbările de sistem ca şi greşeli, sunt descoperite la testare şi sunt reparate.
Managementul de configurare software era plasat în partea de mentenanţă, cand îmbunătăţirile erau
incremental introduse in sistem. În procesul modern de dezvoltare, schimbările apar mai devreme decat

19
mentenanţa. Totuşi schimbările din dezvoltare pot fi făcute în orice etapă. Managementul de
configurare permite developerilor sa ţină evidenţa schimbărilor. Sistemul este reprezentat ca fiind un
numar de elemente de configurare care sunt revizuite individual. Pentru fiecare element de configurare,
evolutia lui este urmarită ca o serie de versiuni. Selectarea unei versiuni permite developerilor să se
întoarcă la o situatie bine definită a sistemului cand o schimbare cedează.
Managementul de configurare de asemenea permite developerilor să controleze schimbările.
Dupa ce a fost definită o linie de bază orice schimbare trebuie verificată şi aprobata înainte să fie
implementată. Acest lucru permite managementului sa asigure o evolutie a sistemului în concordanţă cu
scopul proiectului şi că numărul de probleme introduse în sistem sunt limitate.

Administrarea proiectului

Se ocupă de supraveghera activităţilor ca acestea sa rămână în limitele timpului şi de buget. Aceasta

include planificarea şi împărţirea bugetului pe proiect pe masura negocierilor cu clientul, angajarea de
programatori şi organizarea acestora în echipe, monitorizarea stadiilor proiectului şi intervenirea cand
proiectul deraiază de la calea impusă

20
 MODULUL III. Modelarea

Conţinutul capitolului :

Noţiunea de modelare
Modelarea V
Modelul Incremental
Modelul Spirală
Extreme Programming

Obiective:
a. Înţelegerea noţiunii de modelare
b. Aprofundarea modelului V.
c. Aprofundarea modelului Incremental
d. Aprofundarea modelului Spirală.
e. Aprofundarea modelului Extreme Programming.

Recomandări privind studiul:

Studierea modelelor prezentate în vederea utilizării lor pe parcursul celorlalte
capitole. Asimilarea conceptelor de bază legate de modele şi de tipurile de modele care
sunt necesare în capitolele următoare

Rezultate aşteptate:
Studenţii trebuie să fie capabili să îşi prezinte cunoştinţele teoretice de natură
coerentă şi consistentă.
Studenţii trebuie să poată prezenta orice model studiat.

Întrebări:
a. Ce este un model?
b. Prezentaţi modelul V.
c. Prezentaţi modelul Incremental
d. Prezentaţi modelul Spirală.
e. Prezentaţi modelul Extreme Programming.
f. Realizaţi o paralelă între oricare două tipuri de modele şi prezentaţi
argumente pro şi contrarea în favoare autilizării unuia sau celuilalt.

21
 Modelarea

Modelarea: metodă utilizată în ştiinţă şi tehnică constând în reproducerea schematică a unui obiect sau
sistem sub forma unui sistem similar sau analog în scopul studierii proprietăţilor şi transformărilor
sistemului original.

Modelarea informaţiilor = Obiecte + Atribute + Relaţii + Supertipuri/Subtipuri +Obiecte

asociative.

Modelul Cascadei

1. Cum a aparut Modelul Cascadei

Modelul cascadă este crezut ca fiind primul model introdus şi folosit pe scară largă in inginerie
soft. Inovaţia introdusă de acest model consta in impartirea pentru intaia oara, a procesului de
dezvoltare a programelor, în faze distincte.
Modelul cascadă impune o abordare sistematică, secvenţială, a dezvoltării softului, abordare
care porneşte de la sistem şi parcurge etape de analiză, proiectare, programare, testare şi întreţinere.
Modelul are în vedere întregul ciclu de viaţă al produsului, există evaluări pentru fiecare etapă şi
posibilităţi de revenire la etape sau de reluare a ciclului de viaţă, într-o fază de evoluţie ulterioară.
Originea termenului “cascadă” este un articol publicat în anul 1970 de către W.W. Royce. Partea
haioasă este că Royce propunea în acel articol o abordare iterativă a dezvoltării softului si nici
măcar nu a folosit termenul de “cascadă”, el descriind ceea ce azi cunoaştem ca fiind modelul
“cascadă” ca fiind o metodă riscantă un adevărat “magnet” pentru erori. În ciuda intenţiilor lui
Royce de a modifica modelul cascadă într-un model iterativ, utilizarea sa ca un proces pur
secvenţial este încă populară, iar pentru unii “modelul cascadă” a ajuns să definească orice abordare
inflexibilă si non-iterativă de dezvoltare a produselor software. Majoritatea acestor persoane văd
“modelul cascadă” ca fiind naiv şi nepotrivit pentru procesele din “lumea reală”.

2. Fazele Modelului Cascada

DEFINIREA SI
ANALIZA
CERINTELOR

DESIGN-UL
SISTEMULUI

DESIGN-UL
SOFTWARE

CODAREA

INTEGRAREA
VERIFICAREA
SOFTWARE

VERIFICAREA
SISTEMULUI

22
 OPERAREA SI
MENTINEREA

Modelul Cascadei („The Waterfall Model”)

1. Definirea şi analiza cerinţelor (Requirement Analysis & Definition): Toate cerinţele sistemului care
trebuiesc indeplinite sunt colectate in această fază. Ca şi in alte modele de procese, cerinţele sunt
impărţite in cerinţe funcţionale şi constrângeri pe care sistemul trebuie să le respecte. Cerinţele trebuie
să fie colectate prin analiza nevoilor clientului şi verificarea lor pentru a fi valide şi posibile de
implementat. Scopul este generarea Documentului de Specificaţie a Cerinţelor care este utilizat ca şi
input pentru următoarea fază.

2. Design-ul sistemului (System Design): Sistemul trebuie să fie bine descris inainte ca implementarea
să inceapă. Aceasta implică un design arhitectural care defineşte şi descrie principalele părţi şi
componente ale sistemului, ale interfeţei şi interacţiunilor. Cu aceasta hardware-ul necesar este definit şi
software-ul este impărţit pe componente. Aceasta implică definirea sau selecţia unei platforme, unui
sistem de operare, a altor componente hardware periferice, etc. Componentele software trebuie să fie
definite astfel incât să intâlnească nevoile clienţilor. Scopul acestei faze este de a genera un Document
pentru Arhitectura Sistemului (System Arhitecture Document) care să servească ca şi un input pentru
faza de design software a dezvoltării, dar şi ca un input pentru design-ul hardware sau selecţia
activităţilor. De obicei in această fază unele documente sunt generate, unul pentru fiecare disciplină,
astfel incât software-ul va primi un document cu arhitectura software.

3. Design-ul Software (Software Design): Bazat pe arhitectura sistemului care a definit principalele
părţi software, design-ul software le va impărţi in module de cod. Interfeţele şi interacţiunile modulelor
vor fi descrise, precum şi funcţionalităţile lor. Toate modurile sistemului ( startup, shutdown, condiţiile
de eroare şi diagnosticul) trebuie să fie luate in considerare dar şi activitatea şi stările acestuia trebuiesc
definite. Output-ul acestei faze este un Document de Design Software care este şi baza implementării ce
urmează a fi făcută.

4. Codarea (Coding): Bazată pe Documentul pentru Arhitectura Sistemului munca este de a seta
modulele sau unităţile definite şi astfel procesul de codare incepe. Sistemul este in primul rând
dezvoltat din părţii mici numite unituri. Ele sunt capabile să stea singure, din punct de vedere funcţional
şi sunt integrate apoi in form, in pachetul software complet.

5. Integrarea şi Verificarea Software (Software Integration & Verification): Fiecare unitate este
prelucrată independent şi poate fi testată pentru funcţionalitatea sa. Aceasta se numeste Testarea Uniţăti.
Aceasta doar verifică dacă modulele sau uniturile se incadrează in specificaţii. Aceasta implică teste
funcţionale la nivel de interfaţă a modulelor, dar şi teste mai detailiate in structura internă a modulelor
software. In timpul integrării, uniturile care sunt prelucrate şi testate pentru funcţionalităţile lor sunt
combinate. Modulele sunt integrate intr-un sistem complet şi sunt testate pentru a vedea dacă toate
funcţionează precum se aşteaptă.

6. Verificarea Sistemului (System Verification): După ce s-au obţinut rezultatele bune la teste asupra
sitemului complet acestea se confruntă cu cerinţele iniţiale. Aceasta va include hardware-ul şi mediul
original.

23
7. Operarea şi menţinerea (Operation & Maintenance): Sistemul este predat clientului care il va
utiliza pentru prima dată. Clientul va verifica dacă cerinţele lui au fost implementate dar şi dacă acestea
sunt cele iniţiale. In cazul in care trebuie să se facă schimbări se vor face astfel incât sistemul să fie
utilizabil şi să indeplinească dorinţele clientului.

3. Avantaje si Dezavantaje

Avantaje:
 Controlul total asupra fazelor
 Uşor de însuşit de către membrii echipei de proiectare
 Fiecare fază este însoţită de o documentaţie completă

Dezavantaje:
 Sistemul poate fi predat după parcurgerea etapelor, deci necesită mult timp de lucru
 Nu corespunde intenţiilor de abordare dinamică
 Nu este deschis schimbărilor ce apar pe parcurs
 Este într-o contradicţie flagrantă cu procesul liber, prin încercări, care este adesea vital pentru rezolvarea
creativă a problemelor

4. Modele Cascada modificate

Ca răspuns la problemele modelului cascadă “pur” au fost introduse o serie de modele cascadă
modificate menite să înlăture o parte din criticile aduse modelului original.
Aceste modele modificate folosesc aceleaşi faze ca şi modelul cascadă pur, însă nu într-un mod
discontinuu. Acest fapt permite ca unele faze să se suprapună ori de câte ori este necesar. O altă
funcţionalitate nouă introdusă de aceste modele o constituie posibilitatea împărţirii modelului pe
mai multe subproiecte după o anumită fază.
Exemple de modele cascadă modificate:
Modelul “sashimi”
Denumit aşa deoarece suportă suprapunerea fazelor, asemenea peştelui japonez sashimi, a fost
iniţiat de către Peter DeGrace, şi de cele mai multe ori este denumit simplu: “modelul cascadă cu
faze suprapuse” sau “modelul cascadă cu feedback”. Deoarece fazele acestui model se suprapun
descoperirea si tratarea erorilor este mai uşoară şi se poate realiza în cadrul fazelor modelului
cascadă.
Cascada cu prototipuri(Prototyping waterfall)
Acest model se bazează pe crearea unui sistem de exemple, prototipuri, care să ajute la
descoperirea rapidă a erorilor. Un dezavantaj al acestui model îl constituie faptul ca crearea unui
astfel de prototip necesită un timp destul de îndelungat.
Cascada cu borne(Milestone waterfall)
Presupune crearea aplicatiilor pe mai multe faze, versiuni, în fiecare fază introducându-se câte o
funcţionalitate cheie. Acest model este excelent pentru demonstrarea conceptelor în cazul folosirii
unor tehnologii noi, reduce considerabil riscurile prin introducerea funcţionalităţilor cu cel mai mare
grad de risc în primele versiuni.
Alte modele alternative
Modelul cascadă cu subproiecte si modelul cascadă cu reducerea riscurilor sunt alte versiuni de
modele cascadă modificate. În unele privinţe chiar şi modelul spirală poate fi privit ca un model
cascadă cu iteraţie.

24
 5. Argumente Pro si Contra

Argumente pro modelul în cascadă

Timpul petrecut în primele faze ale producţiei de software poate duce la o mai mare economie în cadrul
ciclului de viaţa al unui produs soft. Este de preferat să depistăm şi să reparăm o eroare în primele faze
ale ciclului decât mai târziu. McConnell estimează că un defect în faza de specificaţie a cerinţelor
nedetectabil până în faza de implementare sau de mentenanţă costa de 50 până la 200 de ori mai mult
decât ar fi costat în faza de specificare a cerinţelor.

Unul dintre principalele argumente pe care le au susţinătorii acestei metode este faptul că este mai uşor
de schimbat proiectul în cadrul fazei de proiectare decât să aşteptăm luni de zile şi să vedem că ce am
lucrat trebuie refăcut datorită unui design greşit.

Unii specialişti preferă acest model pentru simplitate şi pentru faptul că prezintă o abordare mai
structurată, progresând liniar prin faze uşor de înţeles. Datorită acestui fapt modelul în cascadă este
folosit ca exemplu de început în multe cărţi şi cursuri de inginerie soft.

Modelul în cascadă este folosit de o mulţime de companii de mare anvergură ca de exemplu

Departamentul de defensivă al SUA sau NASA în cadrul proiectelor de cercetare sau pentru alte
scopuri.

Argumente contra modelului în cascadă

Modelul cascadă este contestat de unii specialişti ca fiind greu de realizat în mod practic, pentru că este
imposibil să realizezi perfect o fază a ciclului de viaţă al unui produs software pentru a putea trece
ulterior la următoarea. De exemplu, clienţii nu ştiu întodeauna exact ce au nevoie înainte de a vedea un
prototip funcţionabil al programului. De asemenea, aceştia pot să schimbe în orice moment cerinţele sau
să dorească altceva, astfel încât programatorii şi analiştii nu au control deplin asupra situaţiei, ei
depinzând de client. Dacă schimbăm cerinţele dupa ce am terminat faza de proiectare vom fi nevoiţi să
refacem proiectarea din nou.

Ideea ce stă la baza modelului cascade este „măsoară de doua ori şi taie o dată”. Cei ce se opun
modelului susţin că ideea nu este bună datorită faptului că cerinţele problemei „măsurate” se schimbă
constant datorită modificărilor de cerinţă sau a altor factori.

Principalele critici aduse acestui model sunt :

 multe programe software sunt supuse modificării datorită factorilor externi (ex. clienţi) astfel
încât acestea trebuie sa fie adaptabile nevoilor acestora;
 dacă analiştii şi programatorii nu sunt foarte competenţi este dificil de a ştii exact de ce este
nevoie în fiecare faza de dezvoltare a programelor, fiind necesar feedback de la fazele
superioare pentru a putea rezolva cerinţele de la fazele inferioare;
 este dificil de estimat timpul şi costurile necesare pentru fiecare fază de dezvoltare;
 este o pierdere de resurse de a avea doar personal specializat să rezolve anumite sarcini
legate de exemplu de implementare, care să nu facă nimic în timpul fazei de proiectare.

1. Modelul V
Modelul V este o variantă a modelului cascadă, prin care se introduc conceptele de sistem şi
componente (subsisteme), aplicându-se teste explicite la un sistem ierarhic pentru creşterea controlului

25
asupra modului în care se desfăşoară etapele.
Tocmai această înlesnire constituie o latură a literei V. Prima este latura din stânga, parcursă
descendent, şi conţine treptele propriu-zise, iar cea de-a doua latură, din dreapta, se parcurge ascendent,
pe ea realizându-se verificările şi validările elementelor create anterior. Acest model punctează cu mai
multă claritate separările dintre ceea ce implică participarea utilizatorului, modelul arhitectural şi cel al
implementării. Utilizatorul este implicat doar în fazele din partea superioară a V-ului.
Arhitectura sistemului este surprinsă în partea de mijloc a literei, iar partea inferioară a ei se
referă la faze de implementare, care ar putea consta fie din asamblarea componentelor soft, fie din
codificarea unor componente. Modelul se pretează şi în mediul orientat-obiect, deoarece încurajează
prototipizarea, reutilizarea unor structuri superioare. El oferă un control puternic asupra sistemului în
curs de realizare, prin structurile ierarhice şi modulare pe care le promovează, ceea ce îl face utilizabil şi
în cazul sistemelor complexe. Modelul devine şi mai puternic dacă promovează iteraţia, adică reluarea
unor faze, activităţi sau subactivităţi. De fapt, acesta este stilul adoptat de cei trei autori ai UML -
(Booth, Jacobson şi Rumbaugh), modelul iterativ-incremental, anunţat de anumite performanţe ale
modelului V.
În cadrul acestui model se face, de asemenea, distincţie evidentă între verificare şi validare.
Prima se referă la testarea sistemului, în diverse stadii ale lui, dacă s-a construit corect din punct de
vedere logic, în timp ce validarea va scoate în evidenţă faptul că sistemul, în forma lui finală, răspunde
sau nu cerinţelor iniţiale. Tocmai din această cauză, i se reproşează că lasă validarea prea târziu, după
ce sistemul s-a construit, ceea ce îl face ineficient. În forma lui consacrată, modelul îi aparţine lui Ould,
care îl lansează în 1990, anumite forme fiind folosite şi de Rumbaugh, încă din 1991. El utilizează doar
latura din stânga V-ului, fazele descendente, în care un lot esenţial revine tratării sistemului pe
componente. Cea mai vădită preluare a filosofiei modelului V este regăsită în modelul X (Hodgson).

Definirea cerinţelor Validare

Proiectare sistem Testare sistem

Proiectare subsistem Testare subsistem

Codificare/asamblare componente

Figura 1. Modelul V

2. Modelul incremental
Modelul incremental este o altă variantă a modelului cascadă care promovează ideea proiectării
şi realizării independente a componentelor după definirea arhitecturii globale a sistemelor informatice.
Proiectarea şi realizarea sistemelor informatice (SI) se face astfel în conformitate cu principiile
metodelor top-down. Sistemul va putea fi livrat beneficiarului şi structurat pe etape pe măsura realizării
componentelor (în funcţie de priorităţile formulate de beneficiar) dar, într-o astfel de abordare pot
apărea dificultăţi legate de integrarea componentelor în sistemul final.

26
 Definirea Proiectare Instalare
cerinţelor componentă - 1 componentă - 1

Analiză Implementare Întreţinere

componentă - 1 componentă - 1

Arhitectura … … … …
sistemului
Proiectare Instalare
componentă - n componentă - n

Implementare Întreţinere
componentă - n componentă - n

Figura 2. Modelul incremental

Din figura de mai sus se observă faptul că primele două etape – definirea cerinţelor şi analiza -
sunt identice cu cele două etape de început ale modelului cascadă, însă din momentul definirii
arhitecturii SI fiecare componentă îşi urmează propriul ciclu de viaţă. Spre deosebire de modelul în V
care presupune integrarea componentelor, testarea şi validarea acestuia, de această dată se oferă şi
posibilitatea livrării independente a componentelor SI către beneficiar fără a se exclude şi posibilitatea
livrării SI final având toate componentele integrate. Din descrierea de până acum rezultă câteva dintre
avantajele modelului:
se încadrează în principiul arhicunoscut „divide et impera", prin posibilitatea abordării unor părţi
ale întregului;
sistemul poate fi livrat şi pe componente realizate la perioade scurte de timp;
proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorită
modularizării lui.
Dintre dezavantaje pot fi enumerate:
imposibilitatea aplicării lui în toate cazurile, uneori neexistând elementele necesare
descompunerii întregului;
componentele pot fi realizate numai după ce întregului sistem i se defineşte arhitectura, totul
derulându-se după principiile metodelor top-down, ceea ce înseamnă încă o condiţie dură:
cunoaşterea şi formularea cerinţelor din faza incipientă de abordare a sistemului;
fiind posibil de realizat pe părţi, eforturile de integrare a acestora în întreg sunt destul de mari,
vorbindu-se chiar despre o aşa-zisă testare multiplă de sisteme, cu trimitere la faptul că de fiecare
dată când se adaugă o nouă componentă sistemul poate fi considerat unul nou.

3. Modelul spirală
Modelul spirală este lansat de unul dintre specialiştii cu preocupări mai vechi legate de ciclul de
viaţă, B.W. Boehm. Acesta s-a ocupat de aşa-zisele modele tradiţionale încă din anul 1981, iar în 1986
anunţă modelul spirală şi publică rezultatele cercetării sale în 198837. El se bazează pe două
convingeri:
natura iterativă a dezvoltării şi nevoia de planificare şi evaluare a riscurilor fiecărei iteraţii;
deficienţa înregistrată la modelul V, în care validarea se efectuează prea târziu, îl face să propună,
dimpotrivă, realizarea acesteia cât mai devreme posibil, de cât mai multe ori, prin construirea

27
 prototipurilor, conform modelului simplificat din figura .
Ciclul 1 – Analiza preliminară
1. Obiective, alternative, constrângeri
2. Analiza riscului şi prototipul
3. Conceperea operaţiilor
4. Cerinţele şi planul ciclului de viaţă
5. Obiective, alternative, constrângeri
6. Analiza riscului şi prototipul
Ciclul 2 – Analiza finală
7. Simulare, modele, benchmark-uri
8. Cerinţe software şi validare
9. Plan de dezvoltare
10. Obiective, alternative, constrângeri
11. Analiza riscului şi prototipul
Ciclul 3 – Proiectarea Figura 3. Modelul spirală
12. Simulare, modele, benchmark-uri
13. Proiectarea produsului software, validare şi verificare
14. Integrare şi plan de test
15. Obiective, alternative, constrângeri
16. Analiza riscului şi prototipul operaţional
Ciclul 4 – Implementarea şi testarea
17. Simulare, modele, benchmark-uri
18. Proiectare detaliată
19. Cod
20. Integrarea unităţilor şi testarea acceptării
21. Lansarea produsului

Modelul este îmbunătăţit de R.G. Williams, R.F. Wirfs-Brock iar Ivar Jacobson îl ameliorează,
în 1990, prin modelul spirală ierarhic şi Rumbaugh, în 1992, prin modelul vârtej de apă (whirlpool-
like). În varianta Boehm, echipa de dezvoltare şi utilizatorii se angajează treptat în proiect, diminuând
riscurile la nivel de prototip. De asemenea, de bun augur este valorificarea experienţei anterioare în
planificarea activităţilor din prototipul următor. Facem menţiunea că modelul cascadă se va regăsi în
fiecare iteraţie. Deci după cunoaşterea cerinţelor şi efectuarea studiilor de fezabilitate, se realizează
sistemul, se integrează şi instalează printr-o singură livrare, în varianta modelului cascadă.

Avantaje

Se bazează pe ideea perfecţionării incrementale ale metodologiei secvenţiale

Permite feedback-ul de la fiecare echipă în ceea ce priveşte complexitatea sau corectitudinea
cerinţelor: există etape în care pot fi corectate eventualele greşeli
Clientul poate arunca o privire asupra rezultatului şi poate oferi informaţii importante mai ales în
faza dinaintea lansării produsului
Procesul de dezvoltare se poate adapta mai bine progresului tehnologic: pe măsură ce apar noi
soluţii, ele pot fi încorporate în arhitectura produsului
Recunoaşte că problema principală a dezvoltării programelor este riscul

Exemple de riscuri

În timpul unui proces îndelungat de dezvoltare, cerinţele noi ale clientului sunt ignorate
Clientul schimbă cerinţele
firmă concurentă lansează un program rival pe piaţă
Un dezvoltator/arhitect părăseşte echipa de dezvoltare
echipă nu respectă un termen de livrare pentru o anumită componentă

28
Dezavantaje

Fiecare ciclu produce un efort mai mare de muncă pentru ciclul următor, ceea ce încarcă orarul
planificat şi poate duce la eliminarea unor funcţii sau la o calitate scăzută
Lungimea sau numărul de cicluri poate creşte foarte mult
Scăderea responsabilităţii
Nu există termene limită precise; ciclurile continuă fără o condiţie clară de terminare
Echipa de proiectare nu poate realiza o arhitectură completă
Echipa de implementare poate fi pusă în situaţia nedorită în care arhitectura şi cerinţele sistemului
sunt în permanenţă schimbate

4. Extreme Programming
Extreme Programming = programare extremă
Metodă de programare „agilă”, potrivită dezvoltării rapide de aplicaţii

Figura 4. Modelul XP

Principiile metodelor agile

 Implicarea clientului

29
Clientul trebuie implicat pe tot parcursul procesului de dezvoltare. Rolul său este de a fixa priorităţile,
cerinţele şi de a evalua iteraţiile sistemului
 Livrarea incrementală
Programul este dezvoltat incremental, clientul indicând cerinţele care trebuie incluse la fiecare iteraţie
 Oamenii nu procesul
Abilităţile echipei de dezvoltare trebuie recunoscute şi exploatate. Echipa trebuie lăsată să-şi contureze
propriile modalităţi de lucru, fără a i se da reţete
 Acceptarea schimbării
Echipa trebuie să se aştepte ca cerinţele să se schimbe iar proiectarea sistemului trebuie făcută astfel
încât să se adapteze uşor la aceste schimbări
 Menţinerea simplităţii
Concentrare pe simplitate atât în programele dezvoltate cât şi în procesul de dezvoltare. Oricând este
posibil, trebuie eliminată complexitatea din sistem.
Problemele metodelor agile
 Este dificilă menţinerea interesului clienţilor implicaţi în proces
 Membrii echipei pot fi incapabili să se adapteze la implicarea intensă caracteristică metodelor
agile
 Când există mai mulţi factori de decizie, este dificilă prioritizarea schimbărilor
 Menţinerea simplităţii necesită lucru suplimentar
 Contractele pot fi o problemă în cazul dezvoltării iterative

XP consideră că dezvoltarea programelor nu înseamnă ierarhii, responsabilităţi şi termene limită,

colaborarea oamenilor din care este formată echipa. Aceştia sunt încurajaţi să îşi afirme personalitatea,
să ofere şi să primească cunoştinţe.
XP consideră că dezvoltarea de programe înseamnă în primul rând scrierea de programe, nu
documente, şedinţe şi rapoarte.

Carta drepturilor dezvoltatorului

 Ai dreptul să ştii ceea ce se cere, prin cerinţe clare, cu declaraţii clare de prioritate
 Ai dreptul să spui cât îţi va lua să implementezi fiecare cerinţă, şi să îţi revizuieşti estimările în
funcţie de experienţă
 Ai dreptul să îţi accepţi responsabilităţile, în loc ca acestea să-ţi fie atribuite
 Ai dreptul să faci treabă de calitate în orice moment
 Ai dreptul la linişte, distracţie şi la muncă productivă şi plăcută

Carta drepturilor clientului

 Ai dreptul la un plan general, să ştii ce poate fi făcut, când, şi la ce preţ
 Ai dreptul să vezi progresul într-un sistem care rulează şi care se dovedeşte că funcţionează
trecând teste repetabile pe care le specifici tu
 Ai dreptul să te răzgândeşti, să înlocuieşti funcţionalităţi şi să schimbi priorităţile
 Ai dreptul să fii informat de schimbările în estimări, suficient de devreme pentru a putea reduce
cerinţele astfel ca munca să se termine la data prestabilită. Poţi chiar să te opreşti la un moment
dat şi să rămâi cu un sistem folositor care să reflecte investiţia până la acea dată
 Echipa de dezvoltare nu are o structură ierarhică; fiecare contribuie la proiect folosind maximul
din cunoştinţele sale
 Proiectul este în mintea tuturor programatorilor din echipă, nu în documentaţii, modele sau
rapoarte
 Cerinţele clientului sunt exprimate ca scenarii sau povestiri (“user stories”)
 Acestea sunt scrise pe bileţele iar echipa de dezvoltare le împarte în sarcini de implementare
(care stau la baza planificării orarului de lucru şi a estimării costurilor)
 La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinţelor

30
Caracteristici
 Scrierea de cod este activitatea cea mai importantă
 La fiecare pas se face numai ce este absolut necesar în momentul următor
 Codul se scrie cât mai simplu şi se optimizează (refactoring) de câte ori e posibil
 Se scrie mai întâi cod de test
 Dacă apare necesitatea rescrierii sau eliminării codului, aceasta se face fără milă
 Modificările aduse codului sunt integrate continuu (de câteva ori pe zi)
 Se programează în echipă (programare în perechi); echipele se schimbă la sfârşitul unei iteraţii
(1-2 săptămâni)
 Se lucrează 40 de ore pe săptămână, fără lucru suplimentar

Concluzii
Alegerea unei metodologii de dezvoltare trebuie să ţină seama de natura fiecărui proiect:
Bugetul
Mărimea echipei
Tehnologia utilizată
Instrumentele şi metodele
Termenele limită
Procesele existente deja

MODULUL IV. Modelarea cu UML-urile

Modelare utilizând UML-urile

Noţiunea de UML
Diagrame
Concepte de Modelare
Aprofundarea diagramelor

Concepte de modelare

În această secţiune vom descrie conceptele de bază ale modelării. Mai întâi definim termenii de
sistem şi model si vom discuta despre scopul modelării. Explicăm relaţia lor cu limbajele de
programare şi termeni precum tipuri de date, clase, instanţe şi obiecte. În final, descriem cum
modelarea orientată pe obiect se concentrează pe abstractizarea sistemului in vederea creării modelului
sistemului.

31
 1. Sisteme, Modele şi View-uri

Un sistem este un set organizat de componente care comunică între ele. Ne concentrăm aici pe
ingineria sistemelor care sunt proiectate pentru un scop specific, spre deosebire de sistemele naturale, ca
şi sistemul planetar, al cărui scop final se poate să nu-l cunoaştem. O maşină compusă din patru roţi,
şasiu, un corp şi un motor, este proiectată pentru a transporta persoane. Un ceas compus dintr-o baterie,
un circuit, rotiţe şi manoşe este conceput pentru a măsura timpul. Un sistem de plăţi compus dintr-un
calculator principal, imprimante, discuri, programe şi scheme de state de plată este proiectat pentru a
emite cecurile de salarii pentru angajaţii unei companii. Aşadar părţile unui sistem pot fi considerate
sisteme mai simple, numite subsisteme. Motorul unei maşini, compus din cilindru, pistoane, injectoare
şi multe alte părţi, este un subsistem al masinii. La fel şi circuitele integrate ale unui ceas şi serverul
sistemului de plăţi sunt subsisteme. Obiectele reprezintă finalul acestei recurenţe unde fiecare piesă este
suficient de simplă pentru a o inţelege complet fără alte descompuneri.
Multe sisteme sunt formate din numeroase subsisteme interconectate într-un mod complicat,
deseori atât de complex încât nici un programator nu-l poate dezvolta în totalitate. Modelarea este
metoda de rezolvare a problemelor ridicate de această complexitate. Sistemele complexe sunt în general
descrise prin mai multe modele, fiecare concentrându-se pe un diferit aspect sau nivel al problemei.
Modelarea înseamnă crearea unei abstractizări a unui sistem, concentrându-ne pe aspectele importante
şi ignorând detaliile irelevante. Ceea ce este important sau irelevant depinde de natura problemei de
rezolvat. De exemplu, să presupunem că dorim să construim un avion. Chiar şi cu ajutorul unor experţi
în domeniu nu putem construi de la zero un avion si sa sperăm că va funcţiona chiar de la primul său
zbor. În schimb, vom construi mai întâi un model la scară al avionului pentru a-i testa proprietăţile
aerodinamice. Pentru acest model avem nevoie doar de reprezentarea fuselajului avionului. Putem
ignora detalii precum instrumentele de bord sau motorul. Pentru a instrui pilotul pentru acest nou avion
este necesar de asemenea să construim un simulator de zbor. Simulatorul trebuie să respecte cu
exactitate planul şi comportamentul instrumentelor de zbor. În acest caz detaliile legate de fuselaj pot fi
ignorate. Atât simulatorul cât şi modelul la scară sunt mai puţin complexe decât aparatul de zbor pe care
îl reprezintă. Modelarea ne permite să rezolvăm problema complexitaţii printr-o abordare divide-et-
impera: pentru fiecare tip de problemă pe care vrem să o rezolvăm (de exemplu testarea proprietăţilor
aerodinamice, instruirea pilotului, etc.) construim un model care se concentrează doar pe aspectele
relevante ale problemei. În general modelarea se concentrează pe construirea unui model care este
destul de simplu pentru a fi înţeles în întregime. O regulă de bază este ca fiecare entitate să conţină cel
mult 7 +/- 2 părţi [Miller, 1956].

Modelul la scară

Instalaţia electrică
Totalitatea schiţelor
Combustibil
Avionul

Simulatorul de zbor

Figura 2-6 Un model este o abstractizare ce descrie o submulţime a sistemului. Un view descrie aspectele dorite ale unui
model. View-urile şi modelele unui sistem se pot suprapune unele peste celelalte.

Modelarea ne ajută să rezolvăm problema complexităţii printr-o rafinare în paşi succesivi a

modelelor simple în modele mai detaliate, care sunt mai aproape de realitate. În ingineria soft, ca şi în

32
toate disciplinele inginereşti, modelul precede de obicei sistemul. În timpul analizei mai întâi construim
un model al mediului şi al functionalităţii pe care acest sistem trebuie să o ofere la un nivel la care este
înţeles de client. După aceea rafinăm acest model, adăugând detalii despre forma pe care sistemul
trebuie să o afişeze, modelarea interfeţei utilizatorului şi răspunsul sistemului în cazul excepţiilor.
Mulţimea modelelor construite în timpul dezvoltarii se numeşte modelul sistemului. Dacă nu am
folosi modele ci am incepe cu implementarea sistemului, ar fi necesară specificarea întregii interfeţe cu
utilizatorul înainte de a primi un feedback de la client (fiind posibilă consumarea inutilă de resurse în
cazul apariţiei unor modificări cerute de client).
Din păcate chiar şi un model poate deveni atât de complex încât să fie greu de înţeles. Putem
folosi în continuare metoda divide-et-impera pentru a transforma acest model complex în modele mai
simple. Un view se concentrează pe un subset al unui model pentru a-l face inteligibil (Figura 2-6). De
exemplu toate schiţele necesare construirii unui avion constituie un model. Fragmentele necesare pentru
a explica funcţionarea sistemului de alimentare cu combustibil, constituie view-ul sistemului de
alimentare. View-urile pot fi suprapuse: un view al avionului reprezentând cablarea electrică include şi
cablarea sistemului de alimentare.
Notaţiile sunt reguli grafice sau textuale folosite în reprezentarea view-urilor. O diagrama de
clasă UML este o reprezentare grafic al modelului obiect. În diagramele unei instalaţii electrice fiecare
linie conectata reprezintă un fir sau un mănunchi de fire. În diagrama UML un dreptunghi cu un titlu
reprezintă o clasa. O linie între 2 dreptunghiuri reprezintă o relaţie intre 2 clase corespondente. Pot fi
utilizate diferite notaţii pentru a reprezenta aceleaşi view (Figura 2-7).
În ingineria soft există multe alte notaţii folosite în modelarea sistemelor. UML-ul descrie un
sistem în termeni de clase, evenimente, stări, interacţiuni şi activităţi. Diagramele de fluxuri de date [De
Marco, 1978] descriu modul în care datele sunt extrase, procesate şi stocate.

UML 1
*
Carte Capitol

Booch
N
Carte Capitol

Figura 2-7 Exemplu de descriere a modelului utilizând două tipuri de notaţii. Modelul include două clase, Carte şi Capitol,
cu relaţia O carte este formată din capitole. În UML, clasele sunt reprezentate prin dreptunghiuri iar agregarea printr-o
linie care are la un capăt un romb. În notaţia Booch, clasele sunt reprezentate prin norişori, iar agregarea printr-o linie
terminată cu un cerc plin.

Schemele Z [Spivey, 1989] reprezintă sistemul în termeni de invarianţi (condiţii care nu se

schimbă) şi în termeni de ce este adevărat înainte şi după execuţia unei operaţii. Fiecare notaţie este
concepută pentru probleme diferite.
În secţiunile următoare ne vom concentra asupra mai multor detalii ale procesului de modelare.

2 Tipuri de date, tipuri abstracte de date şi instanţe

Un tip de dată este o abstractizare în contextul unui limbaj de programare. Un tip de dată are un
nume unic care îl deosebeşte de alte tipuri de date. El denotă o mulţime de valori care sunt membre ale
tipului de date (instanţe ale tipului de dată) şi defineşte structura şi operaţiile valide pentru toate
instanţele tipului de dată. Tipurile de date sunt folosite în limbajele tipizate pentru a asigura validitatea
operaţiilor aplicate unor instanţe specifice.
De exemplu numele int în Java corespunde tuturor numerelor întregi cu semn cuprinse în
intervalul -232 si 232-1. Operaţiile valide pentru acest tip sunt toate operaţiile aritmetice întregi (adunare,

33
scădere, înmulţire, împărţire) şi toate funcţiile şi metodele care au parametrii de tip întreg (ex. mod).
Mediul de execuţie Java aruncă o excepţie dacă o operaţie cu virgulă mobilă este aplicată unei instanţe
de tip întreg (exemplu trunc sau floor).
Un tip de dată abstract este un tip de dată specificat independent de implementare. Tipurile
abstracte de date permit programatorilor să folosească aceste mulţimi de instanţe făra a fi necesare
cunostinţe legate de implementarea tipului respectiv. Exemple de tipuri abstracte de date sunt mulţimile,
listele şi tablourile care pot fi definite matematic. Un sistem poate conţine diferite implementări ale unui
tip abstract de date, fiecare fiind optimizat în diferite moduri (pentru consumul redus de memorie,
viteza de adaugare/modificare/stergere, etc), pe când un programator nu are nevoie să cunoască aceste
detalii de implementare ci doar cum să folosească tipul respectiv. De exemplu un tip abstract de date
Persoana poate defini operaţii ca getName(), getSocialSecurityNumber() şi getAdress(). Faptul că numărul
de asigurare socială este stocat sub formă de întreg sau şir de caractere nu este cunoscut de restul
sistemului. Numim aceste aspecte decizii de implementare.

3. Clase, Clase Abstracte şi Obiecte

O clasă este o abstractizare în modelarea orientată obiect sau în limbajele de programare

orientate pe obiect. La fel cu tipurile abstracte de date, o clasă încapsulează atât structura, cât şi
comportamentul. Spre deosebire de tipurile abstracte de date, clasele pot fi definite prin intermediul
altor clase folosind moştenirea. Să presupunem că avem un ceas care poate funcţiona şi ca un
calculator. Clasa CeasulCalculator va putea fi văzută (considerată) ca o rafinare a clasei Ceas.
Acest tip de relaţie între o clasă de bază şi o clasă derivată se numeşte moştenire. Clasa
generală (ex. CeasulCalculator) se numeşte superclasă, iar clasa specializată se numeşte subclasă.
Într-o relaţie de moştenire, subclasa dezvoltă superclasa prin definirea de noi atribute şi operaţii. În
figura 2-8, CeasulCalculator defineşte funcţionalitatea pentru realizarea unor operaţii aritmetice simple
pe care Ceasurile nu le au. Superclasa şi subclasa sunt termeni relativi. Aceeaşi clasă poate fi atât
subclasă pentru o clasă, cât şi superclasă pentru o altă clasă.
Când o relaţie de moştenire serveşte doar pentru modelarea unor atribute şi operaţii comune,
adică, dacă generalizarea nu are drept scop instanţierea, clasa rezultată se numeşte clasă abstractă.
Clasele abstracte reprezintă, adesea, concepte generalizate în domeniul aplicaţiei, iar numele lor sunt
scrise italic. Spre exemplu, în chimie, Benzenul poate fi considerat o clasă de molecule care aparţine
clasei abstracte CompusOrganic (Figura 2-9). CompusOrganic este o generalizare şi nu corespunde nici
unei molecule, cu alte cuvinte, nu are nici o instanţiere. În Java, Collection (Colecţia) este o clasă
abstractă care oferă o generalizare pentru toate clasele colecţie. Cu toate acestea, nu există instanţieri ale
clasei Collection. Mai degrabă, toate obiectele colecţie sunt instanţieri ale unei subclase ale lui
Collection, spre exemplu ListaÎnlănţuită (LinkedList), ListaArray (ArrayList) sau HashMap. De reţinut
este faptul că nu toate generalizările sunt clase abstracte. De exemplu, în Figura 2-8 clasa Ceas nu este
o clasă abstractă deoarece are instanţieri. Când are loc modelarea sistemelor software, uneori clasele
abstracte nu corespund unui concept existent al domeniului aplicaţiei, fiind introduse mai degrabă
pentru a reduce complexitatea în cadrul modelului sau pentru a încuraja reutilizarea.

Ceas
timp
data CeasulCalculator
SeteazăData(d) stareaCalculatorului
IntroduModulCalcul()
NumărIntrare(n)

Figura 2-8 O diagramă de clase UML care prezintă două clase, Ceas şi CeasulCalculator. CeasulCalculator este o rafinare a
clasei Ceas, asigurând funcţionalitatea de calculator care nu se regăseşte, în mod normal, la ceasurile obişnuite. Într-o

34
diagramă de clase UML, clasele şi obiectele sunt reprezentate prin dreptunghiuri având trei compartimente: unul pentru
numele clasei, al doilea pentru atributele aferente, iar ultimul pentru operaţiile sale. Ultimele două pot fi omise pentru
claritate. O relaţie de moştenire este reprezentată cu ajutorul unei săgeţi. Triunghiul săgeţii va arăta spre superclasă, iar
partea opusă spre subclasă.

O clasă defineşte operaţiile care pot fi aplicate instanţierilor sale. Operaţiile unei superclase pot
fi moştenite şi aplicate obiectelor subclasei. De exemplu, în Figura 2-8, operaţia SeteazăData(d), care
setează data curentă pentru Ceas, poate fi aplicată şi CeasuluiCalculator. Operaţia
IntroduModulCalcul(), deşi este definită în clasa CeasulCalculator, nu poate fi aplicată în cadrul clasei
Ceas.
O clasă defineşte atributele care se aplică tuturor instanţierilor sale. Un atribut este o porţiune
în cadrul instanţierii, iar în cadrul ei se stochează o valoare. Atributele au nume unic în cadrul clasei şi
tipului din care fac parte. Ceasurile au un atribut de timp şi dată. CeasurileCalculator au un atribut
denumit StareaCalculatorului.
Un obiect este o instanţiere a unei clase. Un obiect are identitate şi stochează valori ale
atributelor. Fiecare obiect aparţine exact unei singure clase. În UML, o instanţiere este reprezentată
printr-un dreptunghi având numele subliniat.
CompusOrganic

Benzen

Figura 2-9 Un exemplu de clasă abstractă (diagramă de clasă UML). CompusOrganic nu este instanţiat şi foloseşte doar ca
o clasă generalizatoare. Numele claselor abstracte se scriu italic.

Această convenţie se foloseşte în UML pentru a distinge între instanţieri şi tipuri. În figura 2-10,
CeasSimplu1291 este o instanţiere a lui Ceas, iar CeasulCalculator1515 este o instanţiere a
CeasuluiCalculator. Observaţi că deşi operaţiile din Ceas se aplică şi pentru CeasulCalculator1515,
CeasulCalculator1515 nu este o instanţiere a clasei Ceas. Atributele unui obiect pot fi vizibile, în unele
limbaje de programare, şi altor părţi ale sistemului. De exemplu, Java permite implementatorului să
specifice în detaliu care atribute sunt vizibile şi care nu.

<<Instanţiere a>>
CeasSimplu1291:Ceas Ceas

<<Instanţiere a>>
CeasulCalculator1515: CeasulCalculator
CeasulCalculator

Figura 2-10 O diagramă de clasă UML prezentând instanţierile a două clase. CeasSimplu1291 este o instanţiere a lui Ceas.
CeasulCalculator1515 este o instanţiere a CeasuluiCalculator. Chiar dacă operaţiile lui Ceas se aplică şi pentru
CeasulCalculator1515, aceasta din urmă nu este o instanţiere a primeia.

Falsificarea şi Prototipul
Un model este o simplificare a realităţii în sensul că sunt ignorate detaliile irelevante. Cu toate
acestea, detaliile relevante, trebuie să fie reprezentate. Falsificarea [Popper, 1992] este procesul de

35
demonstrare că detaliile relevante au fost reprezentate incorect sau nu au fost deloc reprezentate; adică
modelul nu corespunde realităţii pe care ar trebui să o reprezinte.
Procesul falsificării este foarte bine cunoscut în alte ştiinţe: cercetătorii propun modele diferite
ale realităţii, acceptate gradual pe măsură ce o cantitate semnificativă de informaţie însoţeşte modelul,
respinsă în momentul în care este găsit un contraexemplu. Spre sfârşitul secolului al 18-lea, spre
exemplu, s-a descoperit că orbita planetei Mercur nu se potriveşte exact cu orbita prevăzută de teoria
gravitaţională a lui Newton. Mai târziu, teoria relativităţii a lui Einstein propunea o orbită uşor diferită
care se potrivea mai bine rezultatelor. Cu alte cuvinte, s-a dovedit falsitatea teoriei lui Newton în
favoarea celei a lui Einstein. Reţineţi însă că încă folosim teoria lui Newton pentru aplicaţiile practice
de pe Pământ, deoarece diferenţele previzionate de ambele teorii sunt foarte mici în aceste situaţii, iar
teoria lui Newton este mult mai simplă. Cu alte cuvinte, detaliile ignorate de teoria lui Newton nu sunt
relevante pentru scalele cu care suntem obişnuiţi.
Teoria falsificării poate fi aplicată şi în domeniul dezvoltării soft. De exemplu, o tehnică de
dezvoltare a unui sistem este prototipul: când se proiectează interfaţa cu utilizatorul, dezvoltatorii
proiectează un prototip care doar simulează interfaţa utilizator a unui sistem. Prototipul este apoi
prezentat potenţialilor utilizatori pentru evaluare –adică falsificare –şi modificată succesiv şi
corespunzător. În primele etape ale acestui proces, dezvoltatorii cel mai probabil vor renunţa la
prototipul iniţial ca rezultat al feedback-ului primit de la utilizatori. Cu alte cuvinte, utilizatorii falsifică
prototipul iniţial, deoarece nu prezintă în mod adecvat detaliile relevante.
Observaţi că este posibil de demonstrat doar că un model este incorect. Deşi, în unele cazuri,
este posibil de demonstrat matematic că două modele sunt echivalente, nu este posibil de arătat că unul
dintre ele reprezintă în mod corect realitatea. De exemplu, tehnicile de verificare formale pot să ajute
dezvoltatorii să demonstreze că o implementare soft specifică este consistentă cu o specificare formală.
Cu toate acestea, doar testarea practică şi folosirea îndelungată, pot demonstra că un sistem satisface
nevoile clientului. În orice moment, modelele sistem pot fi falsificate datorită schimbărilor care au loc
referitor la cerinţe, tehnologia implementării sau în cadrul mediului de lucru.

Extensia diagramelor

Scopul designerilor UML a fost de a oferi un set de notaţii pentru a modela clasa mare a
sistemelor de software. De asemenea au recunoscut că un set fix de notaţii ar putea atinge acest ţel,
pentru că e imposibil de anticipat nevoile întâlnite în toate aplicaţiile şi domeniile de soluţii. Din acest
motiv, UML asigură un număr de mecanisme de extensii care permite modelatorului să extindă
limbajul. În această secţiune descriem două asemenea mecanisme stereotipurile şi constrângerile.

Un stereotip este un mecanism de extensie care permite proiectantului să clasifice elemente

model în UML. Un stereotip este reprezentat de un şir între ghilimele (de exemplu “boundar”) ataşat
unui element model căruia i se aplică, ca de exemplu o clasă sau o asociere. În mod normal, ataşând un
stereotip la un element model este echivalentul semantic al creării unei clase noi UML meta-model
(adică, modelul care reprezintă construcţia UML-ului). Aceasta permite proiectantului să creeze noi
tipuri de blocuri de constructii care sunt necesare în domeniul lor. De exemplu în timpul analizei,
clasificăm obiectele in 3 tipuri:
- entitate
- limită
- control
Obiectele entitate, limită si control au aceeaşi structură (adică au atribute, operaţii şi asocieri) dar au
scopuri diferite. Limbajul de bază UML include un singur tip de obiecte. Pentru a reprezenta aceste 3
obiecte folosim stereotipurile “entity”, “boundary” si “control”. Alt exemplu este dat de relaţiile între
use cases. Aceasta include relaţiile în diagramele use cases şi sunt notate cu dashed open arrow şi
stereotipul “include”.

36
 <<entity>> <<control>> <<boundary>>
Year ChangeDateControl Button

<<entity>> <<entity>> <<boundary>>

Year Day LCDDisplay

Exemple de stereotipuri (diagrama de clasa UML)

O constrângere este o regulă ataşată elementului model UML care restrânge semantica. Aceasta
permite să se reprezinte fenomene care nu pot fi exprimate altfel în UML. De exemplu, în figura
următoare, un incident poate fi asociat cu una sau mai multe EmergencyReports din câmp. Totuşi e
important ca dispecerii să poată să vadă raporturile cronologic. Reprezentăm ordinea cronologică a
EmergencyReports la Incident associate cu constrângerea {ordered by time of receipt}. Constrângerile
pot fi exprimate ca un şir informal sau folosind un limbaj ca OCL (Object Constraint Language).

1
EmergencyReport reports Incident

1..*

{ordonata in ordinea primirii}

Exemplu de constrangere (diagrama de clasa UML).

Rădacinile istorice a notaţiilor modelatoare pot fi duse până la analiza structurată (De Marco 1978)
şi designul structurat (Yourdon si Constantine 1975), care se bazează pe descompunerea funcţională.
Aceste metode se bazează pe diagramele de flux de date (De Marco 1978). Diagramele de flux de date
sunt foarte importante pentru inginerii de software care trebuie să menţină tradiţia sistemelor proiectate
cu tehnici de analiză structurată.
UML a rezultat din învăţăturile şi eforturile a mai multor cercetători şi operatori. Eforturile lui
Booch, Jacobson şi Rumbaugh au permis o notaţie unificată şi acceptată în mare. Operele timpurii
(Booch 1994 Jacobson et al., 1992 Rumbaugh et al., 1991) oferă o imagine din interior asupra
rădăcinilor analizei orientată – obiect şi designului şi furnizează informaţii valoroase asupra modelării
orientate – obiect.
Deoarece a fost proiectată să acopere o rază mare de sisteme, UML este un complex standard.

Clasă de evenimente, Evenimente şi Mesaje

Clasele de evenimentele sunt abstractizări care reprezintã un fel de eveniment pentru care
sistemul are un rãspuns normal. Un eveniment, o instanţa a unei clase de evenimente, este un caz
relevant în sistem. De exemplu, un eveniment poate acţiona ca un stimul dintr-un factor(ex., "the
Watchuser apasă butonul din stânga), un time-out(ex., "dupã 2 minute"), sau poate fi transmiterea unui
mesaj între douã obiecte. Trimiterea unui mesaj este un mecanism prin care obiectele trimise cer
executarea unei operaþiuni în obiectul receptor. Mesajul este compus dintr-un nume şi un numãr de
argumente. Obiectul receptor potriveşte numele mesajului cu una dintre operaţiunile sale şi ataşeazã
argumentele operaţiunii respective. Orice rezultate sunt returnate emiţãtorului.

37
 De exemplu, în fig. 2-11 obiectul: Simplewatch calculeazã ora curentã prin extragerea orei din
Greenwich din obiectul: Time şi diferenţele de timp din obiectul: Timezone prin trimiterea mesajelor
getTime() şi getTimeData(). Observaţi ca: SimpleWatch indică un obiect nedesemnat al clasei
SimpleWatch.
Evenimentele şi mesajele sunt instanţe: ele reprezintã cazuri concrete în sistem. Clasele de
evenimente sunt abstractizări ce descriu un grup de evenimente pentru care sistemul are un rãspuns
normal. În practicã, termenul de "eveniment", se poate referi la instanţe sau clase. Această ambiguitate
este rezolvatã prin examinarea contextului în care termenul este folosit.

Modelare Orientată pe Obiect

Domeniul aplicaţiei reprezintã toate aspectele problemei utilizatorului. Aceasta include mediul fizic,
utilizatorii şi alţi oameni, procesul lor de muncã şi aşa mai departe. Este vital pentru analişti şi cei care
dezvoltă sã înşţleagã domeniul aplicaţiei pentru un sistem ca sã poatã îndeplini eficient sarcina dată.
Observaţi faptul că domeniul aplicaţiei se modifică în timp, precum procesele de muncã şi oamenii.
Domeniul soluţiei este spaţiul de modelare al tuturor sistemelor posibile. Modelarea domeniului
soluţiei reprezintã activitãţile legate de design-ul şi obiectul de sistem ale procesului de dezvoltare.
Domeniul de soluţie este mult mai bogat şi mai volatil decât modelul domeniului de aplicaţie. Asta
pentru ca sistemul este de obicei modelat într-un detaliu mai ridicat decât acesta. Apariţia unor noi
tehnologii (declansatori de tehnologie), o înţelegere aprofundată a tehnologiei de implementare de cãtre
cei care dezvolta şi modificãri făcute declanşeazã schimbãri în modelul domeniului de soluţie.
Observaţi ca desfãşurarea sistemelor poate sã schimbe domeniul de aplicaţie pe mãsurã ce utilizatorii
dezvoltă noi procese de muncă pentru a ajusta sistemul.
Analiza orientata pe obiecte se ocupã cu modelarea domeniului de aplicaţie.
Design-ul orientat pe obiecte se referã la modelarea domeniului de soluţie. Ambele activitãţi de
modelare folosesc aceleaşi reprezentãri(i.e, clase şi obiecte). În design-ul şi analiza orientată pe obiecte,
domeniul de aplicaţie este de asemenea o parte din modelul sistem. De exemplu, un sistem de control al
traficului aerian are o clasã Trafficcontroller pentru a reprezenta utilizatorii, preferinţele lor şi
informaţiile de accesare. Sistemul are de asemenea o clasã Aircraft prin care reprezintã informaţia
asociată avionului urmãrit. Trafficcontroller şi Aircraft sunt concepte ale domeniului de aplicaţie care
sunt codificate în sistem.
Figura 2-12 Domeniul de aplicaþie reprezintã entităti ale mediului care sunt relevante unui sistem de
control al traficului aerian. Modelul sistem reprezintã entitãţi care fac parte din sistem. Observaţi că în
design-ul şi analiza orientate pe obiect, modelul domeniului de aplicaţie este o parte a modelului sistem.
Modelul sistem perfectionează modelul domeniului de aplicaţie pentru a include concepte ale
domeniului de soluţie, cum ar fi SumarryDisplay, MapDisplay şi FlightplanDatabase.
Modelarea domeniilor de aplicaþie şi soluţie cu o singurã notaţie are avantaje şi dezavantaje. Pe
de-o parte, poate fi puternică: clasele domeniul de soluţie care reprezintã concepte de aplicaţii pot fi
urmãrite pana la domeniul de aplicaþie. Mai mult decât atât, aceste clase pot fi incapsulate în
subsisteme independente faţă de alte concepte de implementare şi pot fi împachetate într-un toolkit
reutilizabil al claselor de domenii. Pe de altã parte, utilizând o singurã notaţie poate introduce confuzie
pentru ca înlãtură deosebirea dintre lumea realã şi modelul ei. Domeniul sistem este nevoit sã fie mai
simplu şi înclinat cãtre soluţie. Pentru a întâmpina aceastã problemã, folosim o singurã notaţie şi, în
cazuri de ambiguitate, distingem cele douã domenii. În cele mai mult cazuri, ne referim la model.
(ex.:"Un avion este compus dintr-un Manifest şi un Flightplan" este o formulare care se referã la
model).

Diagrama use case

Actorii sunt entitati externe care interactioneaza cu sistemul. Exemple de actori include un rol de user (un
administrator de system, un client al bancii, un casier) sau un alt system (o baza de date centrala, o linie de
fabricatie). Actorii au nume si descrieri unice.

38
Use cases descrie comportamentul sistemului vazut din punctual de vedere al unui actor. Comportamentul
descries de modelul use case mai e numit comportament extern. O diagrama use case descrie o functie furnizata
de system ca un set de evenimente care ofera un rezultat vizibil actorilor. Actorii initiaza o diagrama use case
pentru a accesa functionalitatea sistemului. Use case poate apoi sa initieze alt use case si sa stranga mai multe
informatii de la actori. Cand actorii si diagramele use case schimba informatii, se spune ca comunica. Vom
vedea mai tarziu ca vom reprezenta aceste schimburi cu relatii de comunicare.
De exemplu, in sistemul de management al unui accident, ofiterii de teren, cum ar fi un politist sau un pompier
au acces la un computer wireless care le permite sa comunice cu un dispecer. Dispecerul poate vizualiza
situatia tuturor resurselor, cum ar fi masini ale politiei sau camioane, pe un monitor si sa expedieze o resursa
prin transmiterea comenzilor de la o statie de lucru. In acest exemplu, FieldOfficer si Dispatcher sunt actori.

FRIEND

ReportEmergency

openIncident

AllocateResources

Figura 2-13 descrie actorul FieldOfficer care invoca cazul ReportEmergency pentru a anunta actorul Dispatcher
in privinta unei noi urgente. Ca raspuns, Dispatcher invica cazul OpenIncident pentru a creea un raport al
incidentului si pentru a initia manipularea incidentului. Dispatcher introduce informatii preliminare de la
FieldOfficer in baza de date a incidentului si trimite unitati aditionale la locul incidentului cu cazul
AllocateResources.

Numele use case ReportEmergency

Actori care participa Initiat de FieldOfficer

Comunica cu Dispatcher

Cursul evenimentelor 1. FieldOfficer activeaza functia “Report Emergency” de la terminalul sau.

2. FRIEND raspunde prin a prezenta un formular lui FieldOfficer.
3.FieldOfficer completeaza formularul prin selectarea nivelului urgentei, a
tipului, a locatiei si o scurta descriere a situatiei. FieldOfficer descrie de
asemenea si posibilele raspunsuri la situatia urgentei. Odata ce formularul este
completat, FieldOfficer il submite.

39
 4.FRIEND primeste formularul si il anunta pe Dispatcher.
5. Dispatcher revede informatiile si creeaza un Incident in baza de date prin
invocarea cazului OpenIncident. Dispatcher selecteaza un raspuns si aproba
raportul.
6.FRIEND ii afiseaza lui FieldOfficer aprobarea si raspunsul selectat.

Conditia de intrare FieldOfficer este logat la FRIEND.

Conditia de iesire FieldOfficer a primit aprobarea si raspunsul selectat de la Dispatcher sau

FieldOfficer a primit o indicatie cu privire la motivul din cauza caruia tranzactia
nu a putut fi procesata.

Cerinte Raportul lui FieldOfficer este aprobat in 30 de secunde.

Raspunsul selectat ajunge in mai putin de 30 de secunde dupa ce a fost trimis de
Dispatcher.

Pentru a descrie o diagramă use case, folosim un tabel cu şase câmpuri( vezi Figura 2-14) adaptat
dupa[Constantine şi Lockwood].
 Numele diagramei use case este unic în cadrul sistemului astfel încât proiectanţii(şi participanţii
la proiect) să poata referii diagrama într-un mod clar.
 Actorii participanţi sunt actorii care interacţioneaza cu diagrama use case.
 Condiţiile de intrare descriu condiţiile care trebuie satisfăcute înainte ca diagrama use case să fie
iniţializată.
 Cursul de evenimente descrie segvenţa de interacţiuni ale diagramei use case, care vor fi
numărate pentru referinţă.Cazurile comune(de exemplu cazurile aşteptate de utilizator) şi
cazurile excepţionale(cele care nu sunt aşteptate de utilizator, ca de exemplu erorile şi condiţiile
neobişnuite ) sunt descrise separat în diferite diagrame use case pentru mai multă claritate.
Organizăm paşii în cursul de evenimente în două coloane, coloana stânga reprezintă paşii
îndepliniţi de actori, iar coloana dreaptă reprezintă paşii îndepliniţi de sistem. Fiecare pereche
actor-sistem reprezintă o interacţiune .
 Condiţiile de ieşire descriu condiţiile care sunt satisfăcute după încheierea diagramei use case.
 Cerinţele de calitate sunt cerinţe care nu sunt legate de funcţionalitatea sistemului. Acestea
include constrângeri legate de performanţa sistemului, implementarea sa, platforma hard pe care
rulează, etc. Cerinţele de calitate sunt descrise în detaliu în capitolul 4, Cerinţele Elicitation.
Diagramele use case sunt scrise în limbaj natural. Acest fapt permite proiectanţii să le folosească în
comunicarea cu clienţii şi utilizatorii, care în general nu au cunoştiinţe extinse despre notaţiile
folosite în ingineria soft. Folosirea limbajului natural permite de asemenea participanţilor de la alte
discipline să înţeleagă cerinţele sistemului. Limbajul natural permite proiectanţilor să capteze
lucruri, în special cerinţe, care nu pot fi uşor captate în diagrame.

Scenariile

O diagramă use case este o abstracţie care descrie toate scenariile posibile care implică
funcţionalitate. Un scenariu este o instanţă a unei diagrame use case care descrie un set concret de
acţiuni. Scenariile sunt folosite ca exemple care ilustrează cazuri comune, concentrăndu-se asupra
capacităţii de întelegere. Diagramele use cases sunt folosite pentru a descrie toate cazurile posibile,
concentrându-se asupra complectitudinii. Vom descrie un scenariu folosind un template cu trei
câmpuri:
 Numele scenariului ne permite sa îl referim într-un mod clar. Numele scenariului este
subliniat pentru a indica faptul că este o instanţă.

40
  Instanţele actorilor participanţi indică implicarea actorilor in scenariu. Actorii au au de
asemenea numele subliniat.
 Cursul de evenimente al unui scenariu descrie segvenţele de evenimete pas cu pas.
Observaţi că nu avem nevoie de condiţii de intrare sau ieşire în cadrul scenariilor.
Condiţiile de intrare sau ieşire sunt abstracţii care permit proiectanţilor să descrie o gama
largă de condiţii invocate în diagramele use case. Fiind dat faptul că un scenariu descrie o
situaţie specifică, asemenea condiţii nu sunt necesare(Figura 2-15).
Diagramele use case pot include patru tipuri de relaţii: comunicare, incluziune, întindere şi
moştenire. În continuare vom descrie în detaliu aceste relaţii.

Numele scenariului depozitînflacări

Actorii participanţi bob,alice: poliţisti de teren

john: dispecer

Cursul evenimentelor 1.Bob conducea patrula de poliţie, cănd a observat

faptul că un depozit era în flăcări. Partenera lui,
Alice activează funcţia “Raport de urgenţa” de
pe laptopul ei.
2.Alice introduce adresa clădirii, o scurtă descrie-
re a locaţiei şi un nivel de urgenţă. Pe lânga o
unitate de pompieri, ea mai cere şi căteva uni-
tăţii de paramedici. Ea confirmă cererea şi
aşteaptă o confirmare.
3.John,dispecerul este alertat printr-un beep al
staţiei lui de lucru. Recapitulează informaţiile
trimise de Alice şi confirmă raportul. El alocă
o unităte de pompieri şi două de paramedici la
locul incidentului şi trimite timpul estimat de
sosire(ETA) lui Alice.
4.Alice primeşte confirmarea şi ETA.

Relaţiile de comunicare

Actorii unei diagrame use case comunică pentru a face schimb de informaţii. Relaţiile de comunicare sunt
descrise de o linie boldată între actori şi simbolurile diagramei use case. În figura 2-13, actorii, ofiţerul
comunică prin intermediul raportului de urgenţă. Doar dispecerul prin intermediul reportului incident
deschis şi alocare de resurse. Relaţia de comunicare între actori si diagrama use case se foloseste si pentru a
evidenţia funcţionalitatea. În exemplul nostru , ofiţerul şi dispecerul au acces la diferite interfeţe ale
sistemului şi au funcţionalităţi diferite.

Relaţiile de incluziune

În descrierea unui sistem complex, modelele use case pot conţine unele redundanţe. Minimizăm
complexitatea modelului prin identificarea elementelor comune în diferitele diagrame use case. Să
presupunem că dispecerul poate apasa în orice moment o tastă pentru accesarea unei harţi a străzilor. Acest
lucru poate fi reprezentat printr-o hartă use case care este inclusă în incident deschis şi alocarea

41
resurselor(şi orice alte use cases accesibile dispecerilor). Modelul rezultat descrie doar doar funcţionalitatea
acestei hărţi, reducând complexitatea pe ansamblu a acestui model use case.
Două diagrame use case sunt relatate printr-o relaţie de incluziune, dacă una dintre ele o include pe cea de a
doua. În UML relaţiile de incluziune sunt descrise printr-o sageată întreruptăcare are originea în
incluziunea use case(vezi Figura 2-16). Relaţiile de incluziune sunt etichetate cu eticheta <<include>>.

Figura 2-16 Un exemplu de relatie de includere ( UML – diagrama use case).

Foloseşte căsuţa nume alocă resurse.
Participanţi invitat de expeditor.
Cursul evenimentelor …
Condiţiile intrării expeditorul deschide un eveniment.
Condiţiile ieşirii resursele adiţionale sunt atribuite evenimentului.
Resursele recepţionate anunţă de atribuirea lor.
Ofiţerul superior care se ocupă de primirea evenimentului notează
despre noile resurse.

Condiţiile de bază ale În cursul evenimentelor la fiecare punct , această căsuţă folosită
calităţii poate include căsuţa vederea planului. Această căsuţă vederea planului este
iniţilizată când dispecerul invocă funcţia “plan”.
Când apelul ajunge în această căsuţă, sistemul desfăşoară planul in aşa fel
încât locaţia evenimentului curent este vizibilă expeditorului.

Figura 2- 17 Repretarea textuală de includere a relaţiilor din figura 2-16. “include” boldat pentru
claritate.

Reprezentăm relaţia de includere în această căsuţă însăşi în unul sau două moduri. Daca use
case-ul include poate fi inclus la fiecare punct din următoarele evenimente (ex. Use case-ul vederea
planului), noi indicăm incluziunea secţiunii cererii de calitate în use case ( Figura 2-17 ). Dacă
incluziunea use case este apelată în timpul unui eveniment, indicăm incluziunea în ordinea
evenimentelor.

Realtiile dezvoltate

Relaţiile dezvoltate sunt o cale alternativă pentru a reduce complexitatea în modelul use case.
Un ese case poate extinde un alt use case prin adăugarea de evenimente. O relaţie extinsă indică faptul
că un exemplu de use case extins poate include (în anumite condiţii) un comportament specific al use
case-ului extins. O aplicaţie tipică de relaţie extinsă este specificaţia comportamentului excepţional. De
exemplu (Figura 2-18) presupune ca legaturile reţelei între expeditor şi ofiţerul superior pot fi întrerupte
în orice timp (ex. Dacă ofiţerul superior întră în tunel). Use case-ul conexiune inferioară descrie setul de

42
 evenimente luate de către sistem şi de participanţi în timp ce conexiunea cade. Conexiunea inferioară
extinde use case-ul DeschideEvenimentul şi AlocăResursele. Exceptând comportamentul excepţional
din comportamentul obişnuit ne dă permisiunea să să scriem use case-uri mai scurte şi mai concentrate.
În reprezentarea textuală a use case-ului putem reprezenta relaţii dezvoltate ca şi condiţiile intrării ale
use case-ului extins. De exemplu relaţiile dezvoltate descrise în Figura 2-18 sunt reprezentate ca şi
condiţii de intrare ale use case-ului Conectare Inferioară (Figura 2-19).
Diferenţa dintre relaţiile incluse şi cele dezvoltate este locaţia de dependenţă. Presupunem că
adăugăm câteva noi use case-uri pentru expeditor ca şi ActualizareEveniment şi ResurseRealocate.
Dacă dezvoltăm use case-ul ConexiuneInferioară cu relaţii de includere iniţiatorii use case-ului
evenimentului actualizare şi realocării resurselor trebuie să ştie acestea şi să includă use case-ul
conexiune inferioară. Dacă folosim în locul relaţiilor numai use case-ul conexiunea inferioară trebuie să
fie modificat să dezvolte use case-ul adiţional. În general, cazurile excepţie cât şi ajutorul, erorile şi alte
condiţii neaşteptate sunt dezvoltate cu relaţiile extinse. Use case-urile care descriu comportamentul
obişnuit distribuit de un set limitat de use case-uri sunt dezvoltate cu relaţiile de includere.

Figura 2-18 Un exemplu de o relaţie dezvoltată ( UML - diagrama use case)

Numele use case-ului ConexiuneInferioară

Participanţi comunicări cu ofiţerul superior şi expeditor.
Cursul evenimentelor …
Condiţiile intrării Acest use case dezvoltă evenimentul deschis şi resursele
alocate. Este iniţiată de către sistem oricând conexiunea
legăturii dintre ofiţerul superior şi expeditor cade.
Condiţiile ieşirii …
Figura 2- 19 Reprezentarea textuală a relaţiilor de dezvoltare din figura 2-18. “dezvoltare” boldat
pentru claritate.

Relatiile de mostenire

O relatie de mostenire reprezinta al treilea mecanism pentru reducerea complexitatii unui model.Un caz
folosit particular poate completa un altul general prin adaugarea de mai multe detalii.De exemplu,Ofiterilor
de Camp sa se autentifice inainte sa foloseasca eticheta PRIETEN.Inca din timpul primelor etape ale
cererilor solicitate, autentificarea este conceputa ca un caz de autentificare folosit la nivel inalt.Mai tarziu,
cercetatorii descriu cazul de autentificare folosit in detaliu si permit folosirea mai multor platforme hard
diferite.Aceasta activitate definita se imparte in inca doua cazuri folosite,Autentificarea cu Parola, care da
dreptul Ofiterilor de Camp sa se conecteze fara a folosi o parte hard specificata, si Autentificarea cu Card,
care da dreptul Ofiterior de Camp sa se conecteze folosind un card intelligent.Cele doua cazuri noi folosite
sunt reprezentate ca fiind specializari ale cazului de autentificare folosit(Figura 2-20).In reprezentarea

43
textuala, cazurile specializate folosite mostenesc actorul initiat si intrarea, cat si conditiile de iesire din
cazul general folosit (Figura 2-21).

Observati ca relatiile extinse si relatiile de mostenire sunt diferite.Intr-o relatie extinsa, fiecare caz
folosit descrie un flux diferit de evenimente pentru a indeplini o sarcina diferita.In figura 2-18,
Incidentul de deschidere al cazurilor folosite descriu actiunea, care se petrece cand Dispecerul creeaza
un nou Incident, in timp ce Conexiunea de nivel scazut al cazului folosit descrie actiunile, ce se
intampla.

_____________________________________________________________________

_____________________________________________________________________

Figura 2-20 Un exemplu al unei relatii de mostenire (diagrama UML).Cazul de autentificare folosit
este un caz un caz de nivel ridicat,descriind in termeni generali procesul de autentificare.
Autentificarea cu Parola si Autentificarea cu Card reprezinta doua specializari ale autentificarii.

Numele cazului folosit Autentificarea cu Card

Actorul participant Mostenirea din cazul autentificat folosit

Fluxul evenimentelor
1.Clienta bancii introduce cardul ei in ATM.
2. ATM-ul recunoaste cardul si cere actorului sa
identifice numarul personal de identificare (PIN).
3.Clienta bancii introduce codul ei PIN cu ajutorul
tastaturii.
4.ATM-ul verifica codul PIN introdus cu cel existent
pe card.Daca cele doua PIN-uri se potrivesc, clientul
bancii este autentificat.In caz contrar, ATM-ul respinge
incercarea de autentificare.

Conditia de intrare Mostenirea din cazul autentificat folosit

Conditia de iesire Mostenirea din cazul autentificat folosit

Figura 2-21 Reprezentarea textuala a relatiilor de mostenire a figurii 2-20.Cuvantul "Mostenire" este
scris ingrosat pentru claritate.

44
Figura 2-20, aici Autentificarea cu Parola si Autentificarea cat si Autentificarea cu Card descriu actiuni
ce se petrec in timpul autentificarii, la nivele de abstractie diferite.

Aplicarea cazului folosind digrame

Cazurile folosite si actorii definesc ariile de legatura ale sistemului.Acestea sunt dezvoltate tinand cont
de cererile solicitate, des cu clientul si utilizatorii.De-a lungul analizei cazurile folosite sunt redefinite si
corectate pe masura ce sunt revazute de o audienta specializata, ce include cercetatorii, si validate
impotriva situatiilor reale.

Diagrame de clasă

Clase şi obiecte

Diagramele de clasă descriu structura sistemului în termeni de clase şi obiecte. Clasele sunt
abstracţii care specifică atributele şi comportamentul unui set de obiecte. O clasă este o colecţie de
obiecte care au în comun un set de atribute care disting obiectele ca membri ai colecţiei. Obiectele sunt
entităţi care încapsulează stări şi comportamente. Fiecare obiect are o identitate : poate fi luat individual
şi se distinge faţă de alte obiecte.

In UML, clasele şi obiectele sunt descrise de către (boxes) alcătuite din trei compartimente.
Compartimentul de sus arată numele clasei sau obiectului. Compartimentul median arată atributele şi
compartimentul de jos arată operaţiile. Compartimentele ce arată atributele şi operaţiile pot fi omise
pentru claritate . Numele obiectelor sunt subliniate pentru a indica că ele sunt exemple. Prin convenţie,
numele claselor încep cu literă mare. Obiectele în diagramele obiect pot primi nume (urmate de clasa
lor) pentru a uşura referirea la acestea. In acest caz, numele lor încep cu literă mică. In exemplul
FRIEND (Figura 2-22 şi 2-23), Radu şi Alina sunt ofiţeri de teren , reprezentaţi în sistem ca ofiţeri de
teren obiectele Radu:ofiţer de teren şi Alina: ofiţer de teren . Ofiţer de teren este o clasă care descrie
toate obiectele ofiţeri de teren, unde Radu şi Alina sunt reprezentate de două obiecte individuale ofiţeri
de teren .

1
Raport de urgentă Incident
1..* **
Generare raport * rapoarte *
Incidente generate

1 autor 1 iniţiator
Ofiţer de teren Dispecerat

nume:String nume:String
număr insignă:Integer număr insignă:Integer

Fig. 2-22
Radu:Ofiţer de teren raport 1291 Incident 1515

45
 nume = radu
număr insignă = 132

Alina:Ofţer de teren Ion:Dispecer

nume = Alina Nume = “Ion D.”

număr insignă = 23 Număr insignă = 12

Fig. 2-23

In figura 2.22 clasa ofiţer de teren are două atribute: un nume şi un număr distincte. Acestea
indică că toate obiectele ofiţeri de teren au aceste două atribute. In figura 2.23 obiectele “Radu: ofiţer de
teren” şi Alina: ofiţer de teren au valori specifice pentru următoarele atribute:”Radu.D.” şi respectiv
“Alina.W.” In figura 2.22 atributul câmpului ofiţer de teren.nume este de tipul string(sir), care indică
faptul că doar exemple de “String” pot fi alocate atributului ofiţer de teren.nume. Tipul unui atribut este
folosit pentru a specifica categoria de valori pe care atributul le poate lua. Este de reţinut că atunci când
tipurile atributelor nu sunt esenţiale pentru definirea sistemului deciziile privind tipul atributelor pot fi
amânate până după designul obiectului. Acest lucru lasă programatorul să se concentreze pe
funcţionalitatea sistemului şi să minimizeze numărul schimbărilor minore care intervin când
funcţionalitatea sistemului este corectată.

Asocieri şi legături
O legătură reprezintă o conexiune între două obiecte. Asocierile sunt relaţii între clase şi
reprezintă grupuri de legături. Fiecare obiect ofiţer de teren are , deasemenea o listă de “raporturi de
urgenţă” care a fost scrisă de ofiţer de teren. In figura 2.22 linia dintre clasa ofiţer de teren şi clasa
raport de urgenta este o asociere. In figura 2.23 linia dintre obiectul “Alina: ofiţer de teren” şi obiectul
“raport_1291” este o legătură. Această legătură reprezintă condiţia care este păstrată în sistem pentru a
arăta că “Alina: ofiţer de teren” a generat raport_1291 raport de urgenţă. In UML, asocierile pot fi
simetrice(bidirectionale) sau asimetrice(unidirectionale). Toate asocierile din figura 2.23 sunt simetrice.
Figura 2.24 descrie un exemplu de asociere unidirecţională între Poligon şi Punct. Săgeata
“navigation”către point, arată că sistemul recunoaşte navigarea doar de la Poligon până la Punct.. Cu
alte cuvinte pentru un poligon dat este posibilă interogarea tuturor punctelor care formează poligonul.
Totuşi, săgeată de navigaţie arată că pentru un punct dat, nu este posibil să se afle din care poligon face
parte. UML da voie ca sageţile de navigare sa fie aşezate pe ambele capete ale asocierii. Prin convenţie,
totuşi, o asociere fără sageţi arată că navigarea este posibilă în amandouă direcţiile.

Poligon * * Punct
Fig. 2-24

Asocieri de clase
Asocierile sunt asemănătoare cu clasele, dintr-un anumit punct de vedere: acela că au atribute şi
operaţii ataşate. O asociere de clase este numită ca asociere si este reprezentată de un simbol de clasă
cu o linie ingroşată. Spre exemplu, în figura 2.25 alocarea obiectului ofiţer de teren unui incident este
construită ca o asociere de clase cu atributele “functie” şi “timp de notificare”. Orice asociere de

Repartizări
nume:String
număr insignă:Time Incident
Ofiţer de teren

46
 nume:String Resurse 1
număr insignă:Integer
1...* incident

Fig. 2-25
clase poate fi transformată într-o clasă şi asociere simplă, asa cum arată figura 2.26. Cu toate că această
figură este asemanatoare cu figura 2.25 ,reprezentarea asocierii de clase este mai clară în figura 2.26: o
asociere nu poate să existe fără clasele pe care le leagă. In mod similar, obiectul “repartizari” nu poate
exista fără un ofiţer de teren şi un incident.Cu toate că figura 2.26 are aceleaşi informaţii, această
diagramă necesită o examinare atentă a numărului mare de asocieri.

Roluri
Fiecare sfârşit de asociere poate fi etichetat de un string(rand) numit rol. In figura 2.22, rolurile
asocierii dintre clasele raport de urgenta şi ofiţer de teren sunt autor şi rapoarte generate. Marcând
sfârşitul asocierilor cu roluri permite distingerea multiplelor asocieri care provin dintr-o clasă. Mai
mult, rolurile clarifică scopul asocierii.

1 Repartizări 1
funcţie:String
timp de notificare:Time
Ofiţer de teren Incident 1
nume:String Incident
număr insignă:Integer
1..*resurse

Fig. 2-26

Agregarea

Asocierile sunt folosite pentru a reprezenta o gamă largă de legături între un set de obiecte. In
practică, apare fregvent un caz special de asociere: agregarea. Spre exemplu, un stat are mai multe
judeţe, care la rândul lor au mai multe oraşe. O sectie de poliţie este compusă din poliţişti. Un director
conţine mai multe fişiere. Acest tip de relaţii pot fi construite folosind o asociere one-to-many. Mai
degrabă, UML furnizează conceptual de agregare , denotat de o linie simplă cu un romb către sfarşitul
asocierii(vezi figura2.27) Asocierile şi agregarile una-la-mai multe deşi asemănătoare, nu pot fi folosite
în mod comutabil, agregarile denotă aspecte ierarhice ale legăturilor şi pot avea şi mulţimi one-to many
so many-to many, pe când asocierile one-to-many implică o relaţie pereche.Spre exemplu, în figura
2.27, poliţiştii sunt parte a secţiei de poliţie. In fig.2.22 un ofiţer de teren scrie zero la mai multe
rapoarte de urgenta.

47
 1 * 1 *
Stat Judeţ Oras

1 *
Poliţie Ofiţer de poliţie

Director 1 * Fisier
Fig. 2-27

Multiplicarea

Fiecare sfarşit de asociere poate fi marcat de un set de numere întregi indicând numărul de
legături care pot să aibă originea din instanţa unei clase conectate la sfârşitul asocierii. Acest set de
numere este numit multiplicarea sfârşitului asocierii. In fig.2.22, sfârşitul asocierii are o multiplicare de
1. Asta înseamnă că toate rapoartele de urgenta sunt scrise de exact un ofiţer de teren. Multiplicarea
“many” este stenografiată pentru 0…n. aceasta înseamnă că orice ofiţer de teren poate fi autorul a zero
sau mai multe rapoarte de urgenta. In UML, un sfârşit de asociere poate avea, în mod un set de numere
întregi arbitrar ca multiplicare. Spre exemplu, o asociere poate permite doar un număr prim de legături,
şi aşa am avea o multiplicare 1,2,3,5,7,11,13 şi aşa mai departe. Totusi, în practică,cele mai multe dintre
asocierile pe care le intâlnim aparţin unuia dintre urmatoarele 2 tipuri:
1. Asocierea one-to-one are o multiplicare pentru fiecare sfârşit. O asociere one-to-one între două
clase(ex. Poliţist şi Numar insignă)inseamnă că există exact o legătura între instanţe ale ale
fiecărei clase(ex. Un poliţist are un singur număr de insignă , iar o insignă poate fi doar a unui
poliţist)
2. Asocierea one-to-many. Are o multiplicare de 1 la un final şi 0…..n(de asemenea este
reprezentata de o steluţa)la celalalt. O asociere one-to-many intre doua clase(ex. Pompier şi
maşina de pompieri)denota compoziţia(ex. Un pompier are una sau mai multe maşini , o maşină
aparţine strict unui pompier)
3. Asocierea many-to-many. Are o multiplicare 0…n sau 1 la ambele capete. O asociere
many-to-many între două clase(ex.: ofiţer şi raport) denotă că poate exista un număr arbitrar de
legături între instanţele a două clase(ex.: un ofiţer poate scrie mai multe rapoarte, un raport poate
fi scris de mai multi ofiţeri) Acesta este cel mai complex mod de asociere.

Ofiţer de poliţie 1 1 Număr insignă

Unitate de pompieri 1 * Masină de pompieri

proprietar bun
* *
Ofiţer de teren Proces verbal
autor raport
Fig. 2-28

Adaugărea multiplicării la legatură mareşte cantitatea de informaţii pe care o preluăm de la aplicaţie sau
de la soluţie.Specificarea unei multiplicării a unei asociaţii devine critică când determinăm care sunt
cauzele de care este nevoie pentru a manipula obiectele din aplicaţie. De exemplu , se consideră un
fişier sistem format din Directoare şi Fisiere . Un Director poate conţine orice număr din
FileSystemElements.Un FileSistemElements este un concept care denotă fie un Director fie un Fisier.In
cazul unei ierarhii stricte de sistem,un FileSystemElements face parte dintr-un director ,pe care îl
deducem cu una sau mai multe multiplicării(fig.2-29).
Această discuţie poate părea că ia în considerare probleme în detaliu care pot fi lăsate pe activităţi
ulterioare în procesul de dezvoltare.Diferenţa dintre fişierele ierarhice ale sistemului şi un fişier non

48
ierarhic ,este în funcţionalitatea pe care o oferă.Dacă sistemul permite ca un anumit Fisier să fie parte
din mai multe Directoare ,avem nevoie să definim un caz care descrie cum un user poate adăuga un
Fisier existent la un Director existent.
Mai mult decât atât folosirea cazului pentru a şterge un Fisuer dintru-un Director trebuie specificat fie
că Fisier este şters dintr-un Director fie din toate Directoarele la care se referă .De reţinut e că asocierea
many-to-many poate duce la un sistem substanţial mai complex.

*
FileSystemElement

Director Fisier

Fig. 2-29

* FileSystemElement

*
Director Fisier
Fig. 2-30

Qualification

Qualification este o tehnică pentru reducerea multiplicării folosind chei. Asocierea cu 0…1 sau 1
multiplicat sunt mai uşor de inteles decât asocierea cu 0…n sau 1…n multiplicat.Adesea în cazul uneia
sau mai multor asocieri, obiectele din “multele” părti(feţe) pot fi distinse dintr-un alt nume folosit.De
exemplu,în ierarhia File Sistem(sistemul de fişiere),fiecare fişier aparţine exact unui director .Fiecare
fişier este unic identificat după nume ,in contextul directorului. Multe fişiere pot avea acelasi nume în
contextul sistemului de fişiere ;oricum ,două fişiere nu pot împărţi (avea) acelaşi nume în acelaşi
director.Fără qualification (fig.2-31),asocierea dintre director şi fişier are o multiplicare pe partea
directorului şi de la 0 la mai multe multiplicări pe partea fişierului.Reducem multiplicarea pe partea
fişierului folosind atributul filename (nume fişier) ca şi cheie, dealtfel numit qualifier(fig.2-31).Relaţia
dintre director şi fişier este numită Qualified association (asociere calificată).

Fără calificare
Fisier
1 *
Director
Nume fisier

Cu calificare
1 0..1
Director Fisier
Nume fisier

Fig. 2-31

Reducerea multiplicării este întotdeauna preferată, iar ca model devine variantă ,iar în unele cazuri
trebuie luată în considerare.Programatorii trebuie să examineze fiecare asociere care are una sau mai

49
multe,sau mult mai multe multiplicări ,pentru a vedea dacă un qualifier poate fi adăugat.Adesea ,aceste
asocieri pot fi asociate cu un atribut sau un target de clase(fig.2-31).

Inheritance (succesiune)

Inheritance este relaţia dintre o clasă generală şi una sau mai multe clase specializate.Inheritance
ne permite să descriem toate atributele şi operaţiile care sunt comune unui set de clase. De exemplu, atât
ofiţer de teren cât şi dispecerul au nume şi număr de înregistrare (numar de insigna) ca atribute. Oricum,
ofiţer de teren are o asociere cu raportul de urgenta ,la fel şi dispecerul cu incident. Atributele comune
ale ofiţer de teren şi ale dispecerului pot fi modelate de introducerea clasei ofiter de politie, care este
specializată de clasele ofiţer de teren şi dispecer (fig.2-32). Clasa ofiter de politie generalizată este
numită şi superclass. Clasele ofiţeri de teren şi dispeceri, specializate ,sunt numite şi subclase.
Subclasele inherit ,conţin atributele şi operaţiile din clasele anterioare. Clasele abstracte se disting
de clasele concrete prin italicizing ,numele claselor abstracte.In fig.2-32, ofiterul de politie este o clasă
abstractă. Clasele abstracte sunt folosite în modelarea orientării –obiective pentru clasificarea
conceptelor relatate ,astfel reducând complexitatea totală a modelului.

Ofiţer de poliţie

nume:String
număr insignă:Integer

autor iniţiator
Ofiţer de teren Dispecer
1 1
* raporturi generate * incidente
Raport de urgenţă 1 Incident
1..*
Fig. 2-32

Comportamentul obiectiv este specificat prin operaţii. Un obiect cere executarea unei operaţii
către alt obiect prin trimiterea unui mesaj . Mesajul se potriveşte cu o metodă definită de clasa căreia
obiectul primit aparţine.
Diferenţa dintre operaţii şi metode ne permite să distingem între comportamentul specific şi
implementarea lui. De exemplu ,clasa Incident, în fig.2-33 ,defineşte o operaţie numită repartizare
resurse, care oferă un ofiţer de teren ,creat în asociere cu Incident- primit şi specificul –resurse. Operaţia
repartizare resurse, poate avea şi un efect de faţadă ,cum ar fi trimiterea unei notificări la noa resursă
desemnată. Operaţia de închidere a Incident este responsabilă pentru închiderea aplicaţiei Incident.
Aceasta include trecerea peste toate resursele, care au fost desemnate în Incident ,în timp , şi colectarea
rapoartelor lor. Deasemenea UML ,distinge operaţiile de metode ,în practica programatorii nu fac
această distincţie referindu-se doar la metode.

Incident

Repartizare resurse(r)
Inchide()

50
 Fig. 2.33

Aplicarea Diagramelor de Clasă

Diagramele de clasă sunt folosite pentru descrierea structurii unui sistem.

In timpul analizei , inginerii software ,construiesc clasa diagramelor pentru a formaliza aplicaţia
domeniului de cunoaştere. Clasele reprezintă participarea obiectelor găsite în cazurile folosite şi
interacţiune diagramelor ,şi descriu atributele şi operaţiile lor. Intenţia analizarii modelelor este de a
descrie scopul sistemului si de a-i descoperii limitele .De exemplu folosirea clasei de diagrame
desenată în fig.2-22; un analist poate examina multiplicarea asocierii dintre ofiţer de teren şi raportului
de urgenta ,întreabând userul dacă aceasta este corectă.
Analizarea modelelor nu se poate focaliza pe implementare. Concepte cum sunt interfata,
comunicarea in retea şi posibilitatea de stocare a bazei de date nu sunt reprezentate. Diagramele de clasă
sunt finalizate pe parcursul designului sistemului si obiectului pentru a include clasele care reprezintă
soluţia domeniului. De exemplu, programatorul adaugă clasele care reprezintă baze de date, utilizează
interfaţa Windows , adaptează un cod legal ,optimizări ş.a.m.d. Clasele sunt deasemenea grupate în
subsisteme cu interfeţe bine definite .

Diagrame de activitate

Schimbarile continue intr-o reprezentare statechart sunt stopate prin completarea unei actiuni
asociata cu o stare. Aceaste schimbari reprezinta o actiune de stare. Prin conventie, denumirea de stare
denota o conditie, in timp ce denumirea unei actiuni denota o actiune. Diagramele de activitate sunt
diagrame statechart a caror stari sunt actiuni de stare. Fig. 2-41 reprezinta o diagrama de activitate ce
corespunde cu diagrama de stare din Fig. 2-37. O repezentare alterntiva si echivalenta a unor diagrame
de activitate este interpretarea actinunilor de stare ca un control de flux intre activitati si scimbari.;
astfel, sagetile deschise sunt interpretate ca si constrangeri secventiale contranse intre activitati.

Handle Document Archieve

Incident Incident Incident

Deciziile sunt ramuri in controlul fluxului. Acestea denota scimbari alternative bazate pe o
conditie de stare a unui obiect sau a unui grup de obiecte. Deciziile sunt reprezentate in figura prin
romburi cu una sau mai multe sageti deschise ingoing si doua sau mai multe sageti outgoing. Sagetile
outgoing sunt etichetate cu o conditie care selecteaza o ramura in control flow. Toate tranzitiile care
pleaca de la o decizie reprezinta totalitatea rezultatelor posibile. In fig. 2-42, o decizie aflata dupa
ramura Incident deschis selecteaza una din cele trei ramuri: daca incidentul este de maxima prioritate si
daca este de foc, atunci Pompierul sef este instiintat (selectat). Daca incidentul este de maxima
prioritate si nu este foc, atunci Seful politiei este selectata. In final, daca nici una din aceste conditii nu
este satisfacuta, adica, daca incidentul este de prioritate inferioara, nici un superior nu este instiintat,
selectat si resursa alocata incepe, continua.
Tranzitiile complexe sunt scimbari cu multiple stari sursa sau multiple stari tinta.
Tranzitiile complexe denota sincronizarea a multiple activitati curente (in caz de surse multiple) sau
impartirea fluxului de control in multiple fire (in caz de tinte multiple). De exemplu, in fig. 2-43, starea
de actiune Resurse Alocate, Resurse Coordinatoare si Document Incident, pot aparea in parallel.
Oricum, pot fi doar initiate dupa actiunea Incident Deschis si actiunea Incidentul Activ poate fi initiata
doar dupa ce celelalte activitati au fost indeplinite.

51
 Daca episodul este un foc si este de inalta prioritate,Dispecerul anunta Pompierul Sef.Daca este
episod de inalta prioritate ,dar care nu e foc atunci este anuntat Seful de Politie.In toate cazurile
Dispecerul aloca resursele pentru a se ocupa de episod.
O privire mai amanuntita in UML:

52
 Actiunile pot fi grupate in swimlanes pentru a desemna obiectul sau subsistemul care
implementeaza actiunile.Swimlanes sunt reprezentate ca dreptunghiuri ce inconjoara un grup de
actiuni.Tranzitiile pot traversa swimlanes.In figura 2-44,Dispecerul swimlane grupuri si toate actiunile
care sunt indeplinite de obiectul dispecerului.Ofiterul de teren swimlanes desemneaza ca obiectul
Ofiterul de teren este responsabil de actiunea Documentele episodului.

Aplicand diagrame de activitate

Diagramele de activitate furnizeaza o privire centrala a comportamentului unui set de

obiecte.Ele pot fi folosite,de exemplu,pentru a descrie succesiunea de constrangeri printre cazuri
folosite(use cases),activitati successive printre un grup de obiecte sau sarcinile unui proiect.In aceasta
carte noi folosim diagramele de activitate pentru a descrie activitatile dezvoltarii software in Cap.14
Project Management si Cap.12 Software Life Cycle.

Organizarea diagramelor

Modelele sistemelor complexe devin repede complexe asa cum dezvoltatorul le rafineaza.
Complexitatea modelelor poate fi distribuita prin grupare referitor la elemente in pachete. Un pachet
este un grup de elemente model, la fel ca folosirea proceselor (use cases), claselor, sau activitatilor,
definind scopurile intelegerii.
De exemplu, figura 2-45 descrie folosirea proceselor sistemului Friend, grupat pe actori.
Pachetele sunt reprezentate printr-un dreptunghi care are atasat in coltul din stanga o eticheta. Folosirea
proceselor se leaga de managementul incident (e.g., creare, alocare resurse, documentare) sunt grupate
in pachetul IncidentManagement. Folosirea proceselor se distribuie cu arhiva incident (e.g., arhivarea
unui incident, generarea rapoartelor din incidente arhivate) sunt grupate in pachetul IncidentArhiva.
Folosirea proceselor se distribuie cu sistemul de administratie (e.g., adaugare de utilizatori, inregistrare
si statii) sunt grupate in pachetul SistemAdministrare. Acesta permite clientului si dezvoltatorului sa
organizeze utilizarea proceselor in grupuri legate si fixarea asupra unui set limitat de use cases la un
timp.

53
 IncidentManagement

Raport Urgenta

Dispecer
Ofiter de teren Deschidere Incident

Alocare resurse

IncidentArhiva SistemAdministrare

IncidentArhiva AdministrareUtilizatori
Bibliotecar Sistem
Administrator
CautareArhiva AdministrareTerminale

Figura 2-45 Exemple de pachete: folosirea pachetelor Prieten organizate de actori (UML diagrama de
evaluare)

Figurile 2-46 si 2-47 sunt exemple de diagrame de clase utilizand pachetele.Clasele din
evaluarea Raportului de Urgenta sunt organizate in conformitate cu locul unde obiectele sunt
create.Ofiterul de teren si Raportul de Urgenta sunt parti ale pachetului FieldStation, si Dispecerul si
Incidentul sunt parti ale Dispeceratului. Figura 2-47 arata pachetele cu elementele modelului pe care le
contin, si figura 2-46 arata aceeasi informatie fara continutul fiecarui pachet.Figura 2-46 este o imagine
de nivel inalt a sistemului si poate fi utilizata pentru discutarea cerintelor nivelului system, in timp ce
Figura 2-47 este o imagine mult mai detaliata care poate fi utilizata pentru discutarea contunutului unui
pachet specific.

Managementul
Incidentului
Ofiter de teren Dispecerul

IncidentArhiva SistemAdministrare

54
 Bibliotecar Administrator Sistem

Fig.2-46 Exemplu de pachete.aceasta imagine arata aceleasi pachete ca si fig 2-45 cu exceptia faptului
ca detaliile fiecarui pachet sunt eliminate(diagrama de evaluare UML)

FieldStation Dispecerat
Ofiter de teren Dispecer

Raport de
urgenta Incident

Fig. 2-47 Exemplu de pachete.Clasele Ofiter de teren si Raportul de Urgenta sunt localizate in pachetul
FieldStation, si clasele Dispecer si Incident sunt localizate in pachetul Dispecerat.

Pachetele sunt utilizate pentru confruntarea cu complexitatea in acelasi mod in care un

utilizator organizeaza fisiere si subdirectoare in directoare. Oricum pachetele nu sunt in mod necesar
ierarhice: aceeasi clasa poate aparea in mai mult de un pachet.Pentru a reduce inconsistentele, clasele
(cele mai generale elemente ale modeluilui) sunt detinute de exact un pachet, in timp ce celelalte
pachete sunt pentru a referi modelarea elementului.Notati ca pachetele sunt constructii organizate, nu
obiecte. Ele nu au associate comportamente si nu pot trimite sau primi mesaje.
Nota este un comentariu atasat unei diagrame. Notele sunt utilizate de dezvoltatori pentru
atasarea informatiei modelelor si elementelor modelelor. Acesta este un mecanism ideal pentru
inregistrarea cerintelor importante legate de un model, clarificarea unui punct complex, sau
inregistrarea inversa sau reamintirea. Cu toate ca notele nu au o semantica, ele sunt uneori utilizate
pentru exprimarea constrangerilor care nu pot fi altfel exprimate in UML. Figura 2-48 furnizeaza un
exemplu de nota.

55
 Bibliografie selectivă
[Cockburn,2001] A. Cockburn, Agile Software Development, Addison-Wesley, Reading, MA,
2001.
[Conradi, 1998] R. Conradi, B. Westfechtel, Version models for software configuration
management, ACM Computing Survey, vol.30, no2, June 1998.
[Akram, 2002]Akram I. Salah, Engineering an Academic Program in Software Engineering Mills,
Harlan D., J. R. Newman, and C. B. Engle, Jr., An Undergraduate Curriculum in Software Engineering
[Budgen,2004] David Budgen, Pearl Brereton, Barbara Kitchenham, Stephen Linkman (2004-12-
14). Realizing Evidence-based Software Engineering
[Pecht, 1995] Pecht, Michael (1995). Product Reliability, Maintainability, and Supportability
Handbook.

http://dictionry.laborlawtalk.com/Software_engineering

http://en.wikipedia.org/wiki/History_of_software_engineering

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Software_engineering/Rework#What_is_the_nature_of_SE.3F

http://www.cs.utexas.edu/~sahilt/research/SEMiths.html

„Handbook of Software Engineering and Knowledge Engineering”,

http://www.ksi.edu/seke/hand.html

J.G.Brookshear, "Introducere în informatică"

56