Sunteți pe pagina 1din 13

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr.

ION LUNGU

T8. O modalitate de parcurgere a proceselor primare cu


exemplificari la sisemul de rezervare pentru liniile aeriene
Identificarea cerinelor
Analiza orientat obiect
Proiectarea orientat obiect
Implementarea sistemelor

Identificarea cerinelor
Principalele activiti ce trebuie parcurse n aceast etap sunt:
Identificarea cerinelor candidate ;
Organizarea sistemului utiliznd pachetele;
Identificarea cerinelor funcionale si nonfunctionale utiliznd modelul
cazurilor de utilizare.
A. Identificarea cerinelor candidate
n documentaia de iniiere a proiectului (viziune) se identific cerine posibile pentru
sistemul respectiv. Acestea se completeaz fie pe baza experienei, fie din notele de interviu
sau alte documente. Cel mai important document pentru identificarea acestor cerine
candidate rmne viziunea.
n cazul sistemului de rezervare, cerinele candidate ar putea fi: rezervarea de bilete
direct la companie sau prin intermediari (ageni de turism), calculul automat al celei mai
avantajoase rute (din punct de vedere al costului sau al timpului), gestiunea automat a
situaiilor speciale (anularea unei curse).
B. Organizarea sistemului utiliznd pachete
Una dintre sarcinile cheie ale modelrii sistemelor software de mari dimensiuni este
mprirea acestora n arii de mici dimensiuni, mai uor de manevrat. Fie c se numesc
domenii, categorii sau subsisteme, ideea de baz e aceeai: mprirea sistemului n arii ce au
o problematic similar.
UML introduce noiunea de pachet ca entitate de grupare a elementelor, permind
proiectanilor s mpart i s clasifice sistemele complexe.
Pachetele pot fi utilizate la orice nivel, de la cel mai nalt, unde sunt utilizate pentru a
mpri sistemul n domenii, pn la cel mai de jos nivel, unde se utilizeaz pentru a grupa
cazuri de utilizare, clase sau componente. n RUP, ca i n cazul altor metodologii orientate pe
cazuri de utilizare, aceasta poate constitui o prim etap.
Sistemul de rezervare a fost structurat n cinci subsisteme (reprezentate printr-o
diagram a pachetelor, figura 1.): ntreinerea flotei, sistem de urmrire a zborurilor, sistem
de rezervare, sistem contabil, personal.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Sistem de urmerire a zborurilor

Intretinerea flotei

Sistem de rezervare

Sistem contabil

Personal

Figura 1. Organizarea sistemului cu ajutorul pachetelor

C. Identificarea cerinelor sistemului cu ajutorul cazurilor de utilizare


Modelarea cu ajutorul cazurilor de utilizare este tehnica cea mai uoar i mai eficient pentru
identificarea cerinelor din perspectiva utilizatorului. Cazurile de utilizare sunt folosite pentru a
modela modul de funcionare al sistemului actual sau modul de funcionare al sistemului dorit de
utilizatori. Nu utilizeaz o abordare orientat obiect, este mai degrab o modelare a proceselor, dar cu
toate astea este o tehnic excelent de iniiere a analizei orientat obiect a sistemului. Cazurile de
utilizare sunt n general punctul de pornire n analiza orientat obiect utiliznd UML.

n cazul exemplului nostru cazurile n care se face apel la sistemul de rezervare sunt
atunci cnd un pasager dorete s fac o rezervare sau atunci cnd acesta dorete s anuleze
o rezervare fcut anterior. O prim diagram a cazurilor de utilizare este reprezentat n
figura 2. ntr-o iteraie ulterioar aceast diagram va putea fi rafinat, fiind identificate i
alte cazuri de utilizare, cum ar fi confirmarea unui zbor.
Descrierea cazului de utilizare sub forma unei
succesiuni de pasi
1. Pasagerul solicita o anumita cursa vazatorului de bilete
2. Vanzatorul verifica disponivilitatea la linia aeriana
3. Linia aeriana comunica disponibilitatea biletului, furnizeaza detalii
despre cursa
4. Vanzatorul comunica pasagerului detaliile zborului
5. Pasagerul solicita un loc, preferinte
6. Vanzatorul rezerva locul
7. Vanzatorul confirma rezervarea pasagerului
8. Vanzatorul solicita plata pasagerului
9. Pasagerul face plata catre vanzator
10. Vanzatorul face plata catre linia aeriana
11. Linia aeriana face confirmarea finala vanzatorului
12. Vanzatorul emite biletul pasagerului

Substantivele
sunt posibile clase

Verbele sunt
posibile operatii

Actor
Rezervare Zbor

Pasager

Anulare Rezervare

LinieAeriana

Caz de utilizare

Figura 2. Modelarea cu ajutorul cazurilor de utilizare


Fiecare caz de utilizare este documentat printr-o descriere a scenariului. Descrierea poate fi
textual sau pe pai.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

n figura 2. este prezentat i o descriere sub forma unei succesiuni de pai pentru cazul de
utilizare Rezervare zbor.
Fiecare caz de utilizare poate avea i alte proprieti, cum ar fi pre- sau post- condiii ale
scenariului condiii care trebuie ndeplinite nainte de nceperea execuiei scenariului sau condiii
care trebuie ndeplinite dup executarea scenariului. Diagrama de activitate reprezint un instrument
grafic pentru modelarea proceselor cazurilor de utilizare. Aceasta va fi detaliat ntr-o seciune ce
urmeaz.

Obiectivul final al oricrui proiect software este o aplicaie care rspunde tuturor
cerinelor beneficiarului. Prin identificarea i verificarea cerinelor se urmrete ca toate
cerinele s fie luate n considerare i sistemul s fie proiectat conform cerinelor beneficiarului. Cel mai adesea cerinele sunt cuprinse ntr-un document (documentaia de iniiere a
proiectului sau viziunea), iar cazurile de utilizare sunt folosite pentru a corela fiecare scenariu
cu cerina pe care o trateaz. Modelarea sistemului cu ajutorul cazurilor de utilizare ajut la
identificarea cerinelor, dac acestea nu au fost identificate anterior.

Analiza orientat obiect


Principalele activiti ce trebuie parcurse n aceast etap sunt:
Rafinarea diagramei cazurilor de utilizare;
Modelarea dinamicii sistemului (utiliznd diagrama de secven sau diagrama
de colaborare);
Modelarea structurii statice (utiliznd diagrama claselor).
A. Rafinarea diagramei cazurilor de utilizare
n aceast etap se pot identifica i alte cazuri de utilizare i ali actori, la un alt nivel
de detaliu.
n exemplul nostru am identificat n plus agenia de voiaj, ca intermediar ntre
pasager i companie. Odat cu introducerea acestui nou actor am mai luat n calcul i
necesitatea achitrii biletului pentru validarea rezervrii i alte situaii speciale care ar
trebui acoperite (achitare prin carte de credit, plat neacceptat).
De asemenea, n cursul analizei proceselor de afaceri se poate dezvolta modelul
cazurilor de utilizare pentru ntreg sistemul i se pot construi mai multe pachete pentru
reprezentarea unor arii diverse ale afacerii. Fiecare pachet poate fi apoi descompus i
reprezentat printr-o diagram ce conine cazurile de utilizare corespunztoare domeniului i
interaciunile cu actorii.
Scopul este de a construi cte o diagram a cazurilor de utilizare pentru fiecare scenariu al
sistemului. Fiecare scenariu descrie o succesiune diferit de interaciuni ntre actori i sistem, fr
condiii SAU.

Modelarea structurii alternative prin relaii de tip Extends. n mod obinuit fiecare
caz de utilizare se construiete dintr-o secven de aciuni, dup care pentru fiecare pas se
3

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


construiesc condiii de tip what if i se realizeaz noi cazuri de utilizare pe baza acestor
activiti alternative. Secvenele alternative sunt cuprinse n cazuri de utilizare distincte
conectate printr-o relaie de tip Extends de cazul de utilizare iniial. Relaia de tip Extends
poate fi privit ca relaie de motenire, ntruct cazul de utilizare ce extinde un alt caz de
utilizare motenete i suprascrie comportamentul acestuia.
Presupunnd c achitarea biletului se face implicit prin numerar, dar opional plata
se poate face i prin carte de credit, cazul de utilizare Achitare prin carte de credit extinde
cazul de utilizare Achitare zbor (figura 3).
Eliminarea comportamentului redundant cu ajutorul relaiilor de tip UsesPentru a elimina o
secven de comportament redundant ce apare n cazuri de utilizare diferite se poate modela acea
secven ntr-un caz de utilizare distinct, conectat de cazurile de utilizare iniiale prin relaii de tip
Uses. Relaia de tip Uses poate fi privit ca fiind echivalent cu relaia de agregare.
n exemplul nostru, fie c rezervarea se face direct la linia aerian sau printr-o agenie de
voiaj, o rezervare trebuie achitat pentru a fi validat. Cazul de utilizare achitare zbor este utilizat
att de Rezervare zbor, ct i de Rezervare zbor prin agent (figura 3).

Rezervare Zbor

<<uses>>

Pasager

Achitare Zbor

<<extends>>

Achitare prin
carte de credit

<<extends>>

<<uses>>

LinieAeriana

Rezervare Zbor
prin Agent

<<extends>>

Plata neacceptata

Agentie de Voiaj

Figura 3. Relaii de extindere i de utilizare ntre cazuri de utilizare

Cazurile de utilizare sunt folosite i pentru a construi scripturi de testare pentru a


verifica satisfacerea cerinelor beneficiarului de ctre aplicaie. Cnd se atinge nivelul cel mai
fin de descompunere, pentru fiecare caz de utilizare se poate realiza o diagram de secven.
Cu diagramele de secven i de colaborare se modeleaz implementarea scenariului.
B. Modelarea dinamicii sistemului Diagramele de secven
Diagrama de secven este una dintre cele mai potrivite pentru a modela interaciunile
ntre obiectele sistemului. Se realizeaz cte o diagram de secven pentru fiecare caz de
utilizare. n timp ce cazul de utilizare modeleaz un scenariu din punctul de vedere al

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


utilizatorului, diagrama de secven conine detalii de implementare ale scenariului, incluznd
clasele i obiectele ce vor implementa scenariul i mesajele transmise ntre obiecte.
n mod obinuit se analizeaz descrierea cazului de utilizare pentru a determina care
sunt obiectele necesare pentru implementarea scenariului. Dac descrierea a fost fcut sub
forma unei succesiuni de pai, obiectele se determin prin parcurgerea acestor pai. ntr-o
diagram de secven obiectele implicate n scenariu sunt reprezentate prin linii punctate
verticale, iar mesajele transmise ntre acestea prin vectori orizontali.
Mesajele se reprezint cronologic de sus n jos, spaierea pe orizontal a obiectelor
fiind arbitrar.
Pentru cazul de utilizare descris mai sus prin pai (Rezervare zbor) diagrama de
secven este prezentat n figura 4. Se observ c paii din descrierea cazului de utilizare se
regsesc n secven de sus n jos.

Ionescu : Pasager

Vlad : Vanzator

Linie Aeriana

solicitare zbor
verifica disponibilitatea
rezervare disponibila
detalii zbor
detalii zbor
transmite preferinte loc
rezerva loc
confirma rezervarea
solicita plata
face plata
face plata
confirmare finala
eliberare bilet

Figura 4. Diagrama de secven pentru un scenariu

n cursul analizei mesajul poart denumirea din sistemul existent. Mai trziu, n cursul
proiectrii acesta este nlocuit cu denumirea metodei obiectului apelat. Metoda apelat sau
invocat aparine clasei instaniate de obiectul ce recepioneaz mesajul.

Modelarea dinamicii sistemului Diagramele de colaborareDiagrama de colaborare


reprezint o alternativ la diagrama de secven pentru modelarea interaciunilor ntre
obiectele sistemului. n timp ce n diagrama de secven accentul cade pe succesiunea

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


cronologic a mesajelor, n diagrama de colaborare accentul cade pe identificarea i
nelegerea tuturor efectelor pe care scenariul le are asupra unui obiect. Obiectele sunt
conectate, fiecare legtur fiind o instan a asocierii ntre clasele implicate.
Legtura evideniaz mesajul transmis ntre obiecte, tipul mesajului (sincron,
asincron, simplu, opional balking sau time-out) i vizibilitatea obiectelor unele fa de
altele.(figura5)
Vlad : Vanzator

5: detalii zbor
8: confirma rezervarea
9: solicita plata
13:eliberare bilet

Ionescu : Pasager

3: rezervare disponibila
4: detalii zbor
12: confirmare finala
1: solicitare zbor
6: preferinte loc
10: face plata

2: verifica disponibilitatea
7: rezerva loc
11: face plata
Linie Aeriana

Figura 5. Diagrama de colaborare pentru un grup de obiecte

C. Modelarea structurii statice cu ajutorul diagramei claselor


Diagrama claselor este instrumentul principal de analiz i proiectare a structurii
statice a sistemului. n ea se precizeaz structura claselor sistemului, relaiile ntre clase i
structurile de motenire. n timpul analizei diagrama este construit urmrind obinerea unei
soluii ideale. La proiectare se utilizeaz aceeai diagram i se modific pentru a fi conform
cu detaliile de implementare.
Dezvoltarea diagramei claselor pe parcursul analizei
Abordarea orientat pe cazuri de utilizare

n cazul analizei orientat pe cazuri de utilizare, diagrama claselor se construiete pe


baza informaiilor furnizate de cazurile de utilizare, diagramele de secven i diagramele de
colaborare.
Obiectele identificate pe parcursul analizei sunt modelate n termenii claselor
instaniate de acestea, iar interaciunile ntre obiecte sunt transpuse n relaii ntre clasele
instaniate.
Abordarea orientat pe responsabiliti

Tehnica fielor CRC este utilizat uneori ca extensie a UML-ului pentru o analiz
orientat pe responsabiliti. Definiiile claselor sunt rafinate pe baza responsabilitilor lor i
a altor clase cu care acestea colaboreaz pentru a ndeplini aceste responsabiliti. Pentru
fiecare clas se ntocmete o fi pe care se evideniaz responsabilitile clasei i care sunt
clasele cu care ea colaboreaz pentru a ndeplini aceste responsabiliti.
6

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Aceste informaii se transpun direct ntr-o diagram a claselor, responsabilitile


corespund metodelor, iar colaborrile corespund asocierilor dintre clase.
Pasager
Superclas: <none>
Subclase: <none>
Responsabiliti
Colaboratori
Plata biletului
Vanzator_bilet
Solicitare zbor
Vanzator_bilet

Pentru a afl preul trebuie


s colaborez cu pasagerul
i compania aerian

Bilet
Superclas: <none>
Subclase: <none>
Responsabiliti
Afl pretul

Companie

Zbor

Superclas: <none>
Subclase: <none>
Responsabiliti
Furnizeaz detalii zbor
Confirm rezervarea

Superclas: <none>
Subclase: <none>
Responsabiliti
Locuri disponibile

Colaboratori
Vanzator_bilet, Zbor
Vanzator_bilet, Zbor

Colaboratori
Companie, Pasager

Colaboratori
<none>

Vanzator_bilet
Superclas: <none>
Subclase: <none>
Responsabiliti
Verific disponibilitatea
Rezerv zbor

Colaboratori
Companie, Zbor
Companie, Pasager

Figura 6.O extensie informal a UML tehnica fielor CRC


pentru analiza orientat pe responsabiliti

Proiectarea orientat obiect


Exist dou obiective principale pe care le urmrim n proiectarea unui sistem informatic:

obinerea ct mai rapid a sistemului care s respecte toate cerinele actuale la


un pre ct mai sczut;
construirea unui sistem uor de ntreinut i adaptat pentru a rspunde unor
viitoare cerine.
Aceste obiective sunt vzute n mod tradiional ca fiind conflictuale; unul dintre
motivele pentru care tehnicile de proiectare orientate obiect au cucerit cu rapiditate piaa este
i concilierea acestor obiective conflictuale.
Ca i n cazul analizei principalele activiti ce trebuie parcurse n aceast etap sunt:

modelarea structurii statice (utiliznd diagrama claselor);


modelarea dinamicii sistemului (utiliznd diagrama de stare sau diagrama de
activitate);
rafinarea diagramei cazurilor de utilizare (utiliznd diagrama de activitate);
modelarea arhitecturii sistemului (utiliznd diagrama componentelor i diagrama de desfurare);
consruirea bazei de date .
Accentul cade de aceast dat pe detaliile concrete ale implementrii sistemului.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


Fiecare dintre modelele abordate vin s completeze diagrama claselor/obiectelor care
n final va sta i la baza proiectrii bazei de date.
A. Proiectarea sistemului cu ajutorul diagramei claselor. Pe parcursul proiectrii,
diagrama claselor este modificat pentru a lua n considerare detalii concrete ale
implementrii sistemului.
Diagrama claselor poate fi dezvoltat ntr-o manier iterativ, printr-o succesiune
repetat a analizei, proiectrii i implementrii. Acest proces este adesea referit ca round-trip
engineering. Utilizarea unui CASE poate facilita acest proces oferind posibilitatea
implementrii ntr-un limbaj de programare, cum ar fi C++ sau Java i invers, reactualizarea
diagramei claselor pornind de la cod (reverse engineering).

Figura 7. Analiza i proiectarea iterativ, documentarea cu ajutorul diagramei claselor

O preocupare esenial pe parcursul proiectrii este stabilirea arhitecturii sistemului.


Se poate opta ntre o aplicaie simpl ce va rula pe o singur main, un sistem client-server
sau un sistem multi-tier cu obiecte specializate pentru interfaa cu utilizatorul, logica aplicaiei
i pentru baza de date, fiecare putnd potenial s ruleze pe o alt platform.
O posibilitate de a gestiona o astfel de arhitectur complex este mprirea diagramei
claselor n trei seciuni diferite care s evidenieze clasele ce descriu interfaa cu utilizatorul
(business layer), clasele responsabile de logica aplicaiei (application layer) i clasele pentru
stocarea datelor (data layer)
Aceasta se poate realiza fizic fie prin segmentarea diagramei claselor i utilizarea unei
diagrame distincte pentru fiecare seciune sau prin adugarea unei proprieti fiecrei clase,
proprietate care s identifice crei seciuni (tier) aparine clasa.
O component este un grup de obiecte sau componente care interacioneaz cu scopul
de a furniza un serviciu. O component este similar unei cutii negre pentru care serviciile

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


sunt specificate prin interfaa sau interfeele sale, fr a se preciza nimic despre componena
sau implementarea intern a componentei.
Dezvoltarea bazat pe componente este procesul care urmrete asamblarea
componentelor celor mai potrivite n configuraia cea mai bun pentru a obine
funcionalitatea dorit pentru sistem. Componentele sunt reprezentate n diagrama claselor din
UML prin specificarea interfeei clasei sau pachetului.
Exist dou posibiliti de reprezentare pentru interfa, ca o clas cu stereotipul
<<interface>> i lista operaiilor suportate de interfa n seciunea destinat metodelor sau n
variant prescurtat, ca un mic cerc ataat printr-o linie continu de clas i preciznd
denumirea interfeei n dreptul cercului.
Exemplul din figura 8.arat c interfaa Afiabil a clasei Pasager pune la dispoziie o
operaie mut (x coord, y coord) pentru afiarea n GUI. Sunt evideniate ambele modaliti
de reprezentare. Interfaa Persistent a clasei Pasager ofer o operaie salveaz (store at)
care ar putea fi folosit de o clas sau component de acces la baza de date.
interface
Afisabil
+mut(x coord, y coord) ()

Afisabil
<<uses>>

<<uses>>

Persistent

Pasager
+mut(x coord, y coord) ()
+salveaz(store at) ()

GUI

Figura 8 Proiectarea componentelor specificarea interfeei unei clase

B. Modelarea comportamentului cu diagrame de stare. n timp ce diagramele de


interaciune i de colaborare modeleaz comportamentul dinamic reprezentat de o secven de
aciuni ntre grupuri de obiecte ale sistemului, diagrama de stare este utilizat pentru a modela
comportamentul dinamic al unui singur obiect sau clas de obiecte.
Se realizeaz cte o diagram de stare pentru fiecare clas cu comportament dinamic
semnificativ. ntr-o astfel de diagram se surprinde secvena strilor pe care le parcurge un
obiect al clasei pe parcursul ntregului su ciclu de via ca rspuns la stimulii primii, dar i
propriile rspunsuri i aciuni ale obiectului. Mai concret, comportamentul unui obiect este
modelat pornind de la starea sa iniial i determinnd care sunt strile pe care le tranziteaz
atunci cnd intervin diverse evenimente. Se urmresc i aciunile pe care obiectul le
efectueaz atunci cnd se afl ntr-o anumit stare.
Strile reprezint suma condiiilor obiectului la un moment dat.
Evenimentele sunt ntmplri care determin trecerea unui obiect dintr-o stare n alta.
Strile de tranziie caracterizeaz micarea dintr-o stare n alta. Fiecare stare de
tranziie (reprezentat printr-o linie continu ce leag cele dou stri ntre care se efectueaz
tranziia) este etichetat cu evenimentul care determin tranziia. Aciunile sunt efectuate de
obiect atunci cnd acesta sosete ntr-o stare.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Rezervare loc
Anulare
Locuri
disponibile

Zbor rezervat

Locuri rezervate

Zbor rezervat

Locuri clasa I
rezervate

Zbor
programat
Locuri
disponibile la
clasa I

Sosete
Soseste ora plecarii
Gata de
decolare

Locuri la clasa I

Permite
modificari la
clasa I

Anulare

Toate locurile ocupate

Figura 9 Modelarea comportamentului dinamic al obiectului Zbor


cu ajutorul diagramei de stare

C. Diagrame de activitate. Diagrama de activitate este o diagram de flux utilizat


pentru a modela comportamentul sistemului. Ea poate fi folosit n mai multe situaii: pentru a
modela un caz de utilizare, o clas sau o metod mai complicat.
Aa cum am mai spus, ea este similar unei diagrame de flux, diferena esenial fiind
aceea c o diagram de activitate poate reprezenta procese paralele. Acest lucru este deosebit
de important atunci cnd diagramele de activitate sunt utilizate pentru a modela procesele de
afaceri (multe din acestea executndu-se n paralel) sau pentru a modela fire multiple de
execuie n programarea concurent.
Diagrama de activitate ofer un instrument grafic pentru a modela procesele unui caz
de utilizare. Aceasta poate fi folosit n completarea, sau n locul, unei descrieri textuale / liste
de pai a cazului de utilizare. O descriere textual, cod sau o alt diagram de activitate poate
prezenta mai multe detalii.
Utilizarea diagramelor de activitate pentru a modela clase. Pentru modelarea
comportamentului unei clase diagrama de stare este utilizat atunci cnd predomin
evenimentele asincrone. Diagrama de activitate se folosete cnd toate sau majoritatea
evenimentelor sunt urmare a unor aciuni interne. ntr-o astfel de diagram activitile trebuie
ataate claselor.

10

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


Pasager

Vanzator

Linie aeriana

Solicitare zbor

Verifica disponibilitatea

Furnizeaza detalii zbor

Furnizeaza optiuni si preturi

Alege zbor

Solicita plata

Rezerva zbor

Achita bilet

Confirma rezervarea

Emite bilet

Figura 10 Diagrama de activitate

D. Modelarea componentelor software. Diagrama componentelor este utilizat pentru


a modela structura software-ului, incluznd dependenele ntre componentele software,
componentele n cod binar i componentele executabile. n diagrama componentelor se
modeleaz componentele sistemului, grupate uneori n pachete, i dependenele care exist
ntre componente (i pachete de componente).

11

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


Sistem de rezervare

SGBD

Print Server
Plan de zbor

Statie de lucru

Figura 11. Modelarea componentelor cu ajutorul diagramei componentelor


Modelarea distribuirii i implementrii. Diagrama de desfurare este utilizat pentru a modela
configuraia elementelor de procesare la momentul execuiei i distribuia componentelor software,
proceselor i obiectelor pe aceste elemente de procesare. Se pornete de la identificarea nodurilor
fizice i a comunicaiilor ce exist ntre acestea. Pentru fiecare nod se precizeaz instanele
componentelor care se stocheaz sau se execut pe nodul respectiv. Se pot evidenia i obiectele
componentei respective. Diagrama de desfurare modeleaz doar componentele existente la
momentul execuiei, ea nu surprinde i componentele folosite doar la compilare sau linkeditare. Se pot
modela i componentele care migreaz dintr-un nod n altul, sau obiectele ce migreaz dintr-o
component ntr-alta, utiliznd relaia de dependen cu stereotipul <<becomes>>

Imprimanta
bilete

Statie de
lucru in
aeroport

Server

LAN

Conexiune
Statie de
lucru la
agentia de
turism

Imprimanta
bilete

Firewall

Internet

Acces read-only

Calculatoare
clienti (acasa)

Figura 12. Modelarea distribuirii sistemului cu ajutorul diagramei de desfurare

E. Proiectarea bazelor de date relaionale o extensie UML. Diagrama claselor


prezint un mecanism neutru de implementare pentru modelarea aspectelor ce in de stocarea
datelor sistemului. Clasele persistente, atributele acestora i relaiile dintre ele pot fi
implementate direct ntr-o baz de date orientat obiect. Cu toate acestea, n prezent, bazele de
date relaionale rmn modalitatea de stocare a datelor cea mai uzual. Diagrama claselor din
UML permite modelarea unor aspecte specifice proiectrii bazelor de date relaionale, dar nu
12

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU


acoper n ntregime aceast problematic, de notat faptul c nu prevede noiunea de atribute
cheie, care sunt mecanismul principal de relaionare a tabelelor. Pentru a surprinde mai bine
aceste aspecte este bine s se apeleze la diagrama entitate asociere (ER), n completarea
setului de diagrame propus de UML. Diagrama claselor poate fi utilizat pentru a modela
logic baza de date, independent de faptul c se alege o implementare relaional sau orientat
obiect, prin clase reprezentndu-se tabelele, iar prin atribute coloanele acestora. Dac se alege
pentru implementare un mediu relaional, atunci diagrama claselor poate fi uor translatat
ntr-o diagram logic entitate asociere. Claselor persistente i atributelor acestora le
corespund entitile logice i atributele lor, iar relaiilor dintre clase le corespund relaii ntre
entiti.

Diagrama claselor - UML


Logica
aplicatiei

Interfata cu
utilizatorul

Datele

Implementare OO

SGBDOO

Translatare obiectual/relational
Schema fizica

SGBDR

Schema fizica

SGBDR

Diagrama entitate
asociere

Translatare logic /
fizic

Figura 13. Proiectarea bazelor de date relaionale


cu ajutorul diagramei entitate asociere
Odat ntocmit aceast diagram se poate trece la proiectarea bazei de date relaionale conform
tehnicii normalizrii.

Implementarea sistemelor
Inainte de implementarea propriu-zisa (scrierea programului sursa) a sistemului
informatic aceasta etapa mai presupune:
realizarea diagramelor claselor la nivel fizic ;
declararea claselor de baza;
realizarea modelului de persistenta;
declararea claselor de tip colectie;
realizarea cazurilor de utilizare la nivel fizic;
proiectarea interfetelor(video formate, rapoarte, meniuri)
Aceste activitati conduc la proiectarea componentelor sistemului si apoi la realizarea
efectiva ,adica, scrierea/generarea codului sursa

13

S-ar putea să vă placă și