Limbaj UML

Dezvoltarea unei colaborari

In sectiunea care urmeaza, prezentam design-ul unei GeneralBill folosite in cazul utilizarii unor modele ale diagramelor de comunicare. Acest proces incepe cu analiza claselor diagramelor pentru calsele cele mai utilizate in acest exemplu, pe care il schimbam, adaugand cateva trasaturi specifice de design pentru a ajuta la indeplinirea comportamentul cazului utilizat.

Asa cum diagrama claselor incepe sa incorporeze designul cazului utilizat si are roul de a stabiliza, tu costruiesti o diagrama de comunicare care trece prin procesului design-ului, aratand pas cu pas interschimbarea mesajelor asupra obiectului precum si legaturile participante in studiul nostru.

In procesul de luare al decizilor in cadrul diagramele de comunicare, trebuie sa te intorci la diagrama claselor ca sa asiguri consistenta datelor. Este de nevoie de individualizarea diagramelor de comunicare pentru a prezenta diferite scenario ale cazului studiat. Aceasta suita de diagrame de comunicare si a diagramelor de clasa la capturarea detaliilor de design ale vederii comportamentului dinamic si vederea clasei statice.

Structurand design-ul diagramelor de clasa

Cand se construieste o diagrama de comunicare, trebuie sa se identifice obiectele participante si

sa se prezinte acestea intr-o diagrama de structura statica. Se pot afla mai multe detalii despre tipurile de trasaturi ale acestor diagrame in Capitolul 3 si Capitolul 5.

In figura 14-1 arata diagrama initiala a claselor construita pe parcursul analizei pentru exemplul cazului utilizat GenerateBill. In diagrama data ca exemplu, se poate vedea ca fiecare Camera are un set ordonat al stays (indicat pe diagrama dupa completitudine si dupa multiplicitate ) si pentru fiecare stays si data este o rata de camera asociata.

O rata de camera poate fi pentru multiple camere dar fiecare combinatie a unui stay o data si o rata de camera este o clasa Lodging care are cateva informatii despre specificitatea datelor respective asa ca numarul de ocupanti ai acelei zile.

Pentru fiecare stay si data este deasemenea un set de rate de camera care pot fi aplicate- care pot include lucruri ca serviciu de camera sau video. Putem sa legam Taxele de camera la Lodging in loc sa fie direct la Stay, dar s-a simtit ca Taxele de camera sunt probabil generate de sisteme diferite de Lodging, Taxe deci este probabil mai bine ca responsabilitatile sa fie separate.

1(ordonator)

Fig 14-1: Diagrama claselor initiala pentru cazul Generate Bill

Concentrarea pe o clasa centrala

O clasa centrala sau o clasa focalizata este clasa pentru care in cazul utilizat pare sa fie cea mai preocupata , deobicei, cu crearea, gasirea sau manipularea instantelor claselor sau cu folosirea ei in cautarea altor informatii care sunt necesare cazului utilizat. Se poate vedea ca pentru acest caz clasa centrala este Stay, ca cele mai multe elemente ale informatiei necesare cazului-in particular, elemetele din factura- sunt valabile in apropierea calsei Stay. Desi informatia necesara este accesibila din alte clase, distanta de la Stay este cea mai scurta. Desigur, masurarea aici nu reprezinta distanta fizica in diagrama, este cate salturi trebuie sa faca ca sa ajunga la informatie.

Cand poti identifica clasa centrala pentru un caz sau operatie utilizate, ai un inceput in desenarea colaboratiei. Ca exemplu, asa cum interactiunile dintre clase dau o lovitura de deschidere, cae mai mare parte a comportamentului va trebui sa fie focalizata pe gasirea instantei corecte pentru clasa centrala. Dupa ce este gasita, aceasta instanta va fi probabil locul corect pentru asignarea celei mai mari parti a lucrului. Stiind care clasa este clasa centrala, va fi mai usor ca atentia sa fie focalizata in locul corect.

Acum ca se stie ca clasa centrala este Stay, trebuie sa se gaseasca abordarea corecta pentru gasirea instantei corecte a lui Stay, atunci cand cazul utilizat ruleaza. Din partea logica a situatiei, apare ca actorul poate fi intrebat de numarul camerei. Pentru a ajuta la gasirea instantei corecte a clasei centrale (Stay), s-a creat o clasa numita InventarulHotelului, care actioneaza ca un container care tine toate camerele libere ale hotelului. Ocupatia principala va fi sa se gaseasca un obiect particular Camera, care sa dea numarul camerei. (Referit la fig 14-3, mai incolo in acest capitol, pentru a vedea cum este pozitionata construirea acestei clase container). Containerul InventarulHotelului foloseste calificativul NumarCamera ca un index pentru Camera. Daca se stie NumarCamera, se poate folosi InventarulHotelului pentru a gasi Camera dorita. (Folosirea calificativului ca indice in asociere este discutata in capitolul 4).

De la Camera corecta, cazul utilizat trebuie sa gaseasca Stay-ul correct. Se presupune ca GenerateBill, cazul utilizat, este in mod normal inceput cu verificarea clientilor, asa ca se poate folosi ultimul Stay asociat cu camera. Este posibil sa se gaseasca ultimul Stay de la Camera, pentru ca Stay-urile sunt ordonate dupa Camere.