Post on 27-Oct-2019
Managementul proiectelorManagementul proiectelor
Modelarea vizuala cu UML
Curs, anul II Calculatoare
Modelarea vizuala cu UML
SumarMetodologii vizuale OOUML. Vedere si notatie: diagramele UMLEvolutia UMLUtilizarea UMLUtilizarea UML
UML ca schitaUML ca planUML ca limbaj de programare
Adresabilitatea UML (Enterprise Computing)Delimitarea domeniului UML. Frontiere
Aparitia UMLProcesele software ale dept. IT s-au concentrat mult timppe 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”“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 proiectn Sa specificen Sa construiascan Sa documenteze
intr-o maniera accesibila arhitectura viitorului sistemintr-o maniera accesibila arhitectura viitorului sistemDeziderate esentiale:n Comunicarea rapida si precisa a deciziilor de proiectaren Ascunderea sau expunerea detaliilor (ne)necesaren Mentinerea consistentei intre artefactele dezvoltarii –
ex. documente referitoare la cerinte, arhitectura, implementare
Capabilitati suplimentareCuplata cu practica dezvoltarii iterative, modelarea vizuala permiten Expunerea modificarilor (cerintelor, arhitecturale)n Evaluarea
ComunicareanComunicareaCuplata cu tehnologia adecvata (setul potrivit de instrumente CASE) permite in plus, la fiecare iteratie, sincronizareanModelului vizualnCodului sursa
Metodologii vizuale OOMetodologia lui Grady BoochOOSE (“Objectory”) – Ivar Jacobsonn Captura cerintelorn Analiza si proiectare generala
OMT (Object Modeling Technique) – J.RumbaughOMT (Object Modeling Technique) – J.Rumbaughn Analiza: formalizarea unui sistem intr-un model
obiectualn Proiectare de sistem: decizii strategicen Proiectare cu obiecte: transformarea modelului de
analiza in model obiectual ce poate fi implementatVezi si: http://www.smartdraw.com/resources/centers/software/tutorials.htm
Unificarea metodologiilor: UMLUnificarea “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 19961996: UML 0.9x pe baza unificarii 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 deschisEvolutia sa e incredintata unui comitet numit OMG (Object Management Group), similar ANSI
Vederi UMLSunt modele conceptuale vizuale ce redau aspectesistem din diferite unghiuri sau prin diferite roluriUML-View = use-case || logical || process ||
implementation || deploymentArhitectura unui sistem software este modelata de Arhitectura unui sistem software este modelata de vederi diferiten in faze de dezvoltare diferiten conform cu rolul diferitilor actori
Fiecare vedere este proiectia unui aspect sistem & unui set de comportamente coerenteImpreuna, 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 diagramDevelopment view : The development view illustrates a system from a programmer's perspective and is concerned with software 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 diagramProcess 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 diagramScenarios : 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 utilizareDescrie comportamente sistem dpdv specifice ale unor actori: end-useri, analisti, designeri, testeri
Cazurile de utilizare:n descriu vederea actorului asupra functiilor partiale ale n descriu vederea actorului asupra functiilor partiale ale
sistemului
n captureaza structura statica a sistemului software prindiagramele cazurilor de utilizare
n comportamentul dinamic este descris prin diagramede interactiune, de stare si activitati
Vederea logicaDescrie cerintele functionale ale unui sistem
Acesta consta in clase, interfete si colaborari
Comportamentul static e descris prindiagrame de clasen diagrame de clase
n diagrame de obiecte
Comportamentele dinamice sunt descrise prinn diagrame de interactiune,
n diagrame de secventa
n diagrame de activitati
Vederea procesualaDescrie: n performantan scalabilitatean rata de iesire a unui sistemn rata de iesire a unui sistem
Acesta consta din task-uri, thread-uri, procese siinteractiuniComportamentul static e descris prin diagramede clase si obiecteComportamentele dinamice sunt descrise prindiagrame de interactiune, de stare si de activitati
Vederea de implementareDescrie: n componente sistemn fisieren configuratii si managementn configuratii si management
Comportamentul static e descris prin diagramede componenteComportamentele dinamice sunt descrise prindiagrame de interactiune, de stare si de activitati
Vederea de aranjareDescrie: n configuratia si topologia platformelor hardware
n distributia, instalarea si livrarea componentelorsistemsistem
Comportamentele statice sunt descrise prindiagrame de aranjare
Comportamentele dinamice sunt descrise prindiagrame de interactiune, de stare si de activitati
Diagrame UMLSunt instrumente vizuale in descrierea vederilor, componentelor si proceselor de proiectare, si interactiunilor om-calculatorConstau din elemente vizuale ce suporta modelarea si vizualizarea unui sistem softwaremodelarea si vizualizarea unui sistem softwareTipurile 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 utilizareorientate 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 “Object diagram”: un set de obiecte si descrieri ale relatiilor lor prin legaturi“Sequence diagram”: o diagrama de interactiune cedescrie ordinea si timing-ul relativ al obiectelor siproceselor secventiale si paralele“Collaboration diagram”: o diagrama de secventaextinsa cu interactiunea si organizarea obiectelor ceschimba mesaje
Tipuri de diagrame UML (2)“Statechart diagram”: o reprezentare vizuala a unei masini de stare a unui sistem softwaren O masina de stare consta din stari, evenimente,
tranzitii si activitati
“Activity diagram”: un tip special de diagrama de “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 UMLDiagramele 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.)restaurant, ecranul etc.)In UML se acorda (aparent!) atentie descrierii artefactelor dezvoltarii software, mai putin formalizarii procesuluiDe fapt, exista un progres bine fundamentat si sustinut de OMG
Diagramele cazurilor de utilizare
PackageCeasSimplu
Functionalitatea sistemului “ceas digital” – puncte de vedere utilizatori
Detinator Ceasornicar
CitesteTimp
PuneTimp
SchimbaBateria
Actor
Use case
Diagrame de clasa
CeasSimplu
Clasa
AsociatieMultiplicitate
Reprezinta structura sistemului “ceas digital”
Batteryload()
12
Timenow()
PushButtonstatepush()release()
11
11
12
blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()refresh()
DisplayLCD
CeasSimplu AsociatieMultiplicitate
Atribut
Operatii
Diagrame de secventa
Obiect
:Detinator :Time:DisplayLCD:CeasSimplu
Reprezinta comportamentele ca interactiuni
MesajActivare
blinkHours()
blinkMinutes()
incrementMinutes()refresh()
commitNewTime()stopBlinking()
pressButton1()
pressButton2()
pressButtons1And2()
pressButton1()
button1&2Pressed
button1Pressed
button2Pressed IncrementHours
BlinkHours
Diagrame de stariStareStare initiala
Tranzitie Eveniment
button1&2Pressed
button2Pressed
button2Pressed
button1Pressed
button1&2Pressed IncrementMinutes
BlinkSeconds
BlinkMinutes
IncrementSeconds
StopBlinking
Stare finala
incidentHandled
Active
Diagrame de activitati
incidentDocumentedincidentArchived
Closed
Inactive
StopArchived
Alte elemente si conventii UMLDiagramele UML ca grafuri:n Nodurile sunt entitatin Arcele sunt relatii intre entitatin Dreptunghiurile sunt clase sau obiecte (instante)n Instantele sunt notate prin nume subliniatew myWatch:CeasSimplu
n Tipurile sunt notate prin nume nesubliniatew 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 PartnersRational 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 1997OMG 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 DanielsUML 1.2, 1998 (versiune “editoriala pura”); 1.3; 1.4 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 executabileActualmente: UML 2.0, adoptat in octombrie 2004
Rolul OMGDupa 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)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 versiuniDe 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 UMLTelurile evolutiei UML sunt parte a strategiei MDAStandardul poate esua daca:n e prea rigid sau, dimpotriva, prea relaxatn prea ingust sau prea cuprinzator n prea legat de o anumita tehnologie sau prea vag pentru a fi
aplicat tehnologiilor realeZona cheie ce apare pe masura stabilizarii UML:n inter-operabilitatea instrumentelor, ce a condus la XMI
(XML Metadata InterChange) – standard definit in XMLn XML (eXtensible Markup Language) – format standard
industrial pt. schimb de inf. in medii distribuite
UML in strategia OMGCel 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 face dificila alinierea UML cu MOF (Meta-Object Facility) – o tehnologie fundamentala in strategia globala MDA (Model-Driven Architecture) a OMGObiective urmarite in evolutia standard:n Clarificarea problemelor cu meta-modelul UMLn Eliminarea ambiguitatilor din documentul originaln Imbunatatirea consistentei numelor si a facilitatilor de
adresare cerute de domenii specializate, etc.
Cum se utilizeaza UMLNotatiile suporta documentarea modelelor folosite in SDP, ca si comunicatia intre modelePentru categorii diferite de participanti la procesele software, UML poate reprezenta procesele software, UML poate reprezenta instrumente diferite:n Schitan Plann Limbaj de programare
UML ca schitaAspecte esentiale in dezvoltarea unui sistem software pot fi comunicate simplu si rapidO schita poate fi folosita in ambele sensuri ale unui SDP:unui SDP:n Forward Engineering (FE): se deseneaza diagrame
UML inainte de a se scrie codn 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 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 UMLTrebuie facuta rapid si colaborativDaca se folosesc instrumente software (tools): n acestea pot fi generale sau specializaten dar nu foarte puternice (de ex., programe de
desenare)
UML ca planDiagramele UML folosite ca plan al dezvoltarii unui sistem software sunt complete si riguroasen se respecta strict regulile formarii diagramelor UML
Instrumentele software folosite sunt mult mai 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 planificarePlanurile trebuie sa aiba si un caracter definitiv pentru a putea fi folosite in codificareIn FE: planul se face de catre un arhitect de sistem (designer) – in general un “senior developer” care (designer) – in general un “senior developer” care proiecteaza pentru o echipa de programatorin 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 limbajAutomatizarea programarii
Multe instrumente CASE asigura, intr-o anumita forma, generarea unei parti din cod pe baza planurilorPrin aceasta:n Se automatizeaza constructia unei parti a sistemuluin Se automatizeaza constructia unei parti a sistemuluin 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 UMLScopurile de adresabilitate la necesitatile SDPs:1. Crearea unui limbaj vizual, expresiv, care sa permita
atat dezvoltarea, cat si schimbarea modelelor2. Furnizarea mecanismelor de extensibilitate si
specializare pentru extinderea conceptelor de bazaspecializare pentru extinderea conceptelor de baza3. Suportul specificatiilor independente de limbajele de
programare sau procesele de dezvoltare particulare4. Asigurarea unei baze formale pentru intelegerea
limbajului de modelare5. Incurajarea aparitiei de instrumente de modelare
obiectuale6. Suportul conceptelor de dezvoltare abstracte
A1: Crearea unui limbaj vizual complet si expresiv
Acesta trebuia sa defineasca:n Modul de dezvoltare/ modificare a modelelorn Semantica, pentru asigurarea aplicarii consistente a
modelelor/ elem. de modelareReprezentarea vizuala, pentru a facilita adoptarea si n Reprezentarea vizuala, pentru a facilita adoptarea si utilizarea
Limbajul trebuie sa fie:n Complet, gata de utilizare imediata, fara customizare
prealabila, pentru majoritatea proiectelorn 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 bazaRegula 80/20:n Putem construi 80% din sisteme cu 20% din
conceptele ce pot fi imaginate; acestea sunt 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 concepten asigura posibilitatea definitiilor multiple
UML suporta customizarea unui concept prin UML suporta customizarea unui concept prin specializarea uneia sau mai multor definitii ale salen Specializarea = refolosirea unei definitii existente cu
stergerea si/sau adaugarea de noi elemente
Se pot defini profile
Profile UMLProfilul 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 implementareLegarea UML de o implementare ar avea drept consecinte negative:consecinte negative:n Indepartarea celor ce nu folosesc un limbaj/ proces
particularn 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 POOMaparea se face intr-o maniera care sa permita independenta specificatiilor UML de limbaje, prin profilen 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
implementaren Permite ambelor sa evolueze in ritm propriu
A4: Asigurarea unei baze formale pentru limbajul de modelare
Limbajul trebuie definit la un niveln Precis – pentru a permite definirea unei solutiin Accesibil - pentru a permite utilizarea sa
De exemplu, standardul UML folosesteDe exemplu, standardul UML folosesten diagrame de clase pentru a reprezenta definitiile
formale ale obiectelor si relatiile dintre elen un text ce detaliaza optiunile de semantica si
notatie, ce suplimenteaza fiecare diagrama de clasen 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)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 toolAceasta 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 executien instrumente de management pentru BDn verificarea sintaxei si a modelului
Fata de cele vechi care doar desenau diagrame, Fata de cele vechi care doar desenau diagrame, noile tool-uri asigura n verificare sintactica pentru instructiunile OCLn sincronizarea diagramelor si generarea coduluin facilitati de reverse engineeringn import din alte medii, export de rapoarte HTML/XMLn 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 Componenten Colaborarin Cadre (frameworks)n Sabloane (patterns)
Asigurand potentialul viitor e facilitata evolutia tehnologicaUML nu e o “mostenire grea” ce trebuie carata in viitor odata cu alte tehnologii vechi
Delimitarea domeniului UML1/ 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 /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 UMLSe 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 proprietaren Rational Unified Processes (RUP)
n eXtreme Programming (XP)
n Agile Methodologies (AM)
A doua frontiera UMLDesi UML si limbajele OOP au o baza si concepte comune, nu sunt legate
De exemplu:n Java nu suporta mostenirea multipla (C++ da)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 UMLUML nu se substituie altor tehnici de modelare, ca BPR (Business Process Re-engineering) sau E/R (Entity/Relationship)
Similaritatile structurale pot fi exploatate totusi 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