Ingineria Programarii: Limbajul Unificat de Modelare, UML

Ingineria programrii
2. Limbajul unificat de modelare, UML
Florin Leon
Universitatea Tehnic Gheorghe Asachi din Iai
Facultatea de Automatic i Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
Limbajul unificat de
modelare, UML
1. Modelarea
2. Limbajul unificat de modelare
3. Clasificarea diagramelor UML 2.0
4. Diagramele UML 2.0
5. Concluzii
modelare, UML
1. Modelarea
5. Concluzii
Modelarea
Un model este o simplificare a unui anumit sistem, care

permite analizarea unora dintre proprietile acestuia
Folosirea de modele poate nlesni abordarea problemelor

complexe, facilitnd comunicarea i nelegerea
Divide et impera
Exemple:
Reine caracteristicile necesare
Formalismul matematic
Reprezentrile din fizic
Orice limbaj intern poate fi folosit pentru modelare,

ns ntr-un context formal este nevoie de standardizare
4
modelare, UML
1. Modelarea
5. Concluzii
Scurt istoric (I)
ntre 1989 i 1994 erau folosite mai mult de 50 de limbaje de

modelare software, fiecare cu propriile notaii
Utilizatorii doreau un limbaj standardizat, o lingua franca a
modelrii
La mijlocul anilor 90 trei metode s-au dovedit mai eficiente:
Booch (Grady Booch): potrivit mai ales pentru proiectare i

implementare, cu dezavantajul unor notaii complicate
OMT, Object Modeling Technique (Jim Rumbaugh): potrivit
pentru analiz i sisteme informaionale cu multe date
OOSE, Object Oriented Software Engineering (Ivar Jacobson):
aceast metod a propus aa-numitele cazuri de utilizare, care
ajut la nelegerea comportamentului sistemului n ansamblu
6
Precursorii UML
Booch
OMT
OOSE
7
Scurt istoric (II)
1994: Jim Rumbaugh, creatorul OMT, a prsit General

Electric, alturndu-se lui Grady Booch la Rational Corp.
1995: Ivar Jacobson, creatorul OOSE, a venit la Rational

iar ideile lui, n special conceptul de cazuri de utilizare,
au fost adugate Metodei unificate
Metoda rezultat a fost numit Limbajul unificat de

modelare, UML
1996: Formarea de ctre Rational a consoriului

Partenerilor UML din care fceau parte gigani precum
Hewlett-Packard, Microsoft i Oracle
8
UML
Limbaj pentru specificarea, vizualizarea,

construirea i documentarea elementelor
sistemelor software
Un limbaj grafic care ne permite s reproducem

pe hrtie ceea ce este produs n procesul de
dezvoltare a unui sistem software
Poate fi folosit i pentru alte sisteme, cum ar fi
procesele de afaceri (business processes)
Versiuni i standardizare
Ianuarie 1997: UML 1.0 a fost propus spre standardizare

n cadrul OMG (Object Management Group)
Noiembrie 1997: versiunea UML 1.1 a fost adoptat ca
standard de ctre OMG
Martie 2003: a fost lansat versiunea 1.5
Octombrie 2004: versiunea 2.0
August 2011: versiunea 2.4.1
UML este standardul ISO/IEC 19501:2005
10
UML
Ca orice limbaj, UML are:
Notaii (alfabetul de simboluri)

Sintax i gramatic (reguli pentru combinarea
simbolurilor)
UML este un instrument de comunicare

UML nu este o metodologie de dezvoltare
Dar este determinat de cele mai bune practici n

domeniu
11
modelare, UML
1. Modelarea
5. Concluzii
Clase de diagrame
Diagrame de structur
Prezint elementele unei specificaii independent de timp
Includ: diagramele de clase, structuri compuse, componente,
desfurare (deployment), obiecte i pachete
Diagrame de comportament
Prezint trsturile comportamentale ale sistemului
Includ: diagramele de activiti, maini de stare i cazuri de
utilizare, precum i cele 4 diagrame de interaciune
Diagrame de interaciune
Scot n eviden interaciunile dintre obiecte

Includ: diagramele de secvene, comunicare, interaciuni generale
(interaction overview) i cronometrare (timing)
Legend: utilitate practic mare, medie, mic

13
Diagramele UML 2.0 (I)
Diagrame de structur:
ce conine sistemul
Clase
Structuri compuse
Componente
Desfurare
Obiecte
Pachete
Diagrame de comportament:
ce se ntmpl n sistem
Diagrame de interaciune:
fluxurile de control i date
dintre componentele sistemului
Diagrame introduse n UML 2.0
Activiti
Maini de stare
Cazuri de utilizare
Secvene
Comunicare
Interaciuni generale
Cronometrare
14
Diagramele UML 2.0 (II)
15
modelare, UML
1. Modelarea
2. Limbajul unificat de Modelare
5. Concluzii
1. Diagrama cazurilor de utilizare
Descrie interaciunile dintre utilizatori i

sistem
17
Actori i cazuri multiple
18
Granularitatea
Un caz de utilizare trebuie s satisfac un scop pentru actor

19
Avantaje
Suma cazurilor de utilizare este ntregul

sistem
Permit comunicarea cu persoane fr
cunotine tehnice IT
Partiioneaz funcionalitatea, ghideaz
dezvoltarea iterativ
Ajut planificarea i testarea
Ajut la crearea manualurilor de utilizare
20
Determinarea cazurilor de
utilizare
Interviuri cu utilizatori poteniali

ntlniri cu prile interesate (stakeholders)
Facilitator, asistent (scribe), modelare CASE
Brainstorming
Mai nti actorii

Apoi posibilele cazuri de utilizare
Justificarea fiecrui caz de utilizare
Descriere simpl, de o linie sau un paragraf
Toate ideile trebuie documentate
Cazurile de utilizare nu trebuie s fie perfecte de prima

dat, se vor rafina ulterior
21
Actori primari i secundari
beneficiaz
ia parte
22
Identificarea actorilor
Exemplu: timpul poate fi un actor

23
Generalizarea actorilor
note (comentarii)
24
Relaiile dintre
cazurile de utilizare (I)
Include: pentru reutilizare
Doar Check Identity

este conectat cu
Author Credentials
Database
25
Relaiile dintre
cazurile de utilizare (II)
Generalizarea cazurilor de utilizare:

reutilizare cu modificri
26
Relaiile dintre
cazurile de utilizare (III)
Extend: comportament
opional, depinznd de o
decizie (de implementare
sau din timpul execuiei)
Diferit de incluziune i
generalizare!
O relaie mai puin intuitiv
27
Specificarea cazurilor
de utilizare (I)
Pre-condiii
Utilizatorul s-a logat

i s-a autentificat ca
administrator
Post-condiii
Participantul a fost
eliminat de la curs
28
Specificarea cazurilor
de utilizare (II)
Fluxuri de extensie (fluxuri alternative sau fluxuri de excepie)
29
Storyboard (tabl de naraiune)
30
2. Diagrama de clase
Clasa
31
Vizibilitatea trsturilor
Public
Protejat
Pachet
Privat
32
Vizibilitatea n C# i Java
33
Reprezentarea atributelor
Inline (n interiorul clasei)

Prin asociere
34
Vizibilitatea atributelor
De obicei private sau protejate

Nu se recomand atribute publice, dect:
Pentru constante
Atribute read-only
35
Operaiile
36
Parametrii i tipurile de return
Constructor
37
Trsturi statice
Trsturi (features) = atribute i operaii

Trsturile statice se subliniaz
38
Relaii ntre clase
39
Dependena
O clas folosete pentru scurt timp o alt clas
Exemplu: trimiterea unui mesaj - metodele clasei Math
Din punct de vedere al implementrii:
Instanierea unei clase ntr-o metod

Primirea unui obiect ca parametru ntr-o metod
Crearea i returnarea unui obiect dintr-o metod
40
Asocierea
O clas folosete un timp ndelungat o alt clas

De obicei, o clas are un cmp instaniat din
cealalt clas
41
Direcia de citire
Direcia de citire este de obicei de la stnga la

dreapta i de sus n jos
Direcia de citire se poate indica explicit
Sgeata care indic direcia de citire nu trebuie pus

pe linia de asociere!
42
Validarea asocierilor
Fiecare. Obiect. Este predat ca. 0 sau mai multe. Cursuri.
Fiecare. Curs. Este pentru. Unul i numai unul. Obiect.
43
Asociere complex
44
Asociere unidirecional
Numai o clas tie de cealalt
45
Cardinalitatea (multiplicitatea)
asocierii
46
Asocieri multiple (I)
47
Asocieri multiple (II)
48
Agregarea
O clas are dar partajeaz obiecte din

cealalt clas
Este o relaie de tip ARE-UN / ARE-O

49
Agregarea
50
Compunerea
Atributele compun clasa
51
Compunerea
52
Implementarea
Din punct de vedere al implementrii,

asocierea, agregarea i compunerea
presupun introducerea unui atribut (cmp)
Dac nu sunt evidente sau foarte importante

distinciile privind agregarea sau
compunerea, este mai simplu s se
foloseasc numai relaiile de asociere
53
Motenirea (generalizarea)
Este o relaie de tip ESTE-UN / ESTE-O

54
Regula 100%
Toate definiiile clasei de baz trebuie s se

aplice tuturor claselor derivate
55
Corectitudinea generalizrilor
56
Motenire multipl
57
Recomandare
Compunerea ar trebui preferat motenirii
Motenirea este cea mai puternic form de

cuplare
n general, compunerea este mai uor de
gestionat
58
Clase i operaii abstracte

virtual
<<virtual>>
abstract
59
Interfee
60
Template-uri
De exemplu: List<int> tipul este specificat n implementare
61
Constrngeri
Tipuri de constrngeri:
Invariante
Pre-condiii
Post-condiii
OCL (Object Constraint Language) parte din UML 2.0
62
Recomandri
Nu introducei prea multe informaii n diagram

Ignorai atributele i operaiile necritice
Artai ntr-o diagram numai clasele relevante
pentru un caz de utilizare
Nu includei clasele sistem (string, Hashtable
etc.)
Nu includei prea devreme informaii despre
implementare (navigabilitate, vizibilitate)
63
3. Diagrama de obiecte
Arat cum se comport

obiectele ntr-un anumit
scenariu, cum interacioneaz
Asocierile corespund
asocierilor dintre clase
64
Template-uri
De exemplu: List<ClasaDeBaza> tipul este specificat n momentul execuiei
65
4. Diagrama de activiti
Aceste diagrame descriu logica

procedural, procesele
Sunt asemntoare schemelor logice,
dar suport i paralelismul
merge = mbinare
66
Activiti i aciuni
Activitatea este procesul modelat

O aciune este un pas din activitate
67
Decizii i mbinri
Condiiile trebuie s fie complete i mutual exclusive

Pasul urmtor trebuie s fie unic determinat
68
Teste incomplete
69
Procese paralele
fork = ramificaie
join = reunire
Se folosesc pentru procese sau fire de execuie multiple

La reunire, se ateapt terminarea tuturor aciunilor incidente
70
Evenimente de timp
Perioad de ateptare
Eveniment de timp recurent
71
Apelarea altor activiti
72
Semnale
Ateapt tot timpul
73
ntreruperi i terminri de flux
Un flux se poate termina fr a termina

ntreaga activitate
Dac se mai poate mbunti soluia n
2 secunde, este foarte bine, dac nu, se
returneaz rezultatul existent
Dup 2 secunde, se returneaz orice
rezultat disponibil, mbuntit sau nu
74
Partiii (culoare)
75
Adnotri
76
Conectori
Un conector este reprezentat de obicei de o singur liter
77
Exemple
78
5. Diagrama de secvene
Arat modul cum lucreaz sistemul
O diagram corespunde unui singur scenariu

Include n principal obiecte i mesaje
Greu de neles doar din descrierea structurii
Un mesaj poate fi un apel de metod
Indic ordinea evenimentelor
Timpul reprezint aici ordinea, nu durata

Pentru durat, se folosete diagrama de cronometrare
79
Participani
80
Mesaje imbricate
81
Tipuri de mesaje
82
Diagram complex
83
Fragmente
Controlul secvenial natural poate fi extins cu

ajutorul fragmentelor de interaciune, introduse
n UML 2.0
Fragmentele sunt asemntoare structurilor de
control care exist ntr-un limbaj de programare
84
Fragmente opionale
85
Fragmente alternative
86
Referine
87
6. Diagrame de comunicare
Similare diagramelor de secvene,
dar se concentreaz pe legturile
dintre participani
Diagramele de secvene i cele de
comunicare pot fi transformate
automat unele n altele
Mesaje imbricate
Mesaje concurente
88
Alte tipuri de mesaje
89
Diagram complex
90
7. Diagrama mainilor de stare
Obiectele pot reaciona diferit n funcie de stare

Diagramele mainilor de stare se realizeaz pentru un
singur obiect
Pot descrie comportamentul unui obiect de-a lungul mai multor

cazuri de utilizare
Nu sunt potrivite pentru a descrie colaborarea mai multor obiecte
Sunt folosite intens n anumite tipuri de aplicaii software

i hardware, precum:
Sisteme critice de timp real

Bancomate
Jocuri (de exemplu first person shooter)
91
Stri, tranziii, declanatoare, condiii
lift/lower switch = declanatoare (triggers)
Stri active ce face (de exemplu prepar cafeaua)

Stri pasive cum este (de exemplu becul e stins sau aprins)
92
Semnale
Accentul este pus pe tranziii
93
Stri compuse (I)
94
Stri compuse (II)
95
8. Diagrama de componente
Pentru proiectele mai complexe, este greu de

trecut de la analiz direct la definirea claselor
O component este o parte ncapsulat,

reutilizabil i nlocuibil a sistemului
Componentele comunic prin interfee, pentru a

asigura cuplarea slab
Componentele pot fi compuse din cteva clase

sau pot reprezenta subsisteme de mari
dimensiuni
96
Notaii pentru componente
UML 1.x
97
Notaii pentru interfee
98
Accent pe interfee
99
Accent pe dependene
100
Clasele componentelor
Notaie compact
101
9. Diagrama de pachete
Sistemele software pot avea sute de clase

Pachetele modeleaz grupuri de clase
Majoritatea limbajelor de programare importante au un
corespondent al pachetelor
Deseori diagramele sunt folosite pentru a indica dependenele dintre

pachete
Pachetele pot cuprinde orice element UML, nu doar clase
C#: namespace
Java: package
De exemplu: cazuri de utilizare
Componentele corespund nivelului conceptual (mai generale)

Pachetele corespund nivelului logic, n coresponden cu faza de
implementare
102
Pachete
Organizarea logic
103
Clase n pachete
104
Dependene
Java import
C# using
105
10. Diagrama de desfurare
Corespunde nivelului fizic: modeleaz elemente

fizice ale sistemului
Fiiere executabile
Entiti hardware
Arat cum sunt atribuite entitile software ctre

cele hardware i cum comunic acestea
Poate include hardware, firmware, sisteme de
operare, medii de execuie, drivere etc.
Dar trebuie s cuprind doar detaliile importante

pentru audien
106
Artefacte
hardware
software
107
Artefacte
Organizarea fizic
108
Instane de noduri
109
Comunicaia ntre noduri
110
Exemplu de utilizare
111
11. Diagrama
structurilor compuse
Arat cum lucreaz
obiectele n interiorul
unei clase sau cum
ndeplinesc un scop
Un port reprezint un mod

distinct de utilizare a unei
clase, de obicei de ctre tipuri
diferite de clieni
Porturile pot grupa

interfee nrudite
112
12. Diagrama de cronometrare

Folosit mai ales pentru sisteme de timp
real sau ncorporate
Arat strile unui obiect i momentele de

timp cnd se afl obiectul n aceste stri
113
Interaciuni i constrngeri
114
Notaie alternativ
Recomandat pentru puine stri
Recomandat pentru multe stri
115
13. Diagrama
interaciunilor generale
Arat cum interacioneaz
mai multe entiti pentru a
realiza un caz de utilizare
(sau un scop)
Poate fi vzut ca o
diagram de activiti,
dar fiecare aciune este
o interaciune complet
descris de o diagram
distinct
116
Diagramele UML i ciclul de

dezvoltare software
Faza modelrii cazurilor de utilizare

Faza modelrii domeniului
Faza modelrii proiectrii
Diagrame statice de structur, diagrame de secvene
Diagrame de clase, de maini de stare, de activiti
Faza modelrii implementrii
Diagrame de componente, de desfurare
117
Diagramele UML i ciclul de

dezvoltare software
Perspectiva logic
Clase, maini de stare,

secvene .a.
Activiti
Perspectiva de
dezvoltare
Modelul vizualizrii 4+1
Perspectiva de proces
Pachete, componente
Perspectiva fizic
Desfurare
118
Concluzii
UML este un limbaj pentru specificarea,

vizualizarea, construirea i documentarea
elementelor sistemelor software
Este un standard de facto pentru modelarea
software
UML 2.0 are 13 diagrame, clasificate n:
Diagrame de structur
Diagrame de comportament
Diagrame de interaciune
119
Referine
Majoritatea diagramelor incluse n acest curs

au fost preluate din urmtoarele surse:
Hamilton, K., Miles, R. (2006). Learning UML 2.0,

O'Reilly
Ariadne Training. UML Applied, 2nd edition,
http://ariadnetraining.com/software-courses/images/stories/YesNo/
ariadne/file/UML_Applied\_Second\_Edition.pdf
120

Ingineria Programarii: Limbajul Unificat de Modelare, UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ingineria Programarii: Limbajul Unificat de Modelare, UML

Uploaded by

Copyright:

Available Formats

Ingineria programrii

2. Limbajul unificat de modelare, UML

Un model este o simplificare a unui anumit sistem, care

Folosirea de modele poate nlesni abordarea problemelor

Reine caracteristicile necesare

Orice limbaj intern poate fi folosit pentru modelare,

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Scurt istoric (I)

ntre 1989 i 1994 erau folosite mai mult de 50 de limbaje de

Booch (Grady Booch): potrivit mai ales pentru proiectare i

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Scurt istoric (II)

1994: Jim Rumbaugh, creatorul OMT, a prsit General

1995: Ivar Jacobson, creatorul OOSE, a venit la Rational

Metoda rezultat a fost numit Limbajul unificat de

1996: Formarea de ctre Rational a consoriului

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Limbaj pentru specificarea, vizualizarea,

Un limbaj grafic care ne permite s reproducem

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Ianuarie 1997: UML 1.0 a fost propus spre standardizare

UML este standardul ISO/IEC 19501:2005

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Ca orice limbaj, UML are:

Notaii (alfabetul de simboluri)

UML este un instrument de comunicare

Dar este determinat de cele mai bune practici n

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Scot n eviden interaciunile dintre obiecte

Legend: utilitate practic mare, medie, mic

Diagramele UML 2.0 (I)

Diagrame introduse n UML 2.0

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Diagramele UML 2.0 (II)

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

1. Diagrama cazurilor de utilizare

Descrie interaciunile dintre utilizatori i

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Actori i cazuri multiple

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Un caz de utilizare trebuie s satisfac un scop pentru actor

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Suma cazurilor de utilizare este ntregul

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Interviuri cu utilizatori poteniali

Facilitator, asistent (scribe), modelare CASE

Mai nti actorii

Descriere simpl, de o linie sau un paragraf

Toate ideile trebuie documentate

Cazurile de utilizare nu trebuie s fie perfecte de prima

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Actori primari i secundari

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu: timpul poate fi un actor

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Include: pentru reutilizare

Doar Check Identity

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Generalizarea cazurilor de utilizare:

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm