Documente Academic
Documente Profesional
Documente Cultură
- Notaţii şi meta-modele
- Diagrame UML
- Semnificaţia UML
Ce este UML (Unified Modelling Language)?
UML este un limbaj de modelare grafică, care ajută la descrierea şi
design-ul sistemelor software, în particular al sistemelor software
construite folosind stilul orientat-obiect (OO).
1) ca schiţă (sketch)
2) ca plan (blueprint)
3) ca limbaj de programare
1) UML ca schiţă. Dezvoltatorii folosesc UML pentru a-i ajuta să
comunice anumite aspecte ale sistemului.
Schiţele se pot folosi în forward-engineering, care desenează o
diagrama UML înainte de a scrie codul
Obs. Se vor folosi diagramele de secvenţă dacă cel mai important aspect este
timpul sau secvenţa de mesaje şi vom folosi diagramele de colaborare când
trebuie evidenţiat contextul.
B2) Diagrama de stare (State Diagram)
• Descrie ciclul de viaţă al unui element (al obiectelor, al subsistemelor şi al
sistemelor), prin specificarea stărilor în care se găseşte un element şi a
evenimentelor (mesaje, erori, condiţii care devin adevărate) care îi modifică starea
(tranziţie).
Obs. Este indicat să se construiască diagrame de stare numai pentru clasele din
sistem care au un număr de stări bine definit şi în care comportamentul clasei
este influenţat de acestea. Aceste diagrame intră în modurile de vizualizare design
şi de proces asupra sistemului.
Fiecare view focalizează atenţia echipei de realizatori asupra unui anumit tip de
probleme şi de aspecte privind subiectul tratat şi se adresează unei categorii
speciale de firme sau de instituţii.
Fiecare view este descris folosind un număr de diagrame care conţin informaţii
referitoare la un anumit aspect particular al sistemului.
• Vizualizarea logică tratează din interior sistemul şi descrie atât structura internă
a acestuia, formată din clase, obiecte şi relaţii, cât şi colaborările care apar în
urma schimbului de mesaje între obiecte, pentru a realiza funcţionalitatea dorită.
• Cei care sunt interesaţi de acest tip de vizualizare a sistemului sunt designerii şi
dezvoltatorii.
V3) Modul de vizualizare componente sistem sau implementare
(The implementation or component view)
• View-ul componentelor se concentrează pe descrierea componentelor care
implementează sistemul, dependenţele care există între ele, resursele alocate
acestora, precum şi rezolvarea unor probleme legate de reutilizarea, portabilitatea
codului, informaţii administrative, cum ar fi un desfăşurător al muncii de
dezvoltare.
• Este folosit de dezvoltatorii sistemului, iar în componenţa sa intră diagramele de
componente, care descriu cum este implementat sistemul.
Pentru paradigma de modelare UML, cel mai adecvat este modelul de dezvoltare
a sistemului dirijat de cazurile de utilizare, centrat pe arhitectură, iar abordarea
este iterativă sau cascadă.
Pachete (Packages)
Putem stabili relaţii între pachete, dar numai între tipuri, nu şi între instanţe
(pachetele nu au semantică definită de instanţe).
Nota este ataşată unui element dintr-o diagramă printr-o linie punctată.
O notǎ poate să nu fie conectată, dacă aceasta se referă la întreaga diagramă.
Stereotipuri (Stereotypes)
Exemplu. valorile etichetate ale clasei EXAMENE sunt versiunea şi autorul, iar
constrângerea este perioada de examene.
Reprezentarea grafică a elementelor de modelare
Reprezentarea grafică a elementelor de modelare (continuare)
Reprezentarea grafică a elementelor de modelare (continuare)
Concepţii şi principii
orientate-obiect
CLASE, OBIECTE, INSTANŢE
O clasă descrie structura şi comportarea unei mulţimi de obiecte
similare.
«instance of»
Class Object
ATRIBUTE, OPERAŢII, RESTRICŢII, RELAŢII
(Attributes, Operations, Constraints, Relationships)
Instanţe
Clase
Asocieri
O asociere e o relaţie între diferitele obiecte ale uneia sau ale mai multor
clase.
Compoziţie
Agregare
1)
2)
Schimb de mesage (Message Exchange)
Principiul schimbului de mesaje: Obiectele sunt unităţi independente
care cooperează şi interacţionează prin intermediul mesajelor pe care şi
le trimit unul altuia.
D.p.d.v. fizic, binding e punctul în viaţa unui program la care caller-ul unei
operaţii e dat de adresa de memorie a operaţiei. Uzual, se întâmplă la
compilare sau link-are. Acest tip de binding se numeşte early binding.
În late binding, locaţia de memorie a unei operaţii e determinată doar
când apelul are loc, i.e. atunci când mesajul corespunzător e trimis
obiectului. Prin urmare, asocierea între mesaj şi operaţie apare dinamic la
rulare, nu la compilare.
Moştenirea înseamnă că o clasă moşteneşte toate proprietăţile
supraclasei sale. Îi este permis totuşi să redefinească o operaţie
moştenită şi s-o rescrie cu o nouă definiţie. Care dintre aceste operaţii se
va folosi ca răspuns pentru un mesaj (adică din ce clasă vine operaţia
apelată) se decide doar la rulare.
Polimorfism dinamic (continuare)
Cercuri şi dreptunghiuri
Paradigma OO
- completări -
Clase
Numele claselor este, de obicei, un substantiv la singular, care trebuie
să fie cât mai sugestiv faţă de abstracţia modelată.
Un mesaj este o comunicare între clase via asocieri, aşa cum un stimul
este comunicarea dintre obiecte via legături.
- introducere -
Proces software
3) Modelul RAD
a) Modelul incremental
b) Modelul spirală
Presupune activităţile:
i) Ingineria de sistem şi modelarea: stabilirea cerinţelor pentru elementele
sistemului
ii) Analiza cerinţelor software: trebuie înţelese comportarea software-ului,
interfaţa, performanţele dorite etc.
iii) Design: e de fapt un proces în mai mulţi paşi, ce se concentrează pe :
structura datelor, arhitectura software-ului, reprezentarea interfeţei şi
detaliul procedural (algoritmic).
iv) Generarea codului: care translatează design-ul în program.
“In most projects, the first system built is barely usable. It may be too
slow, too big, awkward in use or all three. There is no alternative but to
start again, smarting but smarter, and build a redesigned version in
which these problems are solved . . . When a new system concept or
new technology is used, one has to build a system to throw away, for
even the best planning is not so omniscient as to get it right the first
time. The management question, therefore, is not whether to build a
pilot system and throw it away. You will do that. The only question is
whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers . . .” (Brooks, F., The Mythical Man-
Month, Addison-Wesley, 1975.)
Concluzii
• Pentru proiecte mari, dar scalabile, RAD necesită resurse umane
importante pentru a crea numărul corect de echipe RAD.
• RAD nu e potrivit când riscurile tehnice sunt mari. Acest lucru apare
când o nouă aplicaţie foloseşte intens o nouă tehnologie sau când un
software nou cere un grad înalt de interoperabilitate cu programele
existente.
Business modeling
Scopul business process engineering (BPE) este să definească
arhitectura ce va permite business să utilizeze eficient informaţiile.
Se analizează şi se specifică Arhitectura datelor
design-ul pentru Arhitectura aplicaţiilor
Infrastructura tehnologică
World view e obţinută prin Information strategy planning (ISP). ISP vede
întreg întregul business ca o entitate şi izolează domeniile business-ului
(ex: inginerie, manufacturare, marketing etc.). ISP defineşte obiectele
de date care sunt vizibile la nivelul întreprinderii şi relaţiile dintre ele .
Domain view se obţine cu o activitate a BPE numită business area
analysis (BAA), care identifică în detaliu datele (sub forma tipurilor
entităţilor, adică a obiectelor de date) şi cerinţele funcţiilor (sub forma
proceselor) ale domeniilor de business în timpul ISP şi stabileşte
interacţiunile dintre ele.
Odată un information system izolat, BPE face o tranziţie spre ingineria
software. Invocând pasul business system design (BSD), sunt modelate
cerinţele de bază ale unui information system şi aceste cerinţe sunt translatate
în arhitectură de date şi de aplicaţie şi infrastructură tehnologică.
Data modeling
Răspunde la un set de întrebări specifice:
• Care sunt obiectele de date primare procesate iniţial de sistem?
• Care e compoziţia fiecărui obiect de date şi ce atribute descriu
obiectul?
• Unde “stau” în mod curent obiectele?
• Care sunt relaţiile dintre obiecte?
• Care sunt relaţiile dintre obiecte şi procesele care le transformă?
Apelează la diagrama relaţiilor dintre entităţi (ERD – Entity Relationship
Diagram)
4GT (Fourth Generation Techniques)
Termenul 4GT cuprinde o gamă largă de instrumente software care au
un lucru în comun: fiecare permite inginerului software să specifice
anumite caracteristici ale software-ului la un nivel înalt. Instrumentul
(tool) generează apoi automat cod sursă bazat pe specificaţiile
dezvoltatorului.
Fiecare cub plasat de-a lungul axelor poate fi utilizat pentru a reprezenta
punctul de plecare pentru diferite tipuri de proiect.
Un “concept development project” porneşte de la miezul spiralei şi
continuă până ce devine completă dezvoltarea conceptului.
Concluzii
• Modelul spirală e o abordare potrivită pentru sistemele de mari
dimensiuni.
• Modelul spirală foloseşte prototipul ca un mecanism de reducere a
riscurilor dar, mai important, permite dezvoltatorului să aplice abordarea
prototipului la orice etapă din evoluţia proiectului.
• Modelul spirală menţine abordarea sugerată de ciclul de viaţă clasic, dar
o incorporează într-un cadru iterativ care reflectă mai realist lumea.
• Modelul spirală cere luarea în calcul a riscurilor tehnice în toate etapele
proiectului şi, dacă se aplică corect, ar trebui să reducă riscurile înainte să
devină problematice.
• Modelul spirală nu este folosit aşa cum se folosesc modelul liniar
secvenţial şi modelul prototipului.
c) Modelul WINWIN
“Eliciting software requirements demands negociation. Successful
negotiation occurs when both sides « win ».”
Modelul spiral al lui Boehm (Boehm, B., “Using the WINWIN Spiral Model: A
Case Study,” Computer, vol. 31, no. 7, July 1998, pp. 33–44) defineşte o serie
de activităţi de negociere la începutul fiecărei treceri în jurul spiralei:
1. Identificarea stakeholders ai sistemului sau subsistemului.
-generalităţi-
Ingineria software cuprinde metodele, instrumentele şi tehnicile folosite pentru
dezvoltarea software.
Software software de sistem: e software-ul care se comportă ca
instrument de ajutor pentru construcţia software-ului de aplicaţie.
Exemple: SO, baze de date, compilatoare etc.
software de aplicaţie: e software-ul care ajută să se efectueze
task-uri utile sau de recreere. Exemple: jocuri, ATM, software de
control în avioane, software pentru e-mail, editoare de texte etc.
c) performanţă înaltă
d) portabilitate
f) fiabilitate sporită
g) livrare la timp
a) Satisfacerea cerinţelor utilizatorilor
Principala problemă e analiza cerinţelor
f) Fiabilitatea
O parte a software-ului e fiabilă dacă lucrează fără să producă lucruri indezirabile.
Uzual se vorbeşte de bugs în software, dar pentru claritate se definesc si termenii:
Obs. Deoarece este practic imposibil de îndepăratare a tuturor bug-urilor, s-a impus
conceptul de good enough software (software suficient de bun), adică lansarea
software-ului se produce când numărul şi severitatea defectelor (faults) devin
acceptabile
Obs. Se estimează că hardware-ul “pică” de trei ori mai repede decât software-ul.
f) Fiabilitatea (continuare)
Sunt anumite aplicaţii care necesită o fiabilitate ridicată, safety-critical systems.
Exemple:
• sistemele pentru controlul avioanelor;
• controlul proceselor critice (software de comunicaţii ce joacă un rol critic în situaţiile
de urgenţă)
• controlul echipamentelor medicale
Temă. Identificaţi sisteme ce trebuie să fie fiabile şi altele care nu trebuie să fie.
g) Livrare la timp
E una dintre problemele majore, poate chiar principala problemă.
Temă. Identificaţi sisteme care sunt mai greu de utilizat şi altele mai uşor de utilizat.
- exemple -
Scopuri urmărite:
• Să se facă distincţia dintre agregări şi
compuneri
• Folosirea corectă a generalizărilor şi
claselor abstracte
• Folosirea corectă a asocierilor
• Restricţii dintre asocieri
• Noi analysis patterns
Se consideră enunţurile:
E agregare.
Poate fi compunere?
E agregare.
Poate fi compunere?
Nu, pentru că multiplicitatea nu e cel mult 1 (un perete poate aparţine la mai
multe camere alăturate)
Obs. Se consideră (pentru completarea multiplicităţii) că o cameră
poate conţine cel puţin un perete (circular).
3. Modemurile şi tastaturile sunt periferice de intrare/ieşire.
E generalizare, cu observaţia că supraclasa e abstractă, dar şi incompletă
(există şi alte tipuri de periferice de intrare/ieşire). Vezi Glosar de termeni
O soluţie imediată
(deşi incorectă) ar fi:
Obs. Contul va fi deschis unei persoane fizice sau juridice. Prin urmare,
PersFizica şi PersJuridica trebuie excluse mutual.
- exemple -
Temă. Modelaţi enunţul : “O ţară are o capitală.”
- exemple -
Temă. Modelaţi enunţurile următoare (îndeplinite simultan) :
Obs1. Soluţia de mai sus nu e totuşi cea mai fericită. De aceea noţiunea de
stare (state) va fi modelată cu ajutorul diagramelor de stare (state
diagram).
Obs2. În diagramele de clasă, singurele elemente dinamice se realizează
prin intermediul operaţiilor.
(continuare)
Obs. Se respectă principiul: “if we can ask an element for its value only, it
concerns a simple attribute; if several questions apply to it, though, an
object that possesses several attributes itself is involved, as well as links
with other objects”.
Obs. Deoarece noţiunea de airport e complexă şi implică nu doar un nume,
ci şi capacitate etc, e de preferat să se creeze clasa Airport decât
atributele DepartureAirport şi ArrivalAirport în clasa Flight.
inapoi
Glosar de termeni
Un element derivat, de exemplu atribute sau asocieri, este precedat de slash
”/”. Un atribut derivat nu va fi stocat în obiectele clasei, ci va fi calculat de
fiecare dată. Vezi figura de mai jos
inapoi
Studiu de caz
Cardul nu beneficiază prin folosirea ATM, ci cel care deţine cardul, aşadar
cardul nu va fi considerat actor.
Aşadar, primul actor va fi posesorul de card (CardHolder)
Pasul 1. Identificarea actorilor (continuare)
CardHolder
Bank Customer
Concluzie. Actorii sunt: Visa AS
Bank IS
Maintenance Operator
Pasul 1 bis. Reprezentarea unei diagrame
Pentru o mai bună înţelegere a celor deduse la pasul 1, e mai utilă
desenarea unei diagrame, pe care o s-o numim diagramă statică de
context (static context diagram)
Pasul 1 bis. Reprezentarea unei diagrame (continuare)
O altă soluţie, mai elaborată, ar fi să considerăm Bank customer ca
specializarea a lui CardHolder. Se rezolvă astfel problema excluderii
mutuale dintre cei doi actori.
Pasul 2. Identificarea cazurilor de utilizare
1) CardHolder:
• retrage bani
2) Bank customer:
• retrage bani
• consultarea soldului
• depozitarea banilor (cash)
• depozitarea cecurilor
3) Maintenance operator:
• reumple cu bani bancomatul
• recuperarea cardurilor care au fost “înghiţite”
• recuperarea cecurilor care au fost depozitate
4) Visa AS:
• niciuna
5) Bank IS:
• niciuna
ATM
Retragere bani
Umple bancomatul
Consultare sold
Recuperează carduri
Depozitează bani
ATM
Retragere bani
Umple bancomatul
Consultare sold
Recuperează carduri
Depozitează bani
Scenarii
Numim fiecare unitate de descriere a secvenţelor de acţiune secvenţă.
Un scenariu reprezintă o succesiune particulară a secvenţelor, care e rulat de
la începutul la sfârşitul unui caz de utilizare.
Un scenariu poate fi folosit pentru a ilustra o interacţiune sau o execuţie a
unei instanţe a unui caz de utilizare.
Pasul 4. Descrierea textuală a cazurilor de utilizare
(continuare)
Înregistrarea descrierii textuale nu e standardizată în UML. Se recomandă:
Rezumat: Acest caz de utilizare permite unui posesor de card Visa (Visa
CardHolder), care nu e client al băncii, să retragă bani în limita zilnică.
Version: 2.2
4. Visa CardHolder introduce pin-ul. 5. ATM verifică dacă datele sunt corecte.
6. ATM cere autorizaţie de la VISA
authorisation system.
7. VISA authorisation system 8. ATM cere Visa CardHolder să introducă
confirmă şi indică limita zilnică de suma dorită.
retragere.
9. Visa CardHolder introduce suma 10. ATM verifică dacă suma e sub limita
dorită. zilnică.
11. ATM întreabă Visa CardHolder dacă
doreşte chitanţă.
12. Visa CardHolder cere chitanţa. 13. ATM returnează cardul către Visa
CardHolder.
A2) Suma cerută e mai mare decât limita zilnică: intervine la pasul 10
11. ATM informează CardHolder că suma cerută e mai mare decât limita zilnică.
Scenariul se reîntoarce la pasul 8.
Postcondiţii:
• nu sunt prea evidente
c) Cerinţe UI (UI Requirements)
Mecanismul de intrare/ieşire disponibil pentru Visa CardHolder trebuie să fie:
• Un cititor de (smart)card.
• O tastatură numerică (pentru a introduce pin-ul) cu tastele “enter”, “corect” şi
“cancel”.
• Un ecran pe care să se afişeze mesajele ATM-ului.
• Taste în jurul ecranului, a.î. posesorul de card să selecteze suma dorită.
• Un distribuitor de chitanţe.
• Un distribuitor de bani.
d) Restricţii nefuncţionale (Non-functional constraints)
Timpul de răspuns:
• Interfaţa ATM trebuie să răspundă în limita maximă de 2 secunde.
• O tranzacţie nominală trebuie să se termine în cel mult 2 minute.
Disponibilitatea
• ATM trebuie să fie accesibil 24/7
• Lipsa hârtiei pentru tipărirea chitanţelor nu trebuie să fie un obstacol pentru un
posesor de card ră retragă bani.
Integritatea
• Interfaţa ATM trebuie să fie destul de robustă pentru a evita vandalizarea.
Confidenţialitatea
• Rata de eroare a procedurii de comparare a numărului de pin introdus cu acela de
pe card să fie sub 10-6.
Pasul 5. Descrierea grafică a cazurilor de utilizare
Se introduc:
-activităţile principale ale
sistemului (prin mesajele
trimise către sistem);
-referinţe la secvenţele
alternative şi de eroare (prin
note).
Organizarea cazurilor de utilizare
Identificarea părţii comune pe care cazurile de utilizare le au în comun şi
adăugarea relaţiei include.
Relaţia extend e opţională, spre deosebire de include, care e obligatorie.
Reprezentare Activitate
Dacă o bară are o singură tranziţie de intrare şi două sau mai multe de
ieşire, aceasta indică faptul că toate tranziţiile de ieşire se petrec o dată cu
tranziţia de intrare. Acest flux se numeşte splitting control.
Dacă o bară are mai multe intrări şi o singură ieşire, aceasta indică faptul că
toate intrările trebuie să se producă înainte să se producă tranziţia de ieşire.
Acest flux se numeşte synchronization control.
5) Culoare
O diagramă de stare poate fi ataşată oricărei clase care are stări bine
identificate şi un comportament complex. O diagramă de stare descrie o
istorie a vieţii obiectelor unei clase şi poate fi considerată un graf, bazată
pe stări conectate prin tranziţii.
O diagramă de stare are o singură stare iniţială, una sau mai multe stări
simple, una sau mai multe stări finale şi tranziţii între stări.
Elementele unei diagrame de stare
1) Stări
Starea acoperă toate proprietăţile statice ale unui obiect şi valorile
curente pentru fiecare proprietate. Toate instanţele unei clase există în
aceeaşi stare. Starea curentă a unui element se numeşte stare activă.
a) simplă
Stare b) iniţială
c) finală
a) Stare simplă: este o condiţie specială sau o situaţie a unui obiect de-a
lungul ciclului lui de viaţă.
c) Stare finală: indică starea unui element la sfârşitul vieţii sale, când el
este distrus. Într-o diagramă de stare, putem avea zero sau mai multe
stări finale. Se reprezintă, în UML, printr-un mic cerc plin, concentric
altui cerc gol, la care sosesc săgeţi de la stările sistemului, astfel:
2) Tranziţii
Tranziţiile sunt relaţiile dintre stări. O tranziţie reprezintă schimbarea
stării sursă a unui obiect, în urma unor acţiuni, datorită producerii unui
eveniment.
Tranziţiile dintre stări se produc în felul următor:
- un obiect este în stare sursă;
- se produce un eveniment (de exemplu recepţionarea unui mesaj);
- se execută o acţiune;
- obiectul intră în starea ţintă.
d) Eveniment – temporal
Un eveniment temporal este o întâmplare care depinde de scurgerea
timpului. El se reprezintă în UML prin cuvântul cheie after, urmat de un
interval de timp care reprezintă timpul scurs din momentul tranziţiei până
la schimbarea stării. Intervalul de timp poate fi redat în limbaj natural,
expresie de timp, sau în orice mod, dar trebuie să fie cât mai explicit.
Această combinaţie after+expresie_timp se trece în semnătura unei
tranziţii, la condiţia de gardă.
- Concepte şi exemple -
Studiu de caz: ceas cu alarmă
1. Putem seta alarma “pornit” sau “oprit”;
2. La timpul setat, alarma sună continuu;
3. Putem opri soneria.
- Concepte şi exemple -
Studiu de caz: ceas digital
În cazul în care mai multe mesaje alternative sunt trimise aceluiaşi obiect,
pentru a scoate în evidenţă că una dintre alternativele respective nu poate fi
aleasă decât una şi ele nu pot exista simultan, în diagramele de secvenţă
linia de viaţă a obiectului destinatar va avea mai multe ramificaţii, fiecare
corespunzând unei alternative.
Exemplu. Să presupunem exemplu cu centrul de închirieri CD-uri şi casete,
adăugăm ipoteza că există 2 tipuri de CD-uri: obişnuite şi speciale. CD-urile
obişnuite pot fi împrumutate pentru o perioadă mai lungă (3 săptămâni), în
timp ce CD-urile speciale mai puţin (1 săptămână).
Iteraţii
Pentru a arăta că un mesaj poate fi trimis în mod repetat se foloseşte un
asterisc poziţionat după numărul mesajului. În plus, după asterisc se poate
indica o clauză de iteraţie (plasată între paranteze drepte), care determină
de câte ori va fi trimis mesajul.
Exemple:
• [n<10]: este echivalentul condiţiei while;
• [not x];
• [i:=1..10]: este echivalentul condiţiei for;
• [y in Y]: mesajul e trimis în mod repetat pentru fiecare y din colecţia Y
Figura de mai jos reprezintă diagrama de secvenţă pentru cazul unui client
care cumpără un număr de produse dintr-un magazin.
Dacă un mesaj care e transmis în mod repetat are ca rezultat transmiterea
unui alt mesaj, atunci transmiterea acestuia din urmă va fi repetată ori de
câte ori e transmis şi primul mesaj, dar acest lucru nu va fi arătat pe
diagramă.
Răspuns: xyxy.
Exemplul1. Ce rezultat va avea figura de mai jos?
Răspuns: xyyxyy.
Concurenţa
Exemplu
Relaţia dintre componente şi clase
Asemănări:
- Au un nume format dintr-un şir de caractere.
- Au instanţe, care au un nume separat prin “:” de numele clasei, respectiv
al componentei.
- Pot realiza interfeţe.
- Pot participa la relaţii de asociere, de generalizare, de dependenţă, de
realizare şi de agregare (clase sau componente incluse în alte clase,
respectiv componente).
Deosebiri:
- Clasele sunt abstracţii ale unui set de atribute şi de operaţii;
componentele sunt părţi fizice dintr-un sistem, rezidente într-un nod. Se
utilizează componente când modelăm un lucru rezident într-un nod; în
celelalte cazuri, folosim, în modelare, clase.
- Clasele au atribute şi operaţii, pe când componentele au numai operaţii,
accesibile numai prin intermediul interfeţelor lor.
- O componentă este implementarea fizică a uneia sau a mai multor entităţi
conceptuale, cum sunt clasele şi colaborările; între componente şi
implementările ei există o relaţie de dependenţă.
Componentele folosite în UML pot fi împărţite în trei categorii:
• Componente fundamentale (desfăşurare) – care formează baza
sistemelor executabile, ca de exemplu: executabile, DLL-uri, controale
ActiveX, JavaBeans, componente COM+, pagini WEB, tabelele bazelor
de date, etc.
• Componente create de utilizator – care sunt produse rezultate din
procesul de dezvoltare şi care formează componentele fundamentale, ca
de exemplu: fişiere cu codul sursă şi de date. Aceste componente sunt
folosite în crearea, în modificarea şi în dezvoltarea executabilelor.
• Componente de execuţie – create ca o consecinţă a folosirii unui sistem
executabil.
UML foloseşte şi stereotipuri standard:
• <<executable>> - pentru o componentă care poate fi executată în
noduri;
• <<library>> - pentru o componentă care reprezintă biblioteci;
• <<file>> - pentru o componentă care reprezintă un fişier de date sau
fişier sursă;
• <<table>> - pentru o componentă care reprezintă o tabelă a unei baze de
date;
• <<document>> - pentru o componentă care reprezintă un fişier
document.
Interfeţe
Componentele au numai operaţii, care pot fi accesate numai prin
intermediul interfeţelor lor. Interfeţele unei entităţi (clase sau componente)
reprezintă un set de operaţii pe care entitatea le pune la dispoziţia celorlalte
entităţi şi care sunt ascunse prin încapsulare.
Reprezentare
Exemplu
componente:
- Interfaţa Utilizator, care furnizează o interfaţă prin care utilizatorul poate
interacţiona cu sistemul;
- Date – pentru implementarea funcţionalităţii datelor memorate;
pachete şi subsisteme:
- Interfaţa Utilizator, care grupează clasele care furnizează interfaţa cu
utilizatorul;
- Utilităţi – conţine date, timpul şi alte clase de utilităţi;
- Date - subsistem pentru prelucrarea datelor.
interfeţe:
IProduse – produse realizate (create sau scrise);
IConsumabile – produse folosite (citite sau distruse).
- pachetul Utilităţi aparţine ambelor componente;
- componenta Date conţine şi subsistemul Date, care este reprezentat
în interiorul componentei (modul doi de reprezentare), în timp ce
pachetul Utilităţi este legat printr-o relaţie de dependenţă de
componenta client Date (modul întâi de reprezentare);
- deoarece între pachetele Utilităţi şi Interfaţă Utilizator există o relaţie
de dependenţă, ele trebuie să facă parte din aceeaşi componentă, altfel
pachetul Interfaţă Utilizator nu va putea fi utilizat.
Diagrame de desfăşurare
Diagrama de desfăşurare descrie structura sistemului în momentul
execuţiei. Ea prezintă dispunerea fizică a diferitelor elemente hardware,
numite noduri, care intră în componenţa unui sistem, şi repartizarea
programelor executabile pe aceste elemente. În diagrama de desfăşurare,
se indică nodurile şi conexiunile unui model.
Noduri
Un nod este resursa care este disponibilă în timpul execuţiei unui sistem
software şi reprezintă un procesor sau un dispozitiv, pe care vor fi
desfăşurate şi executate componentele sistemului.
Un procesor este un nod care poate executa o componentă (calculatoare în
reţea). Fiecare nod trebuie să aibă un nume. La nivelul fiecărui procesor pot
fi identificate procese. Un procesor trebuie să aibă memorie şi anumite
capabilităţi de procesare (dispozitive de calcul, resurse umane, etc.)
Clase de noduri:
- Client – tip procesor, pe care se execută componenta Interfaţă Utilizator;
- ServerBaze – tip procesor, pe care se execută componenta Date;
- Imprimantă – tip dispozitiv, folosită de sistem pentru a lista rapoarte;
Instanţe de clase de noduri:
- Andrei: Client; Ana: Client;
- O instanţă a nodului Server;
- Hp100: Imprimantă.
Organizarea nodurilor şi legăturile dintre ele
Nodurile pot fi organizate în pachete, în acelaşi mod ca şi clasele şi
componentele.
T-connector
Dependenţe de desfăşurare
O dependenţă de desfăşurare este o relaţie de la o componentă, numită şi
componentă client, la un nod, numit nod furnizor, şi indică faptul că nodul
conţine componenta respectivă.
urmează
nota:Integer
Interfeţe
◄ distribuie marfa
Exemplu. Un joc de şah poate avea o clasă «type», care să conţină doar
declaraţiile mutărilor şi coordonatele tablei de şah şi o altă clasă care să
conţină implementarea lor.
Dependenţe
În general, o clasa A depinde de o clasă B dacă o modificare a lui B
poate produce modificarea lui A. Dependenţa se reprezintă cu o linie
punctată cu o săgeată de la A la B.
• Bara de formatare
• Bara de stare
Când lansăm Visio pentru prima oară ni se va afişa o listă de categorii şi template-uri
(numărul lor diferă datorită tipurilor de instalări; aici s-a folosit instalarea typical) care ne ajută să
începem lucrul:
2. Crearea diagramelor UML utilizând aplicaţia VISIO
Accesăm de pe bara standard meniul
File-> New-> Software-> UML Model Diagram
c) Comunicare bidirecţională:
Dând clic dreapta de formă şi se alege din meniul contextual opţiunea UML Shape Displaz
Options, aşa cum se indică în figurile de mai jos:
Pentru a-i da un alt aspect, de exemplu pentru a face o săgeată, se dă dublu clic pe formă. În
fereastra care apare se bifează în Association Ends în coloana IsNavigable, End 1 sau End 2 (după
preferinţă).
f) System boundary. Pentru a-i da un nume sistemului, se va da clic pe numele care apare
implicit (în acest caz “System”) şi se va putea da noul nume.
Într-o diagramă, o astfel de formă se foloseşte ca o limită care înconjoară cazurile de
utilizare. Pentru a-i da dimensiunea dorită, se va da clic pe formă şi se vo rtrage marcajele de pe
perimetrul formei.
Pentru a face o formă în cadrul unui sistem, se va lua acea formă cu Drag&Drop şi se va
introduce în sistem ca în figura de mai jos.
2.2 Desenarea diagramelor de clasă
În panoul din stânga, se alege matriţa UML static structure.
a) Pentru adăugarea unei interfeţe claselor, componentelor sau altor elemente, într-o
componentă de diagramă de clasă sau diagramă de componente şi de desfăşurare, se trage o formă
Interface (reprezentată cu o linie şi cu un cerc) pe pagina de desen.
Se lipeşte sfârşitul de cursorul fără cerc, la o conexiune x din componenta clasă sau alt
element. Se dă dublu-clic pe forma Interface pentru a adăuga un nume, operaţiile şi alte proprietăţi
de valori.
c) Se trage o formă Object pe pagina de desen şi apoi dublu clic pe forma. În fereastra de
dialog UML Object Properties clic pe Object şi se tastează un nume pentru obiect.
Clic pe Attribute Values şi se selectează atributul căruia i se adaugă o valoare dorită şi apoi
clic pe Properties. Se tastează o valoare pentru atribut. Clic pe Attribute Link, se adaugă orice
proprietate dorită şi apoi clic OK. Se repetă ultimii paşi pentru toate atributele care se doresc să fie
adăugate.
Clic New pentru a se adăuga alt parametru sau clic OK pentru a închide cutia de dialog
UML Class Properties.
Ascunderea atributelor şi secţiilor de operaţii ale unei clase se realizează cu clic dreapta pe forma
Class şi apoi clic Shape Display Option.
În caseta de dialog UML Shape Display Options, sub Suppress, se selectează Attributes
pentru a ascunde partea de atribut şi apoi se selectează Operations pentru a ascunde secţia de
operaţii.
Pentru indicarea claselor dintr-un pachet, într-o diagramă pachet se trage o formă
Dependency pe pagina de desen. Se lipeşte sfârşitul de cursor din Dependency fără vârful de
săgeată la o conexiune spre pachet care va dori referinţa claselor în alt pachet.
Se lipeşte sfârşitul de cursor din Dependency cu vârful de săgeată la o conexiune x pe pachet
care conţine ţinta claselor care va fi referinţa. Dublu clic pe forma Dependency pentru a deschide
fereastra de dialog UML Dependency Properties. Sub Name se tastează un nume pentru
dependenţă. Sub Stereotype se alege Import:
Pentru a arăta implementarea unui tip cu o clasă implementată, într-o diagramă de structură
statică se trage o formă Class pe pagina de desen. Dublu clic pe formă. În fereastra de dialog UML
Class Properties clic pe Class şi se tastează un nume pentru clasă. Sub Stereotype se alege Type
şi apoi clic OK.
Se trage a doua formă Class pe pagina de desen. Dublu-clic pe formă. În fereastra de dialog
UML Class Properties clic Class şi se tastează un nume pentru clasă. Sub Stereotype se alege
Implementation Class.
Clic-dreapta pe caseta de implementare şi clic Shape Display Options. În fereastra de dialog
UML Shape Display Options, sub General Option se selectează Realization Link.
Pentru a indica o relaţie de compoziţie între clase se trage o formă Composition din
diagrama de clasă UML în pagina de desen aproape de clasa relatată.
Se duce cursorul lângă diamant către un punct de legătură x din clasă şi celălalt element din
componenta sa. Se duce cursorul fără diamant către un punct de legătură al clasei din componenta
sa. Dublu-clic pe forma Composition pentru a se adăuga un nume şi asocierile adăugărilor de
sfârşit.
De asemenea, se poate indica poziţia adăugând asocierile de final a formelor Binary
Association, Association Class sau N-ary Association. Dublu-clic pe formă. Se selectează sfârşitul
în care se vrea adăugarea compoziţiei diamant şi apoi clic pe proprietăţi. Clic pe Association End şi
sub Aggregation se alege Composite.
2.3 Diagrama de componente şi de desfăşurare
Din panoul din stânga cu diagramele UML se alege prin clic eticheta diagramei dorite, în
acest caz diagrama de componente şi de desfăşurare (Collaboration and Deployment Diagrams).
Pentru toate simbolurile utilizate se foloseşte procedeul “Drag & Drop”, iar pentru a le
completa se dă dublu click pe desen şi se completează conform ferestrei de mai jos astfel: la Name,
numele instanţei şi la Component selectaţi New pentru a completa numele componentei.
[N um e instanta ] : N um e C om ponenta
Desen.cpp Desen.exe
Reprezentarea nodului. Se selectează NodeInstance şi se trage în pagina de desen. Se dă
dublu click pe desen şi se completează numele la opţiunea Name şi la opţiunea Node se dă New
pentru a se alege instanţele ale acestor noduri.
Im p r im a n ta H P100 :
Im p r im a n ta
2.4 Diagrama de colaborare
Din panoul din stânga cu diagramele UML se alege prin click eticheta diagramei dorite, în
acest caz – diagrama de de colaborare (Collaboration Diagram).
Din eticheta aleasă se va extinde o pagină ce conţine toate obiectele (formele) ce pot fi folosite
într-o diagramă de secvenţă.
În continuare se alege pe rând câte un obiect din panoul din stânga şi se trage pe suprafaţa de
lucru. Cu click-dreapta i se completează sau modifică proprietăţile.
Pentru crearea unui obiect se alege din panoul din stânga obiectul cu denumirea Classifier
Role şi se trage pe pagina de lucru.
Se completează numele obiectului în câmpul Name şi se alege clasa din care face parte din
câmpul Classifier. Dacă nu găsiţi clasa respectivă se poate crea una nouă cu butonul New. Se va
deschide fereastra UML Class Properties în care se creează clasa din care face parte obiectul.
Se completează numele clasei în câmpul Name şi eventual alte proprietăţi pe care le găsiţi în
lista din stânga.
Dacă există constrângeri, acestea se pot completa la a doua proprietate Constraints. Pentru
salvarea acestor informaţii se alege butonul OK.
Se va deschide fereastra UML Shape Display Option. De aici se aleg opţiunile care se pot
seta :
Există opţiunea de a afişa numele obiectului sau/şi clasa din care face parte obiectul. De
asemenea se poate ataşa semnul de destructor.
Crearea unui comunicări – Se alege din panoul din stânga obiectul cu denumirea Association
Role şi se trage pe pagina de lucru.
Pentru a modifica proprietăţile se acţionează click dreapta pe săgeată şi se va deschide
fereastra UML Association Role Properties care prezintă în partea stângă o listă cu proprietăţi.
Alegem a doua linie Messages şi în tabelul alăturat completăm denumirea mesajului, direcţia de
orientare a mesajului şi tipul mesajului (simplu, sincron, asincron):
Apoi se apelează butonul Properties din dreapta. Se va deschide fereastra UML Message
Properties. La prima apelare se va deschide automat şi fereastra UML Operation Properties:
Se completează numele operaţiei (în cazul de faţă Print) şi apoi dacă există argumente pentru
această operaţie de apelează din lista din stânga Arguments :
Pentru a adăuga un argument se apelează butonul New din dreapta. Operaţia se va repeta
pentru fiecare nou argument. Se validează cu OK. Se revine în fereastra UML Message Properties:
Din panoul din stânga cu diagramele UML se alege prin click eticheta diagramei dorite, în
acest caz – diagrama de secvenţă (Sequence Diagram).
Din eticheta aleasă se va extinde o pagină ce conţine toate obiectele (formele) ce pot fi folosite
într-o diagramă de secvenţă. În continuare se alege pe rând câte un obiect din panoul din stânga şi
se trage pe suprafaţa de lucru. Cu click-dreapta i se completează sau modifică proprietăţile.
Pentru a crea un obiect se alege din panoul din stânga obiectul cu denumirea ObjectLifeline şi
se trage pe pagina de lucru.
Pentru a se completa sau modifica proprietăţile se dă click-dreapta pe obiect şi se alege
opţiunea Properties. Se va deschide fereastra UML Classifier Role Properties.
Pentru prima proprietate – Classifier Role - se furnizează un nume pentru obiectul ce s-a creat:
Pentru a doua opţiune – Entry – ce simbolizează acţiunea care se produce atunci când
obiectul intră în starea respectivă – se procedează asemănător.
Alte proprietăţi – cele de afişare – se pot seta apelând opţiunea Shape Display Option.
Există opţiunea de a suprima la afişare anumite părţi ale unei stări: de exemplu, porţiunea
Transition (care cuprinde evenimentele standard – de intrare (Entry) şi de ieşire(Exit)).
Pentru crearea unei stări compuse se alege din panoul din stânga obiectul cu denumirea State
si se trage pe pagina de lucru. În structura arborescentă şi pe suprafaţa de lucru va apărea o nouă
pagină în care se vor desena substări concurente, mutual exclusive sau imbricate ale stării.
Pentru a reprezenta o tranziţie se alege forma Transition din panoul din dreapta.
Pentru a modifica proprietăţile se acţionează click dreapta pe tranziţie şi se va deschide
fereastra UML Transition Properties. La Transition se poate modifica numele tranziţiei şi se pot
completa evenimentul/ evenimentele asociate tranziţiei astfel:
Se acţionează butonul Events; se va deschide fereastra UML Events care cuprinde lista
evenimentelor.
Se acţionează butonul New pentru a adăuga un eveniment. Se alege tipul evenimentului. În
fereastra UML Events se completează numele evenimentului. Se revine în fereastra UML
Transition Properties şi din lista combinată Events se alege evenimentul potrivit.
Din lista din stânga se alege a doua opţiune – Actions - pentru a adăuga, a şterge sau a
schimba ordinea înregistrării acţiunilor.
Pentru a adăuga o nouă acţiune se alege butonul New. Se alege tipul acţiunii. Revenind în
fereastra UML Transition Properties se completează numele acţiunii.
Punctele terminale ale unei tranziţii (Transition) se vor lipi de câte o formă de tip State. De
fapt, o tranziţie va face legătura între două stări, vârful săgeţii ce reprezintă tranziţia va fi lipit de
starea în care va ajunge un obiect.
Alte proprietăţi – cele de afişare – se pot seta apelând opţiunea Shape Display Option ca la
diagramele prezentate mai sus.
Există opţiunea de a suprima la afişare anumite părţi ale unei stări: de exemplu, acţiunile sau
evenimentele – Action sau Events.
Pentru a reprezenta o stare iniţială (Initial State) se alege cu click forma Initial State din
panoul din dreapta şi se trage pe pagina de lucru. Starea iniţială va fi legată de altă stare prin
intermediul unei tranziţii (Transition).
Pentru a reprezenta o stare finală (Final State) se alege cu click forma Final State. Starea
finală va fi legată de altă stare prin intermediul unei tranziţii (Transition).
2.7 Diagrama de activitate
Din panoul din stânga cu diagramele UML se alege prin click eticheta diagramei dorite, în
acest caz – diagrama de activitate (Activity Diagram). Din eticheta aleasă se va extinde o pagină ce
conţine toate obiectele (formele) ce pot fi folosite într-o diagramă de activitate. În continuare se
alege pe rând câte un obiect din panoul din dreapta şi se trage pe suprafaţa de lucru. Cu click-
dreapta i se completează sau modifică proprietăţile.
Pentru crearea unei activităţi se alege din panoul din stânga obiectul cu denumirea Action.
Pentru a se completa sau modifica proprietăţile se dă click-dreapta pe activitate şi se alege
opţiunea Properties. Se va deschide fereastra UML Action State Properties care în partea dreaptă
cuprinde o listă cu proprietăţile ce pot fi modificate sau completate.
Pentru prima proprietate - Action State - se poate modifica numele acţiunii:
La alegerea celei de-a doua poziţii – Call Action – se apelează butonul New pentru a adăuga
o acţiune. Se deschide fereastra New Action Type, din care se alege tipul dorit.
Fluxul de control al tranziţiilor indică ordinea acţiunilor în secvenţă. Pentru a reprezenta un
flux de control se alege cu click forma Flow Control din panoul din dreapta şi se trage pe pagina de
lucru. Pentru a modifica proprietăţile se acţionează click dreapta pe fluxul de control respectiv şi se
va deschide fereastra UML Transition Properties care prezintă în partea stângă o listă cu
proprietăţile. La Transition se poate modifica numele tranziţiei şi se pot completa evenimentul/
evenimentele asociate tranziţiei astfel:
Se acţionează butonul Events; se va deschide fereastra UML Events: care cuprinde lista
evenimentelor şi se procedează ca la diagramele de mai sus.
Din lista din stânga alegeţi a doua opţiune – Actions - pentru a adăuga sau şterge sau pentru
a schimba ordinea înregistrării acţiunilor.
Pentru a adăuga o nouă acţiune alegeţi butonul New din partea dreaptă a ferestrei.
Punctele terminale ale formei Flow Control se vor lipi de câte o formă de tip Action State.
De fapt, o formă Flow Control va face legătura între două acţiuni, vârful săgeţii va fi lipit de
acţiunea care a avea loc.
Alte proprietăţi – cele de afişare – se pot seta apelând opţiunea Shape Display Option.
Pentru a reprezenta o stare iniţială (Initial State) se alege cu click forma Initial State din
panoul din dreapta şi se trage pe pagina de lucru. Starea iniţială va fi legată de altă stare prin
intermediul unei tranziţii (Transition).
Pentru a reprezenta o stare finală (Final State) se alege cu click forma Final State. Starea
finală va fi legată de altă stare prin intermediul unei tranziţii (Transition).