Ingineria produselor

program
(software engineering)
Prelegeri 44 ore
Seminare 30 ore
Laborator 16 ore
examen

Tema 1:Metodologii de proiectare

a produselor program
1. Fazele de proiectare a produselor program(PP).
1.1. Faza de analiz.
1.2. Faza de proiectare.
1.3. Faza de implementare.
1.4. Faza de testare-validare.
2. Metodologii de dezvoltare (MD) a PP.
2.1. MD secvenial.
2.2. MD cascad.
2.3. MD ciclic.
2.4. MD de tip V- Model.
2.5. Metodologia RUP (Rational Unified Process).

Subiectul 1.1.

Faza de analiz. Faza rezid n formularea cerinelor (requirements) fa de

sistemul a fi dezvoltat. Cerinele pot fi formulate att ntr-un limbaj formal,
ct i n limbaj natural.
Rezultatul acestei faze este un document al cerinelor caietul de sarcini.
Caietul de sarcini este un standard oficial.
Caietului de sarcini este un text care definete un set de relaii ntre obiecte,
aciuni, stri, scenarii tipice, scenarii atipice, cerine noi i cele vechi. Relaiile
definite sunt, de obicei, funcionale.
Obiectele reprezint partea static (imuabil)a sistemului. Obiectele sunt
desemnate n textul caietului de substantive. Mulimea acestor nume
formeaz Vocabularul sistemului.
Aciunile reprezint partea dinamic a sistemului a fi dezvoltat. Ele sunt desemnate de verbele textului i definesc funciile sistemului. Numele aciunilor
sunt incluse n Vocabular.
Strile in de obiectele sistemului. Strile denot, depind de domeniul
problemei modelate de sistemul a fi dezvoltat. Evenimentele ce se produc

Subiectul 1
n domeniul problemei declaneaz tranziia obiectelor de la o stare la alta.
n sistem exist stri declarate drept stri iniiale, ct i stri declarate ca fiind
stri finale. Este o vorba de o abordare automatic cu stri finite.
Scenariile tipice sunt iruri de stri care modeleaz tranziia sistemului din
strile iniiale ale sistemului a fi dezvoltat n strile sale finale. Aceast
tranziie declanat de evenimentele din domeniul problemei modeleaz
funciile sistemului. Rezolvarea de ctre sistem a problemelor stipulate de
dezvoltator este nlocuit cu abilitatea utilizatorului de a gestiona scenariile
tipice ale acestui sistem.
Scenariile atipice sunt iruri de stri care modeleaz reacia sistemului la
erori. Aceste scenarii sunt indispensabile pentru meninerea integritii
funcionale a sistemului.
Modificarea cerinelor ine de eliminarea unor cerine deja formulate,
includere unor cerine noi sau modificarea cerinelor vechi. Toate operaiile
enumerate influeneaz integritatea funcional a sistemului.

Subiectul 1.2.

Faza de proiectare. La aceast etap, pe baza cerinelor determinate

n
procesul de analiz a domeniului modelat de sistemul dezvoltat,
este stabilit arhitectura sistemului.
Arhitectura include urmtoarele pri:
1. Componentele, care formeaz structura sistemului. Sunt construite
pe baza cerinelor determinate la faza de analiz.
2. Comportamentul sistemului este reacia la evenimentele produse
att n mediul exterior sistemului, ct i la evenimentele din
interiorul lui.
3. Interfaa gestioneaz evenimentele produse.
Faza de proiectare produce planul de proiectare (implementarea
cerinelor). Planul include urmtoarele pri componente: mediile de
proiectare, platforma, limbajele, structura, interfeele etc.
La aceast faz sunt elaborate i modaliti de gestionare a prioritilor
critice: condiiile cnd sistemul nu funcioneaz corect. Tot aici este
inclus
i analiza performanelor sistemului.

Subiectul 1.3., 1.4.

Faza de implementare. La aceast faz se construiete efectiv

sistemul a fi
dezvoltat pe baza documentelor furnizate de fazele precedente: caietul
de
sarcini, planul de proiectare. n prealabil este instituit planul de
implementare
Echipele de dezvoltare lucreaz conform planului de implementare.
Erorile
care apar n procesul de implementare sunt analizate reieind din tipul
erorilor: erori critice, erori necritice i erori inclasificabile.

Faza de testare. Testarea sistemului dezvoltat se face cu ajutorul

unui
pachet (colecii) de programe testul de regresiune. Testarea se
efectueaz
conform unui plan:
1. Testarea intern - se testeaz fiecare funcie a sistemului.
2. Testarea unitilor se testeaz interaciunea funciilor.
3. Testarea aplicaiei se testeaz sistemul n ntregime.
4. Testarea la stres sistemul este supus unor testri la limit.

Subiectul 2.1.,

Metodologia secvenial. Conform metodologiei secveniale

sistemul se
construiete respectnd ordinea temporal a fazelor. Trecerea
de la faz la
F.
Implem
alta necesit
decizii
centralizate:
Proiect.
Testare
Analiz

Produs
Cerine sistemcascad. Metodologia permite efectuarea
Metodologia
feedback Analiz
ului,
cnd sunt descoperite erori. Trecerea de la o etap la alta se
Proiectare
face astfel:
Codare i depanare
Testare i validare
Mentenan i validare

Subiectul 2.3.,2.4.

Metodologia ciclic. Metodologia este asemntore cu

metodologia
secvenial, dar permite iteraii. Acest lucru permite
optimizarea timpului
rezervat implementrii fiecrei faze. Schematic tranziia de la
faz la alta
Implementar
Testare
analiz
Proiectare
e
poate fi reprezentat astfel:

Produs
Testare
analiz
Metodologia
V Model. Pentru aceast metod este
caracteristic faptul
Testare
Proiectare
c testarea se efectueaz pentru fiecare faz n paralel.
Trecerea la faza
urmtoare seProiectare
face numai dup a fost validatTestare
testarea:

Implementar
e

Subiectul 2.5.

Metodologia RUP (Rational Unified Process). Metodologia a

fost elaborat
de compania Rational Software.
Principiile metodologiei RUP sunt:
1. Dezvoltarea iterativ a produsului.
2. Managementul cerinelor.
3. Arhitectura bazat pe componente.
4. Modelarea vizual.
5. Controlul modificrilor.
Metodologia RUP include:
6. Elaborarea Vocabularului lexical.
7. Determinarea fluxului principal de evenimente.
8. Determinarea fluxului alternativ de evenimente.
9. Proiectarea pre-condiiilor de reacie la evenimente.
10. Proiectarea post-condiiilor de reacie la evenimente.

Tema 2: Modele. Modelarea produselor

program. Limbaje de modelare a
produselor program
1. Conceptul de model al realitii.
2. Model, meta-model, obiecte. Conceptul de multemodelare i descrierea unui obiect complex.
3. Aspecte i niveluri la descrierea produselor
program.
4. Limbajul unificat de modelare a produselor soft
UML. Structura.
5. Conceptele fundamentale ale mediului Enterprise
Architect 7.5.. Realizarea limbajului UML n
mediul EA.

Subiectul 1,2
Modelarea realitii include urmtoarele operaii ale raiunii:
1. Idealizarea fenomenului analizat.
2. Abstractizarea nsuirilor fenomenului analizat.
3. Generalizarea nsuirilor fenomenului analizat.
4. Gndirea intuitiv.
5. Metodele de raionare logica.
Pentru fixa operaiile anunate mai sus se folosete un sistem de notaii
meta
limbaj . Metalimbajul este un meta-model, care permite referirea la operaiile 15.
n metalimbaj sunt definite fenomenele realitii obiectele, nsuirile
obiectelor
proprietile i relaiile ntre obiectele fenomenului. n consecin este creat
modelul
realitii. n meta limbaj pot fi create mai multe modele.
Sunt posibile urmtoarele niveluri de descriere:
6. Meta-meta-modelare.
7. Meta modelare.
8. Modelare.
9. Obiectele realitii.

Subiectul 2,3
Pentru proiectarea produselor program este necesar construirea mai
multor modele.
Multe - modelarea este caracteristic modelrii sistemelor complexe.
Sunt caracteristice urmtoarele modele pentru produsele program:
1. Modelele de utilizare a produsului program: cum este utilizat produsul.
2. Modelele structural a produsului: care sunt entitile domeniului modelat.
3. Modelul comportamental: care sunt funciile produsului i cum sunt
proiectate pe axa temporal.
Exemple. S se creeze un model de utilizare, care ar modela retragerea
banilor de la
un bancomat conform metodologiei RUP.
4. Perfectarea Vocabularului:
o. Abonat persoana care retrage banii din baza unui card.
o. Aplicarea cardului.
o. Introduce PIN.
o. Avanseaz suma.
o. Retrage numerar.
o. Chitana.
o. Retrage cardul.

Subiectul 3

Subiectul 4,5
Exist circa 40 de limbaje de modelare a produselor program. Limbajele sunt
orientate pe modelele enunate mai sus. Fiecare limbaj realizeaz un model.
Limbajul de modelare UML a fost obinut prin reuniunea a trei limbaje de
modelare: Grady Booch, OMT ( Object Modeling Techniques), OOSE (Object
Oriented Software Engineering). Ca rezultat limbajul folosete pentru modela
rea produsului program 3 modele enunate mai sus: modelul cazurilor de
utilizare, modelul structural (static) i modelul comportamental.
Limbajul UML asigur vizualizarea, specificarea, elaborarea i documentarea
produselor program.
Limbajul UML (2.4.1. ) este constituit din fraze lingvistice denumite diagrame.
Matematic, diagramele reprezint nite grafuri. n total sunt 9 tipuri.
Diagramele constau din elemente de modelare: clase, obiecte, relaii de
asociere, dependen, generalizare etc. Diagramele se reunesc n reprezentri
- views.

Subiectul 5

Sunt 5 reprezentri tipice care modeleaz 5 aspecte de realizare a

produselor
program:
1. Reprezentarea logic (Logical view) descrie modelul obiect al produsului.
Ea poate conine diagramele de clase, secveniale, stare, colaborare
2. Reprezentarea proceselor (Process view) descrie interaciunea proceselor
structuri de alocarea a resurselor. Nivelul are un caracter dinamic. n UML
exist un tip dedicat de diagram diagrama activitilor care asigur
reprezentarea.
3. Reprezentarea fizic (Physical view) descrie mediul de execuie a
produsului, adic amplasarea componentelor pe mediul fizic. Amplasarea e
descris de diagrama de desfurare (Deployment).
4. Reprezentarea componentelor (Development view) descrie
componentele produsului soft: pachete (package), biblioteci etc.
Componentele sunt prezentate de diagrama componentelor i de diagrama
pachetelor.
5. Reprezentarea cazurilor de utilizare (Use Case view) descrie interaciunea
produsului cu su mediul extern: funciile produsului la cel mai nalt nivel
de abstractizare. Sunt similitudini aglutinante cu cerinele beneficiarului
fa de produs.

Subiectul 5
Schematic reprezentrile pot fi prezentate astfel:
Logical
View

Process
View

Use
Case
ViewCompone
Physical
nt
View
View

Exemplu: S se proiecteze un sistem informaional care ar

modela nscrierea studenilor la cursuri conform regulilor:
1. Studentul se poate nscrie n primele dou sptmni ale
anului de nvmnt. Anul are doua semestre.
2. Studentul se poate nscrie la cel puin 5 cursuri i cel mult 7.
3. La fiecare curs se pot nscrie cel mult 15 studeni i cel puin
4.

Subiectul 5
4. Cursurile care nu au ntrunit condiiile sunt anulate.
5. Profesorul i alege cursurile pe care le va preda n fiecare
semestru.
6. Operatorul asigur supervizarea sistemului.
7. Cerinele detaliate sunt definite de diagrama Use-Case de pe
slide-ul urmtor.
8.

Subiectul 5

Tema 3: Managementul cerinelor

(requirements) fa de produsul program
proiectat

1. Metodele de identificare i formulare

a cerinelor fa de produs.
2. Clasificarea cerinelor: cerine
funcionale, cerine non-funcionale,
cerinele utilizatorilor.
3. Perfectarea caietului de sarcini
pentru produsul program.
4. Standardul IEEE pentru cerine.

Subiectul 1,2
Definiie 1: Cerinele implic dou componente:
1. Lista serviciilor care sunt oferite de fiecare cerin.
2. Restriciile impuse serviciilor oferite (constraints).
Metodele de identificare a cerinelor fa de produs pot fi reduse la:
3. Interviuri cu utilizatorii poteniali.
4. ntruniri cu prile interesate (stakeholders).
5. Brainstorming, care include o agend precis i documentare ideilor.
6. Reiterarea p. 1-3 se impune ori de cte ori este necesar.
(Detalierea - la lucru individual)

Serviciile oferite sunt clasificate drept:

7. Servicii funcionale, adic serviciile ce descriu: funcii ale produsului,
reacii comportamentale.
8. Servicii non-funcionale, adic securitatea, integritatea, fiabilitatea etc.
Restriciile in de timpul de reacie, stocare, restabilirea informaiei,
transportul de date (protocoale, suporturi fizice), scalabilitate ( numrul
de tranzacii deservite, numrul de utilizatori etc.).
(Detalierea la lucru individual)

Subiectul 3,4

Definiia 2: Caietul de sarcini reprezint un document care

ntrunete descrierea tuturor cerinelor (funciilor) fa de produsul
program a fi elaborat.

Tema 4. Elaborarea modelului cazurilor

de utilizarea (Use Case ) pentru un
produs program
1. Conceptele de actor i scenariu
n modelarea unui produs program.
2. Identificarea cazurilor de utilizare a
unui produs.
3. Reprezentarea cazurilor de utilizare
n limbajul UML. Relaia actor-caz de
utilizare.
4. Elaborarea diagramei cazurilor de
utilizare.

Subiect 1
Diagrama cazurilor de utilizare reprezint un model utilizat
pentru formalizarea i precizarea cerinelor fa de produsul
program. Modelul include trei mulimi:
1. Mulimea actorilor A, care reprezint contextele (mediul ambiant)
externe produsului program.
2. Mulimea cazurilor de utilizare U, care reprezint serviciile
(aciunile) produsului .
3. Mulimea R de relaii definite ntre actori i servicii.
Cazurile de utilizare permit accesul actorilor la serviciile pe care le
regrupeaz pe baz Case: un serviciu la fiecare accesare al
actorului. La
general, diagrama care definete aceste relaii este un graf:
nodurile sunt sau
noduri-actori, sau noduri-caz-de-utilizare, iar arcele sunt relaiile
ntre noduri.
Observaie. Structura intern a nodurilor nu este evocat.
Pe slide-ul urmtor este afiat o diagram Use Case

Subiectul 1

Subiectul 1,2
Actorii sunt numele unor mulimi de roluri. Rolurile modeleaz alegerea unor
cazuri de utilizare concret. Actorii nu ntotdeauna desemneaz utilizatorii. Ei pot
desemna i clase, sisteme, dac ele sunt externe produsului elaborat.
Cazurile de utilizare desemneaz serviciile prestate de ctre produsul program
la
solicitarea mediului extern produsului. Cazurile de utilizare asigur interacionarea
prin intermediul semnalelor i mesajelor.
Cazurile de utilizare (Use Case) sunt reprezentate grafic printr-o elips (vezi
diagrama
anterioar).
Relaiile actor vs caz de utilizare pot fi de urmtoarele tipuri:
1. Relaia de asociere (association relationship) .
2. Relaia de generalizare (generalization relationship).
3. Relaia de includere (include relationship).
4. Relaia de extindere (extend relationship).
. Relaia de asociere are trei nsuiri:
1. Direcie :unidirecional, bidirecional i non-specificat.
2. Nume, care specific individualitatea relaiei.
3. Multiplicitate, care indic numrul de instane asociate. Variante: 1, 0, 1,*, 1 ..*.

Subiectul 3, Exemplu. Asociere cu direcie i multiplicitate.

Subiectul 3

Relaia de generalizare permite construirea de ierarhii

arborescente de actori sau cazuri de utilizare.
Exemplu. Generalizarea cazurilor de utilizare.

Subiectul 3. Exemplu. Generalizarea de actori

Subiectul 3. Relaia de includere face legtura ntre doua

cazuri de utilizare.
Cazul inclus este ncapsulat n cazul de baz (cazul spre care
arat sgeata).
Exemplu. Cazuri de utilizare conectate de relaia include.

Subiectul 3. Relaia de extindere. De obicei, relaia conecteaz

situaiile de comportament excepionale, care sunt complementare
Fluxului de Baz al evenimentelor. Exemplu. Logare nereuit face
parte din Fluxul de extindere.

Subiectul 4. Exemplu. Din elementele prezentate sa se proiecteze o diagram Use Case insernd relaiile potrivite .

Tema 5. Managementul structurii produsului

program. Aspectul static al sistemului soft.

1. Modelul structurii produsului

program: clas, obiect, atribut,
asociere, operaie.
2. Conceptul de clas. Caracterizarea
unei clase. Reprezentarea unei clase
n limbajul UML.
3. Definiia relaiilor ntre clase:
asociere, agregare, compoziie,
dependen, generalizare, realizare.
4. Conceptul de obiect . Instanierea.

Subiectul 1.

Definiie : Obiectul este o entitate prin care putem vorbi despre lumea
(domeniul) a fi modelat. El are identitate, stare i comportament invocabil.
Lumea ( spus i Univers) a fi modelat este tipizat: fiecare obiect are tipul
su.
Tipurile sunt mulimi cu anumite proprieti. Exist o ierarhie a tipurilor.
Definiie : Clas este o descriere a proprietilor, comportamentului i
relaiilor ntre obiectele de un anumit tip ( nu toate proprietile obiectelor
sunt descrise de o anumit clas). Exist o ierarhie a claselor. Clasa are
structur, comportament i relaie
Definiie : Atributul unei clase reprezint informaia deinut de clas.
Definiia : Asocierea este o relaie ntre dou sau mai multe clase.
Definiie : Operaia este un serviciu ce este asigurat de clas. ine de
aspectul comportamental.
Exemple. Clase sunt: PERSOANA, ANGAJAT , STUDENT, CATALOGUL_ AUTO,
CLIENT etc.
Obiecte sunt: < student, nume,Ion Mocanu, 09/01/2015>, <client,
nume,John Ursu, 10/13/2014; vrsta, 25;adresa,Chiinu>.
Atribute sunt: <nume, Ion Mocanu>, <vrsta, 25>,
Operaii sunt: <calculeaz_notaMedie()>

Subiectul 1. Asociere. S se precizeze relaiile diagramei

desennd elementele lips.

Subiectul 2
Clasa are urmtoarele elemente constructive:
1. Nume, care identific clasa. Este scris cu majuscule.
2. Atribute - identific proprietile obiectelor , pe baza crora este
construit clasa.
3. Operaiile definesc aspectul comportamental al obiectelor.
4. Specificatorii vizibilitii atributelor dup cu urmeaz: +
atribut public, - atribut privat, # atribut protejat.
Reprezentarea grafic:
Client
+nume:string
-telefon:int
-adresa: string
#garant:
string
+calcul_suma(
)

Subiectul 2
Sunt trei tipuri de clase:
1. Clase entiti (entity)- stocheaz valorile atributelor clasei.
2. Clase interfa (boundary) asigur legtura ntre actori i
cazurile de utilizarea n modelul Use Case, de exemplu.
3. Clase de control (controller) asigur alegere serviciilor pentru
fiecare caz de utilizare.

Subiectul 3

Definiie : Relaia este o conexiune ntre mai multe clase.

Deoarece clasa este un nume generic pentru mai multe obiecte de
acelai tip, reiese c legtura se extinde peste obiecte.
Exist 4 tipuri de relaii: asociere, dependen, generalizare,
realizare.
Asocierea are nume, rol, vizibilitate, multiplicitate i direcie.
Sunt doua cazuri particulare ale asocierii care au importan:
agregarea i compoziia.
Agregarea permite din mai multe componente extinderea clasei.
Este vorba de relaia part of.
Compoziia a dou sau mai multe clase creeaz o nou clas,
care nu poate exista n aceeai calitate fr aceste pri.
Exemplu.
1. Sala de studii poate exista fr proiector i ecranul de proiectare
agregare.
2. Automobilul fr roi nu are aceeai calitate ca i cel cu roi.
Pe urmtorul slide este prezentate relaiile de mai sus.

Subiectul 3

Exemplu. S se defineasc elementele lips de pe desen astfel ca

desenul s reprezinte o diagram de clase.

Exemplu. S se completeze elementele lips de pe desen

astfel, nct s se obin o diagram de clase reprezentnd o
organigram.

Subiectul 3

Relaia de dependen descriu interdependenele claselor.

Exemplu. Circulaia trenului (deplasarea n timp) depinde de
orarul rutei.
Relaia de generalizare asigur legtura ntre general i
special.
Exemplu. Legtura ntre clasele ANGAJAT i PERSOANA de mai
sus. n acest
caz clasa derivat motenete (inheritance) atributele i
operaiile clasei
generale. Sunt posibile ierarhii de clase .
Relaia de realizare desemneaz relaia de implementare,
cnd o clas este implementat de alte clase.
Implementarea este controlat de clasa a fi implementat.

Exemplul.

Exemplu.

Tema 6. Managementul aspectului

comportamental (dinamic) al unui produs
program.
1. Modelul proiectrii unui produs program:
componentele i regulile de interaciune.
Interaciunea sincron i asincron.
2. Compoziia secvenial a componentelor
sistemului soft. Reprezentarea compoziiei
n limbajul UML: diagrama secvenial.
3. Fragmente combinate i operatori de
interaciune: alt, break, par, critical.
4. Compoziia de comunicare a componentelor
soft. Conceptul de mesaj. Diagrama de
comunicare.

Subiectul 1.

Modelul proiectrii definete nemijlocit etapa proiectrii produsului

program i include:
1. Structura static a produsului, descris anterior de modelul Use-Case
( cazuri de utilizare, actori i relaii) i modelul de domeniu (clase,
obiecte, relaii).
2. Dinamica produsului program, descris de diagramele de
interaciune.
Diagramele de interaciune sunt diagrame bidimensionale: pe vertical
se
depune timpul, iar pe orizontal sunt inserate componentele statice ale
produsului program. Liantul elementului static i al timpului (dinamic)
este
reprezentat de metodele claselor din modelul static al produsului
program.
Diagramele de interaciune sunt de dou tipuri:
3. Diagrame secveniale, care implic nemijlocit timpul ca element al
expunerii.
4. Diagramele de comunicare, care implic mesajele ca factor de
expunere.

Subiectul 1
Diagrama secvenial include urmtoarele elemente: clasele,
obiectele, actorii, mesaje i relaiile.
Clasele, obiectele i relaiile sunt aceleai ca i pentru diagramele
de clase.
Forma general a mesajelor este:
[condiie] aciune (lista de parametri)
Aciunile sunt divizate pe tipuri: call, return, send, create,
destroy etc.
Exemplu. Insert(name), <<destroy>>, type() etc.
Pentru a iniia proiectarea unei diagrame secveniale este necesar:
1. De constituit clasele, pe baza crora vor fi proiectate
diagramele secveniale.
2. De precizat atributele fiecrei clase.
3. De precizat operaiile fiecrei clase.
4. De definit relaiile ntre clase.
5. Vom folosi n scopul proiectrii modelul nregistrarea
studenilor la cursuri.

Subiectul 2. Diagrama secvenial

Exemplu. Diagrama secvenial

Subiectul 2. Diagrama de clase cu relaiile definite

Subiectul 2. Diagrama claselor cu precizarea parial a

atributelor i a operaiilor.

Exemplu. Modelul AutoVanzare. Diagrama claselor.

Subiectul 4.

Diagrama de comunicare - pune accentul pe organizarea

structurala
obiectelor care participla interaciune. Ilustreazmai bine
ramificri complexe, iteraii i comportament concurent.
Poate conine: obiecte, clase, actori; legturi ntre acestea;
mesaje.
Exemple de mesaje
Simple
2: display(x,y)
Subapeluri, inclusiv valoarea de retur
1.3.1: p=find(specs)
Condiionale
4 [x<0]: invert(x,color)
Iteraii
1 *[i=1..n]: update()

Subiectul 4. Exemplu. Diagrama de comunicare