Documente Academic
Documente Profesional
Documente Cultură
Introducere, generaliti
Cuvintele sunt cu adevrat mijlocul de comunicare cel mai puin eficient. Ele sunt cele mai expuse la interpretri greite i cel mai adesea prost nelese. Neale Donald Walsch
Dac din cauza complexitii piesei, cele trei fotografii nu sunt suficiente, inginerul va desena i alte detalii, sau seciuni ale piesei, dar privite din aceleai trei unghiuri. Fiecare dintre cele trei puncte de vizualizare a piesei (noi le vom zice neao, view-uri) reprezint un submodel capabil s descrie o parte a piesei, dar insuficient pentru a descrie complet piesa. Fiecare view arat piesa vzut dintr-un anumit punct de vedere iar modelul complet utilizeaz toate punctele de vedere relevante. Aa cum inginerul proiectant comunic prin desen tehnic, echipei, sau oricrei alte persoane interesate ntr-un limbaj standard, vizual (adic desenul tehnic), fcut s permit descrierea complet dar, n acelai timp, scutit de detalii inutile, inginerii software pot comunica cu maxim eficien n limbajul UML. La fel ca oricare limbaj acesta trebuie nvat i exersat astfel nct fiecare cuvnt s fie neles, s tim unde i cum se folosete, astfel nct s ne putem exprima n fraze coerente, care s spun exact ceea ce vrem s comunicm. Limbajul UML ne permite realizarea mai multor view-uri, ca nite fotografii din diverse unghiuri, ale unei realiti, astfel nct aceast realitate s fie surprins prin toate aspectele ei relevante. n software vom utiliza dou puncte de vedere necesare unei descrieri suficiente a realitii: (1) structural i (2) comportamental (behavioral). n standardul UML, versiunea 1.4 sunt definite urmtoarele diagrame, pe cele dou categorii: a. pentru descrierea structural: - Class Diagram; - Object Diagram; - Component Diagram; - Deployment Diagram. b. pentru descrierea comportamental: - Use Case Diagram; - Activity Diagram; - Statechart Diagram; - Sequence Diagram; - Collaboration Diagram. Deoarece aceast carte nu este un manual de UML, n continuare voi descrie succint doar acele diagrame care am considerat c sunt cele mai utile pentru analist. Pentru restul, las dumneavoastr plcerea studiului.
Use Case
Asocierea este utilizat pentru a indica legtura dintre un Actor i Asociere un Use Case, n sensul c acel actor particip ntr-un fel oarecare n acel Use Case.
ntre actori i use case-uri pot s existe relaii de generalizare / specializare atunci cnd un actor sau un use case poate fi asimilat unei clase de actori, respectiv de use case-uri.
Relaia de tip extensie ntre use case-uri Relaiile de tip extensie (i implicit use case-urile de extensie) se folosesc atunci cnd se modeleaz un comportament opional sau excepional, care nu condiioneaz finalitatea use case-ului de baz. De exemplu, un utilizator poate, n cazuri excepionale s aleag s depun o reclamaie dup efectuarea unei comenzi:
Relaia de tip includere Relaia de tip includere se folosete atunci cnd use case-ul inclus nu este o parte esenial a fluxului din use case-ul de baz sau este un comportament care se repet n mai multe use case-uri. De pild autentificarea n sistem, dei condiioneaz introducerea unei comenzi, nu este specific introducerii comenzii i de asemenea, poate fi folosit n mai multe use case-uri:
Activity Diagram
Activity Diagram reprezint o modalitate de modelare vizual a fluxurilor. Cu ajutorul activity diagram pot fi modelate foarte bine use case-urile, dar, n aceeai msur, aceste diagrame pot fi folosite pentru modelarea proceselor de business (fr legtur cu sistemul informatic). n privina notaiilor, acestea sunt foarte asemntoare cu cele din statechart diagram deoarece activity diagram nu sunt altceva dect o variaie a statechart diagram. Elementele utilizate i notaiile lor sunt urmtoarele: Element Activitate Descriere Notaie
Prin activitate vom desemna ntreaga activitate modelat prin diagram (format dintr-o succesiune de aciuni). Aceasta corespunde unui task de business. Teoretic, aciunile sunt numite activity states i reprezint o aciuni desfurate n cadrul unui task, sau, privite altfel, aciuni ale unui obiect.
Aciune
Reprezint punctul de intrare n activitatea Stare iniial respectiv. Punctul iniial este unic i din el pornete ntotdeauna o singur tranziie.
Reprezint punctul de ieire din activitate. Pot fi mai multe puncte de ieire dintr-o activitate. La ncheierea unei aciuni se trece ntotdeauna la o alt aciune sau la starea final. Tranziia reprezint trecerea de la o aciune la alta. Printr-o decizie (sau punct de decizie) se modeleaz un punct din cadrul fluxului unde se face o alegere, pe o anumit ramur din flux. n acest caz tranzaciile de ieire trebuie s fie de tip condiie. Aceeai notaie se folosete i pentru reunirea fluxurilor dup o decizie precedent (caz n care nu mai sunt necesare condiiile). Este un tip special de tranziie, utilizat la fiecare dintre ieirile posibile dintr-o decizie. Se marcheaz ca un text pe sgeat i arat condiia care trebuie ndeplinit pentru a urma acel flux.
Decizie
Condiie (guard)
Este folosit pentru cazurile n care anumite aciuni se pot desfura n paralel. ntr-un asemenea punct poate avea loc fie separarea fluxurilor, fie reunirea Bara de lor, dup o separare anterioar. Reunirea a dou sincronizare fluxuri nseamn, de fapt, introducerea unei condiii, prin care o activitate nu poate ncepe dect dup terminarea activitilor finale din fluxurile ce trebuie sincronizate (de aici termenul de sincronizare). Culoar (swimlane) Culoarele sunt reprezentri care permit separarea activitilor din flux dup criteriul responsabilitii realizrii activitii.
Punctele de decizie sunt puncte din fluxul de activiti n care se face o anumit alegere ntre mai multe variante posibile. Un caz simplu este ilustrat n figura de mai jos.
Trebuie observat c tranziiile care ies dintr-un punct de decizie sunt de tip guard au nscris ntre paranteze ptrate o condiie. Notaia utilizat pentru punctul de decizie poate fi folosit i pentru reconectarea fluxurilor (merge point), aa cum se poate vedea n figura de mai jos.
Aciunile paralele (asincrone) sunt aciuni care pot desfura n paralel. n viaa real, aceste aciuni sunt aciuni care nu depind una de cealalt. Paralelizarea aciunilor se reprezint pe diagram n felul urmtor:
Aceast reprezentare ne arat c aciunile Verificare stoc i Verificare bonitate client sunt declanate de apariia unei comenzi de la client i c aceste aciuni sunt independenta ntre ele (nceperea uneia nu depinde de rezultatul celeilalte). Revenirea la fluxul unic (cu aciuni sincronizate) se face n felul urmtor:
Aceast reprezentare ne arat c livrarea la client depinde de finalizarea aciunilor independente "Verificare stoc" i "Verificare bonitate client", astfel c aciunea "Livrare la client" nu poate ncepe dect dup finalizarea ambelor aciuni. Pentru a aduga pe diagrame informaia privind responsabilitatea executrii aciunilor se folosesc elementele denumite swimlanes, plasndu-se fiecare aciune pe "culoarul" actorului care execut acea aciune.
n afara elementelor specifice enumerate mai sus se pot folosi punctele de decizie i aciunile paralele (asincrone) la Activity diagram. n figura de mai jos este exemplu de folosire a elementelor specifice statechart diagram, pentru cazul unei comenzi:
Pentru mai multe detalii pentru interpretarea acestei diagrame se gsesc (din motivul similaritii cu exemplele explicate acolo) n articolul despre Activity Diagram
Clas
O clas este reprezentat printr-un dreptunghi cu trei compartimente: n cel de sus se trece numele clasei, n mijloc se trec atributele clasei iar jos se trec operaiile specifice clasei. Motenirea este o relaie care indic faptul c o clas motenete caracteristicile unei clase printe. Sensul sgeii indic sensul n care se poate spune despre clasa copil c este o<-i>, sau este de tipul<-i> clas printe. Asocierea este o relaie generic ntre dou clase. Aceste relaii pot fi de tipurile pot defini i regulile numerice de asociere (unu la unu, unu la mai muli, mai muli la mai muli).
Motenire
Asociere
Atunci cnd o clas depinde de o alt clas, n sensul Dependen c utilizeaz acea clas ca i atribut al su, se folosete relaia de dependen. Agregarea indic o relaie de tip ntreg-parte (se poate spune despre clasa printe c are clase de tip copil). n aceast relaie, clasa copil poate exista i fr clasa printe.
Agregare
Aceast relaie deriv din agregare dar se utilizeaz Compoziie atunci cnd o clas copil nu poate exista dect n cazul existenei clasei printe. n reprezentarea clasei atributele i operaiile sunt declarate n compartimentele speciale din dreptunghi, astfel: - atributele:
numele atributului : tipul atributului = valoare implicit
- operaiile:
Atunci cnd diagrama este folosit pentru a modela structuri de business se pot folosi tipurile de date specifice business-ului, nu programrii, de exemplu: minut, dat calendaristic, minut etc.
Motenirea este o relaie prin care se indic faptul c o clas motenete caracteristicile
Asocierea arat existena unei relaii ntre clase. n exemplul de mai jos, ntre Persoan i Autovehicul urmtoarea relaie: o Persoan poate avea zero, unul sau mai multe Autovehicule.
Un tip special de asociere este indicat printr-o clas de asociere. Altfel spus, relaia n sine este o clas. n exemplul de mai jos, relaia dintre Articol i Lista de preuri este de tip mai muli la mai muli: un Articol poate s apar pe mai multe Liste i o List poate avea mai multe Articole. Pe Liste diferite Articolele pot avea preuri diferite.
Dependena indic faptul c o clas depinde de alt clas, n sensul n care o funcie oarecare depinde de un parametru al su.
Agregarea indic faptul c o clas printe are elemente de tipul clasei copil. n exemplul de mai jos ara poate avea mai multe Judee dar, n acelai timp, un Jude poate exista chiar i n cazul n care clasa ara nu exist.
ntr-o relaie de tip compoziie clasa copil nu poate exista dect dac exist o instan a clasei printe. n exemplul de mai jos instana clasei Comisie exist atta timp ct exist instana clasei Examen.