UNIVERSITATEA TEHNICA A MOLDOVEI

Departament ISA

Raport
Proiect de an
la „Analiza și Modelarea Orientata pe Obiect”

Теmа:
“Programare a clientilor la un cabinet medical.”

Finalizat: studenta gr TI-161 FR

Racovet Elita
Verifica : Melnic Radu

Chisinau 2018
Programare a clientilor la un cabinet medical.

Introducere:
Enterprise Architect furnizeaza capabilitati de modelare pentru urmatoarele
medii:
- Sisteme IT si Business
- Inginerie pentru Software si Sisteme
- Medii de dezvoltare in timp real.
 Limbaj UML - descrierea grafică a modelului în domeniul dezvoltării de
software, modelării proceselor de afaceri, designului sistemului și structurii
organizaționale.
Enterprise Architect este un software de tip CASE pentru design-ul și construcția
sistemelor software, bazat pe UML. Acest pachet prevede modelarea completă a
ciclului de viață pentru:

- afaceri și sisteme IT;

- software și ingineria sistemelor;
- integrarea dezvoltării în timp real.

Integrînd capacitătile de gestionare a cerintelor, Enterprise Architect ajuta la

urmaăirea specificațiilor la nivel înalt pentru analiza, proiectarea, implementarea,
testarea si intreținerea modelelor folosind UML.
Enterprise Architect este un instrumest grafic, proiectat pentru a ajuta echipele,
construind sisteme robuste si întreținute. Utilizînd calitatea înaltă, integrarea
raportării si documentării poate oferi o viziune imprăștiată cu ușurintă și precizie.

Folosind Enterprise Architect, putem efectua inginerie înainte și înapoi a claselor

ActionScript, C ++, C #, Delphi, Java, Python, PHP, VB.NET și Visual Basic,
sincroniza codul și elementele de model, proiectați și generați elemente de bază de
date. Documentația în format rtf standard poate fi rapid creată de la modele și
importată în Word pentru editare finală, generarea de documente HTML este, de
asemenea, disponibilă.
EA suportă toate modelele / diagramele UML 2.0. Acesta poate fi utilizat pentru a
modela procesele de afaceri, site-urile web, interfețele utilizatorilor, rețelele,
configurațiile hardware, mesajele etc., estimează cantitatea de muncă implicată în
lucrul cu proiectul în ore, evidența și urmărirea cerințelor, resurse, planuri de testare,
defecte și solicitări de modificare.
astfel EA este un instrument de ultimă oră care susține toate aspectele ciclului de
dezvoltare, oferind trasabilitate completă de la designul inițial la plasare și suport.
Oferă, de asemenea, suport pentru testarea, urmărirea și gestionarea modificărilor.

Noutati:
In program Enterprise Architect permanent sunt schimbari. Si mai jos eu o sa arat
ultime schimbari :

 Modificări și remedii pentru Build 1425

 Securitatea utilizatorilor și conectare
 Suport adăugat pentru conectarea la Securitatea utilizatorilor utilizând
OpenID
 A fost adăugată capacitatea de a utiliza acreditările utilizatorului
furnizate la promptul de securitate http pentru modelele cloud pentru a
fi utilizate ca acreditări de securitate
 A fost adăugată restricție opțională pentru a solicita autentificarea
utilizatorilor model prin autentificare Windows sau OpenID
 Opțiunea adăugată pentru a menține automat lista de utilizatori
disponibili pe baza grupurilor Windows Active Directory sau OpenID
 Opțiunea adăugată pentru a permite utilizatorilor unui model să-și
păstreze datele de conectare pentru modelul curent, astfel încât să nu
mai fie nevoie să fie reintrodus
 Butonul curent de utilizator adăugat în partea dreaptă sus a panglicii
pentru a oferi acces la o serie de funcții legate de securitate
 Îmbunătățiri pentru verificarea încuietorilor în diferite situații
 Cod Miner
 Noi opțiuni de configurare din script-urile de executare a analizorului
pentru a utiliza un set de biblioteci de coduri disponibile pentru
interogare
 Creați biblioteci pentru fișierele C ++, C #, Java sau XML
 Specificați un set diferit de macrocomenzi pentru fiecare bibliotecă,
dacă este necesar
 Transferați opțional bibliotecile și gestionarea într-un server comun
(care va fi inclus împreună cu Pro Cloud Server)
 Definiți o bibliotecă de interogări reutilizabile pentru a prelua
informații contextuale pe baza codului importat
 SysML Parametric Editor de expresii
 Introduceți o expresie pentru un bloc de constrângeri, iar EA poate
defini automat parametrii necesari pentru aceasta
 Creați mai multe proprietăți, inclusiv proprietăți de constrângere, și
definiți cu ușurință modul în care proprietățile individuale sunt
cartografiate unele cu altele
 Noțiuni de bază
 Pagina de start simplificată pentru a acorda atenție celor mai utilizate
elemente
 Stilul de dialog vizual și noul document EA 14 Features nu vor mai fi
afișate când EA pornește pentru prima dată
 Browserul de proiecte oferă acum o scurtătură pentru a deschide un
proiect atunci când nici un model nu este deschis
 Versiunea de pornire simplificată de pornire
 Project Browser
 Suport adăugat pentru crearea de proiecte în Browserul de proiect
folosind Toolbox
 Ordonările de sortare
 Procesul de selecție a browserului de proiect a fost actualizat pentru a
asigura că modificările din alte ferestre sunt salvate înainte de
modificarea selecției
 Mai multe meniuri context de selecție oferă acum meniul Collaborate
și opțiunea pentru blocarea elementelor
 Reîmprospătați conținutul unui pachet utilizând F5
 diagrame
 Sa adăugat un tip de diagrama UI simplă
 Opțiunea adăugată pentru a înlocui tema utilizatorilor atunci când
salvați imagini de diagrame pentru WebEA
 Mai multe meniuri context selectare include acum Collaborate meniu
 Îmbunătățiri ale manipulării obiectului Proxy Connector
 Diagrama de redare
 Limitele de pagină sunt acum ascunse pentru toate diagramele în mod
implicit
 Pachetele se supun acum opțiunii Show Stereotype Icons
 Câteva tipuri de clasificatori sunt actualizate pentru a afișa numele în
italice atunci când sunt rezumate
 Câteva tipuri de elemente sunt actualizate pentru a nu sublinia numele
atunci când li se dă un alias
 Obiectele fără nume sau nume de clasificator își vor face acum numele
ca un caracter de colon subliniat ':'
 Diverse diagrame imbunatatiri cadru
 Import / Export XMI
 Îmbunătățiri ale importului canonic XMI
 Îmbunătățiri la importul XMI cu ghiduri de bandă
 Îmbunătățirile la exportul Ecore
 Cod
 Codul sursă Editorul "Du-te la definiție" afișează corect semnăturile de
funcționare
 Îmbunătățirile privind importul și exportul de la VHDL
 Generarea spatiului de nume de PHP sa imbunatatit
 Generarea Python actualizată pentru a permite generarea codului de
operare
 Generarea de compoziție a schemelor dateTime este acum mapată la
xs: dateTime
 transformări
 Transformarea conectorului Realizare sa îmbunătățit
 Suport extins pentru macro-urile construite în TRANSFORM_TAGS
 Simulare
 Adaugat tip de hyperlink de tip simulare
 Simularea pachetelor mari a fost îmbunătățită
 Simularea manuală a modelelor utilizând funcția de primire BPMN sau
UML AcceptEventAction a fost îmbunătățită
 Tehnologia bazei de date
 Secvențele SQL Server pot fi acum importate din diferite scheme
 Tabela Spațiu tabelă și Proprietar sunt acum editabile în fereastra
Proprietăți
 Validarea modelului
 Verificări îmbunătățite pentru conectori de implementare, activare,
pachet de import și pachet de îmbinare pachet
 Regulile UML sunt ignorate în momentul validării modelelor non-
UML
 Integrarea datelor externe
 Sursa de date externe Integrarea poate fi acum utilizată în modele non-
cloud
 Asigurați-vă că discuțiile incluse în datele externe sunt vizibile
 Cartografierea ServiceNow sa îmbunătățit
 Încărcarea elementelor indică acum starea într-un singur cursor de
așteptare
 Comparație de bază
 Etichetate diferențe note de valoare acum raportate
 Porturile redefinite / refolosite nu mai produc false pozitive
 Editarea SysML cu compartimente îmbunătățită:
 Elementele afișate în compartimente actualizează ferestrele de
andocare atunci când textul lor este selectat
 Comportamentul cu două clicuri pentru elementul din compartimente
este acum pentru a deschide fereastra Proprietăți fixate
 Următoarele compartimente suportă acest nou comportament:
parametri, porturi, proprietăți de flux, porturi proxy, porturi complete
și caracteristici direcționate
 Elemente încorporate
 Descărcarea unui element care conține elemente încorporate pe
diagramă arată acum fereastra de puncte de interacțiune pentru a
permite adăugarea elementelor încorporate
 Fereastra Docked Interaction Points permite acum afișarea
proprietăților copilului pentru proprietățile derivate de la tipul părinte
 Docked Features lists improved:
 Tasta Enter se mută acum la fereastra de proprietăți docked pentru a
permite editarea tuturor proprietăților
 Tasta F2 deschide acum editorul in-line pentru proprietatea selectată în
prezent
 Editarea parametrilor la o recepție se mută în editorul pentru atributele
de semnal
 Îmbunătățirea comportamentului atunci când se mișcă selecția
Browserul de proiect dintr-o caracteristică la elementul părinte
 Funcția de dialog restaurat pentru utilizatorii care preferă editarea
atributelor și a operațiilor într-un dialog autonom:
 Accesibil prin comanda panglică: Design> Element> Funcții> Dialogul
funcțiilor
 Dialogul Stiluri vizuale (Start> Vizualizare> Stil vizual) include acum
opțiunea pentru "Preferințe dialoguri proprietate"
 Afișează dialogul Caracteristici în loc de fereastra de andocare pentru
dublu clic sau Enter pe o diagramă, F9 și F10
 ArchiMate
 Elementele de prindere ale elementelor de motivare ArchiMate 3 nu
mai sunt întinse
 Elementele ArchiMate 3 nu mai oferă comanda "Conversie în instanță"
 Tehnologia de autor
 Proprietățile scriptului de proprietate adăugate pentru a obține nume de
elemente chiar și de utilizator a solicitat afișarea Alias:
 # # ActualName
 # # Source.ActualName
 # # Target.ActualName
 # # Classifier.ActualName
 # Classifier.Name # proprietate actualizată pentru a se potrivi
comportamentul altor proprietăți care furnizează aliasul când este
activată funcția Utilizare alias dacă este disponibil
 Script script # Proprietatea RectangleNotation # poate fi acum furnizată
o valoare implicită utilizând proprietatea metype _UCRect în profiluri
 Script script #RectangleNotation # proprietate disponibilă acum pentru
tipuri suplimentare, inclusiv Object
 Proprietatea de tip stereotip _instanceType care specifică un stereotip
de pachete va fi acum ignorată
 Proprietăți suplimentare adăugate la ferestrele de dialog Profil helper:
 _defaultAttributeType
 _meaningForwards
 _meaningBackwards
 _UCRect
 Formatele scripturi pot specifica acum textul dintr-un subset ar trebui
redat ca caractere aldine și / sau cu caractere cursive
 Exportarea profilurilor UML actualizate pentru a susține coerența între
generații:
 Stereotipurile cu mai multe generalizări sau mai multe relații
stereotipizate comandă acum xml după numele țintă
 Simbolurile stereotipe nu mai exportă date binare mai mari decât este
necesar
 Profilurile suportă acum extinderea cazului de utilizare includ și
extindeți conectorii
 Documentație
 Câmpuri noi disponibile în șabloanele "Conținut - Fișiere" pentru
raportul HTML:
 # LINKPATH # - Calea completă a fișierului
 # FILENAME # - Numai numele fișierului
 Câmpuri noi disponibile în șabloanele de asociere pentru raportul
HTML:
 # ELEMNAME # - Numele elementului care face referire
 # LINKREF # - Obiectivul unui hyperlink la elementul specificat
 Elementele listei de verificare generate acum pentru raportarea HTML
într-un format mai prietenos
 tratat acum ca un alias pentru <> în rapoartele HTML
 Elementele de referință ale atributelor și ale operațiilor asociate
tagurilor generează acum hiperlegături în rapoartele HTML
 Generarea unui raport HTML pe un model mare nu mai arată o eroare
de bază de date
 Lista de structuri de specificații structurate generează acum
hiperlegături către documentație
 Generarea de documente generează acum diagrame copil în comanda
Browser proiect
 Filtru element Atribuiți valorile inițiale disponibile acum
 Filtru element pentru Test.Class acceptă acum acceptă numere întregi
separate prin virgulă ca argument la "Unul din ..."
 Șabloanele de generare de documente afișează acum un indicator
modificat în fila sa imediat după modificări
 Generarea de marcaje interne îmbunătățită pentru a îmbunătăți
manevrabilitatea atunci când documentele sunt deschise în LibreOffice
 Schemele de diagrame pentru schemele SysML și mașinile de stat nu
vor mai putea fi accesate în WebEA pentru a se asigura că diagramele
pot fi derulate pe dispozitive iOS
 Automatizare
 DiagramObject.Update () a fost modificat pentru a îmbunătăți
poziționarea elementelor wireframe și a altor elemente încorporate
atunci când diagrama nu este deschisă
 Element.Update () actualizează acum afișarea browserului de proiect a
numelui clasificatorului
 Revenirea la FALSE din transmisia OnPreNewElement nu mai afișează
un avertisment pentru utilizator
 Funcțiile API pentru aplicarea / eliberarea blocărilor pentru utilizatori
și grupuri, acum returnează FALSE fără a face modificări pentru
utilizatori fără permisiunea de a schimba încuietori
 EnumXMIType.xmiARCGIS adăugat pentru a permite exportul de
ArcGIS XML utilizând Interfața de automatizare
 Hiperlinkul "Căutați fișierul" acceptat în documentația generată
 Mai multe modificări
 Lista de verificare a editorului de taguri cu valoare adăugată aplică
acum ordinea definită pentru elemente
 Diagrama de proprietăți diagrame afișează acum timpul creării
diagramei
 Poziționarea inteligentă a fost actualizată pentru a preveni ca obiectele
să fie prinse de marginea dreaptă a unui obiect atunci când se
deplasează aproape de stânga sus
 Repository.GetContextItem actualizat pentru a gestiona faptul că nu
este disponibil niciun obiect atunci când este apelat în timpul schimbării
contextului
 Diferite îmbunătățiri ale editorului de documente
 Rezoluția numelui stereotipului sa îmbunătățit
 Mai multe remedii UI minore
 Au fost îmbunătățite erorile multiple ale bazei de date în diferite tipuri
de depozite
 Modificări și remedii pentru Build 1426
 Corectat comportamentul meniului Quicklinker unde legăturile UML
pot fi eliminate în mod neintenționat
 Diagrama nouă a diagramei va defila la afișarea tipului MDG selectat
anterior la deschidere
 Suport pentru traducerea dialogului SysML "Edit Constraint Block"
 Corectarea comportamentului care a blocat crearea unei diagrame
compozite care nu este definită în perspectiva activă
 Diagramele care afișează cadre nu vor mai permite drag and drop între
diferite pachete / elemente până când cadrul este oprit
 Raportul de testare QA poate filtra acum pe nume care conțin un
apostrof
 Îmbunătățirea manipulării datelor goale atunci când se utilizează
fereastra de construcție Test & Maintenance peste o conexiune cloud
 Editorii de note de bază elimină acum caracterele extinse ascii pentru a
preveni mapările neașteptate în anumite locații
 Corectarea comportamentului editorului Parametrii de funcționare la
poziționarea unui parametru sub rândul "Parametru nou .."
 Fereastra cu elemente de andocare corecte se reîmprospătează atunci
când este deschisă într-o stare plutitoare
 Semnificând textul înainte și înapoi adăugat pentru stereotipurile de
relaționare SysML 1.5
 Timp îmbunătățit efectuat atunci când salvați sau adăugați elemente
într-o diagramă prin pasare drag / copiere
 Prevenite circumstanțe rare care pot duce la pierderea codului actualizat
pentru o operație prin fereastra de proprietăți docked după efectuarea
altor operații
 Timp redus considerabil pentru a efectua o "Sincronizare elemente
structurale"
 Manipularea îmbunătățită a aspectului rutei automate pe o selecție a
diagramei
  Modelarea și simularea cu Biblioteca Modelica
 Suport adăugat pentru referirea unui tip definit în Biblioteca Modelica
 Permiteți includerea unei Biblioteci Modelica într-o simulare (de
exemplu, generați "loadModel (Modelica)")
 Generați ferestre de dialog Documentație și Document
 Eliminat potențialul pentru adăugarea de elemente duplicate în lista
Exclude filtre
 Împiedicați mișcarea excesivă a mouse-ului pe încărcătură
 Timp de încărcare redus

Entităţi în UML
În UML sunt patru tipuri de entităţi:

 de structură;
 de comportament;
 de grupare;
 de adnotare.

Entităţi sunt elementele OO de bază ale limbajului. Cu ajutorul entităţilor este

posibilă crearea modelelor corecte. Entitătile de structură sunt substantivele în
modelurile ale limbajului UML. De regulă ele reprezintă părţi statice ale modelelor
care corespund elementelor conceptuale şi fizice ale sistemului. Există şapte varietăţi
de entităţi de structură:

Clasa (class) este o descriere a unei totalităţi de obiecte cu atribute, operaţii, relaţii
şi semantica comună. Grafic o clasa se reprezintă printr-un dreptunghi în care se
specifică numele, atributele şi operaţiile clase, exemplu este arătat în fig. 3.

NumeleClasei
<<->> AtributPrivat : char
<<#>> AtributProtejat
<<+>> AtributPublic

<<+>> op1()
<<+>> op2()

Fig. 3. Clasa.

Interfaţa (interface) este o totalitate de operaţii care definesc servicii oferite de clasă
sau componentă. În diagrame interfaţa se reprezintă printr-un cerc etichetat cu
numele interfeţei, fig. 4. Interfaţa foarte rar există aparte – de obicei ea este legată
cu clasa sau componenta care o realizează.
Interfata1

Fig. 4. Interfaţa.

Colaborarea (collaboration) defineşte o interacţiune, ea reprezintă o totalitate de

roluri şi alte elemente care produc un efect cooperativ şi care nu se aduce numai la
suma termenilor unei adunări. Grafic colaborarea se reprezintă printr-o elipsă cu
linie întreruptă, interiorul căreia conţine numai numele colaborării, fig. 5.

Colaborare1

Fig. 5. Colaborare.

Cazul de utilizare (use case) este o descriere a consecutivităţii de acţiuni îndeplinite

de sistem care produc un rezultat semnificativ pentru un anumit actor. Grafic cazul
de utilizare se reprezintă
printr-o elipsă cu linie continue în interiorul căreia se conţine denumirea cazului de
utilizare, fig. 6.

Cazul de
utilizare 1

Fig. 6. Caz de utilizare.

Clasa activă (active class) se numeşte o clasă obiectele căreia sunt antrenate în unul
sau mai multe procese sau în şiruri (threads) şi deaceea ele pot iniţia o acţiune
administrativă. Grafic o clasă activă se reprezintă ca şi o clasă simplă, dar se
limitează cu un dreptunghi cu marginile groase şi care conţine numele, atributele şi
operaţiile clasei date, fig. 7.

NumeleClasei
<<->> AtributPrivat : char
<<#>> AtributProtejat
<<+>> AtributPublic

<<+>> op1()
<<+>> op2()

Fig. 7. Clasa activă.

Componenta (component) este o parte fizică a sistemului, care corespunde unui
anumit set de interfeţe şi asigură realizarea lui. Grafic o componentă se reprezintă
printr-un dreptunghi cu anexe, care de obicei conţine numai numele componentei,
fig. 8.

Componenta1

Fig. 8. Componentă.

Nodul (node) este un element real (fizic) al unui sistem care reprezintă un mijloc de
calcul cu un anumit volum de memorie şi deseori cu capacitate de prelucrare a
informaţiei şi care există în timpul funcţionării unui produs soft. Grafic pentru
reprezentarea nodului se utilizează cubul care conţine numele nodului, fig. 9.

Nod 1

Fig. 9. Nod.

Şapte elemente de bază enumerate: clase, interfete, colaborări, cazuri de utilizare,

clase active, componente şi noduri sunt entităţile principale de structură care pot fi
utilizate în diagramele UML. Există şi alte varietăti ale entităţilor de structură: actori,
semnale, utilite (tipurile de clase), procese şi şiruri (tipuri de clase active), aplicaţii,
documente, fişiere, biblioteci, pagini şi tabele (tipuri de componente).

Entităţile de comportament (behaviour things) sunt părţile dinamice ale modelului

UML. Acestea sunt verbele limbajului care descriu comportarea modelului în timpul
şi în spaţiu. Există numai doua tipuri de entităţi de comportament.

Interacţiunea (interaction) este un mod de comportare care constă în schimb reciproc

de mesaje (messages) între obiecte în cadrul unui anumit context pentru a atinge un
anumit scop. Cu ajutorul interacţiunii se descrie atât o operaţie cât şi comportarea
unui set de obiecte. Interacţiunea presupune un şir de alte elemente ca mesaje,
consecutivitate de acţiuni (comportare, iniţializată de către mesaje) şi legături (între
obiecte). Grafic mesajul se reprezintă print-o săgeată deasupră careia se indică
numele mesajului, fig. 10.

CreazaObiect()
Fig. 10. Mesaj.

Automatul (state machine) este un algoritm de comportare care defineşte o

succesiune de stări prin care trece un obiect sau o interacţiune pe parcursul ciclului
de viaţa răspunzînd la diferite evenimente şi reacţiile lui la aceste evenimente. Cu
ajutorul automatului se descrie comportarea unei clase sau a unei colaborări de clase.
Cu automatul este legat un şir de alte elemente: stări, tranziţii de la o stare la altă,
evenimente care sunt entităti ce iniţiază tranziţii şi tipuri de actiuni - reacţii la
tranziţii. Grafic o stare se reprezintă printr-un dreptunghi cu colţuri rotungite care
conţine numele stării sau posibil şi stările intermediare, fig. 11.

Stare 1

Fig. 11. Stare.

Interacţiunile şi automatele sunt entităţile principale de comportament care pot fi

utilizate în diagramele UML. Semantic ele sunt legate cu diferite elemente de
structură, în primul rînd cu clase, cooperări şi obiecte.

Entităţile de grupare sunt părţile organizatorice ale modelului UML. Ele reprezintă
blocuri în care poate fi divizat modelul. O astfel entitate primară este unică –
pachetul.

Pachetele (packages) reprezintă un mecanism universal de organizare în grupe. În

pachet pot fi plasate entităţile de structură, de comportament şi alte entităţi de
grupare. Spre deosebire de componentele care există real, în timpul execuţiei unui
program, pachetele au caracter pur conceptual, adică ele există doar în timpul
elaborării. Pentru reprezentarea unui pachet se utilizează notaţia unei mape cu semn
de carte care conţine deseori numai numele şi doar uneori şi conţinutul, fig. 12.

Fig. 12. Pachet.

Entităţile de adnotare sunt părţile explicative ale unui model UML. Acestea sunt
comentarii destinate descrierii adiţionale, explicaţiei sau observaţiei către orice
element al unui model. Există numai un singur tip de bază al elementelor de adnotare
– remarca.

Remarca (note) este numai un simbol pentru reprezentarea comentariilor sau a

constrângerilor, legate de un element sau de un grup de elemente. Grafic o remarcă
se reprezintă printr-un dreptunghi cu colţul de sus din dreapta îndoit şi care conţine
comentariul textual sau grafic, fig. 13.

Fig. 13. Remarca.

Acest element este entitatea de adnotare principală care poate fi utilizată în modelul
UML. De obicei remarca se utilizează pentru a asigura diagramele cu comentarii sau
cu constrângeri care pot fi reprezentate sub formă de text formal sau neformal. Există
şi variante ale acestui element, de exemplu cerinţe care descriu comportarea dorită
a unui sistem din punct de vedere exterior modelului.

Cazuri de utilizare in aplicatia :

 inscrie pacientului - programeaza pacientii la un doctor dat
 autentificare utilizatorului - permite introducerea contului si a parolei
 administrare sistemului - actualizeaza baza de date si gestioneaza utilizatorii
sistemului
 programare consultatiilor - inscrierea pacientilor autentificate la unul din
doctori
 realizare consutatiilor - inregistreaza in fisa pacientului datele consultatiei
 vizionare serviciilor - permite navigare in lista serviciilor
 vizionare programarii - permite parcurgerea listei cu programari
 facturare serviciilor - calcularea sumelor de plata .

Actorii care interactioneaza cu sistemul:

 administrator sistem - administreaza baza de date a sistemului si

utilizatorii sistemului
 doctor - se autentifica, vizioneaza lista programarilor, consulta pacientii
 pacient - vizioneaza serviciile medicale, se autentifica si se programeaza
la serviciile medicale
 operator - se autentifica, inscrie pacientii la diferite servicii
medicale, emite facturi pentru serviciile medicale efectuate
 vizitator - vizioneaza serviciile medicale.
1. Diagrama generala a cazurilor de utilizare:

Actiunile efectuate de utilizator sunt urmatoarele:

 Introducere identificator utilizator si parola.

 Programul verifica corectitudinea informatiilor introduse.
 Daca informatiile sunt corecte, atunci se permite accesul utilizatorului in
sistem, iar cazul de utilizare se incheie.

Daca informatiile nu sunt corecte:

 Se afiseaza un mesaj de eroare si se solicita reintroducerea informatiilor

pentru autentificare.
 Utilizatorul poate reincerca autentificarea, deci se reia cazul de utilizare cu
fluxul principal de evenimente.
 Utilizatorul renunta, cazul de utilizare luand sfarsit.

Autentificare utilizator: Realizeaza operatia de autentificare pentru un utilizator al

programului.
Actori: medic, operator, pacient, administrator aplicatie.

Administrare: Descrie secventele de actiuni prin care se adauga/modifica/sterg

informatiile despre utilizatorii aplicatiei si prin care se actualizeaza lista de servicii
oferite.

Proiectarea a unei diagrame a cazurilor de utilizare urmăreşte scopurile următoare:

 determinarea limitelor comune şi a contextului domeniului de modelare la

etapele iniţiale de proiectare a unui sistem;
 formularea cerinţelor comune către comportare funcţională a sistemului
proiectat;
 elaborarea modelului iniţial conceptual al unui sistem pentru detalierea de mai
tîrziu în forma modelelor logice şi fizice;
 pregătirea documentărei iniţiale pentru interacţiunea elaboratorilor unui sitem
cu clienţii şi utilizatorii.

Esenţa acestei diagrame constă în faptul că: sistemul proiectat se reprezintă ca o

colecţie de entităţi şi actori care colaborează cu sistemul cu ajutorul aşa numitor
cazuri de utilizare. Totodată orice entitate care colaborează cu sistemul din afară
poate fi numită actor. Aceasta poate fi un om, o instalare tehnică, un program sau
oricare alt sistem care poate fi sursă de acţiune pentru sistemul proiectat în aşa mod,
cum îl determină colaboratorul. La rîndul său, use case-ul este creat pentru descrierea
serviciilor pe care sistemul le oferă actorului. Cu alte cuvinte fiecare caz de utilizare
defineşte o colecţie de acţiuni executate de sistem în timpul dialogului cu actorul.
Totodată nimic nu este spus despre aceea în ce mod va fi realizată colaborare între
actori şi sistem.

2. Diagrama cazului de utilizare administrare:

programare pacientului la doctor

Actiunile executate de utilizator, atunci cand adauga o noua programare, sunt:

 Include cazul de utilizare autentificare utilizator pentru logarea

utilizatorului cu drept de inregistrare programare.
 Selecteaza medicul, data si ora la care se va face programarea.
 Vizualizeaza informatiile introduse si asteapta confirmarea sistemului.
 Salveaza in baza de date.

Actori: pacient, medic, operator.

Flux alternativ de evenimente: Daca inregistrarea informatiilor s-a incheiat cu

eroare, se afiseaza un mesaj corespunzator si se reia cazul de utilizare.

Preconditii: Informatiile despre medicul ce va face consultatia, informatii ce

trebuiesc introduse in baza de date.

Postconditii: Programarea se inregistreaza in baza de date.

Între componentele diagramei cazurilor de utilizare pot să existe diferite legături care
desciu colaborarea exemplarelor unor actori şi cazurilor de utilizare cu exemplarele
altor actori şi cazuri. Un anumit actor poate să colaboreze cu mai multe cazuri de
utilizare. În acest caz actorul dat se adresează către cîteva servicii ale sistemului dat.
La rîndul său un anumit caz de utilizare poate să colaboreze cu mai mulţi actori,
pentru care el acordă serviciul său. Trebuie de observat că două cazuri de utilizare
definite pentru aceeaşi entitate nu pot colabora unul cu altul, fiindcă fiecare din ele
descrie o variantă propie terminală de utilizare a acestei entităţi. Mai mult decît atât,
cazurile de utilizare întotdeauna presupun careva semnale şi mesaje pentru
colaborarea cu actorii în afara limetelor sistemului. În acelaşi timp pot fi definite alte
metode de colaborare între elemente în înteriorul sistemului.

În limbajul UML sunt cîteva tipuri standarde de relaţii între actori şi cazuri de
utilizare:

 relaţia de asociere (association relationship)

 relaţia de extindere (extend relationship)
 relaţia de generalizare (generalization relationship)
 relaţia de cuplare (include relationship)
 relaţia de tip include

Totodată proprietăţile generale ale cazurilor de utilizare pot fi reprezentate prin trei
metode diferite, şi anume cu ajutorul relaţiei de extindere, generalizare şi cuplare.

3.Cazul de utilizare programare:

Flux principal de evenimente: Actiunile efectuate la realizarea unei consultatii sunt:

 Include cazul de utilizare autentificare utilizator pentru logarea medicului

 Posibilitatea vizualizarii istoricului pacientului prezent la consultie
 Completarea fisei pacientului cu informatiile corespunzatoare consultatiei
 Inregistrarea consultatiei in baza de date.

Actori: medic.

Realizare consultatie: Descrie operatia de realizare consultatie.

Preconditii: Pacientul trebuie sa fie programat la consultatie.

Postconditii: Consultatia se inregistreaza in baza de date.

Construirea diagramei cazurilor de utilizare este primul etap a procesului analizei a
obiectului orientat şi proiectări, scopul căruia este de reprezentarea totalităţii de
cereri la comportamentul sistemului proiectat. Specificaţia de cereri la sistemul
proiectat în formă de diagramă a cazurilor de utilizare reprezintă un model
independent, care se numeşte modelul cazurilor de utilizare în limbajul UML şi are
un nume propriu stanadard sau steriotip „UseCaseModel”.

4.Caz de utilizare realizare consultatiilor:

Flux principal de evenimente:

 Include cazul de utilizare autentificare utilizator pentru logarea medicului.

 Se selecteaza ziua dorita pentru a vizuliza programarile.
 Se pot vizualiza informatii despre pacientii programati in ziua respectiva.

Vizualizare programari: Ofera posibilitatea utilizatorului de a vizualiza

programarile dintr-o anumita zi.

Actori: medic.

Preconditii: Informatiile ce privesc programarile ce trebuiesc introduse in baza de

date.
Diagrama cazurilor de utilizare de mai sus, la rîndul său poate fi mai detaliată pentru
precizarea mai adîncă, ce se cere de la sistemul de comandă şi concretizarea
detaliilor pentru realizarea următoare. Detalizarea poate fi executată pe baza
indicării relaţiilor adăugătoare de tipul relaţiei „generalizarea-specializarea” pentru
componentele diagramei deja existente. În sistemul de inregistrarea la un medic
poate avea valoarea independentă şi proprietăţile specifice o categorie independentă
de consultatii.

5.Caz de utilizare realizare consultatie:

Flux principal de evenimente:

 Selecteaza tipul de servicii dorite (consultatii sau analize).

 Vizualizeaza informatiile dorite.

Actori: pacient, vizitator.

6.Caz de utilizare facturare servicii:

Actori: operator.

Flux principal de evenimente:

 Include cazul de utilizare autentificare utilizator pentru logarea

operatorului.
 Fiecare serviciu dorit este introdus in factura.
 Factura este inregistrata in baza de date.

Flux alternativ: daca inregistrarea informatiilor s-a incheiat cu eroare, atunci se

genereaza un mesaj si se propune reintroducerea acestora.

Preconditii: exista o comanda deschisa

7.Diagrama detaliata a cazurilor de utilizare:

Fluxul de evenimente in realizarea obiectivelor aplicatiei

În limbajul UML colaborarea între entităţi se cercetează în aspectul informativ al

comunicaţiilor lor, adică obiectele care interacţionează între ele fac un oarecare
schimb de informaţii. Pentru modelarea colaborării între obiecte în limbajul UML
se utilizează diagramele de interacţiune. Vorbind despre aceste diagrame se iau în
consideraţie două aspecte.

Mai întîi, colaborarea între obiecte poate fi cercetată în timp şi atunci pentru
reprezentarea particularităţilor temporale şi modului de acceptare a mesajelor se
utilizează diagrama de secvenţă.

În al doilea rînd pot fi cercetate particularităţile structurale ale colaborării între

obiecte. Pentru reprezentarea particularităţilor de transmitere şi acceptare a
mesajelor între obiecte se utilizează diagrama de colaborare.
 Stereotipuri de mesaje

În limbajul UML sunt presupuse numai acţiuni standarde, care se execută la primirea
mesajului respectiv. Ele pot fi indicate în diagrama de secvenţă sub forma de
stereotipuri ataşate mesajelor respective şi se scriu în ghilimele. Pentru diagrama de
secvenţă sunt următoarele stereotipuri de mesaje:

 "call" – invocă chemarea operaţiei sau procedurei obiectului-destinatar;

 "return" – returnează valoarea operaţiei executate sau procedurei obiectului
apelant;
 "create" – crează un alt obiect pentru executarea anumitor acţiuni;
 "destroy" – mesaj cu o cerinţă clară de a distruge obiectul corespunzător.Se
transmite în cazul când este necesar pentru a opri acţiunile nedorite a
obiectului din sistemul existent, sau atunci când obiectul nu mai este necesar
şi ar trebui să elibereze resursele alocate lui;
 "send" – trimiterea unui semnal care este iniţializat asincron de către un obiect
şi este acceptat de altul. Diferenţa între un semnal şi un mesaj constă în fapt
că semnalul trebuie să fie descris în clasa obiectul căruia iniţializează
transmiterea lui.

În afară de stereotipuri, mesajul poate avea denumirea sa proprie, a operaţiunii. În

acest caz lîngă săgeată se scrie numele operaţiei cu paranteze rotunde în care se
indică parametrii sau argumentele operaţiei respective. Dacă parametrii lipsesc
atunci parantezele rămîn neapărat după numele operaţiei.

Restricţii temporale în diagrama de secvenţă

În unele cazuri executarea unor acţiuni în diagrama de secvenţă poate necesita

specificaţia unor restricţii temporale către intervalul executării unei operaţii sau
transmiterii mesajelor. În limbajul UML pentru scrierea restricţiilor temporale se
utilizează acoladele figurate. Ca exemple de restricţii în diagrama de secvenţă sunt
situaţii de specificare a timpului pentru transmiterea a unui mesaj de la client către
server sau situatii de prelucrare a cerinţei clientului.

 {timpul_de_aşteptare_a_răspunsului < 5 sec.}

 {timpul_de_trănsmitere_a_pachetului < 10 sec.}

8.Diagrama de secventa pentru programarea pacientului la Doctor:

 Pacientul face autentificare introducand un login si o parola. Sistemul
valideaza datele introduse urmand ca pacientul sa primeasca confirmarea de
logare daca datele au fost corecte. In continuare, pacientul isi alege medicul dorit
dintr-o anumita specializare si vizualizand programul acestuia opteaza pentru o
data si o ora disponibile si convenabile pentru el. Alegerea facuta este inregistrata
in baza de date.
9.Diagrama de secventa pentru consultatie:

Medicul se autentifica introducand un login si o parola. Sistemul valideaza datele

introduse urmand ca medicul sa primeasca confirmarea de logare daca datele au fost
corecte. In continuare, medicul verifica daca pacientul este in baza de date si daca
exista programarea si daca este achitata. Consultatia facuta este inregistrata in baza
de date.

Diagrame de colaborare

Noţiune de colaborare (collaboration) este una din noţiunile fundamentale ale

limbajului UML. Ea înseamnă o mulţime de obiecte care interacţionează în contextul
comun al sistemului modelat. Scopul colaborării constă în specificarea
particularităţilor realizării a celor mai semnificative operaţii în sistem. Colaborarea
determină structura comportamentului sistemului dat în termeni de colaborare a
participanţilor.
Colaborarea poate fi prezentată în două nivele:

 Nivelul de specificare – arată rolurile clasificatorilor şi rolurile asocierilor în

colaborarea dată.
 Nivelul de exemple – indică exemplare şi legături, roluri în colaborare.

Diagrama de colaborare la nivel de specificare arată rolurile elementelor ce participă

în colaborare. Elementele colaborării la acest nivel sunt clase şi asocieri care
reprezintă rolurile unor clasificatori şi asocieri între participanţii acestei colaborari.

Diagrama de colaborare la nivel de exemple reprezintă o totalitate de obiecte

(exemplare de clase) şi legături (exemplare de asociere). Totodată legături sunt
completate cu săgeţile mesajelor. La acest nivel sunt reflectate numai obietce
relevante, adică obiectele care au legătură cu realizarea operaţiei sau clasificatorului.

În colaborare la nivel de exemple sunt definite proprietăţi fiecărui exemplar pentru

participarea în colaborare. În afara de proprietăţile obiectului, în diagrama de
colaborare sunt indicate asocierile între obiectele acestei colaborări. În momentul
cînd clasificatorul necesită descrierea completă a tuturor exemplarilor, rolul
clasificatorului necesită descrierea numai proprietăţilor şi asocierilor pentru
participarea într-o colaborare anumită.

Una şi aceeaşi totalitate de obiecte poate participa în mai multe colaborări. Totodată,
în dependenţă de colaborarea cercetată, unele proprietăţi ale obiectelor pot să se
schimbe aşa precum şi legăturile între ele. Anume acest fapt deosebeşte diagrama de
colaborare de diagrama de clase în care sunt indicate toate proprietăţile şi asocierile
între elementele diagramei.

10.Diagrama de colaborare pentru programare:

11.Diagrama de colaborare pentru consultatie
Diagrami de stare:

În limbajul UML starea este subînţelesă ca metaclasă abstractă, ce se utilizează

pentru modelarea situaţiei aparte, pe parcursul cărei este prezentă executarea
anumitei condiţii.

Starea (state) poate fi în formă de valori concrete a atributului clasei sau obiectului,
în acest caz modificarea anumitelor valorilor va respinge modificarea clasei
modelate sau obiectului.

Trebuie de menţinut că nu fiecare atribut al clasei poate caracteriza starea lui. Ca

regulă, sunt valoroase numai acele proprietăţi a elementelor sistemului, care respinge
aspectul dinamic şi funcţional a comportamentului lui. În acest caz starea va fi
caracterizată ca o condiţie invariată, care include în sine numai cele mai
semnificative clase a atributului pentru comportarea şi semnificarea lor.

D14.12. Dinamica claselor. Diagrama de programare:

 Pacientul se va autentifica in aplicatie si o sa faca o programare alegand
specializarea, medicul, data si ora dorite in functie de disponibilitatile medicului.
Programarea va fi inregistrata in baza de date. Daca pacientul se razgandeste, se
poate reprograma sau poate anula programarea facuta Daca pacientul a achitat
programarea, aceasta se actualizeaza in baza de date ca fiind platita.

13.Diagrama de stare pentru facture:

Daca pacientul achita factura, aceasta devine pentru aplicatie "platita", in caz
contrar devenind "neplatita". Starea facturii va fi inregistrata in baza de date.

Fluxul activitatilor
Pentru o mai buna intelegere a operatiilor, in special a celor complexe, se realizeaza
diagrama de activitate. Aceasta se prezinta sub forma unei scheme logice, care arata
fluxurile de control dintre activitati, si este folosita pentru a modela aspectele
dinamice ale sistemului, modelarea unui proces efectuandu-se pas cu pas.

14.Diagrama de activitate pentru programare:

Pentru o mai buna intelegere a operatiilor, se realizeaza diagrama de activitate.

Aceasta se prezinta sub forma unei scheme logice, care arata fluxurile de control
dintre activitati, si este folosita pentru a modela aspectele dinamice ale sistemului,
modelarea unui proces efectuandu-se pas cu pas.

Diagrama de componente (component diagram)

Toate diagramele cercetate mai sus reflectau aspectele conceptuale de proiectare a

unui model de sistem şi se referiau la nivelul logic de reprezentare. Specificul
reprezentării logice constă în faptul că el utilizează noţiuni care nu au personificare
materială proprie. Cu alte cuvinte diferite elemente ale reprezentării logice (clase,
asocieri, stări, mesaje) nu există în mod material sau fizic. Ele numai reflectă
înţelegerea noastră despre sistemul fizic sau despre aspectele comportamentului
acestui sistem.

Destinaţie principala a reprezentării logice constă în analiza relaţiilor structurale şi

funcţionale între elementele unui model de sistem. Pentru crearea unui sistem fizic
real este necesar a transforma toate elementele reprezentării logice în entităţi
materiale. Pentru descrierea acestor entităţi este destinat aspectul reprezentării
modelare – fizice.
Pentru a explica diferenţa între reprezentarea logică şi fizică vom cerceta procesul
de elaborare a unui sistem de program. În calitate de reprezentare logică iniţială a
acestui sistem pot fi schemele structurale ale algoritmelor şi procedurilor, descrieri
a unor interfeţe şi baza de date conceptuală. Pentru realizarea acestui sistem este
necesar de a elabora codul sursă în anumit limbaj (C++, Pascal, Basic/VBA, JAVA).
Totodată în codul sursă se presupune divizarea acestui cod în module aparte.

Cu toate că codurile sursă iniţiale sunt fragmente ale reprezentării fizice a unui
proiect, ele nu prezintă realizarea finală a lui. Sistemul program poate fi considerat
realizat numai în caz daca el va putea executa funcţiile destinaţiei sale. Aceasta este
posibil dacă codul sursă al unui sistem va fi realizat în forma de module executate,
biblioteci ale claselor şi procedurilor, interfeţelor grafice standarde, fişierelor
bazelor de date. Anume aceste componente sunt necesare pentru reprezentarea fizică
a unui sistem.

Proiectul complet al unui sistem al programului reprezintă o totalitate de modele ale

reprezentării logice şi fizice care sunt coordonate între ele. În limbajul UML pentru
reprezentarea fizică a unui model al sistem sunt utilizate diagramele de realizare
(implementation diagrams) care includ două diagrame canonice: diagrama de
componente şi diagrama de plasare. Specifica creării primei din ele va fi cercetată în
capitolul dat, al ultimei diagrame – în capitolul următor.

Diagrama de componente, spre deosebire de diagramele cercetate, descrie

particularităţile reprezentării fizice a unui sistem. Diagrama de componente permite
determinarea arhitecturii sistemului elaborat prin stabilirea dependenţei între
componentele de program în calitate de care poate fi codul iniţial, binar şi executabil.
În mai multe domenii de elaborare modul şi componenta corespund fişierului.
Săgeţile punctate care leagă modulele arată relaţiile de dependenţa analogice celor
ce au loc la compilarea codurilor sursei iniţiale. Elementul grafic de bază al
diagramei de componente sunt componentele, interfeţele şi dependenţele între ele.

Diagrama de componente se elaborează pentru urmatoarele scopuri:

 Vizualizarea structurii comune a codului sursă a unui sistem de program.

 Specificarea variantei executabile a unui sistem de program.
 Asigurarea utilizării repetate a unor fragmente ale codului sursă.
 Reprezentarea conceptuală şi fizică a schemelor bazei de date.

În elaborarea diagramei de componente participă analiştii de sistem, arhitectorii, şi

programiştii. Diagrama de componente asigură trecere coordonată de la reprezentare
logică spre o realizare a unui proiect în formă de cod sursă. Unele componente pot
exista numai la etapa compilării codului sursei, altele – la etapa realizării lui.
Diagrama de componente reflectă dependenţele între componente la cercetarea
componentelor în calitate de clasificatori.

16.Diagrama de componente

Diagrama componentelor modeleaza dependenta componentei software in functie

de codul sursa, codul binar si componentele executabile.

Diagrama de Pachete

UML furnizează mijloace de grupare a elementelor din cadrul diagramelor, numite

pachete. Într-un pachet pot fi ambalate alte pachete, clase, cazuri de utilizare,
colaborări. Un pachet arată doar structurile pe care le conține. Un pachet nu arată
comportamentul elementelor sale. Un element de modelare aparține unui singur
pachet, dar alte pachete pot consulta acest element. Dacă se arată explicit conținutul
pachetului, atunci numele pachetului se trece pe etichetă.
Un pachet este un mecanism al unor scopuri generale, care organizează elementele
în grupuri. Fiecare pachet are un nume care organizează elementele în grupuri.
Fiecare pachet are un nume care poate fi simplu sau cu cale. Ex: - client (nume
simplu);
- senzor::viziuni (nume cu cale).
Pachetele constituie baza pentru controlul configurației, stocarea și controlul
acestuia. Ele pot conține, spre exemplu, diagrame de clase, ascunzînd detaliile pentru
a putea fi urmărită a rhitectura sistemului; acest mod de lucru este util atît pe durata
dezvoltării programului, cît și mai tîrziu, la întreținerea acestuia; el are o contribuție
importantă în reutilizarea codului.Pachetele de clase reflectă viziunea logică a
sistemului; ele sunt mapate, de obicei, pe pachete de componente, care reflectă
implimentarea lor fizică. Deși în general maparea este directă, se pot face excepții în
următoarele situații:

 un pachet logic este divizat pentru implementare, pentru a fi dezvoltat de firme

diferite;
 mai multe pachete logice sunt unificate, pentru a menține împreună obiectele
ce comunică mult între ele ;
 anumite pachete fizice pot fi adăugate pentru implementarea funcționalităților
de nivel scăzut nereprezentate la analiză, cum ar fi comunicarea în sisteme
distribuite.

Un pachet este reprezentat în UML prin notația caracteristică pentru fișiere; un

dreptunghi , care are atașat în stînga sus . Numele pachetului poate fi trecut în
dreptunghiul mare, în cazul în care conținutul pachetului nu este detaliat, sau în
dreptunghiul mic, dacă în dreptunghiul mare sunt reprezentate elementele sale.
Imbricarea pachetelor mai poate fi exprimată și ca un arbore asemănător cu cel
folosit pentru moștenire, dar care are înspre pachetul ansamblu un semn + în
interiorul unui cerculeț.
Pachetele pot referi alte pachete, relație exprimată printr-o dependență, notată ca
o săgeată cu linie întreruptă însoțită de
stereotipul <<import>> sau <<access>>; rețeaua de utilizare devine astfel un
graf. La nivelul logic, un pachet depinde de altul dacă una sau mai multe clase din
primul pachet denumit client , inițiază comunicarea cu una sau mai multe clase
publice din al doilea pachet denumit furnizor. Relațiile dintre pachete sunt
descoperite dupa ce se elaborează scenariile și se introduc relațiile dintre clase; ele
nu pot fi cunoscute de la începutul etapei de analiză.

17. Diagrama de Pachete

Mentionam ca in cadrul pachetului Business Services se afla situata diagrama
claselor, iar in cadrul pachetului Data Services se afla schema bazei de date.

Diagrama de Desfăşurare (Deployment View)

Arhitectura fizică pe care va fi implementat sistemul, calculatoarele, device-urile

(referite ca nodurile sistemului), împreună cu conexiunile dintre ele, vor putea fi
prezentate în cadrul unei diagrame de desfaşurare. Componentele şi obiectele
executabile sunt alocate în interiorul nodurilor, ceea ce ne va permite o vizualizare
a unitaţilor care se vor executa pe fiecare nod.
Diagramele de desfăşurare sunt utilizate pentru a vizualiza topologia componentelor
fizice ale unui sistem în care componentele software sunt implementate. Așadar,
diagramele de desfăşurare sunt folosite pentru a descrie desfășurarea statica a unui
sistem, și consista din noduri si relația între ele.
Numele de „desfăşurare” se descrie pe sine în scopul de diagrama. Diagramele de
desfășurare sunt utilizate pentru a descrie componentele hardware în care
componentele software sunt vizualizate. Aceste diagrame de desfasurare şi
diagramele de componente sunt strâns legate.
Diagramele Componentelor sunt folosite pentru a descrie componentele, iar
diagramele de desfăşurare arată modul în care acestea sunt dislocate în hardware.
UML este în principal destinat să se concentreze pe artefactele software ale unui
sistem. Dar aceste două diagrame sunt diagrame de construcţii utilizate pentru a se
concentra pe componente software şi componente hardware.
Deci, cele mai multe diagrame UML sunt utilizate pentru a manipula componente
logice, dar diagramele de desfăşurare sunt făcute ca să se concentreze asupra
topologiei hardware a unui sistem. Diagramele de desfăşurare sunt utilizate de către
inginerii de sistem.
Scopul diagramelor de desfăşurare pot fi descrise ca:

1. Vizualizarea topologiei hardware a unui sistem.

2. Descrie componentele hardware utilizate pentru a implementa
componente software.
3. Descrie noduri runtime de prelucrare.

Diagrama de desfăşurare reprezintă vizualizarea implementarii unui sistem. Este

legata de diagrama de componente, deoarece componentele sunt dislocate cu
ajutorul diagramelor de desfăşurare. O diagramă de desfasurare/implementare este
formata din noduri. Nodurile sunt nimic altceva decât produse hardware fizice
utilizate pentru a implementa aplicația.
Diagrame de implementare sunt utile pentru inginerii de sistem. O diagramă de
implementare eficientă este foarte importanta, deoarece controleaza următorii
parametri:

 Performanţă;
 Scalabilitate;
 Mentenabilitatea;
 Portabilitate.

Deci, înainte de elaborarea unei diagrame de implementare ar trebuii identificate

următoarele lucruri:

 Nodurile;
 Relaţiile între noduri.

Urmatoarea diagrama de desfăşurare reprezintă un exemplu pentru a da o idee

legata de implementarea sistemului de management. Aici au fost arătate ca noduri:

 Monitorul;
 Modemul;
 Caching serverul
 Serverele;

Aplicatia se presupune a fi o aplicaţie web care este implementata într-un mediu

cluster folosind serverul 1, 2 şi serverul 3. Utilizatorul se conecteaza la aplicaţie
folosind internetul. Traseul se desfasoara de la serverul de caching catre mediul cu
clustere.
18.Diagrama de desfăşurare

Diagrama de desfasurare reprezinta partitionarea componentelor si obiectelor active

(de exemplu baza de date) pe locatia lor fizica.

Concluzii:
Scopul propus de aceasta lucrare a fost sa se usureze lucru operatorului. Asa fel de
aplicatie ajuta sa facem programare la un doctor de acasa, sa vedem, cind lucru
aceasta este posibil, si in timpul aceala nu deranjam pe doctor, nici pe operator. In
timpu present fiecare are posibilitate sa intre in internet si o sa gaseasca informatia.
In ceea ce priveste pacientul, rularea aplicatiei prin utilizarea unui navigator gen de
Google Chrome, Mozila Firefox, Opera si etc,. permite programarea la doctor intr-
un mod nu numai util dar si placut. In timpul accesarii site-ului utilizatorii care
doresc sa faca efectiv programari se autentifica astfel incat au siguranta datelor
transmise si a programarilor efectuate.
Domeniul medical a fost abordat in multe aplicatii, dar noi trebuie sa mergem într-
un pas cu tehnologii noi, este necesar ca noile aplicatii, sa fie cat mai diversificate si
sa se apropie tot mai mult si intr-un mod prietenos de cerintele acestui domeniu.
Dar pentru ca asa fel de aplicatie sa fie mai mult folosit, este necesar in aplicatie
web.
Efectuind lucrarea aceaste de loborator, eu am facut diagrame, care foarte bine
explica ce si pentru ce. Am facut cunostinta cu un program, care se numeste
Enterprise Architect, cu ajutorul programului, am facut toate diagramele.

Bibliografie:
https://sparxsystems.com/products/ea/14.1/history.html
https://www.slideshare.net/FlorinLeon/limbaje-de-modelare-uml

http://www.cdt-babes.ro/
Reprezentarea UML a claselor. Mihai Gabroveanu