Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  
AccessAdobe photoshopAlgoritmiAutocadBaze de dateC
C sharpCalculatoareCorel drawDot netExcelFox pro
FrontpageHardwareHtmlInternetJavaLinux
MatlabMs dosPascalPhpPower pointRetele calculatoare
SqlTutorialsWebdesignWindowsWordXml

Construirea diagramelor de interactiune pentru un scenariu

calculatoare



+ Font mai mare | - Font mai mic



Construirea diagramelor de interactiune pentru un scenariu

Exemplul utilizat: Problema liftului.



1a. Construirea diagramelor de secventa

Punctul de plecare: scenariile din analiza OO

Scop: ilustrarea obiectelor si a mesajelor transmise intre ele

Elementele constitutive ale diagramei

Actori

utilizatori umani

obiecte active in evenimentele scenariului (instante de clase din sistem) - dreptunghiuri cu numele obiectului subliniat

Mesajele dintre obiecte - linii etichetate cu sageti pe orizontala - corespund evenimentelor din scenariu

actiuni ale utilizatorilor

mesaje intre obiecte

Timpul indica ordinea in care se desfasoara actiunile (de sus in jos)

Scenariul normal

Utilizatorul A apasa butonul Sus la etajul 3 pentru a cere un lift. El doreste sa ajunga la etajul 7.

Butonul Sus de la etajul 3 informeaza controlerul liftului ca a fost apasat

Controlerul liftului trimite un mesaj butonului Sus de la etajul 3 sa se aprinda.

Controlerul liftului trimite o serie de mesaje la lift sa se deplaseze in sus spre etajul 3. In lift se gaseste utilizatorul B, care a intrat in lift la etajul I si a apasat butonul pentru etajul 9.

Controlerul liftului trimite un mesaj butonului Sus de la etajul 3 sa se stinga.

Controlerul liftului trimite un mesaj la usile liftului sa se deschida.

Controlerul liftului porneste cronometrul.
Utilizatorul A intra in lift.

Utilizatorul A apasa butonul din lift pentru etajul 7.

Butonul pentru etajul 7 din lift informeaza controlerul liftului ca a fost apasat.

Controlerul liftului trimite un mesaj butonului pentru etajul 7 din lift sa se aprinda.

Controlerul liftului trimite un mesaj la usile liftului sa se inchida dupa un timp (timeout).

Controlerul liftului trimite o serie de mesaje la lift sa se deplaseze in sus spre etajul 7.

Controlerul liftului trimite un mesaj butonului pentru etajul 7 din lift sa se stinga.

Controlerul liftului trimite un mesaj la usile liftului sa se deschida pentru ca utilizatorul A sa poata iesi din lift.

Controlerul liftului porneste cronometrul.
Utilizatorul A iese in lift.

Controlerul liftului trimite un mesaj la usile liftului sa se inchida dupa un timp (timeout).

Controlerul liftului trimite o serie de mesaje la lift sa se deplaseze in sus spre etajul 9 cu utilizatorul B in el.


Diagrama de secventa pentru scenariul de mai sus

Pasi:

Se extrag actorii din scenariu si se deseneaza pe acelasi nivel

numele actorului cu bold in caseta aferenta (daca actorul este obiect)

se traseaza cate o linie verticala sub fiecare actor - indica timpul

Actorilor li se asociaza evenimente (lista actor - evenimente)

Utilizatorul A (evenimentele 1 si 8)

buton etaj (evenimentele 1, 2, 3 si 5)

buton lift (evenimentele 9, 10 si 13)

controler lift (evenimentele 2-7, 9-17)

lift (evenimentele 4, 12 si 17)

usa lift (evenimentele 6, 11, 14 si 16)

Evenimentele se insereaza in diagrama in ordinea in care ele apar in scenariu.

1b. Construirea diagramelor de colaborare

Punctul de plecare: scenariile din analiza OO

Scop: ilustrarea relatiilor de colaborare intre obiecte

Elementele constitutive ale diagramei

Actori

utilizatori umani



obiecte active in evenimentele scenariului (instante de clase din sistem) - dreptunghiuri cu numele obiectului subliniat

Relatiile de colaborare dintre actori - linii pe orizontala, verticala, oblice -

Evenimentele - linii scurte cu sageti si etichetate, paralele cu liniile relatiilor

actiuni ale utilizatorilor

mesaje intre obiecte


Diagrama de colaborare pentru scenariul de mai sus

Pasi

Se extrag actorii din scenariu si se deseneaza in diagrama

numele actorului cu bold in caseta aferenta (daca actorul este obiect)

casetele cu actori se pozitioneaza astfel ca relatiile sa nu se suprapuna

se traseaza cate o linie (orizontala, verticala, oblica) intre actorii care colaboreaza (isi trimit mesaje)

Relatiilor dintre actori li se asociaza evenimente (lista relatie - evenimente)

Utilizatorul A cu buton etaj (evenimentul 1)

Utilizatorul A cu buton lift (evenimentul 8)

buton etaj cu controler lift (evenimentele 2, 3 si 5)

buton lift cu controler lift (evenimentele 9, 10 si 13)

lift cu controler lift (evenimentele 4, 12 si 17)

usa lift cu controler lift (evenimentele 6, 11, 14 si 16)

Evenimentele se insereaza in diagrama in ordinea in care ele apar in scenariu. Sagetile se pun de-a lungul liniilor ce reprezinta relatia. Sensul sagetii indica directia in care se transmite mesajul.

Asemanari si deosebiri intre diagrama de interactiune si diagrama de colaborare

Asemanari:

o       apar aceiasi actori

o       apar aceleasi evenimente

deosebiri:

o       in diagrama de interactiune se ilustreaza ordinea evenimentelor

o       in diagrama de colaborare se ilustreaza relatiile dintre actori; evenimentele sunt atasate relatiilor si nu este evidenta ordinea lor

2. Construirea diagramei detaliate a claselor

Puncte de plecare:

Diagrama de clase din analiza OO

contine clasele, atributele acestora si relatiile dintre clase

Card-urile CRC

Scopuri:

identificarea metodelor claselor si inserarea lor in diagrama de clase

stabilirea drepturilor de acces (vizibilitatii) pentru membri

adaugarea de clase aditionale

modulul principal (aplicatia)

clase de serviciu (ajuta implementarea)

Elementele definitorii ale unei clase

Membri: date, metode

Drepturi de acces pentru membri

public

private

protected

Reprezentarea claselor

numele clasei este un substantiv la singular, scris cu bold, cu initiale



zona atribute contine specificatii Vnume atribut: tip de date

zona metode contine specificatii Vnume metoda(parametri)[: tip rezultat]

V indica vizibilitatea in afara clasei:

+ public - vizibil (accesibil) in afara

- private - invizibil (inaccesibil) in afara

# protected public in clasele derivate, private in ceilalti clienti

Atasarea de metode la clase - etape

Determinarea tuturor actiunilor pe care le realizeaza sistemul studiat

Atasarea actiunilor la clase sau la clienti - modalitati

folosind principiul ascunderii informatiei: actiunile efectuate asupra variabilelor de stare ale unei clase trebuie sa fie locale in clasa respectiva (deoarece variabilele de stare sunt private, deci nu pot fi accesate din afara clasei)

folosind principiul implementarii unice: orice actiune sa fie implementata o singura data ca metoda a unei clase (intr-o singura clasa)

folosind principiul proiectarii dirijate de responsabilitati - mai jos

Atasarea de metode la clase - pasi

Identificarea responsabilitatilor directe si indirecte ale fiecarei clase (CRC)

Transformarea responsabilitatilor in metode publice ale claselor

Refactorizarea claselor

Verificarea respectarii principiilor de proiectare

CLASS

ControlerLift

RESPONSIBILITY

1. Trimite mesaj la ButonLift sa aprinda butonul

2. Trimite mesaj la ButonLift sa stinga butonul

3. Trimite mesaj la ButonEtaj sa aprinda butonul

4. Trimite mesaj la ButonEtaj sa stinga butonul

5. Trimite mesaj la Lift sa mute liftul un etaj in sus

6. Trimite mesaj la Lift sa mute liftul un etaj in jos

7. Trimite mesaj la UsaLift sa se deschida

8. Porneste cronometrul

9. Trimite mesaj la UsaLift sa se inchida dupa timeout

10. Verifica cererile

11. Actualizeaza cererile

COLLABORATION

1. Subclasa ButonLift

2. Subclasa ButonEtaj

3. Clasa UsaLift

4. Clasa Lift

A doua iteratie a card-ului CRC pentru clasa ControlerLift


A treia iteratie pentru diagrama de clase

a. Identificarea responsabilitatilor directe si indirecte ale fiecarei clase

Din card-ul CRC pentru clasa ControlerLift rezulta ca responsabilitatile se pot grupa in doua categorii

responsabilitati directe ale clasei ControlerLift

8. Porneste cronometrul

10. Verifica cererile

11. Actualizeaza cererile

responsabilitati indirecte ale clasei ControlerLift, exprimate prin trimitere de mesaje spre alte clase C, de genul Trimite mesaj la C sa faca ceva

responsabilitatile 1-7, 9.

b. Transformarea responsabilitatilor in metode publice

responsabilitatile directe se transpun in metode ale clasei in cauza

clasa ControlerLift va avea metodele publice porneste cronometru verifica cereri si actualizeaza cereri

responsabilitatile indirecte se transpun in metode ale clasei careia ii este destinat mesajul

clasa ButonLift va avea metodele publice stinge buton si aprinde buton

clasa ButonEtaj va avea metodele publice stinge buton si aprinde buton



clasa Lift va avea metodele publice deplaseaza un etaj in sus si deplaseaza un etaj in jos

clasa UsaLift va avea metodele publice inchide usa si deschide usa

c. Refactorizarea claselor

se face in prezenta mostenirii - pentru clasele intre care exista relatii de mostenire

clasele ButonLift si ButonEtaj mostenesc de la clasa Buton

principiul factorizarii: fiecare membru al unei clase se pune in ierarhia de clase cat mai aproape de radacina

modalitati concrete de realizare

datele comune claselor derivate se pun in clasa de baza

membrul data iluminat este pus in clasa de baza Buton

metodele comune claselor derivate se pun in clasa de baza

clasele ButonLift si ButonEtaj au metodele comune stinge buton si aprinde buton

metodele stinge buton si aprinde buton se pun si in clasa de baza Buton

implementarea fiecarei metode se face cat mai aproape de radacina

implementarea metodelor stinge buton si aprinde buton este proprie fiecareia dintre clasele ButonLift si ButonEtaj, prin urmare implementarea apartine respectivelor clase

acolo unde o metoda nu se poate implementa, se declara abstracta

metodele stinge buton si aprinde buton se declara abstracte in clasa Buton

d. Verificarea respectarii principiilor de proiectare

principiul proiectarii dirijate de responsabilitati: fiecare clasa trebuie sa aiba controlul complet al comportamentului sau

responsabilitatile directe se transpun in metode ale clasei in cauza

responsabilitatile indirecte se transpun in metode ale clasei careia ii este destinat mesajul

principiul ascunderii informatiei: membrii date sunt ascunsi

se obtin clase independente si refolosibile

clientii nu au acces la reprezentarea obiectelor - rezulta obiecte mai sigure

exemple

clasa Buton: atributul iluminat este ascuns

clasa UsaLift: atributul usi deschise este ascuns

clasa ControlerLift: atributul cereri este ascuns

principiul factorizarii: fiecare membru este plasat cat mai aproape de radacina

metodele unei clase C formeaza un protocol de comunicatie respectat de toti descendentii clasei C

este favorizat polimorfismul: oriunde apare un obiect din clasa C se poate folosi un obiect al unei clase derivate din C

se simplifica scrierea codului (si intelegerea acestuia).


Figura - Diagrama de clase detaliata pentru problema liftului





Politica de confidentialitate | Termeni si conditii de utilizare



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 1800
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved