Documente Academic
Documente Profesional
Documente Cultură
Structura general a limbajului UML .......................................................................................7 2.2. Particularitatea (specificul) limbajului UML ...........................................................................8 2.2.1. UML limbaj de vizualizare ............................................................................................9 2.2.2. UML limbaj de specificare .............................................................................................9 2.2.3. UML limbaj de construire ..............................................................................................9 2.2.4. UML limbaj de documentare .......................................................................................10 2.3. Entiti n UML ......................................................................................................................11 2.4. Relaii UML ...........................................................................................................................14 2.5. Diagrame UML ......................................................................................................................16 3. Diagarama cazurilor de utilizare (use case diagram) ....................................................................17 3.1. Cazul de utilizare ....................................................................................................................17 3.2. Actori ......................................................................................................................................18 3.3. Interfee ..................................................................................................................................19 3.4. Legturile n diagrama a cazurilor de utilizare ......................................................................20 3.4.1. Relaia de asociere ...........................................................................................................20 3.4.2. Relaia de extindere .........................................................................................................22 3.4.3. Relaia de generalizare ....................................................................................................22 3.4.4. Relaia de tip include .......................................................................................................23 3.5. Exemplu de construirea diagramei cazurilor de utilizare .......................................................24 4. Diagrama de clase (class diagram) ................................................................................................26 4.1. Clasa .......................................................................................................................................27 4.1.1. Numele clasei ..................................................................................................................27 4.1.2. Atributele clasei ...............................................................................................................28 4.1.3. Operaiile .........................................................................................................................30 4.2. Relaii ntre clase ....................................................................................................................31 4.2.1. Relaia de dependena.......................................................................................................31 4.2.2. Relaia de asociere............................................................................................................32 4.2.3. Relaia de agregare ..........................................................................................................33 4.2.4. Relaia de compoziie ......................................................................................................33 4.2.5. Relaie de generalizare ....................................................................................................34 4.3. Interfee ..................................................................................................................................35 4.4. Obiecte ....................................................................................................................................35 5. Diagrama de stri (statechart diagram) .........................................................................................36 5.1. Automate ................................................................................................................................36 5.2. Stare ........................................................................................................................................37 5.2.1. Numele strii ...................................................................................................................38 5.2.2. Starea iniial ...................................................................................................................38 5.2.3. Starea final .....................................................................................................................38 5.3. Tranziie ..................................................................................................................................38 5.3.1. Eveniment ........................................................................................................................39 5.3.2. Condiie gard .................................................................................................................39 5.3.3. Expresia aciunei .............................................................................................................40 5.4. Stare i substare compus .......................................................................................................41 5.4.1. Substri disjuncte ............................................................................................................41 5.4.2. Substri concurente .........................................................................................................42 6. Diagrama de activiti (activity diagram).......................................................................................44 6.1. Starea activitii ......................................................................................................................44
6.2. Tranziii ..................................................................................................................................45 6.3. Partiii .....................................................................................................................................47 6.4. Obiecte ....................................................................................................................................49 7. Diagrama de secven (sequence diagram) ...................................................................................50 7.1. Obiecte ....................................................................................................................................50 7.1.1. Linia de via al obiectului ..............................................................................................51 7.2. Focus control ..........................................................................................................................51 7.3. Mesaje ....................................................................................................................................51 7.3.1. Stereotipuri de mesaje .....................................................................................................52 7.4. Restricii temporale n diagrama de secven .........................................................................52 8. Diagrama de colaborare (collaboration diagram) ..........................................................................53 8.1. Obiecte ....................................................................................................................................53 8.1.1. Multiobiect ......................................................................................................................55 8.1.2. Obiect activ .....................................................................................................................55 8.1.3. Obiect compus .................................................................................................................56 8.2. Legturi ..................................................................................................................................56 8.2.1. Tipuri de legturi .............................................................................................................57 8.3. Colaborare ..............................................................................................................................58 8.3.1. Diagrama de colaborare la nivel de specificare ...............................................................59 9. Diagrama de componente (component diagram) ..........................................................................60 9.1. Componente ............................................................................................................................61 9.1.1. Numele componentului ...................................................................................................62 9.1.2. Feluri de componente ......................................................................................................63 9.2. Interfee ..................................................................................................................................64 9.3. Dependene .............................................................................................................................64 9.4. Recomandri la construirea diagramei de componente ..........................................................66 10. Diagrama de plasare (deployment diagram) ...............................................................................67 10.1. Nod .......................................................................................................................................68 10.2. Conexare ...............................................................................................................................70 10.3. Recomandri la construirea diagramei de plasare ................................................................72
Metoda lui Grady Booch, care este cunoscut ca Booch sau Booch91, Booch Lite (mai trziu Booch93). Metoda lui James Rumbaugh, cunoscuta ca Object Modeling Technique OMT (mai trziu OMT-2). Metoda lui Ivar Jacobson, cunoscuta ca Object-Oriented Software Engineering OOSE.
Fiecare metod a fost orientat spre susinerea unor etape aparte ale APOO. De exemplu, metoda OOSE coninea mijloace de prezentare a cazurilor de utilizare, care au semnificaie esenial la etapa analizei cerinelor n timpul proiectrii business-aplicaiilor. Metoda OMT-2 era cea mai potrivit pentru analiza proceselor de prelucrare a datelor n sistemele informaionale. Metoda Booch93 era cea mai aplicabil la etapele de proiectare i exploatare a diferitor sisteme program. Istoria dezvoltrii limbajului UML ncepe n luna octombrie a anului 1994, cnd Grady Booch i James Rumbaugh din Rational Software Corporation au nceput s lucreze mpreun asupra unificrii metodelor Booch i OMT. Cu toate c aceste metode fiecare n parte erau destul de cunoscute, lucrul n comun era organizat pentru cercetarea tuturor metodelor OO cu scopul unificrii celor mai avantajoase trsturi ale lor. Proiectul acestei aa zise metode unificate (Unified Method) versiunea 0.8 a fost pregtit i publicat n luna octombrie anului 1995. n toamna aceluiai an a aderat la ei i Iv. Jacobson, tehnologul principal al companiei Objectory AV (Suedia), cu scopul integrrii metodei sale OOSE cu celelalte dou precedente. ncepnd lucrul spre unificarea metodelor, G. Booch, J. Rumbaugh i Iv. Jacobson au formulat urmtoarele cerinele ctre limbajul de modelare. El trebuie:
S ofere posibilitatea de a modela nu numai produse soft dar i clase mai largi de sisteme i business-aplicaii cu utilizarea noiunilor obiect orientate. S asigure n mod evident legatura ntre noiunile de baz ale modelelor nivelurilor conceptual i fizic. S asigure scalarea modelelor, ce este o calitate important a sistemelor complicate. S fie clar pentru analiti i programatori, de asemenea trebuie s fie susinut de ctre mijloace instrumentale speciale, realizate pe diferite platforme de calculator.
Dezvoltarea sistemei de notaii pentru APOO s-a dovedit s nu fie asemntoare cu dezvoltarea unui nou limbaj de programare. n primul rnd era necesar de rezolvat dou probleme:
1. Notaia dat trebuie s includ n ea i specificarea cerinelor? 2. Este necesar de extins notaia dat pna la nivelul limbajului de programare vizual? n al doilea rnd era necesar de gsit echilibrul ntre expresivitatea i simplitatea limbajului. Pe o parte, o prea simpl notaie limiteaz sfera problemelor poteniale care pot fi rezolvate cu ajutorul sistemului de notaii corespunztor. Pe de alt parte, o prea complicat notaie creaza dificulti adugatoare pentru studierea i aplicarea de ctre analiti i programatori. n cazul unificrii metodelor existente este necesar de a lua n consideraie interesele specialitilor, care au experien de lucru cu aceste metode, fiindc introducerea schimbrilor semnificative poate atrage dup sine nenelegerea i respingerea din partea utilizatorilor altor metode. Pentru a exclude opunerea neevident din partea unor specialiti, este necesar de a lua n considerarie interesele pturilor largi ale utilizatorilor. n continuare lucrul asupra limbajului de modelare unificat (Unified Modeling Language) a trebuit s ia n consideraie toate aceste circumstane. n aceast period suportul elaborrii limbajului UML devine unul din scopurile consoriului OMG (Object Management Group). Cu totate c consoriul OMG a fost creat nca n anul 1989 cu scopul de a elabora propuneri de standartizare a tehnologiilor orientate pe obiecte i componente CORBA, limbajul UML a captat statutul de a doua direcie strategic n lucrul OMG. Anume n cadrul OMG este creat comanda de elaboratori sub conducerea lui Richard Soli care va asigura lucrul de mai departe asupra unificrii i standartizrii limbajului UML. Eforturile lui G. Booch, J. Rumbaugh i Iv. Jacobson au dus la apariia primelor documente care conineau descrierea limbajului UML versiunea 0.9 (n iunie 1996) i versiunea 0.91 (n octombrie 1996). Aceste documente cu statut de propuneri RTP (Request For Proposals) au servit ca catalizator pentru discutarea n mas a limbajului UML de ctre diferite categorii de specialiti. Primele preri i reacii n ce privete limbajul UML indicau necesitatea de a-l completa cu notaii i construcii. Compania Rational Software mpreun cu cteva organizaii, care au manifestat dorina de a aloca resurse pentru elaborarea definiiei stricte a versiunii 1.0 limbajului UML, au fondat consoriul partenerilor UML n care iniial au intrat aa companii ca Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI Unisys. Aceste companii au asigurat suportul lucrului n continuare asupra definirii unei notaiei nc mai stricte i precise, ceea ce a dus la apariia versiunii 1.0 limbajului UML. Particularitatea limbajului UML const n aceea ca limbajul definete metamodelul semantic, dar nu modelul unei interfee concrete i metodele de prezentare i realizare a componentelor. n prezent toate ntrebrile elaborrii n continuare a limbajului UML sunt concentrate n limitele consoriului OMG. Grupul corespunztor de specialiti asigur publicarea materialelor care conin descrierea versiunilor urmtoare ale limbajului UML i a propunerilor RFP de standardizarea. O urmtoare etap de dezvoltare a acestui limbaj s-a terminat n martie anului 2003 cind consoriul OMG a publicat descrierea limbajului UML 2.0. Istoria elaborrii i dezvoltrii urmtoare al limbajului UML este reprezentat grafic n fig. 1. Pe baza tehnologiei UML Microsoft, Rational Software i ali furnizori de medii de dezvoltare a sistemelor de programare au elaborat modelul informaional unic care a fost numit UML Information Model. Se presupune c acest model va da posibilitatea diferitor programe care suport ideologia UML s fac schimb de componente i descrieri. Toate acestea vor permite crearea interfeei standarde ntre mijloacele de elaborare i mijloacele de modelare vizuala.
Fig. 1. Istoria dezvoltrii limbajului UML. Deja n prezent sunt elaborate mijloace de programare vizual pe baza lui UML care asigura integrarea, inclusiv generare directa i invers a codului de programe cu cele mai raspndite limbaje i medii de programare, aa cum sunt MS Visual C++, Java, C#, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Deoarece la elaborarea limbajului UML au fost luate n consideraie multe idei i metode de frunte se poate de ateptat c versiunile urmtoare ale limbajului UML vor fi influenate i de alte tehnologii i conceptii de perspectiv. n plus la aceasta n baza limbajului UML pot fi definite multe metode perspective noi. Limbajul UML poate fi extins fr o redefinire nucleului su.
Utilizarea constructiv a limbajului UML este bazat pe inelegerea principiilor comune de modelare a sistemelor complexe i a particularitilor procesului de analiza i proiectarea obiect orientate. Alegerea mijloacelor expresive pentru construcia modelelor ale sistemelor complexe stabilete din vreme problemele care pot fi rezolvate cu ajutorul utilizrii acestor modele. Totodat unul din principiile de baz pentru construirea modelelor ale sistemelor complexe este principiul de abstractizare care presupune includerea n model numai a acelor aspecte ale sistemului proiectat, care au nemijlocit legtura cu executarea de ctre sistem a funciilor sale sau cu destinaia lui de baza. Totodat toate detalii de importana secundar sunt omise pentru ca procesul de analiza i cercetare a modelului primit s nu fie foarte complicat. Alt principiu de construcie a modelelor ale sistemelor complexe este principiul de multi-modele. Acest principiu reprezint afirmaia c nici un model unic nu poate descrie diferite aspecte ale sistemului complex. Cu privire la metodologia APOO aceasta nseamn c un model destul de complet al unui sistem complex admite un anumit numr de reprezentri (views) legate reciproc, fiecare din ele reflectnd adecvat un anumit aspect de comportare sau structura a sistemului. Totodat cele mai generale reprezentri ale unui sistem complex sunt considerate reprezentri statice i dinamice care la rndul lor pot fi divizate n alte reprezentri particulare. nca un principiu al analizei aplicate de sistem este principiul de construire ierarhic a modelelor sistemelor complexe. Acest principiu presupune cercetarea procesului de construire a modelului la diferite nivele de abstractizare sau detaliere n limitele reprezentrilor stabilite. Totodat modelul iniial sau elementar al unui sistem complex are reprezentarea cea mai generala (meta-reprezentare). Un astfel de model se construiete la etapa iniial de proiectare i poate s nu conin multe detalii i aspecte ale sistemului modelat.
Reprezentare logica Utilizatorul final Relaii structurale exterioare i inferioare Reprezentare realizrii Programistul Relaii ntre componente ale produsului soft Reprezentare deplasrii componentelor Administratorul de sistem Topologia legaturilor i comunicaiilor ale componentelor Model fizic Model static
Reprezentare procesului de funcionare Integratorul de sistem Randamentul i volumul componentelor al unui sistem Model conceptual
Model dinamic
Fig. 2 Schema comun legturilor modelelor i reprezentrilor ale unui sistem complex n procesul APOO. n aa fel, un proces APOO poate fi reprezentat ca o coborre pe nivele: de la cele mai generale modele i reprezentri de nivel conceptual spre reprezentri mai particulare i detaliate ale nivelului logic i fizic. Totodat la fiecarea etap a procesului APOO modelele date sunt completate consecvent cu un numr din ce n ce mai mare de detalii ce le premite s reflecte mai adecvat diferite aspecte ale realizrii unui anumit sistem complex. Schema comun legturilor modelelor APOO este reprezentat n fig. 2.
Semantica limbajului UML reprezint un careva metamodel, care definete sintaxa abstracta i semantica noiunilor modelrii orientate pe obiecte n limbajul UML. Notaia limbajului UML reprezint o notaie grafica pentru reprezentarea vizual a semanticii limbajului UML.
Sintaxa abstract i semantica limbajului UML sunt descrise cu ajutorul unei anumite submulimi de notaii ale UML. n completare la aceasta, notatia UML descrie corespunderea sau reprezentarea notaiei grafice n semantica noiunilor de baza. n aa fel din punct de vedere funcional aceste dou pri completeaz una pe alt. Totodat semantica limbajului UML este descris pe baza unui metamodel care are trei reprezentri aparte: sintaxa abstract, reguli de construcia corect a expresiilor i semantica. Cercetarea semanticii limbajului UML presupune un careva stil semiformal de redare, care unifica limbaje naturale i formale pentru reprezentarea noiunilor de baza i regulilor de extindere a lor. Semantica se definete pentru dou tipuri de modele de obiecte: de structura i de comportare. Modelele de structur, cunoscute ca modele statice, descriu structura entitilor sau a componentelor unui sistem inclusiv clase, interfee, atribute i relaii. Modelele de comportare, numite uneori dinamice, descriu comportarea sau funcionarea obiectelor unui sistem, inclusiv metodele lor, colaborarea ntre ele, i procesul de schimbare a strilor unor componente aparte i al sistemului ntreg. Pentru rezolvarea unui diapazon att de larg de probleme de modelare este elaborat semantica destul de complet pentru toate componentele notaiilor grafice. Cerinele semanticii limbajului UML sunt concretizate la construirea anumitor tipuri de diagrame. Notaia limbajului UML include n sine descrierea elementelor semantice care pot fi utilizate la construcia diagramelor. Descriere formal a limbajului UML se bazeaza pe careva structur ierarhic comun a reprezentrilor de model care const din patru nivele:
Nivelul de meta-metamodel creaz o baz iniial pentru toate reprezentri de metamodele. Destinatia principal a acestui nivel const n definiia limbajului pentru specificarea metamodelului. Meta-metamodelul definete modelul limbajului UML la cel mai nalt nivel de abstractizare i cea mai compact descriere a lui. Din alt parte, meta-metamodelul poate specifica cteva metamodele ce permite atingerea flexibilitii poteniale de includere a noiunilor adugtoare. Ca exemple de notaii ale acestui nivel pot fi meta-clasa, meta-atribut, meta-operaie. Semantica meta-metamodelului nu intra n descrierea limbajului UML. Aceasta face limbajul UML mai simplu pentru studiere, fiindc nu cere cunoaterea teoriei limbajelor formale i a logicii formale. Metamodelul este un exemplar sau concretizarea meta-metamodelului. Scopul principal acestui nivel este definirea limbajului pentru specificarea modelelor. Acest nivel este mai constructiv dect cel precedent, fiindc semantica lui ale noiunilor de baz este mai dezvoltat. Toate noiunile de 7
baz ale limbajului UML sunt noiunile nivelului de metamodel. Exemple de aceste notiuni sunt clasa, atributul, operaia, componenta, asocierea i multe alte. Modelul n contextul limbajului UML este exemplarul metamodelului n sensul c fiecare model concret a unui sistem trebuie s utilizeze numai noiunile lui metamodel concretizndu-le cu privire la situaia dat. Acest nivel este pentru descrierea informaiei despre un domeniu concret (de obiecte).Ca exemple a acestui nivel pot fi numele cmpurilor ale bazei de date proiectate, de exemplu, numele i prenumele angajatului, vrsta, postul, adresa, numrul de telefon. Totodat noiunile date sunt utilizate numai ca nume ale atributelor informaionale corespunztoare. Descrierea semanticii limbajului UML presupune cercetarea noiunilor de baz numai ale nivelului metamodel care reprezint numai exemplu sau caz particular al nivelului meta-metamodel.
i textual dac programele instrumentale asigur coordonare ntre aceste dou prezentri al proiectului. n afar de reflectare direct datorit expresivitii i uniformitii limbajul UML permite executarea modelelor, imitarea colaborrii sistemului i controlul sistemului care funcioneaz.
cerine ctre sistem; arhitectura; proiectul; codul iniial; planuri de proiecte; teste; prototipuri; versiuni s.a.
n dependena de metodica elaborrii stabilit unele lucrurile se execut mai formal dect altele. Artifactele menionate mai sus sunt necesare pentru administrarea, aprecierea rezultatelor i ca mijloc de comunicare ntre membrii colectivului n timpul elaborrii proiectului i desfurrii lui. UML permite rezolvarea problemei de documentare a arhitecturii sistemului, ofer limbajul pentru definirea formal a cerinelor ctre sistemul i ctre teste, definete mijloace pentru modelarea lucrurilor pe etapa planificrii proiectului i administrrii versiunelor. Limbajul UML este destinat n primul rnd elaborrii sistemului de programare. Utilizarea lui este cu mult mai eficienta n urmatoarele sfere:
sisteme informaionale; servicii bancare i financiare; telecomunicaie; transport; industria de aprare, aviaie, cosmonautic; sisteme comerciale; electronica medical; tiina; distribuirea sistemului Web.
Sfera de aplicare a limbajului UML nu se limiteaz la modelarea produsului soft. Expresivitatea lui permite modelarea documentelor n sisteme juridice, modelarea structurii i functionalitatea sistemelor de deservire a pacienelor n spitale, proiectarea aparaturii. Pentru inelegerea limbajului este necesar de cunoscut principiile de baz a structurii acestui limbaj. Sunt numai trei principii i limbajul parc const din trei pri: construcii de baz ale limbajului, reguli de colaborare i anumite mecanizme comune. tiind toate aceste ideile vom putea citi modelele n UML i s le proiectm, desigur c vom ncepe cu cele mai simple. Pe parcursul obinerii experienei de lucru cu limbajul vom nva s utilizm posibilitile limbajului mai avansate. Dicionarul limbajului nclude trei tipuri de construcii de baz: 10
entiti abstracii ce sunt elemente de baz a modelului; relaii legturi ntre entiti; diagrame ce grupeaz interesele entitilor i relaiilor.
Entiti sunt elementele OO de baz ale limbajului. Cu ajutorul entitilor este posibil crearea modelelor corecte. Entittile de structur sunt substantivele n modelurile ale limbajului UML. De regul ele reprezint pri statice ale modelelor care corespund elementelor conceptuale i fizice ale sistemului. Exist apte varieti de entiti de structur: Clasa (class) este o descriere a unei totaliti de obiecte cu atribute, operaii, relaii i semantica comun. Grafic o clasa se reprezint printr-un dreptunghi n care se specific numele, atributele i operaiile clase, exemplu este artat n fig. 3.
NumeleClasei <<->> AtributPrivat : char <<#>> AtributProtejat <<+>> AtributPublic <<+>> op1() <<+>> op2()
Fig. 3. Clasa. Interfaa (interface) este o totalitate de operaii care definesc servicii oferite de clas sau component. n diagrame interfaa se reprezint printr-un cerc etichetat cu numele interfeei, fig. 4. Interfaa foarte rar exist aparte de obicei ea este legat cu clasa sau componenta care o realizeaz.
Interfata1
Fig. 4. Interfaa. Colaborarea (collaboration) definete o interaciune, ea reprezint o totalitate de roluri i alte elemente care produc un efect cooperativ i care nu se aduce numai la suma termenilor unei adunri. Grafic colaborarea se reprezint printr-o elips cu linie ntrerupt, interiorul creia conine numai numele colaborrii, fig. 5.
Colaborare1
Fig. 5. Colaborare. 11
Cazul de utilizare (use case) este o descriere a consecutivitii de aciuni ndeplinite de sistem care produc un rezultat semnificativ pentru un anumit actor. Grafic cazul de utilizare se reprezint printr-o elips cu linie continue n interiorul creia se conine denumirea cazului de utilizare, fig. 6.
Cazul de utilizare 1
Fig. 6. Caz de utilizare. Clasa activ (active class) se numete o clas obiectele creia sunt antrenate n unul sau mai multe procese sau n iruri (threads) i deaceea ele pot iniia o aciune administrativ. Grafic o clas activ se reprezint ca i o clas simpl, dar se limiteaz cu un dreptunghi cu marginile groase i care conine numele, atributele i operaiile clasei date, fig. 7.
NumeleClasei <<->> AtributPrivat : char <<#>> AtributProtejat <<+>> AtributPublic <<+>> op1() <<+>> op2()
Fig. 7. Clasa activ. Componenta (component) este o parte fizic a sistemului, care corespunde unui anumit set de interfee i asigur realizarea lui. Grafic o component se reprezint printr-un dreptunghi cu anexe, care de obicei conine numai numele componentei, fig. 8.
Componenta1
Fig. 8. Component. Nodul (node) este un element real (fizic) al unui sistem care reprezint un mijloc de calcul cu un anumit volum de memorie i deseori cu capacitate de prelucrare a informaiei i care exist n timpul funcionrii unui produs soft. Grafic pentru reprezentarea nodului se utilizeaz cubul care conine numele nodului, fig. 9.
Nod 1
Fig. 9. Nod. apte elemente de baz enumerate: clase, interfete, colaborri, cazuri de utilizare, clase active, componente i noduri sunt entitile principale de structur care pot fi utilizate n diagramele UML. Exist i alte varietti ale entitilor de structur: actori, semnale, utilite (tipurile de clase), procese
12
i iruri (tipuri de clase active), aplicaii, documente, fiiere, biblioteci, pagini i tabele (tipuri de componente). Entitile de comportament (behaviour things) sunt prile dinamice ale modelului UML. Acestea sunt verbele limbajului care descriu comportarea modelului n timpul i n spaiu. Exist numai doua tipuri de entiti de comportament. Interaciunea (interaction) este un mod de comportare care const n schimb reciproc de mesaje (messages) ntre obiecte n cadrul unui anumit context pentru a atinge un anumit scop. Cu ajutorul interaciunii se descrie att o operaie ct i comportarea unui set de obiecte. Interaciunea presupune un ir de alte elemente ca mesaje, consecutivitate de aciuni (comportare, iniializat de ctre mesaje) i legturi (ntre obiecte). Grafic mesajul se reprezint print-o sgeat deasupr careia se indic numele mesajului, fig. 10.
CreazaObiect()
Fig. 10. Mesaj. Automatul (state machine) este un algoritm de comportare care definete o succesiune de stri prin care trece un obiect sau o interaciune pe parcursul ciclului de viaa rspunznd la diferite evenimente i reaciile lui la aceste evenimente. Cu ajutorul automatului se descrie comportarea unei clase sau a unei colaborri de clase. Cu automatul este legat un ir de alte elemente: stri, tranziii de la o stare la alt, evenimente care sunt entitti ce iniiaz tranziii i tipuri de actiuni reacii la tranziii. Grafic o stare se reprezint printr-un dreptunghi cu coluri rotungite care conine numele strii sau posibil i strile intermediare, fig. 11.
Stare 1
Fig. 11. Stare. Interaciunile i automatele sunt entitile principale de comportament care pot fi utilizate n diagramele UML. Semantic ele sunt legate cu diferite elemente de structur, n primul rnd cu clase, cooperri i obiecte. Entitile de grupare sunt prile organizatorice ale modelului UML. Ele reprezint blocuri n care poate fi divizat modelul. O astfel entitate primar este unic pachetul. Pachetele (packages) reprezint un mecanism universal de organizare n grupe. n pachet pot fi plasate entitile de structur, de comportament i alte entiti de grupare. Spre deosebire de componentele care exist real, n timpul execuiei unui program, pachetele au caracter pur conceptual, adic ele exist doar n timpul elaborrii. Pentru reprezentarea unui pachet se utilizeaz notaia unei mape cu semn de carte care conine deseori numai numele i doar uneori i coninutul, fig. 12.
Entitile de adnotare sunt prile explicative ale unui model UML. Acestea sunt comentarii destinate descrierii adiionale, explicaiei sau observaiei ctre orice element al unui model. Exist numai un singur tip de baz al elementelor de adnotare remarca. Remarca (note) este numai un simbol pentru reprezentarea comentariilor sau a constrngerilor, legate de un element sau de un grup de elemente. Grafic o remarc se reprezint printr-un dreptunghi cu colul de sus din dreapta ndoit i care conine comentariul textual sau grafic, fig. 13.
Fig. 13. Remarca. Acest element este entitatea de adnotare principal care poate fi utilizat n modelul UML. De obicei remarca se utilizeaz pentru a asigura diagramele cu comentarii sau cu constrngeri care pot fi reprezentate sub form de text formal sau neformal. Exist i variante ale acestui element, de exemplu cerine care descriu comportarea dorit a unui sistem din punct de vedere exterior modelului.
Aceste relaii sunt construcii principale de legare n UML i sunt utilizate pentru construirea modelelor corecte. Dependena (dependency) este o relaie semantic ntre dou entiti astfel nct modificarea uneia din ele,a celei independente, poate influena semantica celeilalte, dependente. Grafic pentru reprezentarea dependenei se utilizeaza o linie ntrerupt, deseori cu sgeat care poate conine o etichet.
Fig. 14. Dependena. Asocierea (association) este o relaie de structur care descrie o totalitate de legturi, prin legtur se subnelege conexiunea semantic ntre obiecte. n calitate de simboluri suplementare pot fi utilizate numele unei asocieri, numele i multiplicitatea claselor rolurile asocierii. Numele asocierii nu este un element obligatoriu. Dac numele este dat, atunci el se scrie cu majuscul lnga linia ce corespunde asocierei. Grafic asocierea se reprezint printr-o linie (care uneori se termin cu o sgeat sau este etichetat), fig. 15.
NewClass 1 -Angajat Angajeaza -Angajator * NewClass2
O form special sau caz particular al relaiei de asociere se socoate relaia agregrii care la rndul su are o form special compoziia. Agregare (aggregation) este o anumit relaie ntre ntreg i prile lui componente. Aceast relaie are un sens fundamental pentru descrierea sistemelor complexe fiindc se utilizeaz pentru reprezentarea legturilor parte-ntreg. Dezvluind structura interioar a sistemului, relaia de agregare arat din ce elemente const sistemul i cum elementele sunt legate. Din punct de vedere al modelului prile aparte ale sistemului pot fi socotite ca elemente i ca subsisteme care la rndul lor pot crea componente sau subsisteme. Grafic relaia de agregare se reprezint printr-o linie continu, unul din capetele creia reprezint un romb gol. Acest romb arat ntregul i restul - prile, fig. 16.
Intreg Parte
Fig. 16. Agregare. Relaia compoziie este cazul particular al relaiei de agregare. Aceast relaie este destinat prezentrii formei speciale a relaiei parte-ntreg n care prile componente sunt n interiorul priii ntregi. Specifica legturii ntre ele const n aceea c prile componente nu pot exista fr partea ntreag, adic cu distrugerea ntregului se destrug i prile componente a lui. Grafic relaia de compoziie se reprezint printr-o linie continu, unul din capetele cruia reprezint un romb haurat. Acest romb arat clasa-compoziie sau ntregul i restul sunt prile lui, fig. 17.
Fig. 17. Compoziie. Generalizarea (generalization) este o relaie de tip specializare/generalizare n urma creia un obiect al elementului specializat (descendent) poate substitui obiectul elementului generalizat (printe). Descendentul (child) motenete structura i comportamentul printelui (parent) su. Grafic relaia de generalizare se reprezint printr-o linie cu o sgeat goal care arat printe, fig. 18.
Child Parent
Fig. 18. Generalizarea. Realizarea (realization) este o relaie semantic ntre clasificatori n care un clasificator definete un contract, iar cellat garanteaz ndeplinirea lui. Relaia de realizare se ntlnete n cazurile urmtoare: ntre interfee i clase sau componente care realizeaz aceste interfee, i ntre cazuri de utilizare i colaborri care le realizez. Relaia de realizare se reprezint printr-o linie ntrerupt cu o sgeat goal, ca ceva intermediar ntre relaiile generalizare i dependena, fig. 19.
Diagrame cazurilor de utilizare (use case diagram) Diagrame de clase (class diagram) Diagrame de comportament (behavior diagrams) o Diagrame de stri (statechart diagram) o Diagrame de activiti (activity diagram) o Diagrame de interaciune (interaction diagrams) Diagrame de secven (sequence diagram) Diagrame de colaborare (collaboration diagram) Diagrame de realizare (implementation diagrams) o Diagrame de componente (component diagram) o Diagrame de plasare (deployment diagram)
Lista acestor diagrame i denumirilor respective este canonica n caz dac diagramele reprezint partea integrant a notaiei grafice a limbajului UML. Mai mult dect att, procesul APOO este strns legat de procesul construirii acestor diagrame. Totodat o totalitate de diagrame construite n aa fel este suficient n caz dac diagramele conin informaia necesar pentru realizarea proiectului unui sistem complex. Fiecare din aceste diagrame detalizeaz i concretizeaz diferite reprezentri despre modelul unui sistem complex n termenii limbajului UML. Totodat diagrama cazurilor de utilizare reprezint cel mai general model conceptual al unui sistem complex care este iniial pentru construirea tuturor celorlalte diagrame. Diagrama de clase este un model logic care reflect aspectele statice ale procesului de construire structural a unui sistem complex. Diagramele de comportament la fel sunt varieti ale unui model logic care reflect aspectele dinamice ale procesului de funcionare a unui sistem complex. Diagramele de realizare sunt destinate reprezentrii fizice a componentelor sistemului complex i de aceea sunt atribuite modelului fizic. Modelul integrat al unui sistem complex n notaia UML (fig. 20) se reprezint ca totalitatea diagramelor enumerate mai sus.
determinarea limitelor comune i a contextului domeniului de modelare la etapele iniiale de proiectare a unui sistem; formularea cerinelor comune ctre comportare funcional a sistemului proiectat; elaborarea modelului iniial conceptual al unui sistem pentru detalierea de mai trziu n forma modelelor logice i fizice; pregtirea documentrei iniiale pentru interaciunea elaboratorilor unui sitem cu clienii i utilizatorii.
Esena acestei diagrame const n faptul c: sistemul proiectat se reprezint ca o colecie de entiti i actori care colaboreaz cu sistemul cu ajutorul aa numitor cazuri de utilizare. Totodat orice entitate care colaboreaz cu sistemul din afar poate fi numit actor. Aceasta poate fi un om, o instalare tehnic, un program sau oricare alt sistem care poate fi surs de aciune pentru sistemul proiectat n aa mod, cum l determin colaboratorul. La rndul su, use case-ul este creat pentru descrierea serviciilor pe care sistemul le ofer actorului. Cu alte cuvinte fiecare caz de utilizare definete o colecie de aciuni executate de sistem n timpul dialogului cu actorul. Totodat nimic nu este spus despre aceea n ce mod va fi realizat colaborare ntre actori i sistem. n caz general, diagrama cazurilor de utilizare reprezint un graf deosebit, care este o notaie grafic pentru prezentarea cazurilor de utilizare concrete, actorilor, poate i a unora interfee i pentru prezentarea legturilor ntre aceste elemente. Totodat componente aparte ale diagramei pot fi incluse ntr-un dreptunghi, care semnific sistemul proiectat n ntregime. Trebuie de specificat c legturile acestui graf pot fi de numai anumite tipuri de interaciuni ntre actori i cazuri de utilizare, care mpreun descriu servicii i cerine funcionale ctre sistemul modelat.
entitate poate fi un sistem iniial sau un element al modelului care dispune de comportament propriu, precum este subsitemul sau clasa n modelul unui sistem. Fiecare caz de utilizare corespunde unui serviciu aparte, care reprezint o entitate modelat sau un sistem la cererea utilizatorului (actorului), mai precis determin metoda aplicat ctre anumit entitate. Serviciul care este iniializat la cererea utilizatorului reprezint o succesiune terminat de aciuni. Aceasta nseamn c dup ce sistemul va termina prelucrarea cererii utilizatorului el (sistemul) trebuie sa se intoarc n starea iniial n care este gata pentru a indeplini cererile urmtoare. Cazurile de utilizare descriu nu numai colaborarea ntre utilizatori i entiti, dar i reacia entitii la primirea anumitor mesaje de la utilizatori i asupra percepiei acestor mesaje n afar entitii. Cazurile de utilizare pot include (conine) descrierea specificaiilor modurilor de realizare a serviciului i a diferitor situaii excepionale, aa cum este prelucrarea corect a erorilor unui sistem. Mulimea cazurilor de utilizare n total poate determina toate aspecte posibile comportrii ateptate a unui sistem. Pentru comoditate mulimea cazurilor de utilizare poate fi considerat ca un pachet aparte. Din punct de vedere sistemo-analitic cazurile de utilizare pot fi folosite pentru specificarea cerinelor externe ctre sistemul proiectat i pentru specificarea comportrii funcionale a sitemului deja existent. Exemple de cazuri de utilizare pot fi aciunile urmtoare: verificarea strii contului curent al clientului, intocmirea comenzii la procurarea mrfii, obinerea informaiei suplimentare despre solvabilitatea clientului, reprezentarea formei grafice la ecranul monitorului s.a.
3.2. Actori
Actorul reprezint orice entitate extern sistemului modelat, care colaboreaz cu sistemul i utilizeaz posibilitile lui funcionale pentru atingerea anumitor scopuri i pentru rezolvarea problemelor particulare. Totodat actorii sunt utilizai pentru notarea mulimii rolurilor coordonate ale utilizatorilor n procesul de colaborare cu sistemul proiectat. Fiecare actor poate fi considerat un anumit rol aparte relativ unui caz de utilizare concret. Notaia grafic standard a unui actor n diagram este omuleul sub care se indic numele actorului (fig. 21).
Fig. 21. Actor. n unele cazuri actorul poate fi notat ca dreptunghiul clasei cu cuvntul-cheie actor i cu elementele comune ale clasei. Numele actorilor trebuie s fie scrise cu litere majuscule i trebuie s respecte recomandrile la utilizarea numelor pentru tipurile i clasele modelului. Totoadat simbolul actorului aparte leag descrierea corespunztoare a actorului cu un anumit nume. Numele actorilor abstraci, aa cum i a altor elemente abstracte n limbajul UML, se recomand de notat n italic. Ca exemplu de actori pot fi: clientul unei bnci, angajatul unei bnci, vnztorul unui magazin, managerul seciei de vnzare, pasagerul unui avion, conductorul unui auto, administratorul unui hotel, celularul i alte entiti, care au legtur cu modelul conceptual care corespunde domeniului de lucru. 18
Actorii sunt utilizai pentru modelarea entitilor exeterne sitemului de entiti proiectat, care acioneaz reciproc cu sistemul i pe care l utilizez n calitate de utilizatori separai. n calitate de actori pot fi i alte sisteme, subsisteme ale sistemului proiectat sau clase aparte. Este important s intelegem c actorul definete o anumit mulime de roluri coordonate, care pot fi utilizatorii unui sistem dat n procesul de colaborare. n fiecare moment de timp cu sistemul colaboreaz un anumit utilizator n unul din roluri date. Ca exemplu evident de actor poate fi un anumit utilizator al sistemului cu parametri de autentificare proprie.
3.3. Interfee
Interfaa (interface) specific parametrii modelului care sunt vizibili din afar fr indicarea structurii lor interne. n limbajul UML interfaa este clasificatorul care caracterizez numai o parte limitat a comportrii unei entiti modelate. Referitor la diagrama cazurilor de utilizare interfeele definesc o totalitate de operaii ce asigur serviciile necesare sau funcionalitatea pentru actorii. Interfeele nu pot conine nici atribute, nici stri, nici asocieri dirijate. Ele conin numai operaii fr indicarea specificaiilor de realizare a lor. O interfa este formal echivalent clasei abstracte fr atribute i metode numai cu prezena operaiilor abstracte. n diagrama cazurilor de utilizare o interfa este reprezentat ca un cercule mic lng care este indicat numele lui. (fig. 22, a). n calitatea de nume poate fi un substantiv, ce caracterizeaza informaia corespunztoare sau serviciu (de exemplu, sirena, camera video), dar mai des este oricare rnd de text (de exemplu, sensor, interpolare ctre baza de date, forma de introducere, dispozitiv de semnalizare sonor). Dac numele este nscris n limba englez, atunci acest nume trebuie s inceap cu majuscula I, de exemplu, ISecurelnformation, ISensor (fig. 22, ).
Fig. 22. Reprezentarea grafica a interfeelor n diagrama cazurilor de utilizare. Simbolul grafic al unei interfee aparte n diagram poate fi conectat cu cazul de utilizare ce l susine cu o linie nentrerupt (continu). Linia nentrerupt n acest caz indic faptul c cazul de utilizare legat cu interfaa trebuie s realizeze toate operaiile necesare pentru aceast interfa, sau poate i mai mult (fig. 23, a). n afar de aceasta, interfeele pot fi legate cu cazurile de utilizare cu o linie ntrerupt cu o sgeat (fig. 23, b), ce nseamna c cazul de utilizare specific numai cel serviciu, care este necesar pentru realizarea interfeei date.
Fig. 23. Reprezentarea grafic a legturilor ntre interfee i cazuri de utilizare. Din punct de vedere sistemo-analitic interfaa nu numai separ specificaia operaiilor unui sistem de la realizarea lor, dar i definete limetele comune ale sistemului proiectat. Ulterior interfaa poate fi specificat cu indicarea acelor operaii care specific un aspect de colaborare al sistemului. n acest caz el se reprezint n forma de dreptunghi cu cuvnt-cheie interface n secia de nume, cu 19
secia de atribute goala i cu secia de operaii completat. Dar aa fel de reprezentare grafic se utilizeaz n diagrama claselor sau n diagrame ce caracterizeaz comportarea sistemului modelat. Importana interfeelor const n faptul c ele definesc noduri de jonciune n sistemul proiectat, ce este necesar pentru organizarea lucrului colectiv asupra proiectul. Mai mult dect att, specificaia interfeelor contribuie la modificarea uoarla trecerea la soluii tehnologice ale unui sistem deja existent. n acest caz schimbrii este supus numai realizarea operaiilor, dar nu funcionalitatea sistemului. Aceasta asigur compatibilitatea versiunilor urmtoare de program cu cele iniiale la folosirea tehnologiei n spiral de creare sistemelor de program.
relaia de asociere (association relationship) relaia de extindere (extend relationship) relaia de generalizare (generalization relationship) relaia de cuplare (include relationship)
Totodat proprietile generale ale cazurilor de utilizare pot fi reprezentate prin trei metode diferite, i anume cu ajutorul relaiei de extindere, generalizare i cuplare.
Fig. 24. Reprezentare grafic relaiei de asociere ntre acotr i caz de utilizare. 20
Multiplicitatea (multiplicity) asocierei se indic lnga notaia componentului diagramei care este membru acestei asocieri. Multiplicitatea caracterizeaz cantitate total de exemplare concrete al unui component anumit care pot fi n calitate de elemente acestei asocieri. Cu privire la diagrame cazurilor de utilizare multiplicitate are o notaie specific n forma de una sau mai multe cifre i posibil simbolul special *. Pentru diagrama cazurilor de utilizare mai rspndite sunt patru forme de nscriere a multiplicitii relaiilor de asociere:
Numr ntreg nenegativ (inclusiv cifra 0) este destinat indicaiei multiplicitii care este strict fixat pentru elementul corespunztor asocierii. n acest caz cantitate de exemplare a actorilor sau cazurilor de utilizare, ce pot fi i elemente ale relaiei de asociere, ntocmai este egal cu numrul indicat.
Ca exemplu a acestei forme de nregistrare a multiplicitii relaiilor de asociere este indicarea multiplicitii 1 pentru actorul Clientul bncii (fig. 24). Aceast nregistrare nseamna c fiecare exemplar al cazului de utilizare Perfectarea creditului pentru clientul bncii poate s aib n calitate de element propriu un singur exemplar de actor Clientul bncii. Cu alte cuvinte, la perfectarea creditului n banc trebuie de luat n vedere c fiecare credit concret se perfecteaz pentru un singur client al acestei bnci.
Dou numere ntregi nenegative, separate cu dou puncte i scrise n forma: primul numr..al doilea numr. Aceast nregistrare n limbajul UML corespunde notaiei pentru o mulime sau pentru un interval de numere ntregi, care se utilizeaz n unele limbaje de programare pentru indicarea limitelor masivului de elemente. Aceast nregistrare trebuie s fie neleas ca o mulime de numere ntregi nenegative care sunt n ordinea crescatoare: {numar_1, numar_1+1, numar_1+2, , numar_2}. Evident c primul numr trebuie s fie strict mai mic dect al doilea numr n sens aritmetic, totodat primul numr poate fi egal cu 0.
Ca exemplu a acestei forme de nregistrare a multiplicictii asocierii 1..5. Aceast nregistrare nseamna c cantitatea de exemplare ale acestui component care pot fi i elemente ale acestei asocieri, este egal unui numr preliminar necunoscut din mulimea numerelor ntregi {1, 2, 3, 4, 5}. Aceast situaie are loc cnd n calitate de actor este clientul bncii, dar n calitate de caz de utilizare este procedura deschiderii contului n banc. Totodat cantitatea de conturi ale fiecrui client n aceast banca, reieind din consideraii tactice, poate fi nu mai mult dect 5. Aceste consideraii tocmai i sunt cerinele exterioare sistemului proiectat i sunt definite de ctre client la etapele iniiale de APOO.
Dou simboluri separate cu doua puncte. Totodat primul dintre ele este un numr ntreg nenegativ sau 0, iar al doilea este simbolul special *. Aici simbolul * nseamn un numr arbitrar ntreg nenegativ, valoarea cruia este necunoscut la momentul nregistrrii unei relatii de asociere.
Ca exemplu acestei forme de nregistrare de multiplicitate asocierei 2 ..*. Aceast nregistrare nseamn c cantitatea de exemplare ale acestui component, care pot fi i elementele acestei asocieri, este egal cu un numr anticipat necunoscut din mulimea numerelor ntregi {2, 3, 4}.
Simbolul *, care este prescurtarea nregistrrii intervalului 0..*. n acest caz cantitatea de exemplare ale acestui component al relaiei de asociere poate fi oricare numr ntreg nenegativ. Totodat 0 nseamn c pentru careva exemplare ale componentului corespunztor aceast relaie de asociere poate nici s nu aib loc. 21
Ca exemplu acestei forme de nregistrare poate fi cercetat multiplicitatea asocierei pentru cazul de utilizare ntocmire creditului pentru clientul bncii (fig. 24). n acest caz * nseamn fiecare client aparte al acestei bnci poate ntocmi pentru sine cteva credite, totodat numrul lor comun este necunoscut i nelimitat. Unele clieni pot s nu aib credite deloc (cazul valorii 0). Dac multiplicitatea asocierei nu este indicat atuinci implicit se ia valoarea egal cu 1.
Fig. 25. Exemplu de reprezentare grafic a relaiei de extindere ntre cazurile de utilizare. Relaia de extindere indic acel fapt c unul din cazurile de utilizare poate fi conectat la comportamentul su care-va comportament adugtor, definit pentru un alt caz de utilizare. Relaia dat include o anumit condiie i exilri la puncte de extensie n cazul de utilizare de baz. Pentru alocarea extinderii este necesar de a executa o anumit condiie a relaiei date. Exilri la puncte de extensie definesc acele locuri n cazul de utilizare de baz n care trebuie s fie pus extinderea respectiv n timpul executrii condiiei. Unul din cazurile de utilizare pot fi extinderea pentru cteva cazuri de baz i pot avea ca extinderi proprii nc cte-va alte cazuri. Cazul de utilizare de baz poate fi adugtor independent de la alte extensii. Semantica relaiei de extensie este definit n felul urmtor. Dac exemplarul cazului de utilizare execut anumit consecven de aciuni, care definete comportamentul lui i n urma cruia exist un punct de extensie la alt exemplar a cazului de utilizare, care este unul din primele puncte de extensie a cazului iniial, atunci controleaz condiia relaiei date. Dac condiia este executat, consecvena iniial de aciuni extinde datorit includerea aciunii altui exemplar a cazului de utilizare. Trebuie de meninut, c condiia relaiei de extensie este controlat numai o dat n timpul exilrii la un punct de extensie i dac aceasta este executat, atunci toate cazurile de extindere utilizate se folosesc n cazul de baz.
Este nevoie de menionat, c descendentul motenete toate proprietile i comportamentul printelui su i poate avea proprietile i comportamentul su adugtor. Grafic relaia dat este reprezentat cu linia ntreag cu sgeat n forma de triunghi nehaurat, care indic cazul de utilizare printe (fig. 26). Aceast linie cu sgeat are un nume specific sgeata generalizare.
Fig. 26. Exemplu de reprezentare grafic a relaiei de generalizare ntre cazuri de utilizare. Relaia de generalizare ntre cazurile de utilizare este folosit n acele cazuri cnd este necesar de indicat c cazul de utilizare derivat conine toate atributele i particularitile comportamentului cazurilor de baz. n urma cruia cazurile de utilizare derivate pot participa n relaii cazurilor de baz. n urma sa cazurile derivate pot avea proprieti noi de comportament, care nu au cazurile de utilizare de baz, dar i de a preciza sau modifica proprietile de comportament motenite. Relativ cu relaia dat un variant de utilizare poate avea cte-va cazuri de baz. n acest caz se realizeaz motenirea multipl a proprietilor i comportamentului cazurilor de baz. Din alt parte un caz de utilizare poate fi printe pentru cte-va cazuri de utilizare derivate, ce corespunde caracterului taxonometric relaiei de generalizare. ntre actori aparte de asemenea poate exista relaia de generalizare. Aceast relaie este direct i indic faptul c specializarea unor actori este relativ cu alii. De exemplu, relaia de generalizare de la actorul A la actorul B indic faptul c fiecare exemplar a actorului A este concomitent cu exemplarul actorului B i are toate proprietile lui. n acest caz actorul B este printe relativ cu actorul A, iar actorul A este descendentul actorului B. n urma cruia actorul A are posibilitatea de joac a aceleeai mulimi de roluri ca i actorul B. Grafic relaia dat este reprezentat cu sgeata de generalizare, adic cu linia ntreag cu sgeat n form de triunghi nehaurat, care indic printele actorului (fig. 27).
utilizare, aciunile lor trebuie s se sfreasc ntr-un anumit moment, dup ce trebuie s continue executarea aciunilor ntrerupe exemplarele primului caz de utilizare n conformitate cu comportamentul lui dat. Unul din cazurile de utilizare poate fi inclus n alte cazuri i poate include alte cazuri. Cazul de utilizare ce este inclus poate fi independent de cazul de baz, anume el d ultimului un comportament incapsulat, detalii realizaiei cruia sunt ascunse i pot fi liber mprite ntre cte-va cazuri de utilizare incluse. Mai mult, cazul de baz poate depinde numai de rezultatele executrii comportamentului inclus n el, sar nu de la structura cazurilor incluse n el. Relaia de tip include orientat de la cazul de utilizare A la cazul de utilizare B indic c fiecare exemplar al cazului A include proprieti funcionale stabilite pentru cazul B. Aceste proprieti specializeaz comportamentul cazului respectiv A n diagrama dat. Grafic relaiile date sunt indicate cu linia punctat cu sgeat (cazul relaiei de dependen), ndreptate de la cazul de utilizare de baz la cazul ce este inclus. n urma cruia linia cu sgeata este indicat cu cuvntulcheie include, (fig. 28).
Fig. 28. Exemplu de reprezentare grafic a relaiei de tip include ntre cazuri de utilizare.
Fig. 29. Diagrama cazurilor de utilizare pentru exemplu de perefectare a sistemului de vindere a mrfurilor dup catalog. Valorile divizibilitilor n diagrama dat reflect regulile de baz sau logica de formare a cerinelor la vinderea mrfurilor. Conform regulilor respective un vnztor poate participa n formarea a ctorva comenzi, n acelai timp fiecare comand poate fi format numai de un singur vnztor, care are responsabilitatea pentru corectitudinea formrii lui i respectiv va avea rsplat pentru formarea dat. Din alt parte, fiecare cumprtor poate forma cteva comenzi i n acelai timp fiecare comand trebuie s fie format la un singur cumprtor, care va avea drepturile de proprietate la marf dup achiziionarea ei. 24
Etapul urmtor n diagrama dat este A perfecta comanda de cumprare a mrfii poate fi precizat pe baza ntroducerii a patru cazuri de utilizare adugtoare. Acest lucru este evident din analiza mai detaliat a procesului de vindere a mrfii, ce permite de alege ca servicii separate acele aciuni ca asigurarea cumpratorului cu informaia despre marf, coordonarea condiiilor de plat i comandarea mrfii de la depozit. Evident c aciunile indicate desfoar comportamentul cazului de utilizare iniial i anume concretizarea lui i de aceea ntre ele v-a exista relaia de tip include. n cazul nostru catalogul cu mrfuri poate fi comandat de cumprtor sau vnztor cnd apare necesitatea de a alege marfa i precizarea detaliilor de vindere. Corect este reprezentat serviciul Cererea catalogului cu mrfuri ca caz de utilizare independent. Dup detalizare diagrama cazurilor de utilizare va avea 5 cazuri de utilizare i 2 actori (fig. 30), ntre care este stabilit relaia de tip includ i extend.
Fig. 30. Variantul mai detaliat a diagramei cazurilor de utilizare pentru exemplu de perefectare a sistemului de vindere a mrfurilor dup catalog. Diagrama cazurilor de utilizare de mai sus, la rndul su poate fi mai detaliat pentru precizarea mai adnc, ce se cere de la sistemul de comand i concretizarea detaliilor pentru realizarea urmtoare. Detalizarea poate fi executat pe baza indicrii relaiilor adugtoare de tipul relaiei generalizareaspecializarea pentru componentele diagramei deja existente. n sistemul de vindere a mrfurilor poate avea valoarea independent i proprietile specifice o categorie independent de mrfuri calculatoare. n acest caz n diagram poate fi adugat un caz de utilizare Perfectarea comenzii de achiziionare a calculatorului i cu actori Cumprator de calculatoare i Vnztor de calculatoare, care sunt legate cu componentele corespunztoare a diagramei relaiei de generalizare (fig. 31).
25
Fig. 31. Unul din variantele de concretizare a diagramei cazurilor de utilizare pentru exemplul de sistem de vindere. Construirea diagramei cazurilor de utilizare este primul etap a procesului analizei a obiectului orientat i proiectri, scopul cruia este de reprezentarea totalitii de cereri la comportamentul sistemului proiectat. Specificaia de cereri la sistemul proiectat n form de diagram a cazurilor de utilizare reprezint un model independent, care se numete modelul cazurilor de utilizare n limbajul UML i are un nume propriu stanadard sau steriotip UseCaseModel.
26
Diagrama de clase reprezint un graf cu noduri elemente de tip clasificatori care sunt legate prin diferite tipuri de relaii de structur. Trebuie de menionat c diagrama de clase poate conine interfee, pachete, relaii i chiar exemplare, aa ca obiecte i legturi. Prin diagrama de clase se subnelege modelul structural static al sistemului proiectat, de accea diagrama de clase deseori se socoate o reprezentare grafic a legturilor structurale ale modelului logic al sistemului care sunt independente i invariante n timp.
4.1. Clasa
Clasa (class) n limbajul UML definete totalitatea de obiecte care au aceeai structur, comportament i relaii cu obiectele din alte clase. Grafic o clas se reprezint printr-un dreptunghi care poate fi divizat de linii orizontale n seciuni, fig. 3. Elementul obligtoriu n notaia clasei este numele lui. Pe etapele iniiale ale elaborrii diagramei, clase aparte pot fi notate prin dreptunghiuri simple cu indicaia numelui clasei respective. Pe parcursul elaborrii componentelor diagramei descrierea claselor este completat cu atribute i operaii. Se presupune c varianta final a diagramei conine descrierea complet a claselor care const din cele trei seciuni. Uneori n notaia claselor se utilizeaz a patra seciune suplementar n care se indic informaia semantic de caracter informativ i se indic situaiile excepionale. Dac seciunea atributelor i operaiilor clasei nu este completat, n notaia clasei ea se evidentiaz cu o linie orizontal pentru a deosebi clasa de alte elemente ale limbajului UML. Exemple de notaii grafice ale claselor n diagrama de clase sunt artate n fig. 32. n primul caz pentru clasa Dreptunghi (fig. 32, a) sunt indicate numai atributele clasei punctele pe planul de coordonate care i definesc poziia. Pentru clasa Fereastr (fig. 32, b) sunt indicate numai operaiile, seciunea de atribute este lsat necompletat. Pentru clasa Contul (fig. 32, c) suplementar este indicat seciunea de excepii refuz de la prelucrarea cartelei bancare expirate (nevalabile).
Dreptunghi p1.Pont p2.Pont Fereastra arata() ascunde() Cont verifica() exceptiile cartela bancara nu este valabila a) b) c)
27
n prima seciune a notaiei clasei pot fi referine la modelele (abloanele) standarte sau la clasele abstracte de la care este format clasa dat i respectiv de la care clasa motenete proprietile i metodele. n aceast seciune poate fi indicat informaia despre elaboratorul clasei date i starea elaborrii, nc pot fi indicate i alte proprieti comune ale acestei clase care au legtura cu alte clase ale diagramei sau cu elementele standarde ale limbajului UML. Ca exemple de nume ale claselor pot fi aa substantive ca: Angajatul, Compania, Conductorul, Clientul, Vnztorul, Managerul, Oficiu .a. care au legtur cu domeniul de obiecte proiectat i cu destinaia funcional a sistemului proiectat. Clasa poate s nu aib exemplare sau obiecte. n acest caz clasa devine abstract, i pentru notaia denumirii acestei clase se utilizeaz caractere italice. n limbajul UML este adoptat o inelegere (acord) despre ceea c orice text care se refer la elementele abstracte se scrie n italic. Aceast circumstan este un aspect semantic pentru descrierea elementelor respective ale limbajului UML. n unele cazuri este necesar de indicat clar la care pachet se refer clasa. Pentru acest scop se utilizeaz un simbol special de divizare dou puncte duble ::. Sintaxa liniei ce conine numele clasei n acest caz va fi urmatoarea: <Numele_pachetului>::<Numele_clasei>. Cu alte cuvinte nainte de numele clasei trebuie s fie indicat clar numele pachetului la care clasa se refer. De exemplu, dac este specificat pachetul cu numele Banca, atunci clasa Cont n aceast banca poate fi scris n fel urmtor: Banca::Cont.
Simbolul + nseamn atributul cu regiunea de vizibilitate de tip public (public). Atributul cu aceast regiune de vizibilitate poate fi accesat sau vzut din alt clas de pachet, n care este stabilit diagrama. Simbolul #. nseamn atributul cu regiunea de vizibilitate de tip protecie (protected). Atributul cu aceast regiune de viyibilitate nu poate fi accesat sau vzut pentru toate clase n afar de subclasele acestui clas. n sfrit, simbolul atributul cu regiunea de vizibilitate tipului privat. (private). Atributul cu aceast regiune de vizibilitate nu poate fi accesat sau vzut pentru toate clasele fr excepie.
Specificatorul de vizibilitate poate fi omis. n acest caz nu este present, pur i simplu nseamn c vederea acestui atribut nu este indicat. Aceast situaie difer de nelegerile de baz n limbile de tradiionale programare, cnd nu este prezent specificatorul de vizibilitate este tratat ca public sau privat.
28
Numele atributului prezint aliniat de text, care este folosit n calitate de identificator a atributului corespunztor i de aceea trebuie s fie unic n clasa corespunztoare. Numele atributului este unic, un element obligator al nsemnrii sintaxice al atributului. Ca exemplu de multiplicitate al atributelor putem vedea urmtoarele variante:
[0..1] nseamn c, multiplicitatea atributului poate primi semnificaia 0 sau 1. n acest caz 0 nseamn c semnificaia pentru acest atribut nu este prezent. [0..*] nseamn c, multiplicitatea atributului poate primi orice semnificaie pozitiv ntreag mai mult sau egal cu 0. Aceast multiplicitate poate fi scris mai scurt n calitate de simbolul - [*]. [1.:*] nseamn c, multiplicitatea atributului poate primi orice semnificaie pozitiv ntreag mai mult sau egal cu 1. [1..5] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, 4, 5. [1..3,5,7] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, 5, 7. [1..3,7.. 10] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, 7, 8, 9, 10. [1..3,7..*] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, de asemenea orice semnificaie pozitiv ntreag mai mult sau egal cu 7.
Dac multiplicitatea atributului nu este specificat, atunci dup starea iniial voloarea ei este egal cu 1..1, adic exact 1. Tipul atributului prezint o expresie, semantica cruia este definit dup limbajul specificaiei al modelului corespunztor. n notaii UML-ului tipul atributului uneori este specificat n dependen de limbajul de programare, care va fi utilizat pentru realizarea modelului dat. n cazul elementar tipul atributului este specificat n rndul textului, care are un sens n limita pachetului sau modelului, la care are atitudinea clasa dat. Sublinierea rndului atributului nseamn c acest atribut corespunztor poate avea o submulime de valori din oarecare domeniu al valorilor atributului, definit de tipul lui. Aceste valori pot fi considerate ca trus de notie cu acelai tip sau ca masiv, care n ansamblu caracterizeaz fiecare obiect al clasei. De exemplu, dac oarecare atribut este dat n form de forma: Dreptunghi, aceasta va semna c toate obiectele clasei date poate avea cteva forme diferite, dintre care fiecare prezint un dreptunghi. Ca alt exemplu poate fi atribut n form de numrul_contului:Integer, ce poate nsemna pentru obiect Colaborator prezena submulimii de conturi, valoarea total crora nu este fixat din timp. Aliniat proprietatea este utilizat pentru indicarea valorilor atributului, care nu poate fi shimbat n program n lucrul cu tipul dat al obiectelor. n paranteze ... anume este indicat valorea fix al atributului propriu pentru toat clas, care trebuie s conin toate exemplarele clasei, care vor fi create, fr excepie. Aceast valoare este considerat ca valoare iniial a atributului, care nu poate fi reiniializat n continuare. Absena aliniatului proprietatea de baz se trateaz n felul urmtor, valoarea atributului corespunztor pot fi shimbat n program. De exemplu, aliniat proprietate n nscrierea atributului salariu:Currency = = {$500} poate fi utilizat pentru indicarea salariului fixat pentru fiecare obiect al clasei Colaborator pentru o funcie definit n oarecare organizaie. Din alt 29
parte, nscrierea atributului dat n form de salariu:Currency = = {$500} nseamn alt ceva, i anume n timpul formrii a unui nou exemplar Colaborator (angajarea la lucru unui nou colaborator) pentru el salariul de $500 este stabilit automat. Totui, pentru careva colaboratori pot fi fcute excepii, cum ar fi n cretere sau descretere, ce ar trebui fi prevzut n program.
4.1.3. Operaiile
n a treia secie a dreptunghiului de clas se nscriu operaii sau metodele clasei. Operaia (operation) prezint un anumit serviciu, care prezint fiecare exemplar al clasei dup anumit cerin. Totalitatea de operaii caracterizeaz un aspect funcional n comportamentul clasei. Notaia operaiei clasei n limbajul UML este la fel standartizat i este subordonat de careva regulli sintactice. n urma acesteia fiecare operaie clasei corespunde un rnd aparte, care este compus din specificator de vizibilitate al operaiei, numele operaiei, expresiei de tipul valoarei returnat de opearaia i posibil, aliniat proprietate operaiei date: <specificator de vizibilitate><numele operaiei>(lista de parametri): <expresie de tipul valoarei returnate>{aliniat - proprietate} Specificator de vizibilitate ca i n cazul atributelor clasei, poate primi unul din trei valori posibile i n mod corespunztor este specificat cu un simbol special. Simbolul + nseamn operaia cu specificator de vizibillitate de tip public(public). Simbolul # nseamn operaia cu specificator de vizibilitate de tip protecie(protected). n sfrit, simbolul este utilizat pentru identificarea operaiei cu regiunea de vizibilitate de tip privat (private). Specificator de vizibilitate pentru operaie poate fi absent. n acest caz absena lui nseamn c vizibilitatea operaiei nu este indicat. n locul nsemnrii grafice convenionale de asemenea poate nscrie un cuvnt cheie corespunztor: public, protected, private. Numele operaiei prezint aliniat de text, care este utilizat ca identificator al operaiei corespunztoare i de aceea trebuie s fie unic n mediul clasei date. Numele atributului este un element unic obligator n indicarea sintactic operaiei. Operaia, care nu poate schimba starea sistemului i n mod corespunztor nu are nici un efect suplimentar, este specificat cu aliniat proprietate {interpelare} ({query}). n caz contrar operaia poate schimba starea sistemului, dei nu sunt garanii c ea va face acest lucru. Lista parametrilor formate i tipul de valoare redus pot fi nespecificate. Specificator de vizibilitate atributelor i operaiilor pot fi indicate de un semn sau simbol special, care sunt utilizate pentru prezena modelelor grafice n careva mijloace de instrumente. Numele operaiilor la fel ca i a atributelor, sunt scrise cu minuscule, iar tipurile lor cu majuscule. n urma cruia o parte obligatorie al aliniatului de text al operaiei este prezena numelelui i parantezelor rotunde. Ca exemplu al nscrierei operaiei pot fi urmtorii specificatori al operaiilor:
+a crea() pot indica o operaie abstract n fondarea obiectului separat, care este public i nu conine parametri formali. Aceast operaie nu reduce nici o valoare dup executarea sa. +a desena(forma: multilateral=dreptunghi, culoarea_inundrii: Color =(0,0,255)) pot indica o operaiune de nfiare pe ecranul monitorului regiunii dreptunghiului cu culoare albastr, dac nu indic alte valori n calitate de argumente operaiei date. cererea_contulului_clientului(numrul_contului: Integer): Currency nseamn, operaiunea de indicare n contul curent a clientului bncii. n urma cruia argumentul operaiei date este 30
numrul contului clientului, care este scris ca numr ntreg (de exemplu: 123456). Ca rezultat al executrii operaiei date va fi un numr ntreg scris n formatul monetar(de exemplu: $1,500.00). a da_mesajul():{Eroare mpririi la nul} sensul operaiei acestea nu este nevoie de a explica, deoarece este ntreinut n aliniat proprietatea operaiei. Mesajul dat poate aprea pe ecranul monitorului n cazul cnd desprim un numr la nul, ce este inadmisibil.
Relaia de dependena (dependency relationship) Relaia de asociere (association relationship) Relaia de generalizare(generalization relationship) Relaia de realizare(realization relationship)
Fiecare din relaiile aceste are reprezentare grafic proprie pe diagram, care reflect interconexiunele ntre obiectele claselor corespunztoare.
Fig.33. Reprezentarea grafic relaiei de dependena n diagrama de clase. Sgeata poate fi indicat sau nu poate fi indicat cu cuvntul-cheie standart n ghelimele i nu este necesar nume individual. Pentru relaia de dependen exist cuvintele cheie, care indic careva feluri de relaii speciale. Aceste cuvintele cheie (stereotipuri) sunt scrise n ghelimele alturi de sgeat, care corespunde relaiei date. Exemple de stereotipuri pentru relaie de dependen sunt urmtoarele:
access servete ca indicator de accesibilitate unor atribute i operaii clasei surs pentru claseclienii; bind clasaclient pote utiliza careva ablon pentru urmtoarea parametrizare; 31
derive atributul clasei client poate fi calculat dup atributele clasei surs; import atribute deschise i operaii publice clasei surs devine o parte a clasei client, care dac ar fi nemijlocit n el; refine indic c clasa client servete ca precizie a clasei surs n cauza caracterului istoric, cnd n timpul lucrului la un proiect apare informaia adugtoare.
Fig. 34. Reprezentarea gafic a relaiei asocierii binare ntre clase. Unul dintre simboluri adugtoare este numele rolului a clasei aparte, care ntr n asociere. Numele rolului reprezint aliniat de text alturi de captul asocierii pentru clasa respectiv. Ea indic un rol specific, care joac clasa, ce reprezint captul asociaiei. Numele rolului nu este un element obligatoriu i poate lipsi n diagram. Urmtorul element de indicare este multiplicitatea claselor, care sunt capetele asociaiei. Multiplicitatea unei clase reprezint un interval de numere intregi, analogic cu multiplicitatea atributelor i operaiilor claselor. Forma special sau caz particular a relaiei de asociere este relaia de agregare, care n rndul su are o form special relaie de compoziie. ntruct relaiile acestea au notaii speciale i aparin noiunelor de baz a limbajului UML, vor fi examinate consecutiv.
32
Bloc de sistem
Monitor
Tastatura
Mouse
Fig. 36. Reprezentarea grafic a relaiei de compoziie pentru Fereastra programului n diagrama claselor. 33
Acest exemplu poate ilustra i alte proprietile programei computerizate, care nu a fost specificat pentru acest exemplu. Deci, specificarea divizibitii 1 lng clasa Regiunea de lucru este utilizat n anexe unidocumentate (aplicaii).
Fig. 37. Variantul grafic a relaiei de generalizare n cazul unirii liniilor aparte. Lng sgeat de generalizare poate fi amplasat aliniat de text, care specific care-va proprieti adugtoare a acestei relaii. Textul dat va fi referitor la toate linile de generalizare, care trec n clase descendente. Cu alte cuvinte, proprietatea marcat se refer la toate subclase relaiei date. n urma cruia textul trebuie s fie examinat ca restricie i atunci el va fi scris n paranteze. Ca restricie pot fi folosite urmtoarele cuvintecheie din limbajul UML:
{complete} nseamn c n aceast relaie de generalizare sunt specificate toate clasele descendente i alte clase descendente nu pot exista n clasa dat. De exemplu, clasa Clientul_bncii este clasa printe pentru dou clase: Persoana_fizic i Companie i alte clase descendente el nu are. n diagrama acestei clase poate fi indicat evident cu ajutorul scrierii liniei de generalizare cu aceast aliniat limit; {disjoint} nseamn c clasele descendente nu pot conine obiecte, care concomitent sunt exemplare a dou sau mai multor clase. n exemplu precedent acest condiie se ndeplinete, deoarece este presupus c nici o persoan fizic nu poate fi concomitent i companie concret. n cazul acesta alturi de linie de generalizare poate fi scris aliniat limit dat; {incomplete} este cazul contrar a primului caz. Anume, presupune c n diagrama nu sunt indicate toate clase descendente. n continuare poate fi restabilit lista lor fr schimbarea n diagrama construit. Exemplu: diagrama de clas Automobil, pentru care indicarea 34
tuturor modelelor de automobile este echivant cu formarea catalogului respectiv. Din alt parte, pentru o alt problem ca elaborarea sistemului de vindere automobilelor de modele concrete nu este necesitate. Iar indicarea structurii incomplete a claselor descendente este necesar; {overlapping} nseamn c care-va exemplare a claselor descendente pot aparine mai multor clase. Exemplu: clasa Multilateral este clasa printe pentru clasa Dreptunghi i clasa Rombul. Totui exist clasa Ptrat, exemplarele cruia concomitent sunt obiectele a primelor dou clase. Este clar c aceast situaie trebuie s fie marcat cu aliniat limit.
4.3. Interfee
Interfeele sunt exemplarele diagramelor cazurilor de utilizare. Totui n construirea diagramei de clas care-va interfee pot fi precizate i n cazul dat pentru reprezentarea lor este folosit un simbol grafic special dreptunghi de clas cu cuvntul-cheie i stereotip interfaa (fig. 38). n urma cruia secia de atribute a dreptunghiului lipsete, iar este indicat numai secia de operaii.
"interface" Element_termomentric valoarea_temperaturii()
4.4. Obiecte
Obiect (object) este un exemplar special al clasei, care este creat n timpul executrii programului. El are un propriu nume i valoare concret atributelor. n urma care-va motivelor poate aprea necesitatea de reprezentare a interconexiunelor nu numai ntre clasele modelului, dar i ntre obiecte aparte, care realizeaz clase date. n acest caz poate fi elaborat diagrama de obiecte, care nu este canonic n metamodelul limbajului UML, dar are destinaie proprie. Pentru reprezentarea grafic a obiectelor este utilizat acelai simbol a dreptunghiului ca i pentru clase. Diferena este n indicarea numelelor obiectelor, care n cazul de obiecte este obligatoriu subliniat (fig. 39). n urma cruia notarea numelelui obiectului reprezint aliniat de text numele obiectului: numele clasei, separat cu dou puncte (fig. 39 a, b). Numele obiectului poate lipsi, n acest caz presupunem c obiectul este anonim i dou puncte indic acest lucru (fig. 39 d). Numele clasei poate lipsi. Atunci este indicat numele obiectului (fig. 39 c). Atributele obiectelor primesc valorile concrete.
35
5.1. Automate
Un automat (state machine) n limbajul UML reprezint o formalizare pentru modelarea comportamentului elementelor modelului i a sistemului ntreg. n metamodelul UML automatul este un pachet, n care sunt definite o mulime de definiii, necesare pentru reprezentarea comportamentului entitii modelate n form de spaiu discret cu un numr finit de stri i treceri. Din alt parte, automatul descrie comportamentul obiectului n forma consecutivitilor de stri, care conine toate etapele ciclului de via, ncepnd cu formarea obiectului i sfrind cu destrugerea lui. Fiecare diagrama de stri reprezint un automat. Ca un simplu exemplu de reprezentare vizual de stri i treceri pe baz de formalizmul automatului poate servi situaia descris de mai sus cu funcionizarea echipamentului tehnic ca calculator. n acest caz sunt introduse dou stri: funcioneaz i nu funcioneaz i dou treceri: defect i reparare. n mod grafic aceast informaie poate fi reprezentat n form de urmtoarea diagram de stri pentru un calculator (fig. 40).
Fig. 40. Un simplu exemplu de diagram de stri pentru echipamentul tehnic de tip calculator. 36
Noiunile de baz care intr n formalizmul automatului sunt starea i trecerea. Diferena principal ntre ele este durata aflrii sistemului n stare aparte, care depete mult timpul, care este utilizat pentru trecerea de la o stare la alt. Presupune c iniial timpul de trecere de la o stare la alta este egal cu zero (dac nu exist informaie suplimentar). Cu alte cuvinte, trecerea obiectului de la o stare la alt este momental. n cazul general automatul reprezint aspecte dinamice a sitemului modelat n forma de graf orientat, vrfurile crui corespunde cu strile, iar arcurile cu trecerile. n urma cruia comportamentul modeleaz ca deplasare consecutiv n graful de stri de la vrf la vrf dup arcurile legate innd cont de orientaia lor.
5.2. Stare
n limbajul UML starea este subneles ca metaclas abstract, ce se utilizeaz pentru modelarea situaiei aparte, pe parcursul crei este prezent executarea anumitei condiii. Starea (state) poate fi n form de valori concrete a atributului clasei sau obiectului, n acest caz modificarea anumitelor valorilor va respinge modificarea clasei modelate sau obiectului. Trebuie de meninut c nu fiecare atribut al clasei poate caracteriza starea lui. Ca regul, sunt valoroase numai acele proprieti a elementelor sistemului, care respinge aspectul dinamic i funcional a comportamentului lui. n acest caz starea va fi caracterizat ca o condiie invariat, care include n sine numai cele mai semnificative clase a atributului pentru comportarea i semnificarea lor. De exemplu, invariant poate reprezenta o situaie static, cnd obiectul este n stare de ateptare a aprrii care-va eveniment extern. Din alt parte, invariantul este utilizat pentru modelarea aspectelor dinamice, cnd n timpul procesului sunt executate anumite aciuni. Atunci n cazul dat elementul modelat trece n starea dat n momentul iniial al activitii respective i iese din starea dat n momentul finalizrii ei.
Fig. 41. Reprezentarea grafic strilor n diagrama de stri. Starea pe diagram este reprezentat ca dreptunghi cu vrfurile rotungite (fig.41). Acest dreptunghi, la rndul su, poate fi desprit n dou seciuni cu ajutorul liniei orizontale. Dac este indicat numai o seciune, atunci n ea este scris numai numele strii (fig. 41, a). n caz contrar n prima din ele este scris numele strii, iar n a doilea lista cror-va aciuni interne sau treceri n starea dat (fig. 41, b). n urma cruia dup aciunea limbajului UML se subnelege o anumit operaie atomic, executarea creia duce la schimbarea strii sau red o anumit valoare (exemplu, adevr sau fals).
37
Fig. 42. Reprezentarea grafic a strii iniiale i finale n diagrama de stri. La cel mai nalt nivel de reprezentare a obiectului trecerea de la starea iniial la starea final poate fi marcat ca aciunea de creare (iniializare) a obiectului dat. n cazul contrar tranziia nu esre marcat deloc. Dac acest tranziie nu este marcata, atunci ea este prima trecere n starea urmtoare.
5.3. Tranziie
O simpl tranziie reprezint o relaie ntre dou stri consecutive indicnd faptul schimbrii a unei stri cu alt. Prezena obiectului modelat n prima stare va efectua anumite aciuni, dar trecerea n starea a doua va fi atunci cnd anumite aciuni vor fi terminate i dup ndeplinirea anumitor condiii adugtoare. Tranziia ncepe cnd un anumit eveniment se petrece: terminarea executrii aciunii (do activity), trimiterea mesajului sau emiterea semnalului. n trecere se indic numele aciunii. Mai mult, n tranziie poate fi indicat aciunea produs de un obiect ca reacia tranziiei de la o stare la alta. Executarea tranziiei poate depinde nu numai de petrecerea unui anumit eveniment, dar i de la ndeplinirea condiiei corespunztoare, care se numete condiie gard. Obiectul va trece de la o stare la alta, numai n caz dac a fost aciunea indicat i condiia de gard este adevrat.
38
n diagrama de stri tranziia este reprezentat ca linie ntreag cu sgeat, care este ndreptat n starea de int (exemplu, defect n fig. 40). Fiecare tranziie poate fi marcat cu aliniat de text, care are urmtorul format general: <signatura evenimentului>'['<condiia de paz>']' <exprimarea aciunii>. Signatura aciunii descrie un anumit eveniment cu argumentele necesare: <numele evenimentului>'('<lista parametrilor mprite cu virgule>')'.
5.3.1. Eveniment
Termenul eveniment (event) trebuie explicat aparte, deoarece el este un element independent al limbajului UML. Opional evenimentul reprezint specificaia anumitui fapt, care are ataat o locaie n timp i n spaiu. Despre fapte se spune c ele se petrec, n acelai timp evenimente aparte trebuie s fie aranjate n timp. Dup sosirea evenimentului este imposibil de a ne ntoarce la evenimentul precedent, dac aceast posibilitate nu este prevzut n model. n limbajul UML evenimentele joac rol de stimule, care iniializeaz treceri de la o stare la alta. n calitate de evenimente destingem semnale, apeluri, terminarea intervalurilor fixate de timp sau momentele de finisare a executrii anumitor aciuni. Numele evenimentului identific fiecare tranziie aparte n diagrama de stri i pot conine aliniat de text, care ncepe cu minuscul. n acest caz tranziia va fi triger, adic care specific un eveniment triger. De exemplu, tranziii n fig. 40 sunt trigere, deoarece cu fiecare din ei sunt legate care-va eveniment triger, care petrece asincron n momentul ieirii din funciune a echipamentului tehnic sau n timpul terminrii reparaiei lui. Dac alturi de sgeata trecerii nu este indicat nici un aliniat de text, atunci trecerea corespunztoare este netriger i n acest caz din contextul diagramei de stri trebuei s fie clar dup care terminare a aciunii el ncepe a funciona. Dup numele evenimentului pot urma paranteze rotungite pentru parametrii evenimentului triger. Dac nu exist aa parametri, atunci lista parametrilor cu paranteze pot lipsi.
contrar (linie ocupat, parol incorect) nici o ncrcare a potei nu va fi i programul va lsa n fosta stare.
Fig.43. Diagrama de stri pentru modelarea programului client potal. A doua trecere de triger pe diagram iniializeaz ntreruperea automat a conectrii telefonice cu provaiderul dup terminarea ncrcrii potei n calculatorul utilizatorului. n acest cazul eveniment-triger de a finisa ncrcarea potei se petrece dup verificarea condiiei gard pota electronic pe server este deeart, care tot trebuie sa fie subneles n form de ntrebare. Dac rspunsul este pozitiv (toat pota este ncrcat sau ea nu este n pota electronic) programul potal ntrerupe ncrcarea potei i trece n starea de activaie. Dar n cazul rspunsului negativ ncrcarea potei va continua.
40
Fig. 44. Reprezentarea grafic a strii compuse. Starea compus poate conine dou sau mai multe subautomate paralele sau cte-va substri consecutive. Fiecare substare compus poate fi precizat numai ntr-un singur mod, artat mai sus. n urma cruia oricare din substri la rndul su pot fi stare compus i conine nuntru alte substri depuse. Cantitatea nivelelor depuse a strilor compuse nu sunt fixate n limbajul UML.
Oarecare lmuriri pot necesita tranziii. Dou din ele specific eveniment triger formarea numrului, care are numele de cifra cu parametru n. Ca exemplu parametrului menifest o cifr n discul telefonului. Tranziia din substarea iniial este netriger, deoarece ea nu conine nici un aliniat de text. Ultima tranziie n substarea final nu are eveniment-triger, dar are condiie gard, care verific corectitudinea formrii numrului abonatului. Numai n cazul cnd aceast condiie este adevrat aparatul de telefon poate duce n substarea final, care caracterizeaz superstarea conectarea cu abonatul n ntregime. Starea compus poate conine ca depozit substarea iniial i final. n urma creia substarea iniial este punct de plecare, cnd se ntmpl tranziia obiectului n starea compus. Dac starea compus conine nuntru substarea final, atunci tranziia n aceast stare final depus nseamn finisarea considerrii obiectului n starea depus. Este imporatant ca pentru substri disjuncte starea iniial i final trebuie s fie unic n fiecare stare depus.
Fig.46. Reprezentarea grafic a strii compuse su substrile concurente depuse. Pentru ca fiecare region a strii depuse specific un anumit subautomat, atunci pentru fiecare din subautomate depuse pot fi definite substarea iniial i final (fig. 46). n timpul tranziiei n starea depus dat fiecare din subautomate devine n substarea sa iniial. Mai departe se ntmpl executarea concurent a fiecrui din subautomatele date, iar ieirea din starea depus va fiposibil numai n cazul cnd toate automatele vor fi n strile sale finale. Dac unul din subautomate a venit n starea sa final mai degrab dect altele, atunci el trebuie s ateapte pn cnd alte subautomate vor veni n strile sale finale. 42
Exemplu a diagramei de stri, care reprezint modelarea comportamentului obiectului concret este procesul funcionrii aparatului de telefon (fig. 47). Aceast diagram de stri reprezint un automat cu o stare depus. Din exteriorul strii depuse exist numai o stare ateptare, care caracterizeaz aparatul de telefon funcionat i conectat. Tranziia n starea urmtoare se ntmpl dup riricarea receptorului. Tranziia cu aciunea atomic emiterea semnalului de ton transfer aparatul n starea compus, adic n substarea lui iniial.
Fig. 47. Diagrama de stri a procesului de funcionare a aparatului de telefon. Apoi aparatul de telefon va fi n starea semnalul de ton. n urma cruia el va scoate acest semnal pn cnd nu v-a avea loc evenimentul-triger formarea cifrei(n), sau nu trec 15 secunde de la momentul ridicrii receptorului. n primul caz aparatul va trece n starea formarea numrului, dar n starea doua sfrirea timpului de ateptare. Ultima situaie poate fi ca rezultat a ndoielii s sun sau s nu sun!? n urma cruia auzim bipuri n receptor, n urma cruia noi nu avem ce s facem, n afar de a pune receptorul. n timpul formrii numrului se execut evenimentul-triger formarea cifrei (n) cu condiia gard numrul incomplet. Aceast luru nseamn c numrul format nu conine numrul necesar de cifre, atunci este nevoie de a continua formarea cifrei urmtoare, rmnnd n starea formarea numrului. Dac numrul format este incomplet, atunci putem duce n starea numrul greit sau conectarea. n cazul numrului greit (condiia gard greit este adevr) nu avem alt alternativ dect s ieim din starea compus cu punerea receptorului. Dar dac numrul este corect, atunci are loc conectarea pe acest numr. Totui n rezultatul conectrii poate s se ntmple ca aparatul abonatului este ocupat (trecerea n starea ocupat) sau liber (trecerea n starea sunetul la abonat). n primul caz sunetul poate fi 43
repetat, dup punerea receptorului (ieirea din starea compus). n al doilea caz se ntmpl controlarea condiiei gard convorbirea este accesibil. Dac ea este adevrat, ceea ce corespunde cu ridicarea receptorului cu abonatul, ncepe convorbirea telefonic. n caz contrar (aceast condiie nu se execut, adic este fals) telefonul abonatului va continua s sune, ceea ce ne spune c ori abonatul nu este, sau din care-va alt motiv nu putem continua cinvorbirea la telefon. n urma cruia noi nu avem alt soluie dect s punem receptorul. Dac convorbirea a avut loc, atunci dup cuvinte de adio i executarea condiiei de gard confirmarea la terminarea convorbirii noi iari punem receptorul la loc. n urma cruia aparatul de telefon trece n starea ateptarea, n care poate s se afle un timp nelimitat.
O aciune poate fi indicat n limbaj natural, n pseudocod sau n limbaj de programare. Nu sunt restricii suplimentare pentru indicarea aciunilor. Se recomand n calitate de nume al unei aciuni simple s se utilizeze un verb cu cuvinte explicative (fig. 48, a). Dac aciunea nu poate fi reprezentat ntr-un mod formal, atunci este util a-l indica n limbaj de programare pentru realizarea proiectului dat (fig. 48, b). Uneori este necesar a reprezinta n diagrama de activiti o aciune complex care la rndul su const din mai multe aciuni simple. n acest caz poate fi utilizat notaia special a strii de subactivitate (subactivity state). Aa fel de stare este un graf de activitate care se noteaz cu un semn special n colul drept de jos (fig. 49). Aceast construcie poate fi aplicat oricrui element al limbajului UML care susine imbricarea pentru structura sa. Totodat semnul special poate fi etichetat cu tipul structurii.
Fig. 49. Starea subactivitii. Fiecare diagrama de activiti trebuie s aib o singur stare iniial i o singur stare final.
6.2. Tranziii
Tranziia ca element al limbajului UML a fost studiat n capitolul despre diagrama de stri. La construirea diagramei de activiti se utilizeaz careva tranziii netrigere care acioneaz deodat dup perfectarea activitii sau dup executarea aciunii corespunzatoare. Aceast tranziie transmite activitatea n urmtoarea stare imediat dup ce se termin aciunea din starea precedent. n diagram aceast tranziie se reprezint printr-o linie continu cu o sgeat. Dac din starea dat iese numai o tranziie atunci ea poate s nu fie marcat (indicat), dar dac tranziiile de ieire sunt mai multe atunci poate s acioneze numai una din ele. Anume n acest caz pentru fiecare din tranziii trebuie s fie indicat n paranteze patrate o condiie de supraveghere. Totodat pentru toate strile de ieire trebuie s fie executat numai o cerin de veridicitate a unei tranziii. Acest caz are loc cnd activitatea consecvent executat trebuie s fie divizat n ramuri alternative independent de valoarea unui rezultat intermediar. Aceast situaie se numete ramificaie. Grafic ramificaie se reprezint printr-un romb gol (fig. 50). n acest romb numai o sgeat de la o aciune corespunztoare poate s intre. Sgeata de intrare se unete cu vrful de sus sau cu cel din stnga al simbolului de ramificaie. Pot fi mai multe sgei de ieire, dar pentru fiecare din ele trebuie s fie indicat condiia de supraveghere sub form de expresie boolean. Ca exemplu vom cerceta calcularea costului total al produciei procurate cu o cartel bancar. Dac costul depete 50$ atunci se acioneaz identificarea proprietarului cartelei bancare. n caz dac cartela este valabil i contul nu depete suma n 50$ atunci suma se scoate de pe cont i se achit 45
producia procurat. n caz contrar (dac cartela nu este valabil) achitarea nu se execut i producia rmne la vnztor.
Fig. 50. Diverse variante ale ramificaiilor n diagrama de activiti. Unul din cele mai semnificative neajunsuri ale schemelor-block sau ale schemelor ce reprezint algoritmi este legat cu problema reprezentrii ramurilor paralele ale unor calcule. Din motiv c divizarea calculelor n ramuri aparte marete viteza produsului soft, sunt necesare primitive grafice pentru reprezentarea proceselor paralele. n limbajul UML pentru acest scop se utilizeaz simboluri pentru diviziune i unire a calculelor paralele sau a fluxurilor de control. Acest simbol este o linie dreapt analogic notaiei unei tranziii n formalismul reelelor Petri. De regul aceast linie se reprezint printr-un segment al unei linii orizontale, grosimea creia este mai mare dect grosimea liniilor n diagrama de activiti. Totodat fork (diviziunea concurrent fork) are o tranziie de intrare i mai multe de ieire (fig. 51, a). Join (unirea concurrent join) invers are mai multe tranziii de intrare i numai o tranziie de ieire (fig. 51, b).
Fig. 51. Fork i join a mai multor fluxurilor paralele de control. Pentru ilustrarea particularitilor proceselor paralele de executare a aciunilor este util a cerceta exemplul devenit clasic de pregtire a a unei buturi. Avantajul acestui exemplu const n faptul c exemplul practic nu cere explicaii adugtoare, fiindc este considerat evident (fig. 52).
46
6.3. Partiii
Diagramele de stri pot fi utilizate nu numai pentru specificarea algoritmelor de calculare sau fluxurilor de control n sistemele de programare. Un domeniu de utilizare este legat cu modelarea busimes-proceselor. ntra-devr, activitatea oricrei companii reprezint totalitatea aciunilor independente ndreptate la atingerea rezultatului. Totui relativ de businesprocese este de dorit efectuarea fiecarei aciuni asociative cu subdivizare a companiei concrete. n acest caz aceste subdiviziuni au responsabilitatea de realizare a unor aciuni, iar businesprocesele reprezint trecerea aciunilor de la o subdivizare la alta. 47
Pentru modelarea acestor particulariti n limbajul UML se folosete construcia special, care are denumire de partiii (swimlanes), care sunt divizate unul cu altul cu linii verticale. Dou linii vecine formeaz o partiie, iar un grup de stri ntre aceste linii sunt executate de subdiviziunea separat (secie, filial, diviziuni) a companiei (fig. 53). Denumirele subdiviziunelor sunt indicate n partea de sus a partiiei. A ntretia linia partiiei pot numai tranzaciile, care n acest caz indic ieirea sau intrarea fluxului de control n subdiviziunea respectiv a companiei. Ordinea trecerii partiiilor nu are care-va informaie simantic i este definit dup motivele de comfortabilitate. Ca exemplu vom lua fragmentul diagramei de activitate a companiei de vindere, care servesc clienii cu ajutorul telefonului. Subdiviziunele companiei sunt secia de acceptare i perfectare a cerinelor, secia de vindere i depozitul. Acestor subdiviziuni vor corespunde trei partiii n diagrama de activitate, fiecare din care specific zona de responsabilitate a subdiviziunei. n cazul dat diagrama de activitate ntreine nu numai informaie despre consecutivitatea executrii a aciunii lucrtorilor, dar i care subdiviziuni a companiei de vindere trebuie s execute o aciune sau alta (fig. 53).
Fig. 53. Fragmentul diagramei de activitate pentru compania de vindere. Din aceast diagram de activitate este evident c dup acceptarea comandei de la client a seciei de acceptare i perfectare a cerinelor se realizeaz diviziunea activitii la dou fluxuri (tranzacie diviziune). Primul din ei rmne n aceeai secie i este legat cu acceptarea mrfurilor n secia de vindere (modelul mrfii, dimensiuna, culoarea, anul de editare etc.). Dup finisarea lucrului acesta iniializeaz aciunea de eliberare a marfurilor din depozit. Totui pregtirea mrfii pentru expedierea n secia de vindere ncepe numai dup achizionarea mrfii de la client i marfa va fi expediat din depozit (tranziie - conectare). Numai dup aceasta marfa este expediat la client i devine proprietatea lui. 48
6.4. Obiecte
n cazul general aciunile n diagrama de activitate sunt efectuate cu obiecte. Aceste obiecte sau iniializeaz executarea aciunelor sau definesc un anumit rezultat a acestor aciuni. n urma cruia aciunile specific apelurile, care trec de la un obiect a grafului de activitate la altul. ntruct n acest racurs obiectele joac un anumit rol n nelegerea procesului de activitate, uneori apare necesitatea indicrii lor n diagrama de activitate. Pentru reperezentarea grafic a obiectelor sunt utilizate dreptunghiurile clasei cu o deosebire: numele obiectului se subliniaz. Dup nume poate fi indicat caracteristica strii obiectului n paranteze ptrate. Aceste dreptunghiuri a obiectelor sunt unite cu strile de activiti a relaiei de dependen cu linia punctir cu sgeat. Dependena respectiv definete starea concret a obiectului dup efectuarea aciunii precedente. n diagrama de activitate cu partiii deplasarea obiectelor poate avea un sens adugtor. i anume, dac obiectul este amplasat la hotarul ambilor partiii, aceast lucru nseamn c trecerea la starea de aciune urmtoare n partiia vecin este asociat cu un document finit (obiectul n care-va stare). Dar dac obiectul este amplasat nuntrul partiiei, atunci starea acestui obiect este definit de aciunile partiiei date. Revenind la exemplul precedent cu compania de vindere, poate nota c obiectul central a procesului de vindere este comanda, anume starea ei de executare. La nceput, pn la primirea sunetului de la client, comanda ca obiect lipsete i apare numai dup ce a am primit sunetul de la client. Totui, aceast comand nu este ndeplinit pn la urm, deoarece este necesar de alege o marf concret din secia de vindere. Dup pregtirea lui el transfer marfa la depozit, unde mpreun cu eliberarea mrfurilor comanda este perfectat. La sfrit, dup trimiterea confirmrii despre achiziionarea mrfii aceast informaie nscrie n comand i el este ndeplinit i sfrit (fig. 54).
7.1. Obiecte
n diagrama de secven se reprezint numai obiectele care acioneaz i nu se reflect asocierile statice cu alte obiecte. Pentru diagrama de secven momentul principal este dinamica colaborrii ntre obiecte n timp. Grafic fiecare obiect se reprezint printr-un dreptunghi i se plaseaz n partea de sus a ciclului su de via (fig. 54). n nteriorul dreptunghiului se indic numele obiectului i numele clasei desprite prin dou puncte. Totodat toat nregistrare se subliniaz, ce indic c obiectul este exemplarul unei clase. n caz dac numele obiectului lipsete, atunci se indic numai numele clasei i obiectul se consider anonim.
Fig. 55. Primitivele grafice ale diagramei de secven. Obiectul din stnga diagramei este cel care iniiaz colaborarea (obiectul 1 n fig. 55). Mai la dreapt se reprezint obiectul care interacioneaz cu primul. Totate obiecte n diagrama de secven formeaz o anumit ordine determinat de activitatea colaborrii lor. A dou msur a diagramei de secven este axa vertical de timp (din sus n jos). Momentului iniial de timp i corespunde partea de sus al diagramei. Totodat colaborarea obiectelor este realizat prin mesajele transferate. Mesajele se reprezint sub forma de sgei drepte cu numele mesajelor, ele de asemenea sunt ntr-o ordine anumit n timp. Cu alte cuvinte, mesajele plasate n diagrama de secven mai sus sunt iniiate mai devreme dect cele din jos. Totodat proporiile pe axa temporal nu se indic fiindc diagrama de secven modeleaz doar ordonarea n timp a legturilor de tip mai devrememai trziu.
50
7.3. Mesaje
Scopul colaborrii n contextul limbajului UML const n specificarea comunicaiei ntre o mulime de obiecte. Fiecare legtura se descrie cu o totalitate de mesaje transferate cu care obiecteleparticipante se schimb. n acest sens mesajul (messaje) reprezint un fragment de informaie care este transferat de ctre un obiect altuia. Totodat acceptarea mesajului iniializeaz anumite aciuni ndreptate spre rezolvarea problemei de ctre obiectul cruia mesajul i este transferat. Mesajele nu numai transmit informaia, ele presupun executarea aciunilor ateptate de ctre obiectul acceptabil. Mesajele pot iniia executarea operaiilor de ctre obiectul unei clase, dar parametrii acestor operaii sunt transferai mpreun cu mesajul. n diagrama de secven toate mesajele sunt coordonate dup timpul de apariie n sistemul modelat. n context dat mesajul este destinat de ctre obiect care iniiaz sau transfer mesajul ctre obiectul care l accept. Uneori expeditorul al unui mesaj este numit clinet, dar destintarul server. Totodat mesajul de la un anumit client este o cerin a unui server. Reacia acesctui server la cerina dup primirea mesajului presupune executarea anumitor aciuni i transmiterea informaiei sub forma a unui mesaj ctre client. n limbajul UML sunt cteva varieti de mesaje, fiecare din ele are notaia grafic proprie. n unele cazuri obiectul poate transmite mesaje ctre sine iniializnd mesaje reflexive. 51
"call" invoc o operaie sau procedur a obiectului-destinatar; "return" returneaz valoarea operaiei executate obiectului apelant; "create" creaz alt obiect pentru executarea anumitor aciuni; "destroy" distruge un obiect. Se transmite n caz dac este necesar a termina aciunile din partea obiectului existent sau dac obiectul trebuie s elibereze resursele alocate; "send" trimite un semnal unui obiect care se iniializeaz asincron de ctre un obiect i este acceptat de altul. Diferena ntre un semnal i un mesaj const n fapt c semnalul trebuie s fie descris n clasa obiectul creia iniializeaz transmiterea lui.
Mesajele pot avea notaii proprii pentru operaii, apelarea crora ele o iniializeaz. n acest caz lng sgeat se scrie numele operaiei cu paranteze rotunde n care se indic parametrii sau argumentele operaiei respective. Dac parametrii lipsesc atunci parantezele rmn neaprat dup numele operaiei.
52
a : Abonat
: Comutator
d: Aparat de telef on
b : Abonat
f ormeaza un numar
: Conv orbire "create" conexare() conexare(a) pune receptorul termina conv orbire "destroy " termina conv orbire "send" "send" sunet() ridica receptorul conexare(b) pune receptorul
8.1. Obiecte
Obiecte sunt elementele de baz sau primitivele grafice din care const diagrama de colaborare. Pentru reprezentarea grafic a obiectelor se utilizeaz acelai dreptunghi ca i pentru reprezentarea clasei. 53
Obiectul (object) este un exemplar aparte al clasei care este creat la etapa executrii a unui program. El poate avea un nume propriu i valorile atributelor. Referitor la obiecte formatul liniei ce conine clasificatorul se completeaz cu numele obiectului: <Numele obiectului>'/' <Numele rolului al clasificatorului> ':' <Numele clasificatorului> [':' <Numele clasificatorului >]* Aici Numele rolului clasificatorului poate s nu fie indicat. n acest caz el se exclude din context mpreun cu dou puncte. Numele rolului poate fi omis n caz daca exist mai multe roluri n colaborarea obiectelor create pe baza clasei date. Pentru definirea rolului clasificatorului este de ajuns a indica numele clasei (mpreuna cu dou puncte) sau numele rolului (mpreuna cu /). n caz contrar dreptunghiul va corespunde clasei ordinare. Dac rolul unui obiect se motenete de la mai multe clase, atunci ele toate trebuie s fie indicate i desprite prin virgul i dou puncte. Urmtoarele sunt variante de indicare a textului n nteriorul dreptunghiului.
: un obiect anonim creat pe baza clasei . / R un obiect anonim cu rolul R. / R : un obiect anonim creat pe baza clasei cu rolul R. / R un obiect cu numele O cu rolul R. : un obiect cu numele O creat pe baza clasei . / R : un obiect cu numele O creat pe baza clasei cu rolul R. sau obiectul cu numele . : un "obiect orfan" cu numele . / R un rol cu numele R. : un rol anonim pe baza clase . / R : un rol cu numele R pe baza clase .
Fig. 58. Exemple de moduri de indicare a numelor obiectelor, rolurilor i claselor n diagrama de colaborare. n primul caz (fig. 58, a) obiectul cu numele client cu rolul iniiatorul cerinei. n cazul (fig. 58, b) este indicat un obiect anonim cu rolul iniiatorului cerinei. n ambele cazuri nu este indicat clasa pe baza creia sunt create aceste obiecte. n cazul (fig. 58, c) clasa este determinat, dar obiectul rmne anonim. Referitor la nivelul de specificare n diagramele de colaborare pot fi specificate clase denumite cu indicarea rolurilor (fig. 58, d) sau clase anonime dar tot cu indicarea rolurilor (fig. 58, e). Ultimul caz reflect situaia cnd n model pot fi prezente cteva clase cu numele Client, de aceea este necesar specificarea numelui pachetului Baza de date (fig. 58, f).
54
8.1.1. Multiobiect
Multiobiect (multiobject) reprezint o mulime de obiecte n una din terminaiile asocierei. n diagrama de colaborare multiobiectul se utilizeaz pentru a arat operaiile i semnalele care sunt adresate ctre toat mulimea de obiecte. Multiobiectul se reprezint n forma a dou dreptunghiuri, unul din care iese n afara laturei de sus a altui dreptunghi (fig. 59, a). Totodat sgeata mesajului se refer la toat mulime de obiecte care definesc multiobiect dat. n diagrama de colaborare poate fi indicat relaia compoziiei (structura) ntre multiobiect i un obiectul aparte din mulime care l definete (fig. 59, b).
Fig. 60. Obiect activ. n exemplu urmtor se cerceteaz situaia de apelare a funciei de tipar a unui redactor textual (fig. 61). Obiectul activ anonim Redactor textual mai nti trimite mesajul ctre multiobiectul Imprimant care iniiaz alegearea unui singur obiect Imprimant care satisface cerinele suplementare. Dup aceea obiectului ales i se transmite mesajul de tipar al unui document ncrcat n redactorul textual.
55
2: tipar(document) : Imprimanta
Fig. 61. Fragmentul diagramei de colaborare pentru apelare funciei de tipar din redactor textual.
8.2. Legturi
Legtura (link) este exemplarul sau exemplul asocierii arbitrare. Legtura ca element al limbajului UML poate fi ntre dou sau mai multe obiecte. Legtura binar n diagrama de colaborare se reprezint n form de segment al liniei drepte care leag dou dreptunghiuri ale obiectelor (fig. 61). La fiecare terminal al acestui segment pot fi indicate numele rolurilor asocierii date. Lng linie, n mijlocul ei, se indic numele asocierii respective. Legturile nu au numele proprii fiindc sunt identice ca exemplare ale asocierii. Cu alte cuvinte toate legturile n diagrama de colaborare pot fi numai anonime i se indic fr dou puncte naintea numelui asocierii. Pentru legaturi nu se indic nici multiplicitatea. ns alte reprezentri ale cazurilor particulare de asociere (agregare, compoziia) pot fi la terminaiile legturilor. De exemplu, simbolul de tip compoziia ntre multiobiectul Imprimant i obiectul aparte Imprimant (fig. 61). 56
"association" asociere (se presupune implicit, de aceea acest tip poate s nu fie indicat). "parameter" parametrul metodei. Obiectul respectiv poate s fie doar paramentru al unei metode. "local" variabila local a metodei. Domeniul ei de vizibilitate este limitat de ctre obiectul vecin. "global" variabila global. Domeniul ei de vizibilitate este toat diagrama de colaborare. "self" legtura reflexiv a obiectului care presupune transferul mesajelor ctre sine. n diagrama de colaborare legtura reflexiv se reprezint n form de bucl n partea de sus al dreptunghiului obiectului.
Unele exemple de legturi cu diferite stereotipuri sunt prezentate n fig. 63. Aici este reprezentat schema unei companii cu numele C care const din secii (multiobiect anonim Secie). Seciile constau din angajai (multiobiect anonim Angajat). Legtura reflexiv indic faptul c managerul seciei este i angajatul acesteia.
c : Compania
: Angajat
Fig. 63. Legturi de diferite tipuri. Pentru obiectul Convorbire2 se indic valoarea {transient} care nseamn c obiectul este creat pe parcursul executrii procesului i se distruge nainte de terminaia lui.
57
5: comutati e(a,b)
: Comutator
4: formeaza un numar(i) 8: apeleaza_abonatul(b)
legatura telefonica
6: creaza()
d : Aparat de telefon
1: ridica_receptorul() 3: roteste_discul ()
"local"
2: signal_ton()
: Convorbire
transient
10: ridica_receptorul()
"local"
11: i ncepe_convorbire()
9: sunet()
12: i ncepe_convorbire()
"global" participant_convorbirei
"global" participant_convorbire
a : Abonat
b : Abonat
8.3. Colaborare
Noiune de colaborare (collaboration) este una din noiunile fundamentale ale limbajului UML. Ea nseamn o mulime de obiecte care interacioneaz n contextul comun al sistemului modelat. Scopul colaborrii const n specificarea particularitilor realizrii a celor mai semnificative operaii n sistem. Colaborarea determin structura comportamentului sistemului dat n termeni de colaborare a participanilor. Colaborarea poate fi prezentat n dou nivele:
Nivelul de specificare arat rolurile clasificatorilor i rolurile asocierilor n colaborarea dat. Nivelul de exemple indic exemplare i legturi, roluri n colaborare.
Diagrama de colaborare la nivel de specificare arat rolurile elementelor ce particip n colaborare. Elementele colaborrii la acest nivel sunt clase i asocieri care reprezint rolurile unor clasificatori i asocieri ntre participanii acestei colaborari. Diagrama de colaborare la nivel de exemple reprezint o totalitate de obiecte (exemplare de clase) i legturi (exemplare de asociere). Totodat legturi sunt completate cu sgeile mesajelor. La acest nivel sunt reflectate numai obietce relevante, adic obiectele care au legtur cu realizarea operaiei sau clasificatorului. n colaborare la nivel de exemple sunt definite proprieti fiecrui exemplar pentru participarea n colaborare. n afara de proprietile obiectului, n diagrama de colaborare sunt indicate asocierile ntre obiectele acestei colaborri. n momentul cnd clasificatorul necesit descrierea complet a tuturor exemplarilor, rolul clasificatorului necesit descrierea numai proprietilor i asocierilor pentru participarea ntr-o colaborare anumit. 58
Una i aceeai totalitate de obiecte poate participa n mai multe colaborri. Totodat, n dependen de colaborarea cercetat, unele proprieti ale obiectelor pot s se schimbe aa precum i legturile ntre ele. Anume acest fapt deosebete diagrama de colaborare de diagrama de clase n care sunt indicate toate proprietile i asocierile ntre elementele diagramei.
Fig. 65. Colaborarea n diagrame la nivel de specificare. Clasa elementar n diagrama de colaborare se reprezint printr-un dreptunghi n nteriorul creia se indic textul. Acest text este (definete) rolul clasificatorului (classifier role). Rolul clasificatorului specific utilizarea obiectelor clasei date. Deseori n dreptunghi se indic numele clasei, dar nu se exclude posibilitatea de a indica atribute i operaii. Textul n dreptunghi este de fel urmtor: '/' <Numele rolului clasificatorului> ':' <Numele clasificatorului> [':' < Numele clasificatorului >]* Aici Numele clasificatorului poate s conin direcia tuturor pachetelor componente. Totodat un pachet se divezeaz de altul prin dou puncte duble ::. Dac aceast nu ncurc atunci se poate de indica numai pachetul apropiat care conine colaborare dat. Simbolul * arat posibilitatea de repetare iterativ a numelui clasificatorului. Dac colaborarea permite reprezentarea generalizat, atunci n diagrame pot fi indicate relaii de generalizare a elementelor respective. Acest principiu determin colaborri aparte, care sunt cazuri particulare sau specializare ale altei colaborri. Aceasta situaie deseori se reprezint n form de sgeat de generalizare ndreptat de la simbolul colaborrii al descendentului spre simbolul colaborrii alunui printe (fig. 66).
59
Fig. 66. Relaii de generalizare ntre colaborrii la nivel de specificare. n unele cazuri apare necesitatea de a indica faptul c colaborarea este realizarea unei operaii sau a unui clasificator. Acest fapt poate fi reprezentat n doi feluri. n primul rnd simbolul colaborrii poate fi conectat cu ajutorul liniei punctate cu sgeata generalizrii cu simbolul clasei, realizarea operaiei cruia specific colaborarea data (fig. 67, a). Dac n calitate de clas va fi cercetat Comanda la procurarea produciei care are operaia ntocmirea_comandei() atunci realizarea ei poate fi specificat n form de colaborare.
Fig. 67. Metode de reprezentare a colaborrii care realizeaz operaiunea clasei. n al doilea rnd este uor de reprezentat simbolul colaborrii n nteriorul cruia se poate de indicat toat informaia necesar conform regulii speciale (fig. 67, b). Aceste reguli definesc formatul de nregistrare a numelui de colaborare, dup care se scriu dou puncte i numele clasei, dup numele clasei se scriu dou puncte duble i numele operaiei. Aa fel de reprezentare generalizat a colaborrii la nivel de specificare se utilizeaz la etapele iniiale de proiectare. Ulterior fiecare din colaborri poate fi detaliat la nivel de exemple, la care se desfoar coninutul i structura legturilor elementelor acestei colaborri n diagrama de colaborare aparte. Totodat n calitate de elemente ale diagramei pot fi obiecte i legturi completate cu mesaje. Anume astfel de elemente sunt obiectul cercetrii n capitolul dat.
60
Destinaie principala a reprezentrii logice const n analiza relaiilor structurale i funcionale ntre elementele unui model de sistem. Pentru crearea unui sistem fizic real este necesar a transforma toate elementele reprezentrii logice n entiti materiale. Pentru descrierea acestor entiti este destinat aspectul reprezentrii modelare fizice. Pentru a explica diferena ntre reprezentarea logic i fizic vom cerceta procesul de elaborare a unui sistem de program. n calitate de reprezentare logic iniial a acestui sistem pot fi schemele structurale ale algoritmelor i procedurilor, descrieri a unor interfee i baza de date conceptual. Pentru realizarea acestui sistem este necesar de a elabora codul surs n anumit limbaj (C++, Pascal, Basic/VBA, JAVA). Totodat n codul surs se presupune divizarea acestui cod n module aparte. Cu toate c codurile surs iniiale sunt fragmente ale reprezentrii fizice a unui proiect, ele nu prezint realizarea final a lui. Sistemul program poate fi considerat realizat numai n caz daca el va putea executa funciile destinaiei sale. Aceasta este posibil dac codul surs al unui sistem va fi realizat n forma de module executate, biblioteci ale claselor i procedurilor, interfeelor grafice standarde, fiierelor bazelor de date. Anume aceste componente sunt necesare pentru reprezentarea fizic a unui sistem. Proiectul complet al unui sistem al programului reprezint o totalitate de modele ale reprezentrii logice i fizice care sunt coordonate ntre ele. n limbajul UML pentru reprezentarea fizic a unui model al sistem sunt utilizate diagramele de realizare (implementation diagrams) care includ dou diagrame canonice: diagrama de componente i diagrama de plasare. Specifica crerii primei din ele va fi cercetat n capitolul dat, al ultimei diagrame n capitolul urmtor. Diagrama de componente, spre deosebire de diagramele cercetate, descrie particularitile reprezentrii fizice a unui sistem. Diagrama de componente permite determinarea arhitecturii sistemului elaborat prin stabilirea dependenei ntre componentele de program n calitate de care poate fi codul iniial, binar i executabil. n mai multe domenii de elaborare modul i componenta corespund fiierului. Sgeile punctate care leag modulele arat relaiile de dependena analogice celor ce au loc la compilarea codurilor sursei iniiale. Elementul grafic de baz al diagramei de componente sunt componentele, interfeele i dependenele ntre ele. Diagrama de componente se elaboreaz pentru urmatoarele scopuri:
Vizualizarea structurii comune a codului surs a unui sistem de program. Specificarea variantei executabile a unui sistem de program. Asigurarea utilizrii repetate a unor fragmente ale codului surs. Reprezentarea conceptual i fizic a schemelor bazei de date.
n elaborarea diagramei de componente particip analitii de sistem, arhitectorii, i programitii. Diagrama de componente asigur trecere coordonat de la reprezentare logic spre o realizare a unui proiect n form de cod surs. Unele componente pot exista numai la etapa compilrii codului sursei, altele la etapa realizrii lui. Diagrama de componente reflect dependenele ntre componente la cercetarea componentelor n calitate de clasificatori.
9.1. Componente
Pentru reprezentarea entitilor fizice n limbajul UML se utilizeaz componenta (component). Componenta realizeaz un set de interfee i desemneaz elementele reprezentrii fizice a unui model. Grafic componenta se reprezint printr-un dreptunghi cu anexe (fig. 67). n nteriorul acestui dreptunghi se indic numele componentei i posibil informaia suplementar. Reprezentarea acestui simbol variaz n dependen de informaia asociat cu componenta dat. 61
n metamodelul limbajului UML componentul este descendentul clasificatorului. El reprezint organizaia n cadrul unui pachet fizic cu care el este asociat cu ajutorul elementelor unui model. n calitate de clasificator componentul poate s aib aa proprieti ca atribute i operaii.
Fig. 68. Componenta. n primul caz (fig. 68, a) cu exemplarul componentei se leag numai numele lui, n al doilea caz (fig. 68, b) se leag n completare numele pachetului i valoarea marcat. Adnotare Reprezantarea componentului devine de la marcare modulului programului, care a fost utilizat un anumit timp pentru reprezentarea particularitilor incapsularii datelor i procedurilor. n aa fel, un dreptunghi mic de sus se asociaz cu datele, care realizeaz acest component (anterior a fost semnat cu oval). Un dreptunghi mic de jos se asociaz cu operaii i metode, realizate de component. n cazurile mai simple numele de date i metode au fost scrise n aceste dreptunghiuri mici, totui ele nu sunt indicate n limbajul UML.
n primul rnd componente de regrupare, care specific executarea de ctre sistem a funciilor sale. Aa fel de componente pot fi librrii conectate dinamic cu extensia .dll (fig. 69, a), Web pagini n limbajul de trasare hipertextului cu extensia .html (fig. 69, b) i fiierele de adeverin cu extensia .hip (fig. 69, c). n al doilea rnd, componente produse de lucru. Ca regul acestea sunt fiierele cu texte iniiale a programului, de exemplu, cu extensia .h sau .cpp pentru limbajul C++ (fig. 69, d). n al treilea rnd, componentele de executare, ce reprezint modulele fiierele cu extensia .exe. Ei se indic obinuit.
Fig. 69. Variantele reprezentrii grafice a componentelor diagramei de componente. Aceste elemente sunt uneori numite artefacte, subliniaz n aa fel coninutul lor informaional finit, dependent de tehnologie de realizare concret a componentelor respective. Mai mult dect att, elaboratorii pentru acest scop pot utiliza notaii independente, deoarece n limbajul UML nu exist notare strict pentru reprezentarea grafic a notaiilor. Un alt mod de specificare a diferitor feluri componentelor este indicarea steriotipului componentului naintea numelui lui. n limbajul UML pentru componente sunt specificate urmtori steriotipuri:
Librrie (library) definete prima specie a componentuluui, care reprezent librrie dinamic sau static. Tabel (table) definete prima specie a componentului, care reprezent un tabel de baze de date. Fiier (file) definete a doua specie a componentului, care reprezint un fiier cu texte iniiale a programului. Document (document) definete a doua specie a componentului, care reprezint un document. Executare (executable) definete a treia specie componentului, care poate fi executat n nod.
63
9.2. Interfee
Urmtorul element a diagramei a componentelor sunt interfeele. Ultimele au fost desrise mai sus, de aceea aici vor fi indicate numai acele proprieti, care sunt tipice pentru reprezentarea la diagramele de componente. Ne reamentim c n cazul general interfaa este reprezentat n form de circumferin, care este legat cu componentul cu ajutorul liniei fr sgeat (fig. 70, a). n urma cruia numele interfeei, care obligatoriu trebuie s fie scris cu majuscul I, este scris alturi de circumferin. Semantic linia nseamn interfaa, iar prezena interfeelor la componente nseamn c componentul dat realizeaz trus de interfee respective.
Fig. 70. Reprezentarea grafic interfeelor n diagrama de componente. Un alt mod de reprezentare a interfeelor n diagrama de componente este reprezentarea lui n forma de dreptunghi a clasei cu stereotipul interfaa i cu seciuni posibile a atributelor i operaiilor (fig. 70, b). Ca regul, acest caz de notare este utilizat pentru reprezentarea structurii interne a interfeei, care poate fi important pentru realizarea. n urma elaborrii sistemelor de programare interfeele asigur nu numai coinciderea diferitor versiuni, dar i posibilitatea de ntroducere a schimbrilor n unele pri a programului neschimbnd altele pri a ei. n aa fel, destinaia interfeilor este mai adnc, dect specificaia interaciunii cu utilizatorii sistemului (actorii). Adnotare Caracter de utilizare a interfeelor cu unele componente poate fi diferit. De aceea exist dou feluri de legtur a interfeei i componentului. Dac componentul realizeaz o anumit interfa, atunci aceast interfa este numit de export, deoarece acest component prezint n el modul de serviciu pentru altele componente. Dac componentul utilizeaz o anumit interfa, care este realizat de un alt component, atunci acea interfa pentru primul component este numit de import. Particularitile interfeei de import const n aceea c n diagrama de componente aceast relaie este reprezentat cu ajutorul dependenei.
9.3. Dependene
n cazul general relaia de dependen a fost examinat mai sus. Reamentim c relaia de dependen nu este asociere, dar este utilizat numai pentru reprezantarea faptului existenei acestei legturi, cnd modificarea unui element a modelului nflueneaz sau duce la schimbarea altui element a modelului. Relaia de dependen n diagrama de componente reprezint o linie punctir cu sgeat orientat de la client (element dependent) la surs (element independent). Relaia poate indica legturile modulelor programului la etapa de compilare i generare a codului. n alt caz dependena poate indica existena n componentul independent descrierea clasei, care sunt utilizate n componentul dependent pentru crearea obiectelor respective. n diagrama de 64
componente dependenele pot conecta componentele i interfeele de import de component, dar i diferite feluri de componente ntre sine. n primul caz se deseaneaz sgeat de la component client la interfaa de import (fig. 71). Prezena sgeii nseamn c componetul nu realizeaz interfaa respectiv, dar utilizeaz n ea procesul su de executare. n aceast diagram mai poate exista i un alt component, care realizeaz aceast interfa. De exepmplu, fragmentul diagramei de componente prezentat mai jos reprezint o informaie despre componentul cu numele main.exe dependent de interfaa de import I dialog, care la rndul su este realizat de componentul cu numele image.java. Pentru al doilea component aceai interfa este de export.
Fig. 71. Fragmentul diagrameide componente cu relaie de dependena. Observm, c de a reprezentarea al doilea component cu numele image.java n form de variant de adnotare nu este posibil, deoarece acest component realizeaz interfaa. Un alt caz de relaie de dependen n diagrama de componente este relaia ntre diferite feluri de componente (fig. 72). Prezena dependenei acestea nseamn c shimbrile n texte a programelor sau librrii dinamice vor duce la schimbarea componentului. n urma cruia caracterul schimbrii poate fi indicat adugtor.
Fig. 72. Reprezentarea grafic relaie de dependena ntre componente. i n sfrit, n diagrama de componente pot fi reprezentate relaiile de dependen ntre componente i realizate n ele clase. Aceast informaie este foarte imporatant pentru coordonarea reprezentrii logice i fizice a modelelor sistemului. Shimbrile n structura descrierii claselor poate duce la schimbarea componentului. Mai jos este prezentat fragmentul dependenei, cnd un anumit component depinde de clase respective.
n cazul dat, din diagrama de componente nu reiese c clasele sunt realizate de acest component. Dac este necesar de subliniat c care-va component realizeaz anumite clase, atunci pentru indicarea componentului este utilizat simbolul n form de dreptunghi. n urma cruia dreptunghiul componentului divizeaz n dou seciuni cu linia orizontal. Secia de sus este utilizat pentru notarea numelui componentului, iar cea de jos pentru indicarea informaiei adugtoare (fig. 74).
Fig. 74. Reprezentarea grafic a componentului cu informaia adugtoare despre clase realizate. nuntrul simbolului a componentului sunt indicate alte elemente a notaiei grafice, aa clase ca (componentele nivelului de tip) sau obiectele (componentele nivelului de exemplare). n acest caz simbolul componentului este reprezentat n aa fel ca s ntroduc aceste simboluri adugtoare. De exemplu, componentul realizat mai jos (fig. 75) este exemplar i realizeaz trei obiecte.
Fig. 75. Reprezentarea grafic a componentului nivelului de exemplar, ce realizeaz obiectele. Obiecte, care se afl n componentul exemplar sunt reprezentate ntr-un fel de elementele depuse n simbolul componentului dat. Aa fel de depunere nseamn c efectuarea componentului duce la executarea obiectelor respective. Cu alte cuvimte, existena componentului n timpul executrii programului a aprozivionat existena i posibil accesul tuturor obiectelor depuse. Ce se refer la accesul acestor obiecte, el poate fi adugtor specificat cu ajutorul specificatorul de vizibilitate ca i la vizibilitile pachetelor. Sensul vizibilitii poate fi diferit pentru diferite feluri de pachete. De exemplu, pentru pachetul programului cu text iniial vizibilitatea nseamn posibilitatea ntroducerii schimbrii n texte a programului respectiv cu recompilarea lor. Pentru componente cu codul programului executabil vizibilitatea poate caracteriza posibilitatea de a executa componentul respectiv sau chemarea operaiilor sau metodelor realizate n el.
Dup ce putem duce la structurizarea general a diagramei de componente. n primul rnd este necesar de a hotr din care pri (fiiere) fizice va fi compus sistemul de programare. La aceast etap este necesar de a ateniona la aa fel de realizare a sistemului care va garanta nu numai posibiliatea utilizrii repetate a codului pe seama decompoziiei componentelor, dar i crearea obiectelor n urma necesitii. Merge vorba despre producerea general sistemului de programare care n mare parte depinde mult de utilizarea raional a ei de resursele de calcul. Pentru acest scop este necesar descrierea marii pri a claselor, operaiilor i metodelor lor de a scoate n librriile dinamice, lsnd n componentele de executare numai cele mai necesare fragmente pentru iniializare a codului programului. Dup structurizarea general reprezentrii fizice a sistemului este necesar de adugat modelul cu interfee i schemele bazei de date. n elaborarea interfeelor este necesar de a atrage atenia la coordonarea diferitor pri a sistemului de programare. Includerea n modelul bazelor de date presupune specificarea tabelelor i stabilirea legturilor informaionale ntre tabele. n sfrit, etapa final de construire a diagramei de componente este legat de stabilirea i depunerea n diagram a nteraciunilor ntre componente i relaiile de realizare. Aceste relaii trebuie desfurate n toate aspectele importante a realizrii fizice a sistemului, ncepnd cu particularitile compilrii textelor iniiale a programului i terminnd cu ndeplinirea unor pri a programului la etapa de executare. Pentru aceast scop pot fi utilizate diferite feluri de reprezentare grafic a componentelor. n timpul alaborrii programului trebuie de inut cont de principiile generale a crerii modelului n limbajul UML. i anume, n primul rnd este necesar de a utiliza componente i stereotipuri, care exist n limbajul UML. Pentru majoritatea proiectelor tipice aceast trus nu este suficient pentru reprezentarea componentelor i dependenelor ntre ele. Dar dac proiectul conine anumite elemente fizice, descrierea crora lipsete n limbajul UML, atunci trebuie de utilizat mecanizmul de extindere. i anume, utilizarea stereotipuri adugtoare pentru unele componente netipice sau valorile marcate pentru precizarea unor caracteristici a lor. n sfrit trebuie de atras atenia c diagrama de componente este, ca regul, elaborat cu diagrama de plasare, care reprezint informaia despre deplasarea fizic a componentelor sistemului a programei dup nodurile ei. Particularitile construirii diagramei de plasare vor fi definite n capitolul urmtor.
67
n al doilea rnd, integrarea sistemului de programare cu Internet definete necesitatea deciziei ntrebrilor adugtoare n timpul proiectrii sistemului n aa fel ca asigurarea securitii, ... i accesul stabil la informaie pentru clienii corporativi. Aceste aspecte depind mult de realizarea proiectului n form de noduri a sistemului, care exist fizic, aa ca serveri, centralele funcionale, brandmauzeri, canale de conectare i pstrrile de date. Tehnologiile de acces i de manipulare a datelor n schema general clientul-server tot trebuie de amplasat baze de date mair n diferite segmente de reelei corporative, copierea lor rezerv, arhivarea pentru garantarea producerii necesare a sistemului. Aceste aspecte tot necesit reprezentarea vizual pentru specificarea particularitilor tehnologice i de programare a realizrii arhitecturei distribuite. n capitolul 9 prima diagrama reprezentrii fizice este diagrama de componente. Al doilea form de reprezentarea fizic sistemului de programare este diagrama de plasare. Ea este utilizat pentru reprezentarea general configurarei i topologiei sistemului de programare distribuite i conine repartizarea componentelor dup nodurile a sistemului. Pe lng c diagrama de plasare indic prezint legturile fizice rutele de transfer a informaiei ntre echipamente, utilizate n realizarea sistemului. Diagrama de plasare este specific pentru vizualizarea elementelor i componentelor a programului, ce exist numai la etapa executrii lui (runtime). n urma cruia sunt prezentate numai componente exemplare a programului, care sunt fiiere de executare sau librriile dinamice. Acele componente, care nu sunt utilizate la etapa executrii, n diagrama de plasare nu sunt indicate. Componente cu texte iniiale a programului pot fi numai n diagrama de componente. n diagrama de rezervare nu sunt indicate. Diagrama de rezervare conine reprezentarea grafic a procesorilor, echipamentelor, proceselor i legturilor ntre ele. n deosebire de diagrama reprezentrii logice, diagrama de plasare este un sistem unic, deoarece trebuie s desfoare toate particularitile realizrii ei. Aceast diagram finalizeaz procesul pentru un sistem concret de programare i elaborarea ei este ultima etapa de specificarea a modelului. Aadar, enumrm scopurile, ce sunt urmrite n timpul elaborrii diagramei de plasare:
De definit distribuirea componentelor a sistemului dup nodurile fizice. De prezentat legturile fizice ntre toate nodurile de realizare a sistemului la etapa de executare. De a gsi locurile nguste a sistemului i de a reconfigura topologia ei pentru atingerea producerii necesare. Pentru garantarea cerinelor diagramei de plasare se elaboreaz mpreun cu analistele a sistemului, ingineri de reele i altele. Apoi vom examena elemente din care sunt coninute diagramele de plasare.
10.1. Nod
Nodul (node) reprezint un anumit element fizic a sitemului, care are o anumit resurs de calculare. Ca resurs de calculare a nodului poate fi o valoarea electronic sau magnitioptic a memoriei sau procesorului. n ultima versiune a limbajului UML definiia nodului este extins i pot conine nu numai echipamente pentru calculare, dar i mprimant, modemuri, camere digitale, scanere i altele.
68
Adnotare Posibilitatea de a include oamenii (personal) n definiia nodului d posibilitate de a crea mijloacele limbajului UML modele a diferitor sisteme, inclusiv bisnes procese i complexe tehnice. Realizarea business logicei ntreprinderii trebuie de examinat n calitate de noduri a sitemului, subdiviziunele organizatorice, care este compus din personal. Automatizarea conducerii complexurilor tehnice trebuie de examinat ca element independent omul operator, care are posibilitate de a accepta deciziile n situaii complicate i de a purta rspunderea pentru diferite consecine a deciziilor lui. Reprezentaea grafic a nodului n diagrama de plasare este n form de cub trigonometric. Nodul are un propriu nume, care este indicat nuntrul acestui simbol grafic. Nodurile pot fi prezentate n form de tipuri (fig. 76, a), dar i n calitate de exemplare (fig. 76, b).
Fig. 76. Reprezentarea grafic a nodului n diagrama de plasare. n primul caz numele nodului este scris fr subliniere i ncepe cu majuscul. n al doilea caz numele nodului exemplar este scris n form de <numele nodului ':' numele tipului nodului>. Numele tipului nodului indic specia nodurilor, ce se afl n modelul sistemului. De exemplu, partea de aparat a sistemului poate fi compus din cte-va calculatoare, fiecare din cre corespunde nodului exemplar n model. Totui toate nodurile exemplare sunt legate cu un tip de noduri, anume nodul cu numele de tip Calculator. n desenul precedent (fig. 76, a) nodul cu numele Server se refer la tipul general i nu se concretizeaz. Al doilea nod (fig. 76, b) este nodul exemplar anonim a modelului concret a imprimantei. La fel ca n diagrama de componente reprezentarea nodurilor poate fi extins pentru includerea informaiei adugtoare despre specificarea nodului. Dac informaia adugtoare este legat cu numele nodului, atunci ea este scris mai jos de nume ca valoare marcat (fig. 77).
Fig. 77. Reprezentarea grafic a nodului exemplar cu informaie adugtoare ca valoare marcat. Dac este necesar de indicat componentele, care sunt deplasate n nodul separat, atunci pentru aceast exist dou moduri. Primul din ei d posibilitate de a mpri simbolul grafic n dou secii 69
cu linie orizontal. n seciunea cea de sus este scris numele nodului, iar n cea de jos- componente deplasate la nodul dat (fig. 78, a). Al doilea mod permite deplasarea n diagrama de plasare nodurile cu componentele depuse (fig. 78, b). Ca componente depuse pot fi numai componentele executante.
Fig. 78. Reprezentarea grafic a nodurilor exemplare cu componentele deplasate. Ca adugare la numele nodului pot fi utilizate diferite stereotipuri, care specific destinaia nodului. Dei n limbajul UML stereotipuri pentru noduri nu sunt specificate, n literatur exist urmtoarele variante: procesorul, modem, reea i altele, care pot fi specificate de elaborator. Mai mult dect att, n diagramele de plasare pot fi indicaii speciale pentru diferite echipamente fizice, reprezentarea grafic clarific destinaia sau funciile lor. Adnotare Vorbind despre reprezentri grafice adugtoare pentru nodurile diagramei de plasare au n vedere evidena lor n prezentare. De exemplu, procesorul poate fi prezenat ca un nod general (Fig. 11.1) i ca interfaa calculatorului. n mod corespunztor, consoli pot fi prezentate n mod de tastatur. Elaboratorul trebuie s aib adugtor i nsuiri creatoare.
10.2. Conexare
Pe lng reprezentarea nodurilor n diagrama de plasare sunt indicate relaiile ntre ele. n calitate de relaii sunt conectri fizice ntre noduri i dependena ntre noduri i componente, reprezentarea crora poate fi n diagramele de plasare. Conectrile sunt un fel de asociere i sunt prezentate n form de linii fr sgei. Prezena liniei indic necesitatea organizrii canalului fizic pentru schimbarea informaiei ntre nodurile respective. Caracter de conectare poate fi adugtor specificat de adnotare, indicat de valoare sau restricie. n fragmentul prezentat mai jos n diagrama de plasare (fig. 79) sunt specificate nu numai cererea la viteza de transfer a datelor n reea local cu ajutorul valorii indicate, dar i recomandarea la tehnologia fizic a realizrii conexelor n form de adnotare.
n afar de conectri n diagrama de plasare pot fi relaiile de dependen ntre nod i componentele lui. Acest caz este alternativ pentru reprezentarea componentelor depuse nuntrul simbolului al nodului, ce nu este ntodeauna comod, deoarece simbolul devine valoros. De aceea cnd exist mulimea de componente desfurate n nod, o informaie respectiv poate fi reprezentat n fel de relaie de dependen (fig. 80). Diagrama de plasare poate avea o structur mai compus, care include componentele, interfee i alte echipamente. n diagrama de plasare mai jos (fig. 81) este prezentat fragmentul reprezentrii fizice a sistemului serviciului ndreptat pentru clienii bncii. Nodurile acestui sistem sunt terminalul ndreptat (nodul - tip) i serverul bncii (nodul - exemplar).
Fig. 80. Diagrama de plasare cu relaia de dependen ntre nod i componenii desfurrii n el.
Fig. 81. Diagrama de plasare pentru sistemul serviciului ndreptat clienelor bncii. n aceast diagram de plasare este indicat dependena componentul de realizare a dialogului dialog.exe n terminalul ndreptat de la interfaa Iuthorise, realizat de componenii main.exe, care la rndul su se desfoar la nodul exemplar anonim Serverul bncii. Ultimul depinde de componentul bazei de date Clienii bncii, care de asemenea este desfurat la acest nod. Adnotarea indic necesitatea utilizrii liniei protejate de comunicare pentru schimbarea datelor n sistemul dat. Alt variant a acestei notaii a informaiei este n adugarea nodului n diagrama cu stereotipul reea inchis. Elaborarea sistemelor depuse presupune nu numai crearea codului programului, dar i coordonarea totalitii de mijloace de aparate i echipamente macanice. Ca exemplu, vom urmri fragmentul modelul de conducere a mijloacelor mecanice ndreptate de tip platformei de transport. Aceast platform este specificat pentru deplasarea n regiunele de agresiune, unde prezena omului este imposibil n urma cazurilor fizice.
71
Platforma de transport are un propriu microprocesor, camer digital, cu indicatoare de temperatur i amplasament, de asemenea dispozitiv de conducere pentru schimbarea direciei i vitezei de deplasare a platformei. Informaie de conducere i telemetric de la platform dup linii radio este transferat n centrul de conducere, dotat cu calculator de conducere, manipulatoare de conducere i un tablou mare de informaie. n microprocesor platformele sunt desfurate componentele de program pentru realizarea influenei simple de conducere la dispozitive, ce permite de a schimba discret direcia i viteza de deplasare a platformei. n calculator centrele de conducere sunt desfurate componentele de program a analizei informaiei telemetrice, care caracterizeaz starea unor echipamente a platformei i sunt realizate algoritmele conducerii deplasrii platformei. Varianta reprezentrii grafice acestui sistem de transport este prezentat n urmtoare diagrama de plasare (fig. 82).
Fig. 82. Diagrama de plasare pentru modelul sistemului de conducere a platformei de transport. Diagrama dat conine informaia general despre desfurarea sistemului i n continuare poate fi detalizat n timpul elaborrii componentelor de conducere a programului. Este evident din desen c n timpul elaborrii acestui program de plasare sunt utilizai steriotipul adugtor receptoremitor, care lipsete n descrierea limbajului UML i descriere special pentru care-va echipamente mecanice.
72
deplasate, atunci aceast situaie trebuie s fie exclus prin introducerea n modelul nodutilor adugtori, care conin procesorul i memorie. n timpul elaborrii programelor simple, care sunt executate local n un calculator aa ca n cazul de diagrama de componente necesitatea n diagrama de plasare pot lipsi deloc. n cazurile mai compuse diagrama de plasare este construit pentru aa restricii ca:
Modelarea sistemelor de programare, ce realizeaz tehnologie de acces la datele clientserver. Pentru aa fel de sisteme este caracter divizare strict a puterilor i respectiv componentelor ntre stanii lucrtoare a clienilor i serverul bazei de date. Posibilitatea realizrii clienelor fine n terminalele sau organizarea accesului la depozitul de date duce la necesitatea preciziei nu numai topologiei sistemului,dar i la coninutul componentelor . Modelarea arhitecturilor desfurate diferite. Aceast este despre intrareelele corporative,ce conin sute de calculatoare i altor echipamentelor pereferice, care funcioneaz n diferite platforme i sub diferite sisteme operaionale. n urma cruia unele noduri sistemului acest au distana ntre sine sute de kilometre (filialele companiei). n cazul acest diagrama de plasare devine un instrument important de vizualizare topologiei generale a sistemului i controlului migraiei unor componente ntre noduri. n sfrit, sistemele cu microprocesoare, care pot funciona autonom. Aa fel de sisteme pot conine diferite echipamente adugtoare, care garanteaz autonomia funcionrii lor i rezolvarea problemelor. Pentru aceste sisteme diagrama de plasare d posibilitate de a vizualiza coninutul acestor echipamente i intreconexiunea lor n sistemul.
Ca regul, elaborarea diagramei de plasare este realizat la etapa final a OOAP, ce caracterizeaz sfiritul fazei de proiectare reprezentrii fizice. Din alt parte, diagrama de plasare poate fi construit pentru analiza sistemului respectiv cu scopul analizei i modificrii urmtoare. n urma cruia analiza presupune elaborarea acestei diagrame la etapa ei iniial ,ce caracterizeaz direcia general analizei de la reprezentarea fizic la logic. n timpul modelrii busines-proceselor diagrama de plasare n afar de calculatoare reelei corporative poate conine n calitate de noduri diferite mijloace a orgtehnicei (fax, staii multicanale de telefon). n urma cruia fiecare din echipamente respective poate funciona autonom i n structura reelei corporative. Dac este necesar de introdus n model surs de Internet, atunci n diagrama de plasare Internet reprezint norul cu numele respectiv. Aceast indicare nu este specificat n limbajul UML, totui ea este rar utilizat n timpul elaborrii modelelor a sistemelor desfurate. n sfrit este necesar de a nota o situaie important, caracter elaborrii tuturor diagramelor canonive. Dei n limbajul UML este definit notarea grafic pentru toate elemente a diagramelor canonice, metode de reprezentare grafic a unor mijloacelor instrumentale au particularitile specifice. Utilizarea CASE- mijloc instrumental duce la restricie la vizualizarea modelelor sistemelor de programare. Merge vorba despre aceea c, unele elemente a limbajului UML pot lipsi n CASE mijloace. Ieirea din aceast situaie poate fi legat ori cu alegearea altui instrument, ce susine ultimile versiuni a limbajului UML, ori simplificarea modelului la baza de tipizrii ei. n capitolul 12 care-va din aceste aspecte vor fi desfurate mai detaliat n exemplul CASE mijloace Rational Rose 98/981.
73