Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

CATEGORII DOCUMENTE





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







DOCUMENTE SIMILARE

Trimite pe Messenger
LUCRARE DE DIPLOMA - Crearea si publicarea unei pagini web pe internet
Limbajul pseudocod
Votul electronic
Functia comerciala
Corelatia neliniara - Biostatistica
ARBORI BINARI. DEFINITIE SI TERMINOLOGIE
SUBIECTELE PROBEI PRACTICE PENTRU EXAMENUL DE ATESTAT PROFESIONAL LA INFORMATICA
Intretinerea fisierelor redolog Oracle9I
Utilizare de programe utilitare specializate pe diferite domenii
Prezentarea protocoalelor VoIP

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

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

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

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

4.       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.

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

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

7.       Controlerul liftului porneste cronometrul.
Utilizatorul A intra in lift.

8.       Utilizatorul A apasa butonul din lift pentru etajul 7.

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

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

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

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

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

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

15.   Controlerul liftului porneste cronometrul.
Utilizatorul A iese in lift.

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

17.   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

DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 894
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 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site