Proiectarea sistemelor

informatice

Seminar 10 - Proiectarea
 Diagrama de clase în proiectare
 Proiectarea bazei de date
 Proiectarea interfețelor
1
Diagrama detaliată de
clase
Etapa de proiectare
 Se parcurg pe rând cazurile de utilizare. Se aleg clasele
domeniului care sunt implicate în cazul de utilizare. Se
Diagrama de adaugă noi clase în funcție de specificul implementării.

clase la Se adaugă o clasa controller care sa fie responsabilă pentru

proiectare cazul de utilizare.

Se determină cerințele de vizibilitate a navigării.

Se completează atributele fiecărei clase cu vizibilitate și tip. Se

identifica responsabilitățile fiecărei clase și se completează
metodele specifice.
Exemple de clase stereotipe uzuale
Clasele stereotipe conțin informații adiționale despre semnificația clasei, cu scopul
de a face modelul mai ușor de înțeles.

• entitate (<<entity>>) – o clasă pasivă, care nu iniţiază interacţiuni;

• control (<<control>>) – iniţiază interacţiuni, conţine o componentă
tranzacţională şi este separator între entităţi şi limite;
• limită (<<boundary>>) – este aflată la periferia sistemului, dar în interiorul
său. Reprezintă limita de legătură cu actorul sau cu alte sisteme informatice;
• enumerare (<<enumeration>>) - este folosită pentru definirea tipurilor de
date ale căror valori sunt enumerate.
• primitivă (<<primitive>>) - o formă de clasă care reprezintă tipuri de date
predefinite, cum ar fi tipul Boolean.
Vizibilitatea navigării
• Abilitatea unui obiect de a vedea și interacționa cu alt obiect
• Realizată prin adăugarea într-o clasă a unei variabile referință la obiect
• Apare ca o săgeată pe capătul asocierii – Clientul poate vedea și
interacționa cu Rezervare
Reguli pentru navigabilitate
• Asocierile unu la mulți care indică o relație superior-subordonat
asigură navigarea de la superior la subordonați

• Asocierile obligatorii în care obiectele dintr-o clasă nu pot să

existe fără obiectele din altă clasă asigură, de obicei, navigarea
de la clasa mai independentă la cea mai dependentă.

• Când un obiect are nevoie de informații de la un alt obiect, ar

putea fi nevoie de o sageată de navigare.
Exemplu: transformarea diagramei de clase
Metodele claselor
• Se poate folosi tehnica CRC – Class, Responsibility,
Collaboration cards
• Care sunt responsabilitățile unei clase și cum colaborează cu
alte clase pentru a realiza cazul de utilizare
• Se obțin prin brainstorming
• Se pot folosi diagramele de secvență detaliate – fiecare mesaj
recepționat de un obiect al unei clase trebuie să aibă în
corespondență o metodă în clasa respectivă
Exemplu de carduri CRC
Completarea
metodelor
Protecția în fața schimbării
⮚Un principiu al proiectării este de a separa părțile care sunt stabile de
părțile care suferă numeroase schimbări.
⮚Se separă formularele și paginile din interfața cu utilizatorul care au
probabilitate mare de a se modifica de logica aplicației.
⮚Conexiunea la baza de date și logica SQL care probabil se vor modifica se
păstrează în clase separate de logica aplicației.
⮚Se utilizează clase adaptor care se pot schimba pentru interacțiunea cu alte
sisteme.
Dacă se alege între două variante de proiectare, se va alege varianta care
⮚

oferă o protecție mai mare în fața schimbării.

 Relațiile de asociere la proiectare
• Asocierile indică o conexiune bidirecțională între clase. Ele vor fi implementate ca atribute în
definitiile claselor.
• De exemplu, relația Client- Rezervare ( unu la mulți)
Implementarea relațiilor de agregare: prin referință
• Agregare partajată: un obiect va conține doar o referință la al
doilea obiect; obiectul conținut poate fi referit și de alte obiecte
• De exemplu, Factura- Serviciu
Implementarea relațiilor de agregare: prin valoare
• Agregare compusă: o copie a obiectului agregat
este inclusă, prin valoare. Obiectul conținut nu e
partajat cu alte obiecte
 Implementarea relațiilor de generalizare
• O subclasă moștenește dintr-o superclasă trei elemente specifice: atribute,
operații și relații. O ierarhie practică a moștenirii este de obicei adâncă pe
maxim trei niveluri.
• De exemplu, pentru cele trei tipuri de plăți, mecanismul de moștenire permite
reutilizarea elementelor din clasa de bază, Plata.
• Polimorfism: comportamentul polimorf implică, în timpul rulării, că același mesaj
are efecte comportamentale diferite.
2
Proiectarea bazei de date
- Schema ERD
- Scriptul de creare a BD
 Se pleaca de la modelul claselor domeniului

Proiectarea Se alege structura bazei de date: relațională, orientate obiect, tip graf,
bazei de tip mesaj, perechi cheie-valoare etc

date
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ă
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 realizăm asocierei 1-n de la
tabela originală către cele noi.
Maparea obiectelor domeniului
pentru SGBDR

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 o cheie externă tabelei de pe latura mulți a relației.
8. a. Cheia primară a subclasei trebuie să fie aceeași ca și cheia primară a superclasei.
Multiplicitatea acestei noi asocieri de la subclasă la superclasă ar trebui sa fie 1..1. SAU
b. Aplatizăm ierarhia de moștenire prin copierea atributelor superclasei în toate subclasele și
eliminarea superclasei din model.
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 Card este
stocat în acest tabel anume, acesta ar lăsa coloanele
specifice Cash si Banca necompletate. (varianta din
imagine, preferata de VP)
b) Creați tabele pentru toate clasele pentru copii și
adăugaț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
(id_plata)
 Pasi de urmat in Visual Paradigm
• Pentru clasele persistente se va adauga stereotipul <<ORM Persistable>>
• Se genereaza automat modelul entitate asociere (Synchronize to entity-
relationship diagram)
• Se fac rafinarile dorite pe modelul ERD
• Se generează baza de date in limbajul dorit (sau se generează scriptul DDL)

• Vezi tutorialul pentru Generarea bazei de date pe online.ase.ro

3
Proiectarea interfețelor
- Interfața cu utilizatorul
 Finalizarea diagramelor de cazuri de utilizare şi a unor prime
Proiectarea versiuni stabile ale diagramelor de interacţiune şi de clase.

interfețelor Se recomandă implementarea unui prototip al sistemului informatic.

Acest prototip se numeşte prototip de interfaţă.

Ajută la rafinarea relaţiilor dintre actori şi clasele de interfaţă.

Are rolul de a obţine feedback din partea beneficiarului (clientului)

asupra aspectului vizual al aplicaţiei.
Proiectarea interfețelor
• Primul pas - investigarea aşteptării actorilor asupra interfeţei prin
completarea unor chestionare specifice formate din următoarele
întrebări:
1. ce nivel de pregătire (informatică) necesită actorul pentru a realiza o anumită
funcţionalitate?
2. actorul are experienţă de lucru în medii bazate pe ferestre?
3. actorul are experienţă în utilizarea altor sisteme de automatizare a procesului
modelat?
4. este necesară consultarea unor documente/cataloage în paralel cu utilizarea
aplicaţiei?
5. actorul doreşte implementarea unor facilităţi de tip ‘salvare/restaurare’?
Proiectarea interfețelor
• Scopurile prototipului sunt:
• stabilirea unor cerinţe ale interfeţei pentru funcţionalităţi
cheie ale aplicaţiei;
• se demonstrează clientului (într-o formă vizuală) că cerinţele
proiectului au fost bine înţelese şi sunt realizabile;
• începerea etapei de dezvoltare a elementelor standard ale
interfeţei.
Proiectarea interfețelor
• Se utilizează hărţi (diagrame) de structură a ecranului în
care se descrie fluxul aplicaţiei urmând căile principale
ale cazurilor de utilizare.
• Mod de reprezentare:
• forme pătrate pentru reprezentarea ferestrelor modale (necesită un
răspuns dat de utilizator pentru a se putea continua o activitate).
• forme pătrate cu colţurile rotunjite Pentru reprezentarea ferestrelor
ne-modale
• Direcţia de traversare arată calea de navigare a ferestrelor.
Proiectarea interfețelor
Ferestre care conţin tab-uri

Diagramă de structură a ecranului

Proiectarea interfeței – exemplu (vezi tutorial VP)
https://balsamiq.com/tutorials/articles/firstwireframe/

Proiectarea interfeței – Balsamiq

•Exemplu aplicatie mobile banking:
https://balsamiq.com/tutorials/articles/mobileapplication/

•Exemplu aplicatie web:

https://balsamiq.com/tutorials/articles/firstwireframe/