Ingineria programrii

Cursul 6

Proiectarea orientat obiect

1. Procesul proiectrii sistemelor software
2. Caracteristicile unei proiectri corecte
2.1. Extensibilitatea
2.2. Sigurana
2.3. Eficiena
3. Proiectarea orientat obiect
4. Etapele proiectrii orientate obiect
4.1. Contextul sistemului i modelele de utilizare
4.2. Proiectarea arhitecturii
4.3. Identificarea obiectelor
4.4. Modele de proiectare
4.5. Specificarea interfeelor obiectelor
5. Metoda de proiectare Coad-Yourdon
5.1. Activitatea I: Proiectarea componentei domeniului problemei
5.2. Activitatea a II-a: Proiectarea componentei interaciunii cu factorul uman
5.3. Activitatea a III-a: Proiectarea componentei coordonrii task-urilor
5.4. Activitatea a IV-a: Proiectarea componentei coordonrii datelor
6. Concluzii
1. Procesul proiectrii sistemelor software
Proiectarea este un proces creativ, care necesit o oarecare experien practic, acumulat n
timp. Acest proces implic o serie de pai:
studiul i nelegerea problemei;
identificarea mai multor soluii posibile i evaluarea fiecreia din ele. Alegerea ei depinde de
experiena proiectantului, simplitatea acesteia, valabilitatea componentelor reutilizabile;
descrierea fiecrei abstractizri a fiecrei soluii. nainte de crearea documentaiei formale, ar
putea fi necesar ca proiectantul s pregteasc o descriere informativ a proiectului pentru a fi
examinat n detaliu. n felul acesta, omisiunile i erorile posibile ar putea fi eliminate nainte
ca proiectul s fie documentat.
Activitile eseniale n cursul proiectrii sunt urmtoarele:

Proiectarea arhitectural: subsistemele ntregului sistem sunt identificate i documentate;

Specificarea abstract: pentru fiecare subsistem, se prezint o specificare abstract a
serviciilor i a constrngerilor sub care acestea opereaz;
Proiectarea interfeei: pentru fiecare subsistem, interfaa cu celelalte subsisteme este
proiectat i documentat;
Proiectarea componentelor: serviciile furnizate de un subsistem sunt partiionate ntre
componentele acelui subsistem;
Proiectarea structurilor de date: structurile de date utilizate n implementarea sistemului sunt
proiectate n detaliu i specificate.

Proiectarea algoritmilor: algoritmii utilizai pentru a furniza servicii sunt proiectai n detaliu
i specificai.
Acest proces se repet pentru fiecare subsistem pn cnd componentele identificate pot fi
mapate direct n componentele limbajului de programare.
2. Caracteristicile unei proiectri corecte
Rezultatul principal a fazei de proiectare este un model al codului care arat cum este
implementat sistemul i o diagram a dependenelor dintre module, care arat cum va fi sistemul
divizat n module i cum interacioneaz acestea. Pentru module mai dificile, se includ specificaii
speciale.
Ce nseamn o proiectare corect? Desigur, nu exist o modalitate simpl i obiectiv care s
spun c o proiectare este mai bun dect alta. Dar exist unele proprieti cheie care pot fi utilizate
pentru a msura calitatea proiectrii. n mod ideal, o proiectare ar trebui s aib toate aceste
caracteristici. n practic, trebuie fcute compromisuri ntre ele. Aceste caracteristici sunt
extensibilitatea, sigurana i eficiena.
2.1. Extensibilitatea
Proiectarea trebuie s poat suporta noi funcii. Un sistem perfect din toate celelalte puncte de
vedere, dar n care nu poate fi integrat nici o schimbare sau mbuntire, nu este de prea mare folos.
Chiar dac nu exist cerine pentru trsturi suplimentare, probabil vor exista schimbri n domeniul
problemei care vor necesita schimbri n program.
Modelul problemei trebuie s reflecte caracteristicile generale ale problemei. Un obstacol des
ntlnit atunci cnd se dorete extinderea unui sistem este faptul c anumite noiuni nu sunt exprimate
n cod i deci funcionalitile corespunztoare care trebuie adugate nu-i gsesc locul n program.
Un exemplu n acest sens poate fi vzut n Microsoft Word. Acesta a fost proiectat plecnd de la
premisa c structura fundamental de organizare a unui document este paragraful. De aceea,
structurile ierarhice pot fi introduse cu greutate i, ca efect, divizarea documentului n seciuni nu se
face foarte eficient. Optimizarea modelului nu trebuie s elimine substructurile care numai par
nefolositoare. Abstractizrile nu trebuie s nlocuiasc structurile concrete dect dup o analiz
serioas.
Chiar dac programul cuprinde noiuni generale pe baza crora s poat fi adugate noi
funcionaliti, acestea trebuie introduse fr a modifica tot codul. De aceea, proiectarea trebuie s fie
localizat, adic problemele diferite trebuie separate n regiuni distincte ale codului. Modulele trebuie
decuplate ct mai mult, astfel nct o schimbare s nu antreneze modificri n cascad.
2.2. Sigurana
Sistemul trebuie s aib un comportament sigur, care nu presupune doar lipsa "prbuirilor"
sau a pierderii datelor, ci i faptul c trebuie s ruleze corect, aa cum se ateapt utilizatorul. Nu e
suficient ca sistemul s ndeplineasc o specificaie obscur, ci trebuie s ndeplineasc o specificaie
care poate fi neleas uor de utilizator, astfel nct acesta s poat prezice comportamentul
sistemului. Pentru sistemele distribuite, este important disponibilitatea. Pentru sisteme de timp real,
este important sincronizarea. Criteriile de stabilire a siguranei variaz n funcie de tipul aplicaiei.
Conexiunile telefonice automate trebuie s fie n permanen disponibile i s fie foarte sigure, uneori
pot fi suprancrcate, iar alte ori mai au loc rutri eronate de mesaje. ntrzieri mici ntr-un program

de trimitere a email-urilor nu prea conteaz, ns aceleai ntrzieri se pot dovedi catastrofale pentru
un controler de reactor nuclear.
Modelarea atent. Sigurana nu poate fi introdus uor ntr-un sistem existent. Cheia realizrii
de produse sigure este modelarea i dezvoltarea atent. Problemele serioase n sistemele critice n
general nu apar din erori de programare, ci din erori de analiz a problemei. Programatorii pur i
simplu nu iau n calcul o anumit proprietate a mediului n care este plasat sistemul. De exemplu,
incidentul din 1993 cnd un avion Airbus a ncercat s aterizeze pe timp de furtun pe aeroportul din
Varovia, ns frnele nu au funcionat, avionul a ieit de pe pist i a luat foc.
Analiza i testarea. Orict de atent ar fi cineva, este foarte probabil c va face pn la urm
greeli. Din punct de vedere al costului, cea mai bun soluie este verificarea codului de ctre alt
persoan. O testare mai detaliat i care poate descoperi erori mai subtile poate fi realizat cu un
instrument automat.
2.3. Eficiena
Sistemul trebuie s consume resurse n limite rezonabile. Eficiena depinde de context. O
aplicaie care ruleaz pe un telefon mobil nu are disponibil la fel de mult memorie ca una care
ruleaz pe un PC. Pentru determinarea eficienei unui program, se analizeaz n general timpul de
execuie i spaiul necesar. Pe lng timpul de execuie, este la fel de important i timpul necesar
dezvoltrii, care este legat de costul aplicaiei. O proiectare care poate fi implementat mai economic
poate fi preferabil uneia care ndeplinete toate metricile de calitate dar este mai scump.
Modelul obiectului. Alegerea modelului obiectelor din cod este crucial, deoarece este greu
de schimbat. De aceea, intele de performan trebuie considerate nc de la nceput n faza de
proiectare.
Evitarea tendeniozitii. Cnd se dezvolt modelul obiectelor pentru problem, trebuie
excluse orice preocupri legate de implementare. Un model care conine detalii de implementare este
tendenios (engl. "biased"), deoarece favorizeaz o anumit implementare. Rezultatul este excluderea
unor posibiliti de implementare care se pot dovedi n final mai eficiente.
Optimizarea. n general, "optimizare" este o denumire greit, deoarece nseamn creterea
performanelor n detrimentul altor caliti, cum ar fi claritatea structurii. Dac optimizarea nu este
tratat cu atenie, putem risca s ajungem la un sistem mai prost din toate punctele de vedere. Sunt
recomandate numai optimizrile care vor avea efecte foarte puternice, de exemplu o modificare care
reduce complexitatea de timp de la O(n) la timp constant. Optimizrile unor aspecte minore trebuie
evitate dac presupun o scdere n claritatea proiectrii.
3. Proiectarea orientat obiect
Dup cum tim, faza de proiectare se afl situat ntre analiz i implementare. Toate aceste
faze fac parte din procesul de dezvoltare orientat obiect. Aa cum am vzut n cursul precedent,
analiza orientat obiect se refer la dezvoltarea unui model orientat obiect al domeniului aplicaiei.
Obiectele identificate reflect entiti i operaii asociate cu problema care trebuie rezolvat.
Proiectarea orientat obiect privete dezvoltarea unui model orientat obiect al sistemului
software care trebuie s implementeze cerinele identificate. Programarea orientat obiect urmrete
implementarea (punerea n practic a) proiectrii software folosind un anumit limbaj de programare
orientat obiect.
Continund faza de analiz orientat obiect, proiectarea orientat obiect este o strategie n
care sistemul se gndete n termeni de "obiecte", n loc de operaii i funcii. Programul nu este
proiectat ca o mulime de funcii care schimb date prin parametri i memorie comun (variabile
3

globale), ci ca o mulime de obiecte care interacioneaz. Obiectele i pstreaz starea intern i i

definesc operaiile pe baza acesteia. Prin ascunderea informaiilor despre reprezentarea strii, ei
limiteaz accesul exterior la starea intern.
Aadar, caracteristicile proiectrii orientate obiect sunt urmtoarele:
a) sistemul este proiectat ca o mulime de obiecte care interacioneaz, i gestioneaz propria
stare intern i ofer servicii altor obiecte;
b) obiectele sunt create prin instanierea unei clase care definete atributele i operaiile asociate
obiectului; mai multe obiecte ale aceleiai clase pot coexista n acelai program;
c) clasele sunt abstractizri ale lumii reale sau entiti care ncapsuleaz informaii de stare i
care definesc un numr de servicii care creeaz, acceseaz sau modific starea;
d) obiectele sunt entiti independente n care reprezentarea strii poate fi modificat fr a afecta
alte clase din sistem;
e) funcionalitatea sistemului este dat de serviciile asociate fiecrui obiect; obiectele
interacioneaz prin apelarea serviciilor definite de alte obiecte;
f) nu exist zone de memorie comun; obiectele comunic prin apeluri de servicii i nu prin
variabile partajate; nu exist posibilitatea ca o component s fie afectat de schimbarea unei
informaii partajate i deci modificrile sunt mai uor de implementat;
g) obiectele pot fi distribuite i pot fi executate secvenial sau paralel; deciziile asupra
paralelismului nu trebuie luate nc de la nceputul procesului de proiectare.
4. Etapele proiectrii orientate obiect
Procesul general al proiectrii orientate obiect cuprinde mai multe etape:
nelegerea i definirea contextului n care va evolua sistemul i a modului n care acesta va fi
utilizat;
proiectarea arhitecturii sistemului;
identificarea principalelor obiecte din sistem;
dezvoltarea modelelor de proiectare;
specificarea interfeelor obiectelor.
Aceste etape nu trebuie gndite ntr-o ordine strict, ele se ntreptrund i se influeneaz
reciproc. Pe msur ce sunt realizate modelele obiect, activitile de mai sus modific treptat
arhitectura sistemului. Proiectarea nu este un proces simplu i bine structurat. n realitate, se propun
i se rafineaz soluii pe msur ce se adun mai multe informaii, se revine asupra unor decizii dac
acestea se dovedesc greite; uneori se exploreaz n detaliu toate opiunile, alteori detaliile sunt
ignorate pentru a fi considerate mai trziu n cadrul procesului.
4.1. Contextul sistemului i modelele de utilizare
Prima etap a procesului de proiectare software este nelegerea relaiilor dintre sistemul
proiectat i mediul su extern. Aceasta va determina alegerea funcionalitilor necesare i
structurarea lor astfel nct sistemul s poat comunica eficient cu mediul. Contextul sistemului i
modelul de utilizare a sistemului reprezint dou modele complementare ale relaiei dintre sistem i
mediu:
contextul sistemului este un model static care descrie celelalte sisteme din mediu;
modelul de utilizare a sistemului este un model dinamic care descrie interaciunea dintre
sistem i mediu.

4.2. Proiectarea arhitecturii

Dup ce au fost definite interaciunile dintre sistem i mediu, aceste informaii pot fi utilizate
ca baz pentru proiectarea arhitecturii sistemului. Desigur, informaiile din etapa precedent trebuie
combinate cu unele cunotine generale despre principiile proiectrii arhitecturii i cu unele
cunotine detaliate despre domeniul problemei.
O regul euristic spune c ntr-un model de arhitectur nu trebuie incluse mai mult de apte
entiti fundamentale. Fiecare din aceste entiti poate fi apoi descris separat, dar, bineneles,
depinde de proiectant dac vrea s prezinte n arhitectur structura tuturor entitilor sistemului.
De exemplu, arhitectura unui agent de corectare lexical (spell-checker) poate fi urmtoarea:

Figura 1. Exemplu de arhitectur: agent spell-checker

4.3. Identificarea obiectelor
n acest stadiu al proiectrii, deja s-au conturat unele idei despre obiectele eseniale pentru
sistem. Obiectele i clasele identificate n faza de analiz sunt verificate i rafinate pentru a se potrivi
n programul care urmeaz a fi realizat.
O tehnic de identificare a obiectelor este utilizarea unei abordri comportamentale.
Proiectantul ncearc s neleag mai nti comportamentul general al sistemului. Comportamentelor
diferite le corespund pri diferite din sistem. Mai trebuie vzut cine iniiaz i particip n aceste
comportamente. Participanii cu rol semnificativ sunt recunoscui drept obiecte.
Alt tehnic se bazeaz pe analiza scenariilor. Diferitele scenarii ale utilizrii sistemului sunt
identificate i analizate pe rnd. Pentru fiecare scenariu se identific obiectele necesare, mpreun cu
atributele i serviciile acestora.
4.4. Modele de proiectare
Modelele de proiectare arat clasele i obiectele n cadrul sistemului, precum i relaiile dintre
acestea. Ele reprezint puntea de legtur ntre cerinele sistemului i implementarea sistemului. De
cele mai multe ori, exist cerine conflictuale pentru modele. Ele trebuie s fie abstracte pentru ca
detaliile nesemnificative s nu ascund relaiile cu cerinele sistemului. Totui, ele trebuie de
asemenea s includ suficiente detalii pentru ca programatorii s poat lua deciziile de implementare
corespunztoare.

O soluie a acestei probleme este dezvoltarea de modele diferite la diferite nivele de detaliu.
Cnd exist legturi strnse ntre inginerii de cerine, proiectani i programatori, modelele abstracte
sunt suficiente. Decizii specifice de proiectare pot fi fcute pe msur ce sistemul este implementat.
Cnd legturile dintre echipele implicate sunt indirecte (de exemplu, cnd sistemul este proiectat de o
parte a unei organizaii i implementat n alt parte), sunt necesare modele mai detaliate.
Detalierea modelului depinde i de tipul de sistem dezvoltat. Un sistem simplu de prelucrare
secvenial a datelor va fi proiectat ntr-un mod diferit fa de un sistem integrat de timp real i deci
vor fi necesare modele de proiectare diferite. n general, exist dou tipuri de modele de proiectare
care descriu o proiectare orientat obiect:
modelele statice, care descriu structura static a sistemului n termenii claselor sistemului i ai
relaiilor dintre ele; relaiile importante care trebuie documentate n aceast etap sunt:
relaiile de generalizare, relaiile folosete/este folosit de, relaiile de compunere etc.;
modelele dinamice, care descriu structura dinamic a sistemului, cu interaciunile dintre
obiectele sistemului (nu dintre clase); interaciunile care trebuie documentate aici sunt
serviciile solicitate de obiecte i modul n care starea sistemului este influenat de acestea.
4.5. Specificarea interfeelor obiectelor
O parte important a procesului de proiectare este specificarea interfeelor dintre diferitele
componente ale proiectrii. Ea este foarte important i deoarece permite posibilitatea ca obiectele i
celelalte componente s fie proiectate n paralel. Odat ce a fost specificat interfaa, cei care
dezvolt celelalte obiecte pot considera c aceasta este interfaa care va fi implementat.
Proiectanii trebuie s evite informaiile privind reprezentarea interfeei. Reprezentarea
trebuie s fie ascuns, iar pentru accesarea i actualizarea datelor trebuie furnizate servicii ale
obiectelor. Dup cum tim, dac reprezentarea este ascuns, ea poate fi schimbat fr a afecta
obiectele care folosesc atributele respective. n acest fel, design-ul devine mai uor de ntreinut. De
exemplu, reprezentarea unei stive ca vector poate fi schimbat cu o reprezentare de tip list fr s
afecteze celelalte obiecte care folosesc stiva.
ntre obiecte i interfee nu exist n mod necesar o relaie simpl 1:1. Acelai obiect poate
avea mai multe interfee care semnific perspective diferite asupra serviciilor pe care le furnizeaz.
De exemplu, n Java sau C#, interfeele sunt declarate separat de clase iar clasele .implementeaz.
interfeele. De asemenea, un grup de obiecte poate fi accesat printr-o singur interfa.
Proiectarea interfeelor obiectelor trebuie s specifice semnturile i semantica serviciilor
asigurate de un obiect sau de ctre un grup de obiecte.
5. Metoda de proiectare Coad-Yourdon
Metoda de proiectare orientat obiect Coad-Yourdon const n 4 componente:
componenta domeniului problemei;
componenta interaciunii cu factorul uman;
componenta coordonrii task-urilor;
componenta coordonrii datelor.
Fiecare component este construit din clase i obiecte. Componenta domeniului problemei se
bazeaz pe modelul logic construit n timpul analizei orientate obiect. Dac sistemul va fi
implementat ntr-un limbaj de programare orientat obiect, atunci va exista o coresponden de 1 la 1
ntre clasele i obiectele domeniului problemei. Componenta interaciunii cu factorul uman
coordoneaz mesajele dinspre i nspre utilizator. Componenta coordonrii task-urilor se refer la
6

multiplele fire de execuie existente ntr-un sistem. Componenta coordonrii datelor furnizeaz
infrastructura pentru nregistrarea i regsirea datelor.
Corespunztoare acestor patru componente, metoda identific patru activiti:
proiectarea componentei domeniului problemei;
proiectarea componentei interaciunii cu factorul uman;
proiectarea componentei coordonrii task-urilor;
proiectarea componentei coordonrii datelor.
5.1. Activitatea I: Proiectarea componentei domeniului problemei
n aceast prim activitate, componentele domeniului rezultate din analiz sunt utilizate i
suplimentate. Deoarece se bazeaz pe reutilizarea claselor identificate de faza de analiz, modificrile
trebuie meninute pe ct posibil la un nivel redus.
Apoi clasele specifice domeniului problemei sunt grupate mpreun prin adugarea unei clase
rdcin. Viznd direct limbajul de programare care va fi utilizat pentru implementare, poate fi
necesar modificarea structurilor gen-spec pentru a se potrivi nivelului de motenire oferit de
limbajul ales.
Dac structurile gen-spec ale modelului analizei orientate obiect includ moteniri multiple,
trebuie fcute cteva modificri ale acestora atunci cnd se va utiliza un limbaj de programare
orientat obiect care nu suport mecanismul motenirii sau care nu suport dect motenirea simpl.
Dou tipuri de motenire multipl sunt prezentate n figurile 2 i 3.

Figura 2. Diamantul mic

Figura 3. Diamantul mare

Chiar dac limbajul permite motenire multipl (de exemplu C++), se recomand evitarea
acesteia datorit complexitii pe care o presupune. n cazul limbajelor care suport doar motenire
simpl (Java, C#) se pot aplica metode de a transforma o motenire multipl ntr-o motenire simpl:

Figura 4. Formarea unor ierarhii separate, mapate ntre ele prin structuri ntreg-parte
Ierarhia multipl poate fi transformat direct ntr-o ierarhie simpl, caz n care anumite
atribute i servicii vor fi repetate n clasele specializate.

Figura 5. Acomodarea cu limbaje care nu suport motenire multipl

Dac limbajul nu suport mecanismul de motenire, fiecare structur gen-spec se va
descompune n clasele componente.

Figura 6. Acomodarea cu limbaje care nu suport motenire

Urmtorul pas n schimbarea componentelor domeniului problemei este mbuntirea
aspectelor de performan. Viteza poate fi mbuntit prin msurarea vitezei efective a codului i
prin optimizarea acestuia. Creterea vitezei e necesar de obicei cnd ntre obiecte exist un trafic
prea mare de mesaje. n acest caz, se combin dou sau mai multe clase. Singurul mod de a ti dac
aceste modificri contribuie la creterea vitezei, este prin msurare i observare. Viteza perceput de
utilizator poate fi mrit prin memorarea rezultatelor intermediare (engl. .caching.).
Tot n aceast activitate se ia n calcul suportul pentru componenta de coordonare a datelor.
Fiecare obiect se poate stoca singur sau poate fi salvat de componenta de coordonare a datelor. n
ambele abordri, la componenta domeniului problemei trebuie adugate atribute i servicii specifice.

Pentru facilitarea proiectrii i programrii, componentele de nivel sczut pot fi izolate n

clase separate. Ultimul pas n proiectarea componentei domeniului problemei este verificarea
completrilor aduse la rezultatele fazei de analiz orientat obiect.
5.2. Activitatea a II-a: Proiectarea componentei interaciunii cu factorul uman
Pentru aceast activitate se recomand prototipizarea. Activitatea ncepe cu clasificarea
persoanelor care vor utiliza sistemul, pe baza unor criterii precum:
nivel de pregtire;
nivel de organizare;
apartenena la diferite grupuri (de exemplu: funcionar sau client).
Fiecare categorie definit trebuie descris, incluzndu-se un scenariu de task-uri. Pentru
fiecare categorie, trebuie notate urmtoarele:
ce este;
scopul;
caracteristici (de exemplu: vrst, educaie etc.);
factori critici de succes (necesiti/dorine, preferine/antipatii/tendine subiective);
nivel de pregtire;
scenarii ale task-urilor.
Apoi trebuie proiectat o ierarhie de comenzi pentru sistem prin studierea sistemelor existente
de interaciune cu factorul uman. Pentru rafinarea ierarhiei, trebuie considerate urmtoarele:
ordonarea serviciilor;
partiionarea modelelor ntreg-parte i verificarea dimensiunilor structurii de comenzi
(lime: numrul de categorii de opiuni, adncime: numrul de nivele pentru fiecare
categorie de opiuni);
minimizarea numrului de pai necesari pentru efectuarea unui serviciu.

n continuare se proiecteaz detaliat interaciunea, dup urmtoarele criterii:

consistena;
minimizarea numrului de pai;
acordarea de feedback prompt i semnificativ utilizatorilor;
asigurarea funciilor .undo.;
minimizarea rolului capacitii de memorare a utilizatorilor pentru reamintirea opiunilor;
minimizarea timpului de nvare i a efortului;
proiectarea estetic a sistemului (este important ca utilizatorilor s le plac sistemul).

Dup verificarea utilitii interaciunilor, sunt proiectate clasele de interaciune cu factorul

uman: ferestre, cmpuri, grafice etc. De cte ori e posibil, trebuie utilizate interfeele grafice standard
cu utilizatorul (GUI).
5.3. Activitatea a III-a: Proiectarea componentei coordonrii task-urilor
Mai nti trebuie vzut dac e nevoie de task-uri n sistem. Urmtoarele tipuri de sisteme
necesit task-uri:
10

sisteme de achiziii de date i de control al dispozitivelor locale;

interaciuni cu factorul uman cu ferestre multiple care ruleaz simultan;
sisteme multi-user;
sisteme mono-procesor care necesit comunicare i coordonare ntre task-uri;
sisteme multi-procesor;
sisteme care comunic cu alte sisteme.

Dac nu sunt necesare, task-urile nu trebuie proiectate ntruct mresc complexitatea. Exist
cteva tipuri de task-uri care pot fi identificate:
task-uri declanate de un eveniment (de exemplu: apsarea unui buton al mouse-ului);
task-uri declanate la un anumit interval de timp;
task-uri prioritare i critice.
Cnd sunt necesare trei sau mai multe task-uri, se recomand adugarea unui task special de
coordonare. Dup identificarea task-urilor, necesitatea lor trebuie reverificat. Pentru fiecare task,
trebuie specificat:
ce este task-ul;
cum este coordonat task-ul;
cum comunic task-ul.
5.4. Activitatea a IV-a: Proiectarea componentei coordonrii datelor
Mai nti trebuie selectat o abordare pentru coordonarea datelor: fiiere simple sau un sistem
de gestionare a bazelor de date, pe baza unor criterii potrivite. Apoi, n funcie de abordarea aleas,
trebuie proiectat componenta de coordonare a datelor, adic a formatului de date i a serviciilor
corespunztoare.
6. Concluzii
Scopul acestui curs este de a realiza o introducere n procesul de proiectare a sistemelor
software. Au fost amintite mai nti caracteristicile unei proiectri corecte: extensibilitatea, sigurana
si eficiena, mpreun cu modalitile prin care pot fi atinse aceste deziderate. S-a definit proiectarea
orientat obiect i s-au detaliat etapele acestei faze de dezvoltare a produselor software: determinarea
contextului sistemului i a modelelor de utilizare, proiectarea arhitecturii, identificarea obiectelor,
modelele de proiectare i specificarea interfeelor obiectelor. n final, s-a concretizat aceast faz prin
descrierea metodei de proiectare Coad-Yourdon, cu cele patru activiti specifice: proiectarea
componentei domeniului problemei, proiectarea componentei interaciunii cu factorul uman,
proiectarea componentei coordonrii task-urilor i proiectarea componentei coordonrii datelor.

11