Ingineria programării

Introducere în UML
Mirel Cosulschi

1
 Scop

 Ingineria software (Software engineering)

– se referă la metodologiile folosite în dezvoltarea
proiectelor mari în care sunt implicate echipe de oameni;
– folosirea principiilor inginereşti în analizarea, dezvoltarea,
punerea în funcţiune, testarea, întreţinerea, retragerea
produselor software;
– tot aici mai pot fi prinse: gestionarea resurselor,
coordonarea echipelor, planificare, buget.
 Scop: obţinerea de programe sigure şi care funcţionează
eficient pe maşini de calcul concrete.

2
 Modelare

 Ce este un model?
– simplificarea realităţii
– planul detaliat al unui
sistem (blueprints).

 De ce modelăm?
– pentru a înţelege mai bine ce avem de făcut
– pentru a ne concentra pe un aspect la un moment dat.
 Unde folosim modelarea?

3
 Scopul modelării
 Un model este o simplificare a realităţii, fără însă a pierde
legătura cu aceasta.
 Principalul motiv pentru care se construieşte un model:
necesitatea de a înţelege sistemul ce urmează a fi dezvoltat.
 Cu cât sistemul este mai complex, cu atât importanţa
modelului creşte.
 Alegerea modelului influenţează atât modul în care
problema este abordată cât şi soluţia proiectată.
 În general, un singur model nu este suficient.
 Pentru a scrie un model, e nevoie de un limbaj de
modelare.
4
 Modelarea arhitecturii

 Cu ajutorul Use case-urilor: pentru a prezenta cerinţele.

 Cu ajutorul Design-ului: surprindem vocabularul şi
domeniul problemei.
 Cu ajutorul Proceselor: surprindem procesele şi thread-
urile.
 Cu ajutorul Implementării: avem modelarea aplicaţiei.
 Cu ajutorul Deployment-ului: surprindem sistemul din
punct de vedere ingineresc.

5
 Limbaje de modelare
 Analiza şi proiectarea unei aplicaţii software trebuie
efectuată înainte de realizarea codului.
 În prezent, se acordă o atenţie deosebită acestei etape,
deoarece de ele depind producerea şi refolosirea
software-ului.
 Pentru analiza si proiectarea programelor s-au creat
limbajele de modelare.
 Limbaj de modelare este un limbaj artificial ce poate fi
folosit să exprime informaţii sau cunoaştere sau sisteme.

6
 Tipuri de limbaje de modelare

 Limbaje grafice: arbori comportamentali, modelarea

proceselor de business, EXPRESS (modelarea datelor),
flowchart, ORM (modelarea rolurilor), reţele Petri,
diagrame UML.
 Limbaje specifice: modelare algebrică (AML) (pentru
descrierea şi rezolvarea problemelor de matematică ce
necesită putere computaţională mare), modelarea
domeniilor specifice (DSL), modelarea arhitecturilor
specifice (FSML), modelarea obiectelor (object modeling
language), modelarea realităţii virtuale (VRML).

7
 Limbaje grafice
 EXPRESS (modelarea datelor)

8
 Limbaje grafice
 Modelarea proceselor de business

9
Flowchart

10
ORM (Object Role Modeling)

11
Reţele Petri

12
Diagrame UML

13
 UML - Introducere

 1975 - 1989: apar primele limbaje de modelare OO.

 1989 - 1994: numărul limbajelor de modelare creşte de la
10 la 50.
 Limbajele de modelare de success din această perioadă:
– Booch (Grady Booch);
– OOSE - Object-Oriented Software Engineering (Ivar
Jacobson);
– OMT - Object Modeling Technique (James Rumbaugh).

14
Metoda Booch (Grady Booch)

15
OOSE (Object-oriented software
engineering)

16
OMT (Object-modeling Technique)

17
 UML - Introducere
 La mijlocul anilor 1990 a început un proces de
omogenizare, prin incorporarea în fiecare limbaj a
caracteristicilor găsite în celelalte limbaje.
 Cauze:
– Booch, Rumbaugh şi Jacobson, au ajuns la concluzia ca ar fi
mai bine să conducă evoluţia limbajelor lor pe un acelaşi
drum, pentru a elimina diferenţele gratuite ce nu făceau
decât să încurce utilizatorii.
– industria software avea nevoie de stabilitate pe piaţa
limbajelor de modelare.
– convingerea că prin unirea forţelor se pot aduce îmbunătăţiri
tehnicilor existente.
18
 UML - Introducere
 Octombrie 1994 - a început în mod oficial dezvoltarea UML prin
unificarea limbajelor Booch şi OMT (Rational Software).
 Octombrie 1995 - apare versiunea preliminară 0.8 a Unified
Method.
 Iunie 1996 – este publicată versiunea 0.9 a UML (include şi
OOSE).
 Pe parcursul anului 1996 multe companii văd în UML o opţiune
strategică pentru dezvoltarea produselor lor.
 Companii care au contribuit la crearea UML 1.0: DEC, Hewlet-
Packard, I-Logix, Intellicorp, IBM, MCI Systemhouse, Microsoft,
Oracle, Rational, Texas Instruments etc.

19
 UML - Evoluţie
 Ianuarie 1997 - UML 1.0 a fost propus spre standardizare
în cadrul OMG.
 Noiembrie 1997 - Versiunea UML 1.1 a fost adoptată ca
standard de către OMG.
 Actualmente UML este dezvoltat de către OMG Revision
Task Force, condus de Cris Kobryn
(http://www.omg.org/).
 2003 – ultima versiune 1.x “definitivă” este UML 1.5.
 Iunie 2015 - ultima versiune, UML 2.5.
 Resurse oficiale UML: http://www.uml.org

20
Evoluţie UML

21
 UML - Definiţie

 The Unified Modeling Language (UML) is a graphical

language for visualizing, specifying, constructing, and
documenting the artifacts of a software-intensive system.
 The UML offers a standard way to write a system's
blueprints, including conceptual things such as business
processes and system functions as well as concrete things
such as programming language statements, database
schemas, and reusable software components."

22
 Ce este UML?
 Este un limbaj de modelare bazat pe notaţii grafice.
 Este folosit pentru a
– specifica,
– vizualiza,
– construi,
– documenta,
componentele unui program (sistem software).
 Este un limbaj cu ajutorul căruia se pot construi (descrie) modele.
 Un model surprinde un anumit aspect al unui program.
 Fiecare model poate fi descris la diferite nivele de abstractizare.
 Fiecărui model îi corespunde o diagramă.
23
 Diagrame UML < 2.0
 Analiză
– Diagrama cazurilor de utilizare (Use Case Diagram)
– Diagrama de activităţi (Activity Diagram)
 Proiectare
– Structura: Diagrama de clase (Class Diagram)
 Comportament
– Diagrama de stări (Statechart Diagram)
– Diagrame de interacţiuni (Interactions Diagrams)
 Diagrama de secvenţă (Sequence Diagram)

 Diagrama de colaborare (Collaboration Diagram)

 Implementare
– Diagrama de componente (Component Diagram)
– Diagrama de plasare (Deployment Diagram)
24
UML 2.0

25
 Diagrame de structură
 Diagrama de clase: clasele (atributele, metodele)
şi relaţiile dintre clase.

26
 Diagrame de structură
 Diagrama componentelor: componentele sistemului
şi legăturile între acestea.

27
 Diagrame de structură
 Diagrama de deployment: modelarea structurii
hardware.

28
 Diagrame de structură
 Diagrama de obiecte: structura sistemului la un
moment dat.

29
 Diagrame de structură
 Diagrama de pachete: împărţirea sistemului în pachete
şi relaţiile dintre ele.

30
 Diagrame comportamentale

 Diagrama de activitate: prezentarea business-ului şi a

fluxului de activităţi.

31
 Diagrame comportamentale
 Diagrama de stare: pentru a prezenta mai multe
sisteme.

32
 Diagrame comportamentale
 Diagrama Use Case: prezintă funţionalităţile
sistemului folosind actori, use case-uri şi dependenţe
între ele.

33
 Diagrame de interacţiuni
 Diagrama de comunicare: arată interacţiunile între
obiecte (comportamentul dinamic al sistemului)
(actori: bucătar, aragaz, acţiuni: gătirea, aprinderea,
deconectarea).

34
 Diagrame de interacţiuni
 Diagrama de secvenţă: prezintă modul în care obiectele
comunică între ele din punct de vedere al trimiterii de
mesaje.

35
 Scenarii de utilizare
 Folosesc actori (elemente cu care programul
interacţionează):
– utilizatori umani;
– elemente software (de ex., un program ce prelucrează
informaţiile colectate de pe Internet);
– elemente hardware (de ex., un cititor de coduri de bare,
telefoane mobile etc.).
 Folosesc scenarii (use case)
– acestea descriu cum interacţionează actorul cu sistemul;
– cum reacţionează sistemul în urma acestor acţiuni;
– care e rezultatul vizibil pentru actori.
36
 Scenarii de utilizare

 Ce nu conţin acestea:
– diagrame de clase;
– structura modulară a programului;
– tipul datelor de intrare şi de ieşire.
 Use Case – Tipuri de conţinut:
– pe scurt – descrie principalul caz de succes;
– cauzal – conţine ce ar trebui făcut în caz că se întâmplă
ceva;
– detaliat – se prezintă pe larg toate situaţiile posibile.

37
 Diagrama cazurilor de utilizare
 Este o diagramă comportamentală ce captează cerinţele
sistemului.
 Delimitează graniţele sistemului.
 Punctul de plecare îl constituie scenariile de folosire a sistemului
din fişa cerinţelor.
 Poate prezenta:
– specificarea cerinţelor (externe) din punctul de vedere al
utilizatorului;
– specificarea funcţionalităţii sistemului din punctul de vedere
al sistemului.
 Conţine:
– Use Case-uri = funcţionalităţi ale sistemului;
– Actori = entităţi externe cu care sistemul interacţionează;
– Relaţii.
38
 Diagrama cazurilor de utilizare
 Este o descriere a unei mulţimi de secvenţe de acţiuni
(incluzând variante) pe care un program le execută atunci
când interacţionează cu entităţile din afara lui (actori) şi
care conduc la obţinerea unui rezultat observabil.
 Poate fi un sistem, un subsistem, o clasă, o metodă.
 Reprezintă o funcţionalitate a programului.
 Precizează ce face un program sau subprogram.
 Nu precizează cum se implementează o funcţionalitate.
 Identificarea Use Case-urilor se face pornind de la cerinţele
clientului şi analizând descrierea problemei.
39
 Caz de utilizare - Reprezentare
 Notaţie
 Atribute
– Nume = frază verbală ce denumeste o operaţie
sau un comportament din domeniul problemei.
 Restricţii
– Numele este unic.

Nume

40
 Actor
 Reprezintă un rol pe care utilizatorii unui Use Case îl
joacă atunci când interacţionează cu acesta.
 Este o entitate exterioară sistemului.
 Interacţionează cu sistemul:
– iniţiază execuţia unor cazuri de utilizare;
– oferă funcţionalitate pentru realizarea unor cazuri de utilizare.
 Poate fi:
– Utilizator (uman);
– Sistem software;
– Sistem hardware.

41
 Actor - Reprezentare
 Notaţie
 Atribute
– Nume = indică rolul pe care actorul îl joacă în
interacţiunea cu un Use Case.
 Restricţii
– Numele este unic.
* *
-
<>

42
 Relaţii
 Se stabilesc între două elemente.
 Tipuri de relaţii:
– Asociere: Actor – Use Case, Use Case – Use Case;
– Generalizare: Actor – Actor, Use Case – Use Case;
– Dependenţă: Use Case – Use Case (<<include>>,
<<extend>>).

43
 Relaţia de asociere
 Modelează o comunicare între elementele pe care le
conectează.
 Poate sa apară între
– un actor şi un Use Case (actorul iniţiază execuţia cazului de
utilizare sau oferă funcţionalitate pentru realizarea acestuia);
– două Use Case-uri (transfer de date, trimitere de
mesaje/semnale).
 Notaţie

44
 Relaţia de generalizare
 Se realizează între elemente de acelaşi tip  ierarhii.
 Modelează situaţii în care un element este un caz
particular al altui element.
 Elementul particular moşteneşte relaţiile în care este
implicat elementul general.
 Notaţie:

45
 Exemplu
* *
-
<>
Autentificare

Persoană
Sistem de Logare
* * * *
* *
-
- -
<> <>
<>
Logare Eveniment

Student Profesor
46
 Relaţia de generalizare

Desenare Figură

Desenare folosind SVG Desenare folosind modul grafic

47
 Relaţia de dependenţă

 Apare între două Use Case-uri.

 Modelează situaţiile în care
– un Use Case foloseşte comportamentul definit în alt
Use Case (<<include>>);
– comportamentul unui Use Case poate fi extins de către
un alt UseCase (<<extend>>).

 Notaţie

48
Exemplu

49
Exemplu

50
Exemplu

Oferă listă
zboruri

<<include>> <<include>>

Solicită listă zboruri

Preia opţiuni client conform cu opţiunile clientului

51
Exemplu

52