ACADEMIA DE STUDII ECONOMICE BUCUREŞTI

FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N FO R MAT I CE

-CURS 10-

BUCUREȘTI
2019-2020
Proiectarea
sistemelor – partea II -

informatice
Cuprins

✓Proiectarea bazei de date

✓Proiectarea diagramei de pachete

✓Proiectarea diagramelor de implementare

Proiectarea bazei de date

• Se pleacă de la modelul claselor domeniului

• Se alege structura bazei de date
• De obicei se lucreaza cu baze de date relaționale, dar
pot există platforme care lucrează cu baze de date
orientate obiect sau alte sisteme NoSQL
• Se proiectează arhitectura BD (distribuită, etc)
• Se proiectează schema bazei de date
• Tabelele și coloanele în relațional
• Se proiectează restricțiile de integritate referențială
• Referințe prin chei externe
Stereotipuri pentru persistență

• Majoritatea obiectelor stereotipe <entity> trebuie să existe

chiar și după închiderea sistemului
• În timp ce un obiect persistent există dincolo de execuția
sistemului, un obiect tranzitoriu dispare atunci când sistemul
este oprit și este recreat atunci când sistemul este executat
din nou. Majoritatea obiectelor <control> și <boundary> sunt
tranzitorii și nu este necesară salvarea acestor tipuri de
obiecte.
 Maparea obiectelor domeniului pentru SGBDR
1. Maparea tuturor claselor concrete ale domeniului în tabele. De asemenea dacă o clasă
abstractă a domeniului are moștenitori direcți multiplii, mapăm clasa într-o tabelă.
2. Mapăm atributele cu valoare unică în coloane ale tabelei
3. Mapăm metodele în proceduri stocate sau module de program
4. Mapăm agregările și relațiile de asociere cu multiplicitate unu-la-unu într-o coloană care poate
stoca cheia tabelei asociate ex: adăugăm o cheie externă tabelei. Facem acest lucru pentru
ambele capete ale relației.
5. Mapăm atributele multi-valoare și grupurile repetitive în tabele noi și creăm asocierei 1-n de la
tabela originală către cele noi.
6. Mapăm agregările și relațiile de asociere cu multiplicitate mulți-la-mulți într-o nouă tabelă de
legătură între cele 2 tabele originale. Copiem cheile primare din ambele tabele în noua tabelă.
7. Pentru relații de agregare și asociere de tip mixt, copiem cheia primară din partea 1 a relației
(1..1 sau 0..1) într-o nouă coloană în tabela aferentă laturii mulți (1..* sau 0..*) a relației care
poate stoca cheia tabelei de legătură ex: adăugăm p cheie externă tabelei de pe latura multi a
relației.
8a. Ne asigurăm că cheia primară a subclasei este aceeași ca și cheia primară a superclasei.
Multiplicitatea acestei noi asocieri de la subclasă la superclasă ar trebui sa fie 1..1. Dacă
superclasele pot fi instanșiate, atunci multiplicitatea dinspre superclasă către subclasă este 0..1,
altfel este 1..1. Mai mult, o restricție exclusivă (XOR) trebuie să fie adăugată între asocieri.
Facem acest lucru pentru fiecare superclasă
SAU
8b. Aplatizăm ierarhia de moștenire prin copierea atributelor superclasei în toate subclasele și
eliminarea superclasei din model.
Mecanismul persistenței - baze de date

• Persistența poate lua diverse forme. Mai jos prezentăm câteva

tehnici pentru a face obiectele persistente:
• Stocarea într-un fișier flat. O astfel de stocare poate conține datele
utilizate de sistem, dar nu este inteligentă și nu oferă o modalitate de
a căuta în date.
• Stocarea într-un fișier cu mecanism de acces secvențial indexat
sau într-o bază de date care organizează datele prin indexuri care
pot fi utilizate pentru căutarea înregistrărilor de date specifice și
actualizarea acestora.
• Stocarea într-o bază de date relațională, care este cea mai potrivită
pentru datele de afaceri care pot fi ușor formatate în rânduri și
coloane, fiind optimizate astfel pentru căutare.
• Stocarea într-o bază de date orientată obiect, care este mai
potrivite pentru informații științifice sau neformatate.
• Stocarea într-o bază de date NoSQL, care poate gestiona
documente mari, nestructurate și date care pot fi căutate în mod
opțional.
Baze de date orientate obiect

• BDOO sunt capabile să stocheze obiecte împreună cu

valorile atributelor acestora, operațiile și relațiile lor.
• Structurile obiectului din memorie în timpul execuției pot fi
stocate direct „as is” în baza de date. Obiecte binare de
dimensiuni mari (BLOB) și datele complexe nestructurate
(de exemplu, video și audio) pot fi de asemenea stocate în
aceste baze de date fără a fi nevoie de conversie
• De asemenea, stochează relații precum moștenirea,
asocierea și agregarea direct în baza de date.
Baze de date NoSQL

• Nu respectă formatul rând-coloană tradițional al unei baze de date

cu un limbaj de interogare structurat (SQL), (baza de date
relațională), dar este capabil să gestioneze date nestructurate.
• Tehnologia pe care se bazează permite gestionarea volumelor
mari de date.
• Bazele de date NoSQL gestionează o structură de baze de date
complicată și federalizată, care se regăsește de obicei în Cloud.
Structura bazei de date federalizată a bazelor de date NoSQL
este de asemenea înțeleasă ca o arhitectură de baze de date
distribuite
• De exemplu, o relație Client-Cont nu este doar o asociere; Cont
este o colecție de conturi care aparțin clientului și vor fi
încorporate în fiecare Client
Bazele de date relaționale

• Majoritatea aplicațiilor comerciale utilizează în continuare

baze de date relaționale. Acestea oferă mecanisme ideale și
mature pentru stocarea, preluarea și gestionarea datelor
structurate
• Tabelele sunt structural diferite de obiecte și necesită
„traducerea” claselor în tabele
• Cele mai multe instrumente de modelare bazate pe UML
permit arhitectului să marcheze clasele ca persistente, ele
pot fi apoi folosite de instrumente pentru a crea o schemă
inițială a bazei de date relaționale pe baza diagramelor de
clase.
Provocări în stocarea obiectelor în BDR

• Provocarea cheie este că obiectele nu pot fi

direct scrise sau citite din baze de date
relaționale.
 Maparea obiectelor în tabele

• Cea mai simplă formă ar fi o mapare unu la unu.

• Toate atributele unei clase ar fi convertite în coloanele unei tabele.
• Fiecare instanță va fi stocată ca un rând în tabelă.

Clasă

Clasă – Tabelă
Atribut – Coloană
Obiecte – Rânduri
Tabelă
Funcții de persistență de bază

• Funcții CRUD :
• Creare (Create) - folosit pentru crearea unui obiect
• Citire (Read) - utilizat în căutarea unui obiect (înregistrare) pe baza unui
criteriu (cheie)
• Actualizare (Update) - utilizat în căutarea și actualizarea obiectelor
(înregistrări)
• Ștergere (Delete) - utilizat pentru localizarea și eliminarea unui obiect
persistent (înregistrare)

Un obiect <boundary> -
aPatientForm - realizează
operațiunile CRUD pe un alt obiect.
Operațiunile sunt rareori executate
împreună, de obicei pot fi
intercalate cu funcții de afaceri.
Separarea operațiunilor de persistență de
logica de afaceri

• Driver și Car sunt clase entități, dar Drive (comportamentul de afaceri) și

Save (persistență) sunt diferite.

Trebuie separat Drive() de

Save(); ca atare, se creează o
persistență sau clasă de tip
<<Table>> care este separată
de clasele entity.

O entitate conține logică de

afaceri, ex. Drive() în exemplu;
O tabelă conține comenzi de
stocare și recuperare, ex: Save()
în exemplu.
Păstrarea separării între stocarea relațională și
obiecte

• Persistența obiectului trebuie separată de comportamentul obiectului; aplicația va

rămâne complet separată de baza de date
• TransactionManager este clasa „control” care oferă interfața bazei de date

TransactionManager separă
logicul (Car) de fizic
(CarDB), deși nu în
totalitate, așa cum se poate
observa în exemplu.
 Relațiile de moștenire și tabele relaționale

Care sunt
modurile
posibile de a
mapa Pacient și
Doctor?
• O singură
tabelă
• 2 tabele, una
pt Pacient,
alta pt Doctor
• 3 tabele?
Relațiile de moștenire

a) Cel mai simplu mod este să mapăm toate atributele din

clasa părinte, precum și subclase, pe coloanele unui
singure tabele. Spațiu irosit: când un obiect Pacient este
stocat în acest tabel anume, acesta ar lăsa coloanele
specifice Doctorului necompletate.
b) Creați tabele pentru toate clasele pentru copii și adăugați-i
atributele clasei părinte. Această abordare devine mai
dificilă pentru mai multe niveluri de moștenire.
c) Creați tabele separate atât pentru clasa părinte, cât și
pentru copii. Aceste tabele sunt apoi legate cu ajutorul
cheii primare a tabelei care reprezintă clasa părinte
(PersonID)
Multiplicități, clase de asociere și tabele Link
(a)

• Fiecare clasă este transformată inițial într-o tabelă în baza de date

relațională și o nouă tabelă este creată pentru a mapa asocierea;
multiplicități mulți-la-mulți nu pot fi implementate direct.
Multiplicități, clase de asociere și tabele Link
(b)

• Maparea unei clase de asociere variază în diferite cazuri și depinde de

multiplicități.
• Maparea va rezulta în două tabele, cu cheia pentru Doctor adăugată
tabelei de stocare a pacienților. Cu toate acestea, clasa de asociere nu
este mapată într-o tabelă. În schimb, atributele data / ora sunt anexate
tabelei Pacient
Multiplicități, clase de asociere și tabele
Link(c)

• Maparea se va schimba dacă multiplicitățile se schimbă. Aceeași clasă de

asociere, dar multiplicități diferite în asociere vor rezulta în trei tabele în
loc de două. Clasa de asociere este mapată direct într-o tabelă, care
conține chei ale tabelelor Doctor și Pacient împreună cu atributul propriu,
TreatmentDate/ Time.
Maparea agregărilor
• Ambele clase vor fi mapate în tabele individuale. Cheia clasei de asociere va fi anexată
tabelei corespunzătoare: PrescriptionLine va conține PresID, cheia tabelei
Prescription.
• Ori de câte ori un obiect Prescription este distrus, trebuie să aveți grijă să eliminați
toate obiectele PrescriptionLine înrudite.
Agregări partajate și tabele de referință

• Agregarea partajată este un concept de proiectare a bazei de date care

ajută la modelarea (printre altele) a unei „tabele de referință” care conține
date la care fac referire mai multe alte tabele.

• Cheia tabelei Doctor va fi adăugată tabelei SpecialityCode. Cu toate

acestea, cheia tabelei SpecialityCode va fi doar SpecCodeID. Această
cheie nu va include cheia tabelei Doctor.
 ➢ Diagrama de
Diagramele de componente
implementare ➢ Diagrama de
desfășurare
Diagrama de componente
 O diagramă de componente prezintă dependenţele
existente între diverse componente software ce compun
un sistem informatic.
 Aceste dependențe sunt:
➢ statice - au loc in etapele de compilare sau link-editare
➢ dinamice - au loc in timpul execuţiei
 O componentă este un modul software (cod sursa, cod
binar, dll, executabil etc) cu o interfaţă bine definită.
Diagrama de componente
• Modelează arhitectura de ansamblu și
componentele locale din interiorul acesteia.
• Componente ale sistemului, logice și reutilizabile, care
definesc arhitectura sistemului.
• Interfețe bine definite sau metode publice, care pot fi
accesate de alte programe sau dispozitive externe:
interfața programului de aplicație (API).
• O componentă este un modul sau program
executabil (cod sursă, cod binar, dll, executabil,
script etc) și constă din toate clasele care sunt
compilate într-o singură entitate.
Diagrama de componente
• Fiecare componentă este responsabilă pentru un obiectiv
clar în cadrul întregului sistem și interacționează numai cu
alte elemente esențiale, în funcție de necesitate.
• O componentă este trasată ca un dreptunghi cu
compartimente opționale organizate vertical.
• Exista doua tipuri de interfețe ale componentelor:
• Furnizată - oferite de către componetă, se reprezintă cu simbolul
unui cerc

• Solicitată – necesare interfeței, se reprezintă cu un semicerc.

• Subsistem: o versiune specializată a unei componente. El
va moșteni toate regulile aplicabile unei componente. Se
folosește stereotipul ‘system’
Relații în diagrama de componente

• Dependență
• linie întreruptă îndreptată spre furnizorul
componentei
• clasele incluse în componenta client pot moșteni,
instanția sau utiliza clasele incluse în componenta
furnizorului
• pot fi, de asemenea, relații de dependență între
componente și interfețe ale altor componente
• Relația de compunere (componente incluse fizic
în alte componente).
 Diagrama de componente
▪ Exemple de stereotipuri predefinite pentru componente:
▪ <<Main Program>>
▪ <<SubProgram>>
▪ <<Package>>
▪ <<DLL>>
▪ <<Task>>
▪ <<EXE>>
Diagrama de componente – folosirea interfețelor
Interdependențe și pachete
Exemplu 1
Exemplu 2
Diagrama de desfăşurare
• Diagramele de desfășurare sunt utilizate pentru a
reprezenta relațiile dintre componentele hardware
utilizate în infrastructura fizică a unui sistem informatic.
• De exemplu, atunci când este proiectat un sistem
informatic distribuit care va utiliza o rețea pe o zonă
extinsă, o diagramă de desfășurare poate să fie folosită
pentru a arăta relațiile de comunicare dintre diferitele
noduri din rețea.
• De asemenea, acestea pot fi folosite pentru a reprezenta
componentele software și modul în care acestea sunt
alocate peste arhitectura fizică sau infrastructura unui
sistem informatic. În acest caz, o diagramă de desfășurare
reprezintă mediul necesare pentru execuția
componentelor software.
Diagrama de desfăşurare
• Elementele de bază ale unei diagrame de desfășurare
sunt nodurile, artefactele și căile de comunicare.
• Un nod reprezintă orice element hardware care
trebuie inclus în modelul de proiectare a unei
arhitecturi fizică. De exemplu, nodurile pot include
computere client, servere, rețele separate sau
dispozitive de rețea individuale.
• În mod obișnuit, un nod este etichetat cu ajutorul lui
numele și, eventual, cu un stereotip. Stereotipul este
modelat ca element de text înconjurat de simbolurile "<<
>>". Stereotipul reprezintă tipul de nod reprezentat în
diagramă.
• Exemple tipice de dispozitive: dispozitivul mobil, serverul
de baze de date, serverul Web și serverul de aplicații.
Diagrama de desfăşurare
• Un artefact reprezintă o piesă a sistemului informatic
care urmează să fie implementată pe arhitectura
fizică. În mod obișnuit, un artefact reprezintă o
componentă software, un subsistem, o tabelă dintr-o
baze de date, o întreagă bază de date sau un nivel al
aplicației (gestionarea datelor sau interacțiunea om-
calculator). Artefactele pot fi etichetate atât cu un
nume, cât și cu un stereotip.
• O cale de comunicare reprezintă o legătură între
nodurile arhitecturii fizice. Căile de comunicare sunt
stereotipizate pe baza tipului de legături pe care le
reprezintă (de exemplu, LAN, Internet, serial, paralel
sau USB) sau un protocol (de exemplu, TCP / IP).
 Diagrama de desfăşurare – notații
Element Reprezentare
Nodul:
▪ Este o resursă de calcul, de exemplu un computer client, un server,
o rețea separată sau un dispozitiv de rețea individuală.
▪ Este etichetat cu numele său.
▪ Poate conține un stereotip pentru a eticheta în mod specific tipul
de nod reprezentat, de exemplu, dispozitiv, stație de lucru client,
server de aplicații, dispozitiv mobil etc.
Artefactul:
▪ Este o specificare a unei componente software.
▪ Este etichetat cu numele său.
▪ Poate conține un stereotip pentru a marca în mod specific tipul de
artefact (fișierul sursă, tabelă de baze de date, fișier executabil).

Calea de comunicare:
▪ Reprezintă o asociere între două noduri.
▪ Permite nodurilor să schimbe mesaje.
▪ Poate conține un stereotip pentru a eticheta în mod specific tipul
de cale de comunicare reprezentat (Internet, serial, paralel) sau
poate fi doar denumită sau poate fi calificată (agregare,
compunere, dependență, generalizare etc.)
 Diagrama de desfăşurare
• Diagramele de desfăşurare conţin două tipuri de noduri:
dispozitive și mediile de execuţie.
➢Dispozitivele (Device) sunt resurse de calcul cu capacități de
procesare și capacitatea de a executa programe (calculatoare,
laptopuri și telefoane mobile).
➢Mediile de execuţie (EEN – Execution Environment Node) sunt
noduri care conțin medii software capabile să execută alte
entități software precum sisteme de operare, servere web
(Apache sau Microsoft's Internet Information Server (IIS) sau
Java Runtime Environment (JRE)).
 Diagrama de desfăşurare
• Diagramele de desfăşurare pot fi utilizate pentru
reprezentarea componentelor ce pot aparţine anumitor
noduri prin imbricarea grafică a simbolului componentei
în cadrul simbolului ce reprezintă nodul.
Diagrama de desfăşurare - exemplu
Diagrama de Structurarea
pachete modelelor
Cuprins

▪ Premize - necesitatea structurării modelelor

▪ Introducere
▪ Pachete
▪ Pachete și spații de nume
▪ Pachete imbricate
▪ Vizibilitatea elementelor din pachet
▪ Relația de compunere
▪ Relația de import
▪ Considerații finale
Premize – necesitatea structurării modelelor
▪ Dacă o diagramă depășește o anumită dimensiune, există
pericolul ca această să devină prea complicată, și, prin urmare,
greu de interpretat și validat.
▪ Multitudinea de elemente de modelare, indiferent dacă sunt
clase, acțiuni, stări etc., poate fi suprasolicitantă pentru un cititor
uman.
▪ Dacă sistemul, per ansamblu, este format dintr-o mulțime de
subsisteme ale căror elemente sunt doar minimal înrudite între
ele, atunci este de preferat să se folosească un mecanism care
să grupeze corespunzător elementele.
▪ Spre exemplu, poate genera confuzie combinarea într-o
diagramă UML a elementelor specifice interfeței utilizator cu
elementele pentru accesul la baza de date.
Premize – necesitatea structurării modelelor

▪ Se pot defini diferite criterii de grupare a elementelor unui model:

▪ Coeziune funcțională: sunt grupate elementele care au un scop similar.
▪ Structura de distribuție: la dezvoltarea unui sistem distribuit, elementele
sunt grupate în funcție de distribuția lor fizică - de exemplu, elemente de
pe client și elemente de pe server.
▪ Structurarea dezvoltării: structurarea reflectă diviziunea sarcinilor de
dezvoltare. Acest lucru este deosebit de important dacă există o echipă de
dezvoltatori implicați în dezvoltarea sistemului. Responsabilitățile și
interfețele bine definite evită situațiile în care membrii echipei nu își
cunosc sau nu își pot îndeplini sarcinile.
▪ În limbajele de programare a fost introdus conceptul de „spațiu de
nume” (namespace) pentru a permite structurarea.
▪ UML oferă în acest scop diagrama de pachete.
Introducere

▪ Diagrama de pachete ajută la structurarea modelelor UML.

▪ Diferite elementele ale limbajului pot fi grupate în pachete.
▪ Pachetul furnizează un spațiu de nume pentru elementele
grupate.
▪ Numele unui pachet trebuie să fie unic în cadrul unui sistem.
▪ Diagrama de pachete arată pachetele și dependențele dintre
acestea.
Pachete

▪ Pachetele sunt folosite pentru organizarea sistemelor care conțin

diagrame, documentație sau alte livrabile.
▪ Un pachet ne permite să grupăm elemente de modelare, cum ar fi
clase, tipuri de date, activități, stări etc., dar poate conține și alte
pachete.
▪ Pachetele pot apărea și ca parte a altor diagrame.
▪ Notația pentru un pachet este un dreptunghi mare cu un dreptunghi mai
mic în colțul din stânga sus. Dreptunghiul mare conține elementele pe
care pachetul le grupează
▪ Notații alternative:
Pachete și spații de nume

▪ Un element din modelul UML poate fi inclus în cel mult un pachet.

▪ Această includere într-un pachet definește spațiul de nume în care un
element este vizibil.
▪ Numele unui element trebuie să fie unic în interiorul unui spațiu de
nume.
▪ Cu toate acestea, diferite elemente pot avea același nume în diferite
spații de nume. Astfel, dacă pachetul P1 conține o clasă C, acesta nu
poate fi confundat cu clasa C din pachetul P2. Apartenența la pachet
este astfel un factor de calificare, permițând o diferențiere clară între
elemente diferite cu același nume.
▪ Numele unic al unui element este specificat având ca prefix numele
pachetului, astfel: P1 :: C și P2 :: C.
Pachete imbricate

▪ Un pachet poate fi reprezentat ca o structură ierarhică de pachete

imbricate.
▪ Modulele atomice pentru pachetele imbricate sunt, de obicei, diagrame
de clasă.
▪ Exemplu de diagramă de pachete care constă din mai multe pachete
imbricate:
Vizibilitatea elementelor din pachet

▪ În esență, elementele unui pachet cu vizibilitate publică sunt accesibile în afara

pachetului, în timp ce elementele cu vizibilitate privată sunt disponibile numai
altor elemente din pachet. Pentru toate tipurile de vizibilitate, se aplică regulile:
▪ Un element public este vizibil pentru toate elementele care pot accesa
conținutul spațiului de nume care îl deține.
▪ Un element cu vizibilitate protected este vizibil pentru elementele care au
o relație de generalizare cu spațiul de nume care îl deține.
▪ Un element cu vizibilitate package este vizibil pentru elementele care se
află în același pachet cu spațiul său de nume.
▪ Un element privat este vizibil numai în spațiul de nume care îl deține.
▪ În UML, vizibilitățile publice, protejate și private corespund unei clase care
este publică, protejată sau privată la nivelul unui pachet Java.
Vizibilitate Sintaxa Java Sintaxa UML
public public +
protected protected #
package ~
private private -
Relația de compunere (containment)

▪ Reprezentarea părților componente ale unui pachet se poate face

vizual prin două metode.
▪ Varianta 1: membrii pachetului sunt evidențiați în interiorul granițelor
pachetului.
▪ Varianta 2: membrii pachetului sunt reprezentați în afara granițelor
pachetului. Se va folosi relația de compunere (containment), având ca
simbol semnul plus (+) în interiorul unui cerc. Din punct de vedere
semantic, această relație este echivalentă cu agregarea compusă.
Relația de import

▪ Relația de import dintre pachete este o relație direcționată între un

spațiu de nume care importă și un pachet importat, care permite
utilizarea de nume necalificate pentru a se referi la membrii pachetului
importat.
▪ Un pachet poate importa elemente ale unui alt pachet sau un întreg
pachet.
▪ Relația de import se reprezintă cu o linie punctată având o săgeată la
capătul pachetului importat.

Pachetul Aplicatie Web va putea folosi elementele din pachetul

Prezentare fără nume calificate.
Relația de import - vizibilitate

▪ Vizibilitatea importului unui pachet poate fi publică sau privată.

▪ Dacă importul pachetului este public, atunci elementele importate vor fi
adăugate în spațiul de nume și vor fi vizibile în afara spațiului de nume.
▪ Dacă importul este privat, atunci elementele importate vor fi adăugate
în spațiul de nume, dar fără a fi vizibile în exterior.
▪ Pentru a specifica vizibilitatea, se afișează un cuvânt cheie lângă
săgeata punctată. Cuvintele cheie predefinite sunt „import” pentru
importul public de pachete și „acces” pentru importul privat.
▪ În mod implicit (fără nicio specificare), valoarea vizibilității este publică.

o Import privat al pachetului

Prezentare
o Import public al pachetului Domeniu
Relația de import – exemplu

P1 importă tot pachetul P2 și doar clasa C3 din pachetul P3

Alte exemple: https://www.visual-paradigm.com/guide/uml-unified-modeling-

language/what-is-package-diagram/
Considerații finale

▪ UML nu tratează diagramele de pachete ca o tehnică separată. De

multe ori este util să le combinăm, prin gruparea altor elemente din
model în pachete diferite din aceeași diagramă.
▪ Situații în care sunt utile diagramele de pachete:
▪ Pentru a crea o imagine de ansamblu a unui set mare de elemente din
model
▪ Pentru a organiza un model
▪ Pentru a grupa elemente conexe
▪ Pentru a separa spațiile de nume
▪ Criterii pentru descompunerea unui sistem în pachete:
▪ Responsabili diferiți - cine este responsabil pentru realizarea căror diagrame
▪ Aplicații sau subsisteme diferite - fiecare cu propriile cerințe specifice
▪ Grupuri de clase cu coeziune puternică - de exemplu curs, descrierea
cursului, instructor, student etc.
▪ Utilizarea unui model arhitectural – ajută la descompunerea pe diferite
niveluri a sistemului, cum ar fi MVC Framework