Problema liftului Studiu de caz

Scopul laboratorului utilizarea UML (Unified Modeling Language) drept mediu de dezvoltare software. UML este un limbaj de modelare bazat pe notaii grafice folosit pentru a specifica, vizualiza, construi i documenta componentele unui program. Formularea problemei: Se cere dezvoltarea unui produs software care s controleze funcionarea a n lifturi ntr-o cldire de m etaje. Produsul trebuie s asigure deplasarea lifturilor ntre etaje, innd cont de urmtoarele restricii: Fiecare lift are un set de m butoane, corespunztoare fiecrui etaj. Fiecare buton se aprinde cnd este apsat i determin deplasarea liftului la etajul corespunztor. Butonul se stinge cnd liftul ajunge la etajul respectiv. Fiecare etaj, cu excepia parterului i a ultimului etaj, are 2 butoane: unul care determin urcarea liftului i unul care determin coborrea acestuia. Aceste butoane se aprind cnd sunt apsate. Butoanele se sting cnd un lift ajunge la etajul de unde se face cererea. Atunci cnd un lift nu este solicitat, el rmne la etajul curent cu uile nchise Etape Analiza orientat obiect (OOA) modelarea cazurilor de utilizare (Use case) modelarea claselor modelarea dinamic Proiectarea orientat obiect (OOD) Diagrame de interaciune Diagrame detaliate de clase Paradigma orientat obiect n acest moment putem da o definiie a unui obiect, care const, acesta constnd n: Date atribute, variabile de stare, variabile instane, cmpuri, membri; Aciuni metode sau funcii membre.

ncapsulnd datele i aciunile, obiectele pot fi privite ca uniti independente, avnd att o independen conceptual ct i fizic. OOA const n urmtorii pai: 1. Modelarea Use Case (cazuri de utilizare) Determin cum se pot obine anumite rezultate folosind produsul ce trebuie creat, fr a interesa ordinea. Prezint informaiile sub forma diagramelor Use Case i a scenariilor asociate. Use Case-ul descrie ce face un program sau subprogram dar nu precizeaz nimic despre cum este realizat o funcionalitate.

2. Modelarea claselor Determin clasele i atributele lor Apoi se determin relaiile i interaciunile ntre clase Prezint informaiile sub forma unei diagrame 3. Modelarea dinamic Determin aciunile fcute de fiecare clas sau subclas Prezint informaiile sub forma unei diagrame n practic, cei trei pai nu se fac exclusiv secvenial. O schimbare ntr-o diagram determin revizia celorlalte dou. Astfel, cei trei pai ai OOA se fac efectiv n paralel. Acest fapt are sens deoarece n paradigma OO, nici o dat sau aciune nu are prioritate n faa alteia. n cursul analizei, cunotinele acumulate despre produs se reprezint n diferite moduri, fiecare reflectnd un aspect diferit al produsului int. Diagramele se actualizeaz continuu, pe msur ce se obin mai multe percepii asupra modelrii sistemului La sfritul fazei OOA, modurile diferite de abordare vor oferi o nelegere general a produsului care ar fi greu de obinut dac se folosete doar o tehnic de modelare 1. Modelarea Use Case Un Use Case descrie funcionalitatea produsului ce trebuie construit. Se furnizeaz astfel o descriere generic a funcionrii generale.

Scenariile sunt instane ale Use Case, la fel cum obiectele sunt instane ale claselor. Un Use Case descrie interaciunile generale dintre clasele produsului software i utilizatorii produsului Un Scenariu este un set particular de interaciuni ntre obiecte specifice i utilizatori. Nu vom discuta acum despre scenarii deoarece acestea sunt utilizate n special pentru OOD. Vom meniona doar faptul c n UML exist dou tipuri de scenarii: diagramele de secvene i diagramele de colaborare.

Exemplu de scenariu normal 1. Utilizatorul (user) A apas butonul de urcare de la etajul 3 pentru a chema un lift. Utilizatorul A dorete s mearg la etajul 7. 2. Butonul de urcare de pe etaj se aprinde. 3. Un lift sosete la etajul 3. n lift se afl utilizatorul B, care a urcat n lift la etajul 1 i a apsat butonul din lift corespunztor etajului 9. 4. Butonul de urcare de pe etaj se stinge. 5. Se deschid uile liftului. 6. Se pornete cronometrul. Utilizatorul A intr n lift. 7. Utilizatorul A apas butonul din lift corespunztor etajului 7. 8. Butonul liftului corespunztor etajului 7 se aprinde. 9. Uile liftului se nchid dup expirarea timpului de staionare pe etaj. 10. Liftul se mic spre etajul 7. 11. Butonul liftului corespunztor etajului 7 se stinge. 12. Uile liftului se deschid pentru a permite utilizatorului A s ias din lift. 13. Se pornete cronometrul. Utilizatorul A iese din lift. 14. Uile liftului se nchid dup expirarea timpului de staionare pe etaj. 15. Liftul urc spre etajul 9 cu utilizatorul B. Scenariul de mai sus reprezint un set de interaciuni ntre utilizatori i lifturi i corespunde modului n care nelegem c ar trebui folosite lifturile. Cele 15 evenimente descriu n detaliu cele dou interaciuni dintre Utilizatorul A i butoanele sistemului liftului (evenimentele 1 i 7) i aciunile componentelor sistemului liftului (evenimentele de la 2 la 6 i de la 8 la 15). Dou aciuni nu sunt numerotate, deoarece Utilizatorul A nu interacioneaz cu componentele liftului cnd intr sau iese din lift. n contrast cu scenariul normal se poate descrie i un scenariu anormal (excepie): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Utilizatorul A apas butonul de urcare de la etajul 3 pentru a chema un lift. Utilizatorul A vrea s mearg la etajul 1. Butonul de urcare de pe etaj se aprinde. Un lift sosete la etajul 3. n el se gsete Utilizatorul B, care a intrat n lift la etajul 1 i a apsat butonul corespunztor etajului 9. Butonul de urcare de pe etaj se stinge. Se deschid uile liftului. Pornete cronometrul. Utilizatorul A intr n lift Utilizatorul A apas butonul din lift corespunztor etajului 1. Se aprinde butonul din lift corespunztor butonului 1. Uile liftului se nchid dup expirarea timpului de staionare pe etaj. Liftul urc la etajul 9. Butonul liftului corespunztor etajului 9 se nchide. Uile se deschid pentru a permite utilizatorului B s ias din lift. Cronometrul pornete. Utilizatorul B iese din lift. Uile liftului se nchid dup expirarea timpului de staionare pe etaj. Liftul coboar la etajul 1 cu Utilizatorul A.

Utilizatorul A apas butonul de pe etaj greit. Observaii: n domenii mai puin familiare dect lifturile, scenariile deriv din documentele cerinelor. Trebuie studiate scenarii suficiente pentru a da echipei OOA o privire cuprinztoare asupra comportrii sistemului ce trebuie modelat Aceste informaii sunt utilizate n faza urmtoare, modelarea claselor, pentru a determina clasele (obiectele). De asemenea sunt folosite n OOD. 2. Modelarea claselor n acest pas, clasele i atributele lor se extrag i se reprezint folosind o diagram entitate-relaie. Se determin doar atributele clasei, nu i metodele (acestea se vor determina n faza OOD). Este dificil de a reui extragerea claselor i a atributelor din primul moment. O metod de a determina clasele este de a le deduce din Use Case-uri i din scenariile asociate acestora, prin identificarea componentelor care joac un rol n Use Case-uri. Adesea exist multe scenarii i exist pericolul posibil de a considera prea multe clase candidate. Este mai simplu s se adauge o nou clas la model dect de a terge o clas care nu trebuia inclus. Exist dou abordri pentru modelarea claselor: 1. Extragerea substantivelor dac dezvoltatorul are puin experien sau nu are deloc n domeniul aplicaiei 2. Cardurile CRC - dac dezvoltatorul are experien n domeniu. (CRC = Class Responsibility Collaboration) Extragerea substantivelor Pentru dezvoltatorii fr experien n domeniul aplicaiei, o metod bun este de a folosi un proces cu trei etape pentru a extrage clasele candidate i apoi pentru a rafina soluia. Et. 1 Definirea concis a problemei Se definete produsul ct mai concis posibil, de preferat ntr-o singur propoziie. Ex. Butoanele din lifturi i de pe etaje controleaz micarea a n lifturi ntr-o cldire cu m etaje. Et. 2 Strategia informal Se introduc constrngerile, exprimnd rezultatele ntr-un singur paragraf (de preferat). Ex. Butoanele din lifturi i de pe etaje controleaz micarea a n lifturi ntr-o cldire cu m etaje. Butoanele se aprind cnd sunt apsate pentru a cere un lift la un anumit etaj. Butoanele se sting cnd cererea este satisfcut. Cnd un lift nu are nici o cerere, rmne la etajul curent cu uile nchise.

Et. 3 Formalizarea strategiei Se identific substantivele din strategia informal, excluzndu-le pe acelea care depesc domeniul problemei. Se folosesc substantivele drept clase candidate. O regul uzual este de a utiliza substantivele rare pentru a defini clasele n timp ce cele frecvente sunt atribute ale claselor (de ex. iluminare este atribut al butonului) Substantive: buton, lift, etaj, micare, cldire, iluminare, cerere, u Etaj, cldire, u sunt n afara problemei, deci se exclud. Micare, iluminare, cerere sunt substantive abstracte, deci se exclud (pot deveni atribute) Clase candidate: (Lift) Elevator i (Buton) Button. Subclase: (Buton Lift) Elevator Button i (Buton Etaj) Floor Button. Prima iteraie a Diagramei de Clase

Atributul illuminated modeleaz evenimentele 2, 4, 8 i 11. Problema specific dou tipuri de butoane, deci se definesc dou subclase ale clasei Button i anume Elevator Button i Floor Button => motenire. Atributul doors open modeleaz evenimentele 5, 9, 12, 14 din scenarii. Fiecare din Elevator Button i Floor Button comunic cu Elevator. Din pcate nceputul nu este bun. ntr-un lift real, butoanele nu au o comunicare direct cu lifturile. Este nevoie de o nou clas Elevator Controller. Totui, expunerea problemei nu menioneaz controlerul, deci nu poate fi selectat drept clas n procesul de extragere a substantivelor. Tehnica de gsire a claselor candidate ofer un punct de start dar cu siguran nu face mai mult dect att.

A doua iteraie pentru Diagrama de clase

Dac folosim doar relaii 1-la-n proiectarea i implementarea sunt mai uoare. De aceea este indicat reducerea, pe ct este posibil, a relaiilor mai multe la - mai multe la relaii 1la-n. Cardurile CRC Pentru fiecare clas, echipa de dezvoltare software completeaz n card numele clasei, funcionalitatea sa (responsabilitatea) i o list a celorlalte clase ce permit obinerea acestei funcionaliti (colaborarea). n acest moment, ntregul proces poate fi automatizat; Uneltele CASE, cum ar fi System Architect include module pentru crearea i actualizarea cardurilor CRC. Puterea cardurilor CRC este aceea c, atunci cnd sunt utilizate de o echip, interaciunea ntre membrii echipei pune n eviden lipsa sau completarea incorect a cmpurilor clasei, ct i a atributelor i metodelor. De asemenea se clarific relaiile ntre clase cnd se folosesc cardurile CRC.. O slbiciune a cardurilor CRC este aceea c aceast abordare general nu este cea mai bun cale de a identifica clasele dect dac membrii echipei au o experien considerabil n domeniul aplicaiei. Pe de alt parte, odat ce dezvoltatorii determin majoritatea claselor i au o idee despre responsabiliti i colaborri, cardurile CRC pot fi un mod excelent de a completa procesul i de a fi siguri c totul este corect.

3. Modelarea dinamic Scopul modelrii dinamice este de a realiza Diagrama de stri, care este o descriere a produsului int, similar cu un automat cu stri finite, pentru fiecare clas. Reprezentarea diagramei de stri UML este mai puin formal. Cele trei aspecte ale unui automat finit (stri, evenimente, predicate) sunt distribuite peste diagrama UML. Predicate sau grzile UML apar ntre paranteze

Testarea in timpul fazei OOA Urmtorul pas este verificarea OOA. O component a acestei verificri este utilizarea cardurilor CRC. Fiecare card CRC este completat pentru fiecare clas. Cardul CRC pentru Elevator Controller se deduce din diagrama de clase i din diagrama de stri. Mai precis: RESPONSABILITATEA pentru Elevator Controller se obine listnd toate aciunile din diagrama de stri pentru Elevator Controller. COLABORAREA pentru Elevator Controller se determin examinnd diagrama de clase i notnd care din clasele Elevator Button, Floor Button i Elevator interacioneaz cu clasa Elevator Controller.

Acest card CRC pune n eviden dou probleme majore n prima iteraie a OOA. S considerm responsabilitatea: 1. Turn on elevator button (aprinde butonul liftului) Aceast comand este inacceptabil din punctual de vedere al paradigmei orientate obiect (OOP). Din punct de vedere al polimorfismului, obiectele clasei Elevator button ar trebui s fie responsabile pentru aprinderea sau stingerea butoanelor. De asemenea se ignor ascunderea informaiilor Responsabilitatea corect este: 1. Trimite mesaj ctre Elevator Button pentru a se aprinde singur. A doua problem este c o clas a fost suprancrcat. S considerm responsabilitatea: 7. Deschide uile liftului i pornete cronometrul. Conceptul cheie aici este noiunea de stare. Atributele unei clase sunt considerate adesea ca variabile de stare. Conceptul de stare joac un rol important n OOP. Acest concept poate fi utilizat pentru a ne ajuta s determinm dac o component poate fi modelat ca o clas. Dac respectiva component are o stare care va fi schimbat n timpul implementrii, atunci ea poate fi probabil modelat ca o clas. Deci Elevator Doors ar putea fi o clas.. Un alt motiv este protejarea n faa schimbrilor neautorizate ale strii = considerente de siguran. Observaie: Dup ce se face aceast schimbare, trebuie s reconsiderm modelul dinamic i modelul Use Case.

A doua iteraie a cardului CRC

n completarea celor dou probleme majore puse n eviden de cardul CRC, responsabilitile Check requests i Update requests necesit ca atributul requests s fie adugat clasei Elevator Controller. A treia iteraie a Diagramei de clase La acest pas, cererile sunt definite ca fiind de tipul requestType ; o structur de date pentru cereri va fi aleas n timpul pasului de proiectare detaliat. Modificnd diagrama de clase trebuie s reexaminm diagramele Use Case i de stri pentru a vedea dac este nevoie de viitoare rafinri. Use-Case => Ok Diagrama de stare => trebuie actualizat cu aciunile care reflect noile responsabiliti i extins pentru a include clasele adiionale. .

A doua iteraie a scenariului normal 1. Utilizatorul A apas butonul de urcare de la etajul 3 pentru a chema un lift. Utilizatorul A dorete s mearg la etajul 7. 2. Butonul etaj informeaz controlerul liftului c a fost apsat 3. Controlerul liftului trimite un mesaj ctre butonul de urcare de pe etaj s se aprind. 4. Controlerul liftului trimite o serie de mesaje ctre lift s se mite n sus spre etajul 3. n lift se afl utilizatorul B, care a luat liftul de la etajul 1 i a apsat butonul din lift corespunztor etajului 9. 5. Controlerul liftului trimite un mesaj ctre butonul de urcare de pe etaj s se sting. 6. Controlerul liftului trimite un mesaj ctre uile liftului s se deschid. 7. Controlerul liftului pornete cronometrul. Utilizatorul A intr n lift. 8. Utilizatorul A apas butonul din lift corespunztor etajului 7. 9. Butonul liftului informeaz controlerul liftului c a fost apsat. 10. Controlerul liftului trimite un mesaj ctre butonul liftului corespunztor etajului 7 s se aprind. 11. Controlerul liftului trimite un mesaj ctre uile liftului s se nchid dup expirarea timpului de staionare pe etaj 12. Controlerul liftului trimite o serie de mesaje ctre lift s urce la etajul 7. 13. Controlerul liftului trimite un mesaj ctre butonul liftului corespunztor etajului 7 s se sting 14. Controlerul liftului trimite un mesaj ctre uile liftului s se deschide pentru a permite utilizatorului A s ias din lift 15. Controlerul liftului pornete cronometrul. Utilizatorul A iese din lift. 16. Controlerul liftului trimite un mesaj ctre uile liftului s se nchid dup expirarea timpului de staionare pe etaj. 17. Controlerul liftului trimite o serie de mesaje ctre lift s urce la etajul 9 cu utilizatorul B

n acest moment toate cele trei modele sunt gata. De fapt, ar fi mai bine s spunem c toate cele trei modele sunt gata pentru moment. S-ar putea s fie nevoie s revenim la analiz orientat obiect n timpul fazei de proiectare orientat obiect Etapele proiectrii orientate obiect (OOD) OOD const n 4 pai: 1. Construirea diagramei de interaciuni pentru fiecare scenariu 2. Construirea diagramei detaliate de clase 3. Proiectarea produsului n termenii clienilor obiectelor 4. Trecerea la proiectarea detaliat Etapa 1. Construirea diagramei de interaciuni pentru fiecare scenariu Se construiete diagrama de secvene, care pune accentul pe aspectul temporal (ordonarea n timp a mesajelor). Notaia grafic este un tabel care are pe axa X obiecte, iar pe axa Z mesaje ordonate cresctor n timp. Axa Z arat pentru fiecare obiect linia vieii (linie punctat vertical) i perioada n care obiectul preia controlul execuiei (reprezentat printr-un dreptunghi subire pe linia vieii). n aceast perioad obiectul efectueaz o aciune, direct sau prin intermediul procedurilor subordonate. Se construiete diagrama de colaborare, care pune accentul pe organizarea structural a obiectelor care particip la interaciune. Ea conine obiecte, legturi care se stabilesc ntre acestea precum i mesajele prin care obiectele comunic. Mesajele sunt prefixate de un numr care indic ordonarea n timp a acestora i sunt ataate legturilor dintre obiecte. Unei legturi i pot fi ataate mai multe mesaje. Notaia grafic este un graf n care vrfurile reprezint obiecte, iar arcele reprezint legturile dintre ele. Se consider scenariul normal dat mai sus, pentru care se construiesc diagramele de secvene i de colaborare urmtoare:

Diagrama de secvene

Diagrama de colaborare

Etapa 2. Construirea diagramei detaliate de clase Se pune problema atribuirii unei aciuni unei clase sau unui client al acelei clase. Aceast atribuire se face n funcie de urmtoarele criterii: ascunderea informaiei reducerea numrului de copii ale aciunii polimorfism Ex.: (nchide ui) close doors este atribuit clasei Elevator Doors. (coboar un etaj) Move one floor down este atribuit clasei Elevator.

Diagrama detaliat de clase

Etapa 3. Proiectarea produsului n termenii clienilor obiectelor Se deseneaz o sgeat de la un obiect la un client al acelui obiect. Obiectele care nu sunt clieni ale unor alte obiecte trebuie s fie instaniate, probabil de metoda (funcia) main. Sunt necesare metode adiionale: Elevator Controler are nevoie de metoda elevator event loop astfel nct elevator application s o poat apela. Relaiile Client Obiect (C++)

Etapa 4. Proiectarea detaliat Se prezint ca exemplu proiectarea detaliat a metodei