Ingineria produselor program

(software engineering)
Prelegeri – 30 ore
Seminare – 10 ore
Laborator – 20 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 secvențială.
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 cerințelor (requirements) față de
sistemul a fi dezvoltat. Cerințele pot fi formulate atât într-un limbaj formal, cât și în
limbaj natural.
Rezultatul acestei faze este un document al cerințelor – caietul de sarcini.
Caietul de sarcini este un standard oficial.
Caietului de sarcini este un text care definește un set de relații între obiecte,
acțiuni, stări, scenarii tipice, scenarii atipice, cerințe noi și cele vechi. Relațiile
definite sunt, de obicei, funcționale.

Obiectele reprezintă partea statică (imuabilă)a sistemului. Obiectele sunt

desemnate în textul caietului ca substantive. Mulțimea acestor nume
formează Vocabularul sistemului.

Acțiunile reprezintă partea dinamică a sistemului a fi dezvoltat. Ele sunt de-

semnate ca verbe în text și definesc funcțiile sistemului. Numele acțiunilor
sunt incluse, de asemenea, în Vocabular.

Stările țin de obiectele sistemului. Stările denotă contextele, stările de lucruri ale
Universului, în care va funcționa sistemul proiectat.
 Subiectul 1
Evenimentele ce se produc în Universul sistemului declanșează tranziția obiectelor
de la o stare la alta. În sistem există stări declarate drept stări inițiale, cât și stări
declarate ca fiind stări finale. Este vorba de o abordare automatică cu
stări finite.
Scenariile tipice sunt șiruri de stări care modelează tranziția sistemului din
stările inițiale ale sistemului a fi dezvoltat în stările sale finale. Această
tranziție declanșată de evenimentele din domeniul problemei modelează
funcțiile sistemului. Rezolvarea de către sistem a problemelor stipulate de
dezvoltator este înlocuită cu abilitatea utilizatorului de a gestiona
scenariile tipice ale acestui sistem.
Scenariile atipice sunt șiruri de stări care modelează reacția sistemului la
erori. Aceste scenarii sunt indispensabile pentru menținerea integrității
funcționale a sistemului.
Modificarea cerințelor ține de eliminarea unor cerințe deja formulate,
includere unor cerințe noi sau modificarea cerințelor vechi. Toate operațiile
enumerate influențează integritatea funcțională a sistemului.
 Subiectul 1.2.
• Faza de proiectare. La această etapă, pe baza cerințelor determinate în
procesul de analiză a domeniului modelat de sistemul dezvoltat,
este stabilită arhitectura sistemului.
Arhitectura include următoarele părți:
1. Componentele, care formează structura sistemului. Sunt construite pe baza
cerințelor determinate la faza de analiză.
2. Comportamentul sistemului este reacția la evenimentele produse atât în
mediul exterior sistemului - Universul, cât și la evenimentele din interiorul
lui.
3. Interfața gestionează evenimentele produse.
Faza de proiectare produce planul de proiectare (implementarea
cerințelor). Planul include următoarele părți componente: mediile de
proiectare, platforma, limbajele, structura, interfețele etc.
La această fază sunt elaborate și modalități de gestionare a priorităților
critice: condițiile când sistemul nu funcționează corect. Tot aici este inclusă
și analiza performanțelor sistemului.
 Subiectul 1.3., 1.4.
• Faza de implementare. La această fază se construiește efectiv sistemul a fi
dezvoltat pe baza documentelor furnizate de fazele precedente: caietul de
sarcini și planul de proiectare. Faza se încheie cu instituirea planului de
implementare. Echipele de dezvoltare lucrează conform planului de
implementare. Erorile care apar în procesul de implementare sunt analizate
reieșind din tipul erorilor: erori critice, erori necritice și erori inclasificabile.
• Faza de testare. Testarea sistemului dezvoltat se face cu ajutorul unui
pachet (colecții) de programe – testul de regresiune. Testarea se efectuează
conform unui plan:
1. Testarea internă - se testează fiecare funcție a sistemului.
2. Testarea unităților – se testează interacțiunea funcțiilor.
3. Testarea aplicației – se testează sistemul în întregime.
4. Testarea la stres – sistemul este supus unor testări la limită.
 Subiectul 2.1.,
• Metodologia secvențială. Conform metodologiei secvențiale sistemul se
construiește respectând ordinea temporală a fazelor. Trecerea de la o fază la
alta necesită decizii centralizate:

F. Analiză Proiect. Implem. Testare

Produs
• Metodologia cascadă. Metodologia permite efectuarea feedback –ului,
când sunt descoperite erori. Trecerea de la o etapă la alta se face astfel:
Cerințe sistem

Analiză

Proiectare

Codare și depanare

Testare și validare

Mentenanță și validare
 Subiectul 2.3.,2.4.
• Metodologia ciclică. Metodologia este asemănătore cu metodologia
secvențială, dar permite iterații. Acest lucru permite optimizarea timpului
rezervat implementării fiecărei faze. Schematic tranziția de la fază la alta
poate fi reprezentată astfel:

analiză Proiectare Implementare Testare Produs

• Metodologia ‘V – Model’. Pentru această metodă este caracteristic faptul
că testarea se efectuează pentru fiecare fază în paralel. Trecerea la faza
următoare se face numai după a fost validată testarea:

analiză Testare

Proiectare Testare

Proiectare Testare

Implementare
 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 cerințelor.
3. Arhitectura bazată pe componente.
4. Modelarea vizuală.
5. Controlul modificărilor.
Metodologia RUP include:
1. Elaborarea Vocabularului lexical.
2. Determinarea fluxului principal de evenimente pe baza scenariilor tipice.
3. Determinarea fluxului alternativ de evenimente pe baza scenariilor atipice.
4. Proiectarea pre-condițiilor de reacție la evenimente.
5. Proiectarea post-condițiilor de reacție la evenimente.
Tema 2: Modele. Modelarea produselor program.
Limbaje de modelare a produselor program
1. Conceptul de model al realității.
2. Model, meta-model, obiecte. Conceptul de multe-
modelare ș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 realității include următoarele operații ale rațiunii:

1. Idealizarea fenomenului analizat.

2. Abstractizarea însușirilor fenomenului analizat.
3. Generalizarea însușirilor fenomenului analizat.
4. Gândirea intuitivă.
5. Metodele de raționare – logica.

Pentru а fixa operațiile anunțate mai sus se folosește un sistem de

notații – meta limbaj . Metalimbajul este un meta-model, care
permite referirea la operațiile 1-5. În metalimbaj sunt definite
fenomenele realității – obiectele, însușirile obiectelor –
proprietățile și relațiile între obiectele fenomenului.
 Subiectul 2
În consecință este creat modelul realității. În meta limbaj pot fi create
mai multe modele.
Sunt posibile următoarele niveluri de descriere:
1. Meta - meta- modelare (mijloace pentru elaborarea gramaticilor).
2. Meta – modelare (gramatici).
3. Modelare (non-terminale, clase).
4. Obiectele realității (șiruri de terminale).

Pentru proiectarea produselor program este necesară construirea mai

multor modele.
Multe - modelarea este caracteristică modelării sistemelor complexe.
Sunt caracteristice următoarele modele pentru produsele program:
1. Modelele de utilizare a produsului program: cum este utilizat produsul.
2. Modelele structurale ale produsului: care sunt entitățile domeniului
modelat.
3. Modelul comportamental: care sunt funcțiile produsului și cum sunt
proiectate pe axa temporală.
 Subiectul 2,3
Exemple. Să se creeze un model de utilizare, care ar modela
retragerea banilor de la
un bancomat conform metodologiei RUP.
Perfectarea Vocabularului:
o Abonat – persoana care retrage banii pe baza unui card.
o Aplicarea cardului.
o Introducerea PIN.
o Avansarea sumei cerute.
o Retragerea sumei în numerar.
o Chitanța.
o Retragerea cardului.
 Subiectul 3

uc Use Case View

Aplică cardul

Abonat

Introduce PIN

Av ansează suma
Retrage numerar

Chitanța

Retrage Cardul
 Subiectul 4,5
Există circa 40 de limbaje de modelare a produselor program. Limbajele sunt
orientate pe modelele enunțate mai sus. Fiecare limbaj realizează un model.
Limbajul de modelare UML a fost obținut prin reuniunea a trei limbaje de
modelare: Grady Booch, OMT ( Object Modeling Techniques), OOSE (Object
Oriented Software Engineering). Ca rezultat limbajul folosește pentru modela
rea produsului program 3 modele enunțate 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ă niște grafuri. În total sunt 9 tipuri.
Diagramele constau din elemente de modelare: clase, obiecte, relații de
asociere, dependență, generalizare etc. Diagramele se reunesc în reprezentări
- views.
 Subiectul 5
• Sunt 5 reprezentări tipice care modelează 5 aspecte de realizare a produselor
program:
1. Reprezentarea logică (Logical view) descrie modelul – obiect al produsului. Ea
poate conține diagramele de clase, secvențiale, stare, colaborare
2. Reprezentarea proceselor (Process view) descrie interacțiunea proceselor –
structuri de alocarea a resurselor. Nivelul are un caracter dinamic. În UML există un
tip dedicat de diagramă – diagrama activităților care asigură reprezentarea
proceselor.
3. Reprezentarea fizică (Physical view) descrie mediul de existență a produsului,
adică amplasarea componentelor pe mediul fizic. Amplasarea e descrisă de
diagrama de desfășurare (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 interacțiunea
produsului cu mediul său extern: funcțiile produsului la cel mai înalt nivel de
abstractizare. Sunt similitudini aglutinante cu cerințele beneficiarului față de
produs.
 Subiectul 5
• Schematic reprezentările pot fi prezentate astfel:

Logical Process
View View
Use Case
View
Physical Component
View View

• Exemplu: Să se proiecteze un sistem informațional care ar modela

înscrierea studenților la cursuri conform regulilor:
1. Studentul se poate înscrie în primele două săptămâni ale anului de
învățământ. Anul are doua semestre.
2. Studentul se poate înscrie la cel puțin 5 cursuri și cel mult 7.
3. La fiecare curs se pot înscrie cel mult 15 studenți și cel puțin 4.
 Subiectul 5
4. Cursurile care nu au întrunit condițiile sunt anulate.
5. Profesorul își alege cursurile pe care le va preda în fiecare semestru.
6. Operatorul asigură supervizarea sistemului.
7. Cerințele detaliate sunt definite de diagrama Use-Case de pe slide-ul următor.
8. ………………
 Subiectul 5
uc MRegistration

Alege cursurile
predare

Profesor
Catalogul cursurilor

Noteaza studen?ii

Login

Alege cursurile
frecv en?a

Student

Afi?eaza reu?ita Contabilitatea

Informa?ie despre
profesori

Închide înregistrarea

Operator

Informa?ie despre
studen?i
Tema 3: Managementul cerințelor (requirements)
față de produsul program proiectat
1. Metodele de identificare și formulare a
cerințelor față de produs.
2. Clasificarea cerințelor: cerințe funcționale,
cerințe non-funcționale, cerințele
utilizatorilor.
3. Perfectarea caietului de sarcini pentru
produsul program.
4. Standardul IEEE pentru cerințe.
 Subiectul 1,2
• Definiție 1: Cerințele implică două componente:
1. Lista serviciilor care sunt oferite de fiecare cerință.
2. Restricțiile impuse serviciilor oferite (constraints).
Metodele de identificare a cerințelor față de produs pot fi reduse la:
1. Interviuri cu utilizatorii potențiali.
2. Întruniri cu părțile interesate (stakeholders).
3. Brainstorming, care include o agendă precisă cu documentarea ideilor.
4. Reiterarea p. 1-3 se impune ori de câte ori este necesar.
(Detalierea - la lucru individual)

Serviciile oferite sunt clasificate drept:

1. Servicii funcționale, adică serviciile ce descriu: funcții ale produsului, reacții
comportamentale.
2. Servicii non-funcționale, adică securitatea, integritatea, fiabilitatea etc.
Restricțiile țin de timpul de reacție, stocare, restabilirea informației,
transportul de date (protocoale, suporturi fizice), scalaritate ( numărul de
tranzacții deservite, numărul de utilizatori etc.).
(Detalierea – la lucru individual)
 Subiectul 3,4
• Definiția 2: Caietul de sarcini reprezintă un document care întrunește descrierea
tuturor cerințelor (funcțiilor) 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. Relația actor-caz de utilizare.
4. Elaborarea diagramei cazurilor de utilizare.
 Subiect 1
• Diagrama cazurilor de utilizare reprezintă un model utilizat pentru
formalizarea și precizarea cerințelor față de produsul program. Modelul
include trei mulțimi:
1. Mulțimea actorilor A, care reprezintă contextele (mediul ambiant) externe
produsului program.
2. Mulțimea cazurilor de utilizare U, care reprezintă serviciile (acțiunile)
produsului .
3. Mulțimea R de relații definite între actori și servicii.
Cazurile de utilizare permit accesul actorilor la serviciile pe care le
regrupează bază Case: un serviciu la fiecare accesare al actorului. La
general, diagrama care definește aceste relații este un graf: nodurile sunt sau
noduri-actori, sau noduri-caz-de-utilizare, iar arcele sunt relațiile între noduri.
Observație. Structura internă a nodurilor nu este evocată.
Pe slide-ul următor este afișată o diagramă Use Case
 Subiectul 1

uc MBancomat

Relatia (asociere)

Use Case

Actor

Actorul reprezinta Cazul de utilizare este

contextul extern lista-case de servicii
produsului oferite actorului
 Subiectul 1,2
• Actorii sunt numele unor mulțimi 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 către produsul program la
solicitarea mediului extern produsului. Cazurile de utilizare asigură interacționarea
prin intermediul semnalelor și mesajelor.
Cazurile de utilizare (Use Case) sunt reprezentate grafic printr-o elipsă (vezi diagrama
anterioară).
• Relațiile actor caz de utilizare pot fi de următoarele tipuri:
1. Relația de asociere (association relationship) .
2. Relația de generalizare (generalization relationship).
3. Relația de includere (include relationship).
4. Relația de extindere (extend relationship).
• Relația de asociere are trei însușiri:
1. Direcție: unidirecțională, bidirecțională și non-specificată.
2. Nume, care specifică individualitatea relației.
3. Multiplicitate, care indică numărul de instanțe asociate. Variante: 1, 0, 1,*, 1 ..*.
Subiectul 3, Exemplu. Asociere cu direcție și multiplicitate.

uc MRegistration

Alege cursurile
frecv enta
4..5

0..*
Student

0..5 Afișeaza reușita

Subiectul 3 Relația de generalizare permite construirea de ierarhii arborescente de actori sau
cazuri de utilizare.
Exemplu. Generalizarea cazurilor de utilizare.

uc MRegistration

Alege cursurile
predare

Catalogul cursurilor
Subiectul 3. Exemplu. Generalizarea de actori
uc MRegistration

Profesor

Utilizator

Student

Operator
Subiectul 3. Relația de includere face legătura între doua cazuri de utilizare.
Cazul inclus este încapsulat în cazul de bază (cazul spre care arată săgeata).
Exemplu. Cazuri de utilizare conectate de relația “include”.

uc MRegistration

Login Verificarea identității

«include»
 Subiectul 3. Relația de extindere. De obicei, relația conectează situațiile de comportament
excepționale, care sunt complementare Fluxului de Bază al evenimentelor. Exemplu. “Logare
nereușită” face parte din Fluxul de alternativă (extindere).

uc MRegistration

Login Verificarea identității

«include»

«extend»

Logare nereușită
Subiectul 4. Exemplu. Din elementele prezentate sa se proiecteze o diagramă UseCase
inserând relațiile potrivite .
uc Caz

Conditiile Plata

Comandarea Depozit

Informarea Client

Procurarea Marfii

Cumparator
Vanzator

Procurarea Auto Catalogul de marfă

Cumparator Auto

Vanzator Auto
 Tema 5. Managementul structurii produsului
program. Aspectul static al sistemului soft.
1. Modelul structurii produsului program: clasă,
obiect, atribut, asociere, operație.
2. Conceptul de clasă. Caracterizarea unei clase.
Reprezentarea unei clase în limbajul UML.
3. Definiția relațiilor între clase: asociere,
agregare, compoziție, dependență,
generalizare, realizare.
4. Conceptul de obiect . Instanțierea.
 Subiectul 1.
• Definiție : Obiectul este o entitate prin care putem vorbi despre lumea (domeniul) a fi
modelat. Obiectul are identitate, stare și comportament invocabil.
Lumea ( spus și “Univers”) a fi modelată este tipizată: fiecare obiect are (aparține) tipul său.
Tipurile sunt mulțimi cu anumite proprietăți. Există o ierarhie a tipurilor. Tipurile se mai
numesc și clase.
• Definiție : Clasă este o descriere a proprietăților, comportamentului și relațiilor între
obiectele de un anumit tip ( nu toate proprietățile obiectelor sunt descrise de o anumită
clasă). Există o ierarhie a claselor (tipurilor). Clasa are nume, structură, comportament și
relație
• Definiție : Atributul unei clase reprezintă informația deținută de clasă.
• Definiție : Asocierea este o relație între două sau mai multe clase.
• Definiție : Operația (metode) 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; vârsta:25;client.adresa,”Chișinău”>.
Atribute sunt: <nume, “Ion Mocanu”>, <vârsta, 25>,
Operații sunt: <calculează_notaMedie ()>
Subiectul 1. Asociere. Să se precizeze relațiile diagramei desenând elementele
lipsă.
uc MBancomat

Persoana

Angaj at Student

nume v arsta
adresa
 Subiectul 2
• Clasa are următoarele elemente constructive:
1. Nume, care denumește clasa. Este scris cu majuscule.
2. Atribute - identifică proprietățile obiectelor , pe baza cărora este construită clasa.
3. Operațiile – definesc aspectul comportamental al obiectelor.
4. Specificatorii vizibilității 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 entități (entity)- stochează valorile atributelor clasei.
2. Clase interfață (boundary) – asigură legătura î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
• Definiție : Relația este o conexiune între mai multe clase. Deoarece clasa este un
nume generic pentru mai multe obiecte de același tip, reiese că legătura se extinde
peste obiecte.
Există 4 tipuri de relații: asociere, dependență, generalizare, realizare.
• Asocierea are nume, rol, vizibilitate, multiplicitate și direcție.
Sunt doua cazuri particulare ale asocierii care au importanță: agregarea și
compoziția.
Agregarea permite din mai multe componente extinderea clasei. Este vorba de
relația “part of…”.
Compoziția a două sau mai multe clase creează o nouă clasă, care nu poate exista
în aceeași calitate fără aceste părți.
Exemplu.
1. Sala de studii poate exista fără proiector și ecranul de proiectare – agregare.
2. Automobilul fără roți nu are aceeași calitate ca și cel cu roți.

Pe următorul slide sunt prezentate relațiile de mai sus.

 Subiectul 3
class Logical View

Class1 Class2
+Rol11 Asociatie +Rol12
bidirectionala Class13 Class14
0..1 * Generalizare
- first: int

Class3 Class4
Unidirectionala

Class5 Class6
Agregare

Class8
Class7
Compozitia

Class9 Class10
Dependenta

Class11 Class12
Realizare
Exemplu. Să se definească elementele lipsă de pe desen astfel ca desenul să
reprezinte o diagramă de clase.

uc Caz

Proiect

Baza de Date

Inginer Proiectant

Tipurile de
Proiecte

Proiecte Rezerv ă

Proiecte
Gestionate
Exemplu. Să se completeze elementele lipsă de pe desen astfel, încât să se
obțină o diagramă de clase reprezentând o organigramă.

uc Caz

Persoană
Postul ocupat

Resurse umane

Companie Departament

Legislație
Contabilitate
 Subiectul 3
• Relația de dependență descriu interdependențele claselor.
Exemplu. Circulația trenului (deplasarea în timp) depinde de orarul rutei.
• Relația de generalizare asigură legătura între general și special.
Exemplu. Legătura între clasele ANGAJAT și PERSOANA de mai sus. În acest
caz clasa derivată moștenește (inheritance) atributele și operațiile clasei
generale. Sunt posibile ierarhii de clase .
• Relația de realizare desemnează relația de implementare, când o clasă
este implementată de alte clase. Implementarea este controlată de clasa a
fi implementată.
 Exemplul.
uc UCpack

Ev identa Clientilor Ev identa Auto

Comercializate

Vanzator

Client

Ev identa Angaj atilor Ev identa Deserv irii

Clientilor

Angaj at

Administrator
Firmei Asigurarea relatiei Asigurarea relatiei
Client-Firma Vanzare-Procurare

Operator
 Exemplu.

class Logical View

«entity» Ev identa Auto

Ev identa Clientilor Comercializate

«boundary»
Relatia
Vanzare-Procurare
«entity»
Ev identa Ev identa
Angaj atilor Angaj atilor

«control»
Relatia
Client-Vanzare-Procurare
«boundary»
«entity» Relatia
Ev identa
Client-Firma
Deserv irii Clintilor
 Anexa 1 Agregare

• Exemplul 1. Agregare.
Anexa 2. Compoziție
 Anexa 3. Asocieri

• Exemplul. Să se indice multiplicitatea și tipul relației.

Student Courses

Player Team

School Department
Departament

Teacher Departament
 Anexa 4. Asocieri
• Exemplu. Să se realizeze pe diagrame următoarele afirmații:
a) O facultate are mai mulți profesori, iar un profesor predă la mai multe
facultăți. Sunt profesori care predau la câteva universități.
b) Un student poate studia la mai multe facultăți. Studentul poate studia la
secția zi sau la secția cu frecvență redusă.
c) Un student poate frecventa mai multe cursuri și un curs poate fi frecventat de
mai mulți studenți. Un student poate avea cursuri la mai multe universități.
d) Compania are câteva sucursale, iar fiecare departament aparține sau
companiei sau sucursalei acestei companii.
e) Un calculator are două procesoare, două monitoare, memorie RAM și
memorie hard, iar imprimanta este partajată cu încă 3 calculatoare similare.
f) O echipă are 18 jucători, inclusiv un căpitan și un goal-keeper. Unii jucători
din lotul de bază pot aparține și lotului de juniori.
g) Un profesor poate preda cursuri la mai multe facultăți, aparținând unor
universități sau academii diferite.
h) O universitate are cel puțin 4 facultăți , 6 departamente, o contabilitate și o
secție cadre și poate partaja cantina cu alte universități.
 Tema 6. Managementul aspectului comportamental
(dinamic) al unui produs program.
1. Modelul proiectării unui produs program:
componentele și regulile de interacțiune.
Interacțiunea sincronă și asincronă.
2. Compoziția secvențială a componentelor sistemului
soft. Reprezentarea compoziției în limbajul UML:
diagrama secvențială.
3. Fragmente combinate și operatori de interacțiune:
alt, break, par, critical.
4. Compoziția de comunicare a componentelor soft.
Conceptul de mesaj. Diagrama de comunicare.
 Subiectul 1.
• Modelul proiectării definește nemijlocit etapa proiectării produsului
program și include:
1. Structura statică a produsului, descrisă anterior de modelul Use-Case (
cazuri de utilizare, actori și relații) și modelul de domeniu (clase, obiecte,
relații).
2. Dinamica produsului program, descrisă de diagramele de interacțiune.
Diagramele de interacțiune 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 interacțiune sunt de două tipuri:
1. Diagrame secvențiale, care implică nemijlocit timpul ca element al
expunerii.
2. Diagramele de comunicare, care implică mesajele ca factor de expunere.
 Subiectul 1
• Diagrama secvențială include următoarele elemente: clasele, obiectele,
actorii, mesaje și relațiile.
Clasele, obiectele și relațiile sunt aceleași ca și pentru diagramele de clase.
Forma generală a mesajelor este:
[condiție] acțiune (lista de parametri)
Acțiunile sunt divizate pe tipuri: call, return, send, create, destroy etc.
Exemplu. Insert(name), <<destroy>>, type() etc.
Pentru a iniția proiectarea unei diagrame secvențiale este necesar:
1. De constituit clasele, pe baza cărora vor fi proiectate diagramele
secvențiale.
2. De precizat atributele fiecărei clase.
3. De precizat operațiile fiecărei clase.
4. De definit relațiile între clase.
5. Vom folosi în scopul proiectării modelul “Înregistrarea studenților la
cursuri.
Exemplu. Modelul “VanzareAuto”. Diagrama claselor.

class AutoVanzare

«boundary» «control» «entity»

ProcurareForm ProcurareControl CatalogAuto

«entity»
«entity»
Tranzactie Client
 Subiectul 2. Diagrama de clase cu relațiile definite
class VOPClase

«boundary» «boundary»
FormularR CatalogCurs

1
«entity» «entity»
«control» +Cursuri de Baza
0..* GraficStudent CursSem
ControlR
0..4

«entity»
StudentR
Subiectul 2. Diagrama claselor cu precizarea parțială a atributelor și a
operațiilor.
class VOPClase

«boundary» «boundary»
FormularR CatalogCurs

+ anuleaza_grafic() : void # get_curs() : void

+ creeaza_grafic() : void
+ inregistrare_curs() : void
+ modificare_grafic() : void

1
1 0..*
«entity» «entity»
«control»
GraficStudent +Cursuri de Baza CursSem
ControlR
- semestru: int
0..4 - num_stud: int
# creeaza_graficsem() : void
# creeaza_curssem() : void # adauga_student() : void

«entity»
StudentR

- nume: byte
- studentID: int

+ adauga_grafic() : void
 Subiectul 2. Diagrama secvențială

sd Inregistrarea

«boundary» «control»
FormularR ControlR
Student

1.0 inregistrare_curs()

1.1 accept inregistrare?()

1.2 [accept inregistrarea]: afiseaza

operatiile()

1.3 creeaza grafic()

Trei fluxuri exclusive

1.4 modifica grafic()

1.5 anuleaza grafic()

Crearea grafic;modificare
grafic;anuleaza grafic
 Exemplu. Diagrama secvențială
sd InregCreare

«boundary» «control» «boundary» «entity» «ent...

RegisterForm RegisterControl CatalogCourse StudentSchedule StudentR
Student Catalog_Curs

1.0 creeaza_grafic()

1.1 obtine_cursurile()

1.2 cursuri_semestru()

1.3 obtine_curs()

1.4
afiseaza_cursuri()

1.5
afiseaz_graf_vid()

1.6 select_curs()

1.7
creeaza_gr_sem()

1.8
creeaza_graf()

1.9 ad_gr_student()
 Subiectul 4.
• Diagrama de comunicare - pune accentul pe organizarea structurală
obiectelor care participă la interacțiune. Ilustrează mai bine ramificările
complexe, iterații și comportament concurent.
Poate conține: obiecte, clase, actori; legături între acestea; mesaje.
Exemple de mesaje
• Simple
• 2: display(x,y)
• Subapeluri, inclusiv valoarea de retur
• 1.3.1: p=find(specs)
• Condiționale
• 4 [x<0]: invert(x,color)
• Iterații
• 1 *[i=1..n]: update()
 Subiectul 4. Exemplu. Diagrama de comunicare

sd Design Model

1: inregistrare_curs() «boundary» 1.1: accept_inregistrare()

/ «control»
:RegisterForm RegisterControl
1.3: creeaza_grafic() 1.2: afiseaza_grafic()
Student 1.4: modifica_grafic()
1.5: anuleaza_grafic()
 Tema 7. Modelarea funcționalității unui sistem
soft
1. Componența modelului: activitate, stare, tranziție, obiecte,
sincronizare, ramificare.
2. Elaborarea grafului de activități al produsului program.
Reprezentarea grafului de activități în limbajul UML:
diagrama de activități. Conceptul “swimlanes”.
3. Modelarea comportamentului unei componente a
produsului program. Conceptele: eveniment, semnal,
acțiune, stare, tranziție.
4. Elaborarea grafului de tranziții al componentei soft.
Reprezentarea grafului în limbajul UML: diagrama de stări.
 Subiectul 1.

• Graful diagramei de activități modelează executarea operațiilor unor

clase din modelul claselor al unui produs program reprezentat în UML de
diagrama claselor.
Nodurile grafului de activități reprezintă stările de activitate, iar arcele
modelează tranzițiile dintr-o stare în alta.
În limbajul UML graful de activități este reprezentat sub forma unei diagrame
de activități.
Diagrama de activități constă din: stări - activitate (activity states) , stări –
acțiune ( action states), tranziții, obiecte, bare de sincronizare și ramificații.
Stările – acțiune sunt atomice (nu pot fi descompuse) și modelează obținerea
unui rezultat (calcularea unei expresii etc.)
Stările – activitate implică o detaliere printr-o diagramă de alt nivel.
Tranzițiile reprezintă relații de precedență temporală între două activități
(acțiuni) .
 Subiectul 1.
Exemplu. Fie date două activități : înregistrare_curs(), accept_înregistrare().
Diagrama de activități va fi:

I(înregistrare_curs() I(accept_înregistrare()

accept_înregistrare()
da
I(creecreează grafic()

……
 Subiectul 2. Exemplu. Diagrama de activități

act Design Model

Achitarea_facturiii

Inceput

Verifica Sfarsit
Contul? Respinge Plata

ActivityFinal

Contul Permite

Autorizarea Platii
 Subiect 2. Diagrama de activități.
act Design M odel

Inceput

AlegeServ iciul

PreiaComanda

ProceseazaComanda

AchitaContul

ComandaProcesata

ComandaVerificata

AsiguraLiv rarea
PreiaM arfa

Sfarsi t
 Subiectul 2. Diagrama de activități. “Swimlanes”.
act Design M odel

Cl i ent Vanzator Depozi t

Inceput

AlegeServ iciul

PreiaComanda

ProceseazaComanda

AchitaContul

ComandaProcesata

ComandaVerificata

AsiguraLiv rarea
PreiaM arfa

Sfarsi t
 Subiectul 3.
• Diagrama de stări este folosită pentru a modela comportamentul unui
singur obiect.
• Elementele unei diagrame de stări sunt: evenimentele, stările, acțiunile,
tranzițiile.
1. Evenimentele.
1.1. Evenimentele sunt entități atomice, care nu au durată în timp.
1.2. Evenimentele desemnează niște schimbări ce se produc în lumea
reală sau în fragmentele ei deja modelate.
1.3. Evenimentele au nume, care referă aceste schimbări.
Evenimentele pot fi clasificate:
1. În raport cu alte evenimente: sincrone – asincrone.
2. În raport cu contextul: interne sistemului –externe sistemului.
3. În raport cu obiectele:
a) semnale (signal event)- produse de un obiect și recepționate de
altul (asincron).
b) apelări de operații (call event) – un obiect cere executarea unei
operații aparținând altui obiect (sincron).
c) așteptarea scurgerii unui interval de timp (time event).
d) fixarea schimbării valorilor de true și false (change event).
 Subiectul 3.
Starea este o situație în timp a unui obiect care: efectuează o acțiune;
așteaptă producerea unui eveniment, satisface unor condiții impuse din
exterior. Sunt două stări cu o destinație specială: starea inițială –
începutul modelării și starea finală – sfârșitul modelării.
Grafic stările se reprezintă astfel:

a) nume - stare

b) - starea inițială

c) - starea finală

Stările au nume, acțiuni de intrare/ieșire (entry/ exit), elemente

compoziționale (include).
 Subiectul 3.
• Stare cu două sub-stări concurente, simultan active:

S1 S S2

• Stare cu două sub-stări disjuncte, secvențial active:

S1 S S2
 Subiect 3.
• Forma generală a unei stări este:
Nume
• Entry/expresie acțiune
tranziții interne
Exit/expresie acțiune
Do/activitate
Include/diagrama sub-stări

• Forma generală a unei tranziții interne:

1. nume_eveniment(lista parametri)[ condiție]/acțiune.
2. Entry și Exit nu au evenimente.
3. Do desemnează activitatea.
4. Include arată prezența sub-stărilor.

• Exemplu de stare completă.

 Subiectul 3.
• Stare cu elemente:

Interfata
itemSelected()/highlightitem()
Entry/ displayitem()
Exit/hideitem()
Do/playSoundClip()

• Tranziția externă: eveniment (lista parametrilor)[condiție]/acțiune

S1 S2
 Subiect 3. Exemplu. Diagrama UML de stare

stm Design Model

Start

Start Adaugare
digit(n) [numar.corect()]
+ entry / start in + entry / numadauga(string)
Initial + exit / stop out Final Final
Initial

digit(n)
 Subiectul 4. Exemplu de diagramă de stare
stm Design Model

Initial

Initialization

+ exit / CourseRoster.create
+ do / initialyze

add_student/count=0

Open Close
[count=15]
+ exit / CourseRoster.addStudent(student)
+ entry / Register Student

cancel cancel

add_student [count<15]
Cancel
Final
+ exit / CourseRoster.delete
 Subiectul 4. Diagrama de stare
stm Design Model

Proiect propus Proiect neales renunta[nr_stud] / nr_stud

aprob/nr_stud=0

Initial

alege/nr_stud++
respinge respinge
sterge
Proiect ales

Proiect respins
proiect sters
sterge

alege[nr_stud==3]/nr_stud++
Final sterge

Proiect adjudecat

Final
 Anexa 5. Etapele proiectării unui sistem informatic (abordarea RUP)
• I etapă: Formularea I-a etapă . Formularea problemei
problemei.
Conținutul: Prezentarea cerințelor (requirements) față de sistemul
Prezentarea
proiectat. cerințelor (requirements) față de sistem. Expunere verbală
Remarcă: Expunerea II-a verbală.
etapă. Perfectarea vocabularului

Reprezentarea conceptuală a domeniului aplicativ (DA). Vezi Tabel –Vocabular.

Specificații nefuncționale: fiabilitate, fezabilitate, sustenabilitate,productivitate
Restricționări: . . . . . . .

III-a etapă. Proiectarea modelului UseCase.

Vezi Tabel-UseCase

IV-a etapă. Definirea fluxurilor de bază (FBE) și alternativ (FAE) ale

evenimentelor
Vezi Tabel-FBE/FAE, cazurile: Logare și Perfectarea contractului.
 Tabelul UseCase

Actorii Descrierea verbală

Client
Angajat
Operator
Catalog-auto
Achitare-sistem
Cazurile de utilizare Descrierea verbală
Logarea
Perfectarea_contractului
Vizualizarea_tranzacțiilor
Alegerea_auto_din_stoc
Acceptarea_alegerilor Vizarea
Evidența_angajaților
Evidența_clienților Livrări
Încheierea_perfectării_contractului
***
………………………………………………..
 Tabel FBE/FAE. Logare

FBE Explicarea evenimentului

1 Sistemul: avansează câmpurile <logname> și <password>

2 Utilizatorul: asigură introducerea conținutului câmpurilor/ FAE:2, FAE:3

3 Sistemul: verifică informația introdusă/ FAE:1

4 Sistemul: permite accesul

FAE Explicarea evenimentului

1 Sistemul: accesul blocat

2 Utilizatorul: acces repetat

3 Utilizatorul: renunțare
 Tabel FBE/FAE Perfectarea contractului
FBE :Perfectare_ contract
1 Sistemul: afișarea listei auto din stoc
2 Clientul: alege auto din stoc
3 Sistemul: caută auto în stoc/ FAE:1
4 Sistemul: creează contractul/FBE: Acceptare_ contract
FBE :Actualizare_contract
1 Sistemul: afișarea contractului curent/FAE:1
2 Sistemul: afișarea listei auto din stoc
3 Clientul: editarea contractului
4 Sistemul: actualizarea contractului/FBE: Acceptare_contract
FBE :Ștergerea_contract
1 Sistemul:afișarea contractului curent/FAE:1
2 Clientul: activarea ștergerii
3 Sistemul: ștergerea contractului
FAE : Evenimente de alternative
Tema 8. Diagramele de implementare: diagrama
de componente și diagrama de desfășurare
(deployment)
1. Elementele unei diagrame de componente.
2. Definirea relațiilor între componente: relația
de dependență și relația de realizare.
Artefactele.
3. Elementele unei diagrame de desfășurare.
4. Relațiile între elementele unei diagrame de
desfășurare (deployment)
 Subiectul 1.
Raționamente preliminare.
1. Toate diagramele expuse și analizate până acum sunt instrumente
de proiectare (instrumentarul). Conceptele de actor, caz de
utilizare, clase, obiecte, relații etc. nu au puse în corespondență
elemente fizice ale unui sistem fizic, adică real.
2. Produsul program se consideră implementat, dacă elementelor
acestui sistem informatic sunt puse în corespondență elementele
unui sistem fizic,real și funcționabil. Totalitatea conceptelor
(elementelor) vehiculate la nivelul sistemului fizic formează
instrumentarul de implementare
3. La nivel de utilizare există o discrepanță între concepte vehiculate
de instrumentele de proiectare și conceptele instrumentarului de
implementare.
4. Pentru a contribui la lichidarea (atenuarea) acestei discrepanțe se
utilizează diagramele de implementare.
 Subiectul 1.
• Diagrama de componente.
• Diagrama constă din următoarele elemente: componente, interfețe,
porturi și relații,
• Componentele
Componentele sunt reprezentate printr-un dreptunghi:

cmp RegisterComp

Register.exe

Componentele pot reprezenta și conține clase sau obiecte:

(următorul slide)
 Subiectul 1.

• Componenta de mai jos conține două clase Class2 și Class3

cmp RegisterComp

Register.exe

Register.exe:: Register.exe::
Class2 Class3
 Subiectul 1.

Componenta poate conține obiecte:

cmp RegisterComp

:Register.exe

Obj ect1 Obj ect2

(următorul slide)
 Subiectul 1.

• Componenta poate intra în relație de dependență cu o altă clasă:

cmp RegisterComp

Register.exe

Class2 Class3

1. Clasele Class2 și Class3 sunt elementele dependente.

2. Clasele pot avea atribute și operații.
 Subiectul 1.
• Interfețele
Interfețele asigură interconexiunea componentelor. Sunt două tipuri de
interfețe : de export (provided) și de import (required). Interfața de
export asigură servicii pentru alte componente decât componenta
proprietară . Interfața de import a unei componente este realizată de o
altă componentă , pentru care ea este o interfață de export.
Componenta poate avea mai multe interfețe fie de export, fie de import
Componentele sunt conectate de două interfețe:
cmp RegisterComp

Register.exe Idialog
Component12

Class2 Class3
 Subiectul 2. Diagramă de componente.
cmp Component View

Booking

Port1
Trav elTrip

Port2 MakeReserv
«executable»
:Schedule Port3

Port4 UpdatePlans
Planner UserTrip
Port5 Port7 Port8

«delegate»
Port9

1. USER CONSOLE
 Subiectul 3.
• Diagrama precedentă conține un element nou – portul. Portul
asigură procesul de imbricare (includere) a structurilor. Cu acest
scop se utilizează un conector de un tip special – „delegate”.
Diagrama de desfășurare (deployment) repartizează resursele
sistemului computațional (fizic prezent) componentelor din diagramele
de componente. Resurse sunt procesoarele, dispozitivele, unitățile
periferice etc.
Diagramele de desfășurare pot conține următoarele elemente:
1. Nodul (node) – semnifică resursa computațională a sistemului.
2. Conectivitatea – desemnează canalele de legătură.
3. Dispozitiv (device) – desemnează orice dispozitiv al sistemului
computațional.
4. Componentă – corespunde modulilor produselor program.
5. Artefact (artifact) – substituie fișierele executabile ale utilizatorilor
6. Relațiile de dependență, realizare, manifestare.
 Subiectul 3.
• Exemple.
Nodul are nume, stereotip, elemente imbricate:
a)
deployment Deployment View

«server»
:RegistrationServ er

Nodul de mai sus are stereotipul „server”, nu are nume (anonim) și are
calitatea de obiect al clasei RegistrationServer.
 Subiectul 3.
b)
deployment Deployment View

«LocalNet»
«processor» «processor»
Unix :NetWork
:Serv er :WorkStation

notes
{speed transfer
300Mb/sec}

Diagrama de mai sus reprezintă o rețea. Rețeaua prezentată are nume

și este instanță a clasei NetWork.
 Subiectul 4.
c)
deployment Deployment View

«server»
:RegistrationServ er

«executable» «executable»
student.exe : schedule.exe :
Student Schedule

Componentele sunt amplasate în nodul RegistrationServer. Legătura

între ele este asigurată de relația de dependență.
 Subiectul 4.
d)

Rețeaua prezentată asigură legătura între terminalul de acces al

utilizatorului și banca (centrală) propriu-zisă.
 Subiectul 4.
Ambele noduri au stereotipul „processor”. Nodul cu numele Terminal
conține un artefact – Dialog realizat în limbajul XML. Prin relația de
dependență <<manifest>> asigură generarea componentei
„dialog.exe”. Componenta prin intermediul portului și interfeței de
import preia scenariul de verificare a utilizatorului. Componenta
„main.exe”, care generează interfața de export folosește baza de date
BankClient.
Tema 9. Mediul EnterpriseArchitect. Generarea de cod

1. Conceptele proiect (project), model (model view,

pachet( package), diagram(diagram).
2. Principiile de organizare a proiectării.
3. Generarea de cod.
4. Exemple.
 Anexa 5. Generarea de cod. Relații între clase

• Asociere unidirecțională

• public class Customer {

• private String name;
• private String address;
• private String contactNumber;
• }
•
• public class Car {
• private String modelNumber;
• private Customer owner;
• }
 Generare de cod. Asociere bidirecțională
• Asociere bidirecțională.

• public class Customer {

• private String name;
• private String address;
• private String contactNumber;
• private Car car;
• }
•
• public class Car {
• private String modelNumber;
• private Customer owner;
• }
 Asociere de cod. Multiplicitate

• public class Car {

• private String brand;
•
• Car(String brands){
• this.brand = brands;
• }
• Car() {
• }
• public String getBrand() {
• return brand;
• }
• }
•
• public class Customer {
• private Car[] vehicles;
•
• public Customer(){
• vehicles = new Car[2];
• vehicles[0] = new Car("Audi");
• vehicles[1] = new Car("Mercedes");
•
• carList.add(new Car("BMW"));
• carList.add(new Car("Chevy"));
• }
• }
 Generare de cod. Generalizare.

• public class Point {

•
• int x,y;
•
• Point(int a,int b){
• x = a;
• y = b;
• }
•
• void draw(){
• System.out.println("Drawing point: "+x+":"+y);
• }
•
• }
• public class Circle extends Point{
• int r;
•
• Circle(int a, int b, int c){
• super(a,b);
• r = c;
• }
•
• void draw(){
• System.out.println("Drawing circle: "+x+":"+y+":"+r);
• }
•
• }
 Generare de cod. Agregare
•
•

• public class Student {

• String name;
• }
•
• class School {
• private ArrayList<Student> students = new ArrayList<Student>();
•
• public void addStudent(Student s){
• students.add(s);
• }
• }

•
•
 Generare de cod. Compoziție
• public class Body {
•
• Arm[ ] arms = new Arm[2];
• Leg[ ] legs = new Leg[2];
• Head head;
•
• Body(){
• head = new Head();
• arms[0] = new Arm();
• arms[1] = new Arm();
• legs[0] = new Leg();
• legs[1] = new Leg();
• }
•
• public static void main(String[] args) {
• Body b = new Body();
• }
•
• }
•
• class Head{ }

• class Leg{}

• class Arm{}
• }