Analiza si gestiunea sistemelor informatice complexe
Curs 5

Diagrame de pachete (module). Rafinarea diagramelor de clase. Prototipizare

Back Up Next

 

Diagrame de pachete (module)

        Pentru sistemele informatice complexe modelele statice conţin zeci de entităţi. Volumul mare de clase poate fi asimilat şi înţeles cu mai mare uşurinţă de către membri echipei de dezvoltare dacă se realizează mai multe diagrame de clase, grupând laolaltă clase cu anumite caracteristici comune (de ex. un criteriu de grupare poate fi dat de tipurile claselor: de interfată, etitate şi de control).

        Aceste diagrame de clase se grupează într-un pachet (modul). UML şi intrumentul Rational Rose permit reprezentarea în cadrul aceleaşi diagrame atat a claselor şi relaţiilor dintre ele cat şi a pachetelor. Pentru o mai bună vizibilitate a modelului propunem ca pachetele şi clasele să fie reprezentate în diagrame separate. Reprezentarea grafică a unui pachet este dată în figura 1.  Unui pachet ii pot fi asociate una sau mai multe diagrame de clase, dintre care una este diagrama principală.


Figura 1.

        Rational Rose priveste un sistem informatic din trei punce de vedere : al cazurilor de utilizare, logic si al componentelor.  Diagramele de clase pot fi contruite atât asociate unui caz de utilizare (în fazele timpurii ale analizei) cât şi unui pachet, in cadrul vederii logice.  Atunci când diagramele de cazuri de utilizare sunt complete, clasele definite la acest nivel se transferă în vederea logică în pachete (module) bine stabilite.

        Intre pachete pot exista relatii de un singur tip: relaţii de dependenţă. Spunem ca un pachet A depinde de pachetul B dacă una sau mai multe clase din pachetul A (numit pachet client) iniţiază o comunicare cu una sau mai multe clase din pachetul B (numit pachet furnizor).  Relaţiile de dependenţă între module se reprezintă grafic printr-o linie punctată, având la capătul corespunzător modului furnizor o săgeată (figura 2).


Figura 2.

        Atunci când o clasă definită într-un pachet apare într-o diagramă de clase a altui pachet (in vederea reprezentarii unei relatii de asociere de exemplu), compartimentul superior va conţine, alături de numele acesteia şi un eventual stereotip, numele pachetului din care provine (figura 3).


Figura 3.

 

Rafinarea diagramelor de clase

Rafinarea claselor pe baza diagramelor de interactiune

        Diagramele de interacţiune (colaborare si secventa) şi diagramele de clase se completează şi influenţează reciproc.  Determinarea unui obiect sau a unei interacţiuni între două obiecte  modelate într-o diagramă de interacţiune poate avea ca efect adăugarea unei noi operaţii, a unui nou atribut, a unei relaţii (de obicei de asociere) sau chiar a unei noi clase.  De asemenea detalierea structurii şi comportamentului unei clase (de ex. adăugarea de argumente şi valoare returnată operaţiilor) poate afecta natura şi/sau ordinea interacţiunilor între obiectele dintr-o diagramă de interacţiune.

        Atât diagramele de clase cât şi diagramele de interacţiune sunt intim legate de diagramele de cazuri de utilizare. O primă variantă a diagramelor de clase se realizează în urma parcurgerii tuturor cazurilor de utilizare şi a actorilor. De asemenea o diagramă de utilizare descrie un scenariu specific unei caz de utilizare concret.  Care dintre acestea trebuie construită mai întâi? Nu există o regulă. Diversele metode existente propun ambele abordări.  Ceea ce este important de reţinut este faptul că atât diagramele de clase cât şi cele de interacţiune nu se realizează ‘dintr-un foc’, ci după o serie de iterări care presupun rafinarea paralelă a acestora.

Rafinarea claselor indusa de structura

        Dacă un obiect al unei clase nu necesită un anumit atribut sau o anumită operaţie, identificate în diagrama de clase in fazele timpurii ale analizei , este foarte probabil că clasa acestuia trebuie să fie descompusă în două sau mai multe clase (ex. clasa CursOptional avand atributele: numărLocuri, locaţie, ziuaDasfăşurării, oraDesfăşurării, departament, numarLocuriCursuriTotal - numarLocuriCursuriTotal  nu este o informatie care caracterizeaza obiectele clasei CursOptional ci mai degraba caracterizeaza un departament - figura 4).


Figura 4.

Rafinarea diagramelor de clase prin specializare/generalizare

        Operatiile de generalizare şi specializare a claselor permit crearea de noi clase care nu pot fi identificate direct prin intermediul documentului de specificare functionala a sistemului informatic modelat.  Astfel, generalizarea conduce la crearea de noi clase ca va contine atributele, operatiile si asocierile comune unui grup de clase deja identificate (figura 5). 


Figura 5.

        La baza specializării (motivul creerii sub-claselor) stă o relatie de asemănare (un obiect al clasei B este obiect al clasei A) şi un discriminator (obiectele clasei B diferă de obiectele clasei A prin...). Discriminatorul are o mulţime finită de valori şi subclasele pot fi create pentru fiecare valoare.  (exemplu: o sticla poate fi returnabilă sau ne-retunabilă; această caracteristică se poate constitui într-un atribut sau se pot creea două sub- clase SticlăReturnabilă şi SticlaNereturnabilă ale clasei Sticla, discriminatorul fiind tipul sticlei).

        Ce se întâmplă atunci când se descoperă mai mulţi discriminatori (ex. Curs: intern/extern, obligatoriu/optional)? Există mai multe soluţii: 
   
         - discriminatorul nu este relevant pentru aplicaţie astfel încât să inducă apariţia unei relaţii de specializare;
           
- modelare folosind moştenirea multiplă;
            -
modelare folosind agregare (figura 6).

        In anumite situatii determinarea asemănării şi a discriminatorului între două clase nu sunt suficiente pentru a modela clar relaţia de specializare/generalizare. (ex. pătratul este un dreptunghi cu toate laturile egale - structura si functionalitatea implementate de clasa Dreptunghi fac dificila specializarea din aceasta a unei clasa Patrat; de asemenea operatia inversa, clasa Dreptunghi mostenind de la Patrat induce anomalii in conditiile extinderii ierarhiei de mostenire cu clasele Patrulater, Paralelogram etc; varianta utilizarii agregarii - figura 6 - pare a fi cea mai potrivita in acest caz; luarea deciziei depinde in mare masura de natura problemei modelate ).


Figura 6.

        Problema utilizării agregării: La specializare atributele şi operaţiile comune subclaselor sunt poziţionate la nivelul superclasei. Ce se va întâmpla cu relaţiile? Există 2 variante:
   
         - rămân la nivelul subclaselor
   
         - se pun la nivelul superclasei în aşa fel încât să reprezinte o reuniune a relaţiilor subclaselor.

        Ambele variante sunt corecte din punct de vedere al modelării. Cea mai bună abordare este, în cele mai multe cazuri, prima (luarea deciziei depinde daca doreste obţinerea tuturor informaţiilor corespunzatoare asocierii în acelaşi timp sau separat, la nivelul subclaselor)


Figura 7.

        Exista situatii in care relatia de specializare/generalizare a claselor in cadrul unui model nu corespunde cu specializarea/generalizarea entitatilor din punct de vedere logic.  In figura 8 este prezentat un exemplu in care clasa ce implementeaza notiunea de punct in spatiul tridimensional reprezinta o specializare a punctului in spatiul bidimensional; din punct de vedere logic insa, lucrurile stau exact invers. 


Figura 8.

Prototipul de interfata

        După finalizarea diagramelor de cazuri de utilizare şi a unor prime versiuni stabile a diagramelor de interacţiune şi de clase se recomandă implementarea unui prototip al sistemului informatic.  Acest prototip se numeşte prototip de interfaţă deoarece are rolul de a :
            -
rafina relaţiiile dintre actori şi clasele de interfaţă,

            -
obţine feedback din partea beneficiatrului (clientului) asupra aspectului vizual al aplicaţiei,
            -
descoperi cazuri de utilizare ce descriu relaţii între componentele interfeţei aplicaţiei (interfaţă utilizator sau interfata cu alte programe).

        Prototipul poate conduce la descoperirea sau confirmarea cerinţelor enunţate.  În acelaşi timp însă un prototip poate genera o reacţie defavorabilă din partea clientului cu privire la termenii stabiliţi iniţial pentru dezvoltarea aplicaţiei.  Acesta trebuie lămurit din start că ceea ce s-a realizat reprezintă doar o ‘carcasă’ vizuală a viitoarei aplicaţii, fără a se avea în vedere funcţionalităţile descrise în specificaţii.

        De asemenea, scopurile prototipului sunt :
            -
stabilirea unor cerinţe ale interfeţei pentru funcţionalităţi cheie ale aplicaţiei;
            -
se demonstrează clientului (într-o formă vizuală) că cerinţele proiectului au fost bine înţelese şi sunt realizabile;
            -
inceperea etapei de dezvoltare a elementelor standard ale interfeţei;
            -
construirea de cutii de dialog care, după validare, vor fi utilizate în aceeaşi forma în faza de construcţie.

        Procesul de prototipizare trebuie început cu investigarea aşteptării actorilor asupra interfeţei prin completarea unor chestionare specifice formate din următoarele întrebări:
            -
ce nivel de pregătire (informatică) necesită actorul pentru a realiza o anumită funcţionalitate?
            -
actorul are experienţă de lucru în medii bazate pe ferestre?
            -
actorul are experienţă în utilizarea altor sisteme de automatizare a procesului modelat?
            -
este necesară consultarea unor documente/cataloage în paralel cu utilizarea aplicaţiei?
            -
actorul doreşte implementarea unor facilităţi de tip ‘salvare/restaurare’?

        Răspunsurile la întrebările de mai sus se notează pentru fiecare element de interfaţă.  De asemena consideraţiile generale legate de interfaţa utilizator sunt specificate în final (culori, mod de introducere general, tip de componente (controale) grafice utilizate etc).

        60% din utilitatea interfeţei este data de modul în care interfaţa utilizator se ‘potriveste’ cu modelul mental al utilizatorului despre o anumită funcţionalitate.  Interacţiunea influenţează utilitatea într-o proporţie de 30% iar prezentarea (modul în care aceasta arată) contează într-o proporţie de 10%.  Prin urmare probleme de genul “Mută butonul OK cu 10 pixeli mai sus” nu trebuie să domine realizarea prototipului.  Prototipul trebuie iniţial să identifice grupuri majore de ferestre şi strategia de interacţiune de ansamblu, lăsând la final aspecte de ordin estetic.

        Se utilizează hărţi (diagrame) de strucutră a ecranului (nu sunt definite în UML) -> descrie fluxul aplicaţiei urmând căile principale ale cazurilor de utilizare.  Se vor utiliza forme pătrate pentru reprezentarea ferestrelor modale (necesită un răspuns dat de utilizator pentru a se putea continua o activitate).  Pentru reprezentarea ferestrelor ne-modale se vor utiliza forme pătrate cu colţurile rotunjite.  

        Direcţia de traversare: arată calea de navigare a ferestrelor.  Prin aceste figuri grafice se pot modela diverse elemente ale interfeţei utilizator (cutii de dialog, meniuri, bare de scule şi chiar ferestre conţinând tab-uri – figura 9)


Figura 9.

 


Figura 10.
Exemplu de diagrama de structura a ecranului

 

Back Up Next