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

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