Managementul proiectelor

Curs, anul II Calculatoare

Modelarea vizuala cu UML

Sumar
Metodologii vizuale OO
UML. Vedere si notatie: diagramele UML
Evolutia UML
Utilizarea UML
UML ca schita
UML ca plan
UML ca limbaj de programare
Adresabilitatea UML (Enterprise Computing)
Delimitarea domeniului UML. Frontiere
Aparitia UML
Procesele software ale dept. IT s-au concentrat mult timp
pe rezolvarea problemelor legate de scrierea codului
Azi, dept.IT sunt mai preocupate (si SDP o reflecta) de
complexitatea modelarii
“design before code” , “architect before design”
Intre 1985 si 1995, au fost publicate 50+ de metodologii de
modelare vizuale orientate-obiect
“Sinteza” lor → UML
Modelarea “vizuala”
Permite echipei de dezvoltare a unui proiect
n Sa specifice
n Sa construiasca

n Sa documenteze

intr-o maniera accesibila arhitectura viitorului sistem

Deziderate esentiale:
n Comunicarea rapida si precisa a deciziilor de proiectare
n Ascunderea sau expunerea detaliilor (ne)necesare

n Mentinerea consistentei intre artefactele dezvoltarii –

ex. documente referitoare la cerinte, arhitectura,
implementare
Capabilitati suplimentare
Cuplata cu practica dezvoltarii iterative, modelarea
vizuala permite
n Expunerea modificarilor (cerintelor, arhitecturale)

n Evaluarea

n Comunicarea

Cuplata cu tehnologia adecvata (setul potrivit de

instrumente CASE) permite in plus, la fiecare iteratie,
sincronizarea
n Modelului vizual

n Codului sursa
Metodologii vizuale OO
Metodologia lui Grady Booch
OOSE (“Objectory”) – Ivar Jacobson
n Captura cerintelor
n Analiza si proiectare generala
OMT (Object Modeling Technique) – J.Rumbaugh
n Analiza: formalizarea unui sistem intr-un model
obiectual
n Proiectare de sistem: decizii strategice
n Proiectare cu obiecte: transformarea modelului de
analiza in model obiectual ce poate fi implementat
Vezi si: http://www.smartdraw.com/resources/centers/software/tutorials.htm
Unificarea metodologiilor: UML
Unificarea “metodelor” Booch, Rumbaugh si Jacobson
are loc pana la sfarsitul anului 1995, cand este lansata
vers.0.8 a “Unified Method”
Numele de UML apare in 1996
1996: UML 0.9x pe baza unificarii
n OMT (James Rumbaugh)
n OOSE (Ivar Jacobson)
n Metoda Booch (Grady Booch)
UML 1.0 este adoptat in ian.1997, ca standard deschis
Evolutia sa e incredintata unui comitet numit OMG
(Object Management Group), similar ANSI
Vederi UML
Sunt modele conceptuale vizuale ce redau aspecte
sistem din diferite unghiuri sau prin diferite roluri
UML-View = use-case || logical || process ||
implementation || deployment
Arhitectura unui sistem software este modelata de
vederi diferite
n in faze de dezvoltare diferite
n conform cu rolul diferitilor actori
Fiecare vedere este proiectia unui aspect sistem &
unui set de comportamente coerente
Impreuna, ele formeaza a.n. “model vizual arhitec-
tural 4+1”
Modelul vizual arhitectural 4+1
Modelul 4+1 in detaliu (cf. Wikipedia)
Logical view : The logical view is concerned with the functionality
that the system provides to end-users. UML Diagrams used to
represent the logical view include Class diagram, Communication
diagram, Sequence diagram
Development view : The development view illustrates a system
from a programmer's perspective and is concerned with software
management. This view is also known as the implementation
view. It uses the UML Component diagram to describe system
components. UML Diagrams used to represent the development
view include the Package diagram
Process view : The process view deals with the dynamic aspects
of the system, explains the system processes and how they
communicate, and focuses on the runtime behavior of the system.
The process view addresses concurrency, distribution, integrators,
performance, and scalability, etc. UML Diagrams to represent
process view include the Activity diagram
Modelul 4+1 in detaliu (cont.)
Physical view : The physical view depicts the system from a
system engineer's point of view. It is concerned with the topology of
software components on the physical layer, as well as the physical
connections between these components. This view is also known as
the deployment view. UML Diagrams used to represent physical
view include the Deployment diagram
Scenarios : The description of an architecture is illustrated using a
small set of use cases, or scenarios which become a fifth view. The
scenarios describe sequences of interactions between objects, and
between processes. They are used to identify architectural elements
and to illustrate and validate the architecture design. They also
serve as a starting point for tests of an architecture prototype. This
view is also known as use case view
Modelul 4+1 sintetic (Phil. Kruchten)
Vederea cazurilor de utilizare
Descrie comportamente sistem dpdv specifice ale
unor actori: end-useri, analisti, designeri, testeri
Cazurile de utilizare:
n descriu vederea actorului asupra functiilor partiale ale
sistemului
n captureaza structura statica a sistemului software prin
diagramele cazurilor de utilizare
n comportamentul dinamic este descris prin diagrame
de interactiune, de stare si activitati
Vederea logica
Descrie cerintele functionale ale unui sistem
Acesta consta in clase, interfete si colaborari
Comportamentul static e descris prin
n diagrame de clase
n diagrame de obiecte
Comportamentele dinamice sunt descrise prin
n diagrame de interactiune,
n diagrame de secventa
n diagrame de activitati
Vederea procesuala
Descrie:
n performanta
n scalabilitatea
n rata de iesire a unui sistem
Acesta consta din task-uri, thread-uri, procese si
interactiuni
Comportamentul static e descris prin diagrame
de clase si obiecte
Comportamentele dinamice sunt descrise prin
diagrame de interactiune, de stare si de activitati
Vederea de implementare
Descrie:
n componente sistem
n fisiere
n configuratii si management
Comportamentul static e descris prin diagrame
de componente
Comportamentele dinamice sunt descrise prin
diagrame de interactiune, de stare si de activitati
Vederea de aranjare
Descrie:
n configuratia si topologia platformelor hardware
n distributia, instalarea si livrarea componentelor
sistem
Comportamentele statice sunt descrise prin
diagrame de aranjare
Comportamentele dinamice sunt descrise prin
diagrame de interactiune, de stare si de activitati
Diagrame UML
Sunt instrumente vizuale in descrierea vederilor,
componentelor si proceselor de proiectare, si
interactiunilor om-calculator
Constau din elemente vizuale ce suporta
modelarea si vizualizarea unui sistem software
Tipurile de diagrame UML sunt definite de
expresia:
UML-Diagram = class| object | sequence |
collaboration | statechart | activity | use-case |
component | deployment
Tipuri de diagrame UML (1)
“Use-case diagram” : un set de cazuri de utilizare
orientate catre actorii sistemului si relatiile lor
“Class diagram”: set de clase, interfete, colaborari,
precum si descrieri ale relatiilor lor prin legaturi
“Object diagram”: un set de obiecte si descrieri ale
relatiilor lor prin legaturi
“Sequence diagram”: o diagrama de interactiune ce
descrie ordinea si timing-ul relativ al obiectelor si
proceselor secventiale si paralele
“Collaboration diagram”: o diagrama de secventa
extinsa cu interactiunea si organizarea obiectelor ce
schimba mesaje
Tipuri de diagrame UML (2)
“Statechart diagram”: o reprezentare vizuala a
unei masini de stare a unui sistem software
n O masina de stare consta din stari, evenimente,
tranzitii si activitati
“Activity diagram”: un tip special de diagrama de
stare ce descrie fluxul activitatilor intr-un sistem
“Component diagram”: un set de componente cu
descrieri ale relatiilor lor
“Deployment diagram”: configuratia tuturor
componentelor de executie si a relatiilor lor
Notatie UML
Diagramele UML sunt notatii simple si pot fi
redate pe o mare varietate de medii (coala de
hartie, tabla, fata de masa sau servetelul de la
restaurant, ecranul etc.)
In UML se acorda (aparent!) atentie descrierii
artefactelor dezvoltarii software, mai putin
formalizarii procesului
De fapt, exista un progres bine fundamentat si
sustinut de OMG
Diagramele cazurilor de utilizare
Functionalitatea sistemului “ceas digital” – puncte de vedere
utilizatori

Package
CeasSimplu

Actor
CitesteTimp

PuneTimp
Detinator Ceasornicar

Use case
SchimbaBateria
Diagrame de clasa
Reprezinta structura sistemului “ceas digital”

Clasa

Multiplicitate CeasSimplu Asociatie

1 1 1 1
2 1 2 1
PushButton DisplayLCD Battery Time
state blinkIdx load() now()
push() blinkSeconds()
release() blinkMinutes()
blinkHours() Atribut
stopBlinking()
refresh()
Operatii
Diagrame de secventa
Reprezinta comportamentele ca interactiuni

Obiect

:CeasSimplu :DisplayLCD :Time

:Detinator

pressButton1() blinkHours()
pressButton1() blinkMinutes()

pressButton2() incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Mesaj
Activare
Diagrame de stari
Stare initiala Stare

button1&2Pressed button2Pressed
Blink Increment
Hours Hours

Tranzitie button1Pressed Eveniment

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes

button1Pressed

button2Pressed
Stop Blink Increment
Blinking Seconds Seconds
button1&2Pressed

Stare finala
Diagrame de activitati

Active

incidentHandled

Inactive

incidentDocumented
incidentArchived

Stop Closed
Archived
Alte elemente si conventii UML
Diagramele UML ca grafuri:
n Nodurile sunt entitati
n Arcele sunt relatii intre entitati
n Dreptunghiurile sunt clase sau obiecte (instante)
n Instantele sunt notate prin nume subliniate
w myWatch:CeasSimplu
n Tipurile sunt notate prin nume nesubliniate
w CeasSimplu
n Cercurile si elipsele sunt functii sau cazuri de utilizare
Alte tipuri de diagrame: de implementare, de
colaborare, de componente, de aranjare
Evolutia UML (1)
OMG – comitet de standardizare cu rol major si in
elaborarea CORBA IDL (Interface Def. Language) si
CORBA IIOP (Internet Inter-ORB Protocol) - a
publicat o cerere de propunere de standard (RFP)
Rational Software a creat consortiul UML Partners
(cu DEC, HP, IBM, Microsoft, Oracle, Unisys etc.)
Contributiile din afara consortiului, ca raspunsuri
separate la RFP din partea (ObjectTime, Platinum
Technology, Ptech etc.) sunt considerate si preluate in
standardul industrial UML 1.1, in toamna 1997
OMG da UML 1.1 ca standard industrial - 14.11.97
Evolutia UML (2)
Dupa versiunea 1.1 se adauga UML si OCL (Object
Constraint Language), un limbaj standard in scrierea
constrangerilor, bazat pe ideile lui Steve Cook si John
Daniels
UML 1.2, 1998 (versiune “editoriala pura”); 1.3; 1.4
(sept.2001)
Semnificativ este UML 1.5,2002 (UML with Action
Semantics) ⇒ crearea modelelor UML executabile
Actualmente: UML 2.0, adoptat in octombrie 2004
Rolul OMG
Dupa 1997, OMG isi asuma responsabilitatea formala
pentru dezvoltarea standardului UML (desi multi din
membrii consortiului UML Partners participa activ)
OMG detine “drepturile” asupra UML, transmise de
Rational (intre timp preluata de IBM)
OMG a creat dupa 1997 RTF (Revision Task Force),
responsabila pt. gestionarea intrebarilor, schimbarilor,
imbunatatirilor UML, si publicarea de noi versiuni
De fapt, exista pentru fiecare zona de dezvoltare cate
un “task force”, ce pregateste propuneri pt. ratificare
si integrare in standardul UML global
Strategia de evolutie a UML
Telurile evolutiei UML sunt parte a strategiei MDA
Standardul poate esua daca:
n e prea rigid sau, dimpotriva, prea relaxat
n prea ingust sau prea cuprinzator
n prea legat de o anumita tehnologie sau prea vag pentru a fi
aplicat tehnologiilor reale
Zona cheie ce apare pe masura stabilizarii UML:
n inter-operabilitatea instrumentelor, ce a condus la XMI
(XML Metadata InterChange) – standard definit in XML
n XML (eXtensible Markup Language) – format standard
industrial pt. schimb de inf. in medii distribuite
UML in strategia OMG
Cel mai stabil element in evolutia UML e arhitectura
(“four layers arch.”)
Problema majora: abordarea meta-model in UML nu
are inca o implementare corespunzatoare, ceea ce
face dificila alinierea UML cu MOF (Meta-Object
Facility) – o tehnologie fundamentala in strategia
globala MDA (Model-Driven Architecture) a OMG
Obiective urmarite in evolutia standard:
n Clarificarea problemelor cu meta-modelul UML
n Eliminarea ambiguitatilor din documentul original
n Imbunatatirea consistentei numelor si a facilitatilor de
adresare cerute de domenii specializate, etc.
Cum se utilizeaza UML
Notatiile suporta documentarea modelelor
folosite in SDP, ca si comunicatia intre modele
Pentru categorii diferite de participanti la
procesele software, UML poate reprezenta
instrumente diferite:
n Schita
n Plan
n Limbaj de programare
UML ca schita
Aspecte esentiale in dezvoltarea unui sistem
software pot fi comunicate simplu si rapid
O schita poate fi folosita in ambele sensuri ale
unui SDP:
n Forward Engineering (FE): se deseneaza diagrame
UML inainte de a se scrie cod
n Reverse Engineering (RE): se deseneaza diagrame
UML pe baza unui cod existent, pentru a ajuta in
intelegerea acestuia
Procesul (sketching)
Esenta procesului de schitare consta in
selectivitate si caracter exploratoriu
n In FE: se abordeaza partile principale din
codul ce urmeaza a fi scris, se comunica ideile
si alternativele in sesiuni scurte (cu durata de
1:10 – 1:12 fata de efortul de programare)
n In RE: se abordeaza clasele principale mai
intai; se construiesc diagrame si pe aceasta
baza se explica functionarea lor, inainte de a
se trece la restul codului
Procesul de schitare (cont.)
Schitarea este informala si dinamica
Nu este completa si nici riguroasa
n nu se respecta intotdeauna cu strictete
regulile privind formarea diagramelor UML
Trebuie facuta rapid si colaborativ
Daca se folosesc instrumente software
(tools):
n acestea pot fi generale sau specializate
n dar nu foarte puternice (de ex., programe de
desenare)
UML ca plan
Diagramele UML folosite ca plan al dezvoltarii
unui sistem software sunt complete si riguroase
n se respecta strict regulile formarii diagramelor UML
Instrumentele software folosite sunt mult mai
sofisticate, din categoria CASE (specializate)
n In FE trebuie sa se asigure pe langa desenarea
diagramelor (folosind “primitive” mai puternice) si
salvarea (incrementala) in repositories; la fel in RE
n Unele pot face atat FE cat si RE (“round trip tools”)
Procesul de planificare
Planurile trebuie sa aiba si un caracter definitiv pentru
a putea fi folosite in codificare
In FE: planul se face de catre un arhitect de sistem
(designer) – in general un “senior developer” care
proiecteaza pentru o echipa de programatori
n planul trebuie sa descrie suficient de detaliat deciziile de
proiectare pentru ca programatorii sa le poata urma direct
In RE: planul cuprinde informatii detaliate despre
codul sursa, fie in documente (text), fie in browsere
grafice interactive
UML ca limbaj
Automatizarea programarii
Multe instrumente CASE asigura, intr-o anumita
forma, generarea unei parti din cod pe baza planurilor
Prin aceasta:
n Se automatizeaza constructia unei parti a sistemului
n UML devine “limbaj de programare”
n Diagramele UML devin similare codului sursa (intr-un
limbaj “vizual”)
In acest caz nu are sens analiza sensurilor SDP, iar
notiuni ca FE si RE isi pierd continutul deoarece
UML si codul sursa reprezinta acelasi lucru
Adresabilitatea UML
Scopurile de adresabilitate la necesitatile SDPs:
1. Crearea unui limbaj vizual, expresiv, care sa permita
atat dezvoltarea, cat si schimbarea modelelor
2. Furnizarea mecanismelor de extensibilitate si
specializare pentru extinderea conceptelor de baza
3. Suportul specificatiilor independente de limbajele de
programare sau procesele de dezvoltare particulare
4. Asigurarea unei baze formale pentru intelegerea
limbajului de modelare
5. Incurajarea aparitiei de instrumente de modelare
obiectuale
6. Suportul conceptelor de dezvoltare abstracte
A1: Crearea unui limbaj vizual
complet si expresiv
Acesta trebuia sa defineasca:
n Modul de dezvoltare/ modificare a modelelor
n Semantica, pentru asigurarea aplicarii consistente a
modelelor/ elem. de modelare
n Reprezentarea vizuala, pentru a facilita adoptarea si
utilizarea
Limbajul trebuie sa fie:
n Complet, gata de utilizare imediata, fara customizare
prealabila, pentru majoritatea proiectelor
n Nu insa si exhaustiv (pur si simplu, pentru ca nu se
poate)
A2: Furnizarea mecanismelor de
extensibilitate si specializare
Acestea pot fi necesare in multe proiecte
pentru extinderea conceptelor de baza
Regula 80/20:
n Putem construi 80% din sisteme cu 20% din
conceptele ce pot fi imaginate; acestea sunt
conceptele de baza
n Cand conceptele de baza nu sunt suficiente tb. sa
existe modalitati pentru a construi noile concepte
n Daca e posibil, noile concepte nu vor fi “inventate”;
tb. folosite concepte deja definite in crearea lor
A2 (cont)
Nucleul UML (core):
n defineste concepte fundamentale ce se pot combina
pentru a crea noi concepte
n asigura posibilitatea definitiilor multiple
UML suporta customizarea unui concept prin
specializarea uneia sau mai multor definitii ale
sale
n Specializarea = refolosirea unei definitii existente cu
stergerea si/sau adaugarea de noi elemente
Se pot defini profile
Profile UML
Profilul este o implementare a UML pentru:
n un domeniu specific,
n o platforma tehnologica particulara, sau
n o linie de business anume
Un profil predefineste un set de elemente de
modelare unice sau comune mediului tinta
Astfel, un domeniu poate fi reprezentat mult mai
exact decat este posibil cu UML generic, fara
insa a pierde claritatea semantica a conceptelor
A3: Suport pentru specificatiile
independente de PLs sau SDPs
Modelarea are ca motivatie separarea cerintelor
de implementare
Legarea UML de o implementare ar avea drept
consecinte negative:
n Indepartarea celor ce nu folosesc un limbaj/ proces
particular
n Legarea UML de o epoca in ingineria soft.
Totusi, pentru a permite integrarea cu mediile
de modelare, dezvoltare si executie, UML
trebuie sa mapeze constructele OO
Translatarea constructelor POO
Acestea sunt comune in multe limbaje POO
Maparea se face intr-o maniera care sa permita
independenta specificatiilor UML de limbaje,
prin profile
n Din aceasta perspectiva, profilele definesc relatiile
intre elementele modelului UML si constructiile de
implementare
Folosirea unui strat suplimentar de translatare
n Decupleaza (separa efectiv) UML de limbajele de
implementare
n Permite ambelor sa evolueze in ritm propriu
A4: Asigurarea unei baze formale
pentru limbajul de modelare
Limbajul trebuie definit la un nivel
n Precis – pentru a permite definirea unei solutii
n Accesibil - pentru a permite utilizarea sa
De exemplu, standardul UML foloseste
n diagrame de clase pentru a reprezenta definitiile
formale ale obiectelor si relatiile dintre ele
n un text ce detaliaza optiunile de semantica si
notatie, ce suplimenteaza fiecare diagrama de clase
n un limbaj specializat (OCL) pentru a exprima
constrangerile ce definesc integritatea elementelor
de modelare
A5: Incurajarea instrumentelor de
modelare obiectuale
Piata lor depinde de un standard unificat pentru
n modele
n repositories (asigurarea stocarii modelelor)
n schimburi intre modele (import/export de obiecte)
Doar in masura in care firmele de software se
pot baza pe un standard stabil, pot implementa
rapid si efectiv cele trei caracteristici esentiale
ale unui tool
Aceasta este si premisa scaderii costurilor de
implementare pentru functionalitatea de baza
Efecte ale scaderii costurilor
Pot fi adaugate imbunatatiri ca:
n integrarea cu mediile de codificare si executie
n instrumente de management pentru BD
n verificarea sintaxei si a modelului
Fata de cele vechi care doar desenau diagrame,
noile tool-uri asigura
n verificare sintactica pentru instructiunile OCL
n sincronizarea diagramelor si generarea codului
n facilitati de reverse engineering
n import din alte medii, export de rapoarte HTML/XML
n suportul integrarii cu unul sau mai multe medii de
codificare
A6: Suportul conceptelor de
dezvoltare abstracte
Standardul implementeaza suport pentru
concepte de nivel inalt, ca de exemplu:
n Componente
n Colaborari
n Cadre (frameworks)
n Sabloane (patterns)
Asigurand potentialul viitor e facilitata evolutia
tehnologica
UML nu e o “mostenire grea” ce trebuie carata
in viitor odata cu alte tehnologii vechi
Delimitarea domeniului UML
1/UML este prin conceptie desemnat sa imbine
cele mai bune practici de dezvoltare si concepte
de modelare de varf ale ultimelor trei decenii
/2 UML tine cont de faptul ca si tehnologiile, si
tehnicile de dezvoltare sunt mereu in schimbare
Exista tentatia de a defini in UML tot ce tine de
SDP: modelarea, metodologia de dezvoltare,
managementul de proiect, integrarea de sistem
OMG a delimitat insa cateva frontiere clare
Prima frontiera UML
Se asigura doar:
n definirea limbajului de modelare
n semantica si notatia pentru crearea modelelor si
descrierea artefactelor dezvoltarii software
n nu insa si a procesului software
UML poate fi si este folosit cu mai multe
metodologii proprietare
n Rational Unified Processes (RUP)
n eXtreme Programming (XP)
n Agile Methodologies (AM)
A doua frontiera UML
Desi UML si limbajele OOP au o baza si
concepte comune, nu sunt legate
De exemplu:
n Java nu suporta mostenirea multipla (C++ da)
n UML asigura mostenirea multipla
n Totusi, nici Java si nici UML nu se vor schimba din
cauza acestei inconsistente
A treia frontiera UML
UML nu se substituie altor tehnici de modelare,
ca BPR (Business Process Re-engineering) sau
E/R (Entity/Relationship)
Similaritatile structurale pot fi exploatate totusi
in scopul asigurarii inter-schimburilor dintre
modele
De exemplu, exista instrumente ce realizeaza
conversii intre un model UML si un model E/R,
in ambele sensuri