Sintaxa i semantica limbajului de modelare UML

Alfabet i cuvinte
Alfabetul definete cele mai mici pri ale limbajului; UML este alctuit din simboluri (dreptunghiuri, linii i alte elemente grafice) i din iruri de caractere. Cuvntul este cea mai mic unitate semantic de limbaj. Un cuvnt este un grup format din elementele alfabetului, care are un neles. n UML, cuvintele sunt grupate n dou categorii mari: entiti sau concepte desemneaz o serie de abstracii i sunt reprezentate prin simboluri etichetate cu nume; relaiile dintre entiti desemneaz tipurile de legturi care pot exista ntre entiti. Ele sunt reprezentate prin linii de legtur ntre simboluri i au un nume. Cuvintele limbajului alctuiesc vocabularul limbajului.

Propoziii i paragrafe
Propoziiile UML sunt fragmente de diagrame sau diagrame simple .

O companie de asigurri are contract de asigurare cu o persoan. O persoan are un contract de asigurare cu o companie de asigurare.

Paragrafele UML se numesc diagrame. Sintaxa limbajului UML implic diagrame. ! Semantica limbajului UML se bazeaz pe paradigma orientrii pe obiecte.

n UML, diagramele fac parte din dou categorii: Diagrame statice sau structurale - descriu structura, responsabilitile

sistemului informatic, componentele executabile ale sistemului, locaiile fizice de execuie i nodurile de stocare a datelor. Din aceast categorie, fac parte diagrame ale claselor, ale obiectelor, ale cazurilor de utilizare, ale componentelor i diagrame de exploatare.
Diagrame dinamice sau comportamentale descriu comportamentul

i interaciunile dintre diverse entiti ale sistemului informatic. Din aceast categorie, fac parte diagramele de secven, de colaborare, de stare i de activitate.

A) Modelare structural (modelare static)

Se refer la vizualizarea, la specificarea, la construirea i la documentarea aspectelor statice ale unui sistem, adic la relaiile invariante dintre componentele unui sistem. Din punct de vedere al modelrii sistemelor orientate pe obiecte din perspectiva UML, aspectele statice sunt: clasele i relaiile dintre clase, interfeele, topologia hard necesar execuiei aplicaiei.

A1) Diagrama claselor (Class Diagram) Descrie structura unui sistem n general. n componena ei intr clase, stereotipuri i relaiile dintre acestea. Acest tip de diagrame este cel mai des ntlnit n modelarea sistemelor orientate pe obiecte. A2) Diagrama obiectelor (Object Diagram) Descrie structura unui sistem la un anumit moment. Acest tip de diagram este o variant a diagramei claselor, care, n locul unei clase, prezint mai multe instane ale ei i este format din obiecte i relaiile (legturile) dintre ele. Este folosit n exemplificarea unei diagrame a claselor de complexitate mare, permind vizualizri statice ale instanelor actuale i ale relaiilor.

A3) Diagrama cazurilor de utilizare (Use Case Diagram) Descrie funcionalitatea unui sistem. Prezint actorii externi, cazurile de utilizare identificate numai din punct de vedere al actorilor (comportamentul sistemului, aa cum este perceput de utilizatorii lui), nu i din interior, precum i relaiile dintre actori i cazurile de utilizare. Un actor poate fi orice sau oricine interacioneaz cu sistemul (trimite sau recepioneaz mesaje de la sistem sau schimb informaii cu acesta). Actorul are un rol n cadrul unui sistem, nu este un utilizator individual al acestuia, i din acest motiv, el este o entitate (o clas), nu o instan. Un caz de utilizare este iniiat mereu de un actor i furnizeaz o valoare actorului. Diagramele cazurilor de utilizare reflect modul static de vizualizare a cazurilor de utilizare asupra sistemului (diferite tipuri de relaii ntre cazurile de utilizare), dar i modul de organizare i de modelare a comportamentului unui sistem.

A4) Diagrama componentelor (Component Diagram) O diagram a componentelor, cunoscut i sub numele de diagram de implementare, descrie structura fizic a codului n termenii componentelor de cod i relaiile dintre acestea. Acest tip de diagram realizeaz o mapare de la view-ul static (logic) la view-ul componentelor. O component poate s conin un cod surs sau s fie sub form binar sau executabil. O component se mapeaz, de obicei, pe una sau mai multe clase, interfee sau colaborri; din aceast cauz, diagrama componentelor are legtur cu diagrama claselor. Diagramele de componente reflect vederea static de implementare asupra sistemului. 5) Diagrama de desfurare (Deployment Diagram) Diagrama de desfurare indic arhitectura fizic pe care este implementat sistemul, calculatoarele, device-urile (noduri ale sistemului) i conexiunile dintre ele.

B) Modelare dinamic (modelare comportamental)

B1) Diagrama de interaciune (Interaction Diagram) Descrie interaciunile n timp ntre obiecte, relaiile i mesajele care circul ntre acestea. Diagramele de interaciune reflect vederea dinamic de design i de proces. Pot fi: a) Diagrama de secven b) Diagrama de colaborare a) Diagrama de secven (Sequence Diagram) - Prezint colaborarea dinamic dintre un numr de obiecte, punnd accentul pe secvene de mesaje trimise ntre acestea pe msura scurgerii timpului. - Au dou axe: timpul, pe axa vertical, i setul de obiecte, pe axa orizontal. a) Diagrama de colaborare (Collaboration Diagram) - Este o diagram de interaciune, dar, pe lng interaciunea dintre obiecte (schimbul de mesaje), prezint i obiectele i legturile dintre ele. Cnd trebuie s decidem ce tip de diagram trebuie folosit pentru a ilustra o interaciune, avem n vedere aspectul cel mai important de evideniat. Obs. Se vor folosi diagramele de secven dac cel mai important aspect este timpul sau secvena de mesaje i vom folosi diagramele de colaborare cnd trebuie evideniat contextul.

B2) Diagrama de stare (State Diagram) Descrie ciclul de via al unui element (al obiectelor, al subsistemelor i al sistemelor), prin specificarea strilor n care se gsete un element i a evenimentelor (mesaje, erori, condiii care devin adevrate) care i modific starea (tranziie). Obs. Este indicat s se construiasc diagrame de stare numai pentru clasele din sistem care au un numr de stri bine definit i n care comportamentul clasei este influenat de acestea. Aceste diagrame intr n modurile de vizualizare design i de proces asupra sistemului. B3) Diagrama de activitate (Activity Diagram) Prezint activitile i responsabilitile elementelor sistemului. Diagramele de activitate au ca elemente constitutive stri de aciune (Action States) i mesaje care vor fi trimise sau recepionate ca parte a aciunii realizate. Reflect vederea dinamic de design i de proces i sunt utilizate pentru modelarea funciilor sistemului.

Seciuni (Views)
Seciunile UML sunt perspectivele arhitecturale sau modurile de vizualizare (arhitectural views). Din punct de vedere gramatical, ele sunt formate din mai multe paragrafe. Obs. Un model UML descrie ce trebuie s fac un sistem, nu cum s se implementeze sistemul. Seciunile UML sau modurile de vizualizare sunt grupuri de diagrame care se adreseaz unei anumite mulimi de concepte (entiti). Modelul captureaz cunotine i le comunic sub form de mod de vizualizare sau, pe scurt, view (arhitectural views). Fiecare view focalizeaz atenia echipei de realizatori asupra unui anumit tip de probleme i de aspecte privind subiectul tratat i se adreseaz unei categorii speciale de firme sau de instituii. Un sistem poate fi descris lund n considerare urmtoarele aspecte: funcional - este descris structura static i comportamentul dinamic al sistemului; non-funcional - necesarul de timp pentru dezvoltarea sistemului; organizatoric - organizarea lucrului, maparea modulelor de cod.

Elementele care construiesc un view se numesc elemente de vizualizare (view elements). Fiecare view este descris folosind un numr de diagrame care conin informaii referitoare la un anumit aspect particular al sistemului. Aceste view-uri se acoper unele pe altele, deci este posibil ca o anumit diagram s fac parte din mai multe view-uri.

V1) Modul de vizualizare cazuri de utilizare (The use-case or user view) Acest view surprinde funcionalitatea sistemului, aa cum este ea perceput de actorii externi care interacioneaz cu sistemul, precum i de utilizatorii acestuia, de diferii membri ai echipei realizatoare sau de alte sisteme. n componena lui intr diagramele cazurilor de utilizare pentru descrierea static a aspectului funcional i ocazional. Se pot folosi i diagrame de activitate pentru a ncapsula latura dinamic a funcionalitii. Cei interesai de aceast perspectiv sunt clienii, designerii, dezvoltatorii i cei care vor testa i vor valida sistemul realizat.

V2) Modul de vizualizare structural sau logic sau design (The structural or logic or design view) Se refer la cerinele funcionale ale acestuia, adic prezint serviciile asigurate de sistem utilizatorilor si. Vizualizarea logic trateaz din interior sistemul i descrie att structura intern a acestuia, format din clase, obiecte i relaii, ct i colaborrile care apar n urma schimbului de mesaje ntre obiecte, pentru a realiza funcionalitatea dorit. Structura static este descris de diagramele de clas i de obiecte, care includ elementele i relaiile care alctuiesc sistemul. Pentru modelarea dinamicii sistemului, se vor folosi diagrame de stare, de secven, de colaborare sau de activitate. Cei care sunt interesai de acest tip de vizualizare a sistemului sunt designerii i dezvoltatorii.

V3) Modul de vizualizare componente sistem sau implementare (The implementation or component view) View-ul componentelor se concentreaz pe descrierea componentelor care implementeaz sistemul, dependenele care exist ntre ele, resursele alocate acestora, precum i rezolvarea unor probleme legate de reutilizarea, portabilitatea codului, informaii administrative, cum ar fi un desfurtor al muncii de dezvoltare. Este folosit de dezvoltatorii sistemului, iar n componena sa intr diagramele de componente, care descriu cum este implementat sistemul. V4) Modul de vizualizare comportamental sau dinamic sau proces sau concuren (The behavioral or dinamic or process or concurent view) Acest mod de vizualizare ia n considerare cerinele de performan, de fiabilitate, de utilitate, etc. Pentru descrierea comportamentului i a dinamicii sistemului, se folosesc diagramele de stare, de secven, de colaborare i de activitate. n reprezentarea acestui mod de vizualizare a sistemului, se folosesc i diagramele de implementare (ale componentelor). Cei interesai de o astfel de vizualizare a sistemului sunt dezvoltatorii i interogatorii de sistem.

V5) Modul de vizualizare desfurare sau mediu (The deployment or environment view) n acest mod de vizualizare sunt surprinse desfurarea fizic a sistemului, ce calculatoare i ce tipuri de device-uri (noduri) vor fi folosite pentru implementarea sistemului, cum sunt acestea conectate, precum i ce componente (procese) se vor executa n fiecare nod. Acest tip de vizualizare este reprezentat cu ajutorul unor diagrame de desfurare, care indic modul de implementare a sistemului. n acest sens, ele poart etichete care specific repartizarea pe tipuri de activitate i informaii despre procesele executate n noduri. De acest tip de vizualizare sunt interesai dezvoltatorii, interogatorii de sistem, precum i cei care realizeaz testarea sistemului.

Documente (Modele)
Un document este format dintr-un numr de seciuni care descriu un subiect comun i pot fi cri, articole etc.

Documentele UML sunt modele. Un model este o reprezentare a unui sistem. View-urile (seciunile) sunt grupate formnd modelul (documentul) arhitectural al sistemului studiat.

Pentru paradigma de modelare UML, cel mai adecvat este modelul de dezvoltare a sistemului dirijat de cazurile de utilizare, centrat pe arhitectur, iar abordarea este iterativ sau cascad.

Pachete (Packages)
Un pachet reprezint un mecanism de grupare a elementelor de modelare. n UML, un pachet definete un mecanism de organizare a elementelor n grupuri legate semantic. Rezult c un element de modelare nu poate fi prins n mai multe pachete, dar un pachet poate importa elemente de modelare din alte pachete, iar dup import le consider ca i cnd ar fi proprietatea lui. Putem stabili relaii ntre pachete, dar numai ntre tipuri, nu i ntre instane (pachetele nu au semantic definit de instane). Un pachet poate s aib vizibilitate, ca i clasele, prin care se precizeaz modalitatea prin care alte pachete pot s-i acceseze coninutul. Un pachet poate s aib o interfa care i red comportamentul.

Note (Notes)
O not cuprinde ipotezele i deciziile aplicate n timpul analizei i al proiectrii. Notele sunt corespondentul comentariilor din limbajele de programare. Notele pot conine orice informaie, inclusiv fragmente de cod sau referiri la alte documente, i se pot folosi n orice tip de diagrame. Ele se reprezint printr-un dreptunghi cu colul dreapta sus ndoit, n interiorul cruia se afl informaia dorit.

Nota este ataat unui element dintr-o diagram printr-o linie punctat. O not poate s nu fie conectat, dac aceasta se refer la ntreaga diagram.

Stereotipuri (Stereotypes)
Stereotipul este un concept introdus n UML, care permite extinderea elementelor de baz pentru a crea noi elemente. Un stereotip reprezint un neles specific asociat unui element. El se reprezint printr-un cuvnt ntre paranteze unghiulare duble (<< >>), scris deasupra sau dedesubtul numelui elementului asociat. Obs. Un stereotip transform un element n altul cu un neles nou. Exemplu. Dac se ataeaz stereotipul <<table>> clasei Examene, acesta va reprezenta o baz de date tabelar.

Proprieti
Proprietile sunt elemente de extindere UML, care lrgesc proprietile i semantica unui element UML. Ele se reprezint printr-o list de iruri de caractere ntre acolade ({ deasupra sau dedesubtul elementului UML. }), scrise

irurile de caractere care reprezint proprietile pot fi de dou forme: valoare etichetat (tagged value) - se exprim prin perechea "string = valoare" i reprezint caracteristicile unui element i valorile sale; constrngeri (constraints) - se exprim n OCL (Object Constraint Language) i reprezint condiiile pe care trebuie s le satisfac elementul. Exemplu. valorile etichetate ale clasei EXAMENE sunt versiunea i autorul, iar constrngerea este perioada de examene.

Reprezentarea grafic a elementelor de modelare

Reprezentarea grafic a elementelor de modelare (continuare)

Reprezentarea grafic a elementelor de modelare (continuare)

Procese software
- introducere -

Proces software

Because software, like all capital, is embodied knowledge, and because that knowledge is initially dispersed, tacit, latent, and incomplete in large measure, software development is a social learning process. The process is a dialogue in which the knowledge that must become the software is brought together and embodied in the software. The process provides interaction between users and designers, between users and evolving tools, and between designers and evolving tools [technology]. It is an iterative process in which the evolving tool itself serves as the medium for communication, with each new round of the dialogue eliciting more useful knowledge from the people involved. Howard Baetjer, Jr.

Ce este procesul software?

O hart a drumului ce trebuie urmat pentru construirea unui produs sau sistem, de calitate crescut i ntr-un timp dat.

Cine face procesul software?

Inginerii de sistem (software engineers) i managerii lor; sunt implicai i cei crora li se adreseaz.

De ce este important procesul software?

Deoarece dovedete stabilitate, control i organizare.

Care sunt paii?

Depind de software-ul pe care l construim.

Care este produsul muncii?

n ochii inginerului de sistem produsul este format din programe, documentaie i datele produse ca urmare a activitii de inginerie software definit de proces.

Proces software o tehnologie pe nivele

IEEE definete astfel Ingineria software: (1) Aplicarea unei abordri sistematice, disciplinate, cuantificabile asupra dezvoltrii, punerii n funciune i mentenanei software-ului (2) Studiul abordrilor de la (1).

Nivelul Proces: definete un cadru pentru o mulime de zone cheie de proces (key process areas). Aceste zone formeaz baza controlului managementului proiectului software i stabilete contextul n care sunt aplicate metodele tehnice, sunt obinute produsele muncii (modele, documente, date, rapoarte, forme etc.), sunt stabilite pietrele de hotar (milestones), e asigurat calitatea i se administreaz potrivit schimbrile. Nivelul Metode: rspunde la ntrebarea : Cum construim software-ul? i cuprinde un spectru larg de sarcini, care includ: analiza cerinelor, designul, construirea programului i testarea. Metodele de inginerie software includ activiti de modelare i alte tehnici descriptive. Nivelul Instrumente: furnizeaz suport automat pentru proces i metode. Cnd instrumentele sunt integrate, astfel nct informaiile create de un instrument s fie folosite de altul, se creeaz CASE (Computer Aided Software Engineering), care combin software, hardware i o baz de date a ingineriei software (ce conine informaii importante despre analiz, design, construcia programului i testare).

Modele de procese software

1) Modelul secvenial liniar 2) Modelul prototipului (prototyping model) 3) Modelul RAD 4) Modele pentru procese software evolutive a) Modelul incremental b) Modelul spiral c) Modelul spiral WINWIN d) Modelul de dezvoltare concurent

1) Modelul secvenial liniar (cascad)

Presupune activitile: i) Ingineria de sistem i modelarea: stabilirea cerinelor pentru elementele sistemului ii) Analiza cerinelor software: trebuie nelese comportarea software-ului, interfaa, performanele dorite etc.

iii) Design: e de fapt un proces n mai muli pai, ce se concentreaz pe : structura datelor, arhitectura software-ului, reprezentarea interfeei i detaliul procedural (algoritmic). iv) Generarea codului: care translateaz design-ul n program. v) Testarea: depistarea eventualelor erori (errors), defecte (faults) i eecuri (failures) Obs. Modelul cascad e cel mai vechi; apar ns problemele: Proiectele reale urmeaz rar acest model E foarte dificil pentru client s stabileasc cu exactitate cerinele O versiune care s poate fi prezentat poate veni dup mult timp Natura liniar a modelului poate conduce la stri de blocaj, cnd o echip implicat n proiect este nevoit s atepte rezultatele altor echipe

Obs. Modelul secvenial liniar e cunoscut n literatur sub denumirea classic life cycle.

2) Modelul prototipului Adesea, un client definete o serie de obiective pentru software, dar nu identific n detaliu cerinele de input, de procesare sau de ieire. n alte cazuri, dezvoltatorul poate s aib ndolieli cu privire la eficiena algoritmului, adaptabilitatea la un SO sau la forma de interaciune om/calculator. Pentru aceste e indicat acest model.

Clientul i dezvoltatorul se ntlnesc pentru a stabili obiectivele de ansamblu i a identifica oricare dintre cerinele care sunt cunoscute i a stabili zonele unde e obligatorie definirea lor ulterioar.

Se contureaz astfel un quick design, care se axeaz pe reprezentarea acelor aspecte ale software-ului care care sunt vizibile clientului (ex: ce anume se ateapt la input i formatul output-ului).

Apare un prototip. Prototipul e evaluat de client i folosit pentru a rafina cerinele.

Apare iteraia, care pune n acord cerinele clientului cu proiectul i ajut pe dezvoltator s neleag mai bine ce se dorete.

Ce facem cu prototipul dac ndeplinete condiiile? In most projects, the first system built is barely usable. It may be too slow, too big, awkward in use or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved . . . When a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers . . . (Brooks, F., The Mythical ManMonth, Addison-Wesley, 1975.)

Concluzie. Dei pot aprea probleme, modelul prototipului poate fi paradigma eficient pentru ingineria software.

3) Modelul RAD Rapid application development (RAD) e un model de proces de dezvoltare software incremental, care pune accentul pe ciclul de dezvoltare extrem de scurt. Modelul RAD e o adaptare high-speed a modelului secvenial liniar. Modelul RAD cuprinde urmtoarele etape: i) Business modeling. Fluxul informaiilor printre funciile business e modelat ntr-un mod ce rspunde la ntrebrile: Ce informaii conduc procesul de business? Ce informaii sunt generate? Cine le genereaz? Unde se duc informaiile? Cine le proceseaz? ii) Data modeling. Fluxul informaiilor ca parte a etapei de business modeling sunt rafinate ntr-o mulime de obiecte de date necesare pentru a susine business-ul.

iii) Process modeling. Obiectele de date obinute n etapa anterioar sunt transformate pentru a obine fluxul de informaii necesar pentru a implementa o funcie business. Descrierile de proces sunt create pentru adugarea, modificarea, tergerea i gsirea unui obiect de date. iv) Generarea aplicaiei. RAD presupune folosirea 4GT (fourth generation technique). Procesul RAD lucreaz pentru a refolosi componentele existente ale programului (unde se poate) sau pentru a crea componente reutilizabile. v) Testarea i predarea. Deoarece RAD ncurajeaz reutilizarea componentelor, multe dintre ele sunt deja testate, aa nct timpul total de testare este redus considerabil. Totui noile componente trebuie testate i toate interfeele trebuie atent verificate.

Fiecare funcie major e acoperit separat de o echip i apoi e integrat n ntreg. Concluzii Pentru proiecte mari, dar scalabile, RAD necesit resurse umane importante pentru a crea numrul corect de echipe RAD. RAD necesit dezvoltatori i clieni care se oblig la activiti rapide necesare pentru a obine un sistem complet ntr-un timp redus Nu toate aplicaiile sunt potrivite pentru RAD. Dac un sistem nu poate fi modularizat, construirea componentelor necesare pentru RAD devine problematic. RAD nu e potrivit cnd riscurile tehnice sunt mari. Acest lucru apare cnd o nou aplicaie folosete intens o nou tehnologie sau cnd un software nou cere un grad nalt de interoperabilitate cu programele existente.

Business modeling Scopul business process engineering (BPE) este s defineasc arhitectura ce va permite business s utilizeze eficient informaiile. Se analizeaz i se specific design-ul pentru Arhitectura datelor Arhitectura aplicaiilor Infrastructura tehnologic 1) Arhitectura datelor are ca blocuri constitutive obiectele de date (data object). Un obiect de date conine o mulime de atribute care descriu un anumit aspect, calitate, caracteristic a datelor ce sunt descrise.

Exemplu: obiectul Customer

O relaie (relationship) indic cum sunt conectate obiectele unul cu altul. Exemplu: pentru obiectele Customer i produsA, o relaie poate fi cumpr.

2) Arhitectura aplicaiei cuprinde acele elemente ale sistemului care transform obiectele n cadrul arhitecturii datelor pentru un anumit scop de business. 3) Infrastructura tehnologic asigur fundaia pentru arhitecturile datelor i aplicaiei. Cuprinde hardware-ul i software-ul care sunt folosite: computere, SO, reele, legturi de telecomunicaii, tehnologii de stocare i arhitectura (ex: client server). Pentru a modela arhitecturile descrise, se definete o ierarhie a activitilor ingineriei proceselor business. World view e obinut prin Information strategy planning (ISP). ISP vede ntreg ntregul business ca o entitate i izoleaz domeniile business-ului (ex: inginerie, manufacturare, marketing etc.). ISP definete obiectele de date care sunt vizibile la nivelul ntreprinderii i relaiile dintre ele . Domain view se obine cu o activitate a BPE numit business area analysis (BAA), care identific n detaliu datele (sub forma tipurilor entitilor, adic a obiectelor de date) i cerinele funciilor (sub forma proceselor) ale domeniilor de business n timpul ISP i stabilete interaciunile dintre ele.

Odat un information system izolat, BPE face o tranziie spre ingineria software. Invocnd pasul business system design (BSD), sunt modelate cerinele de baz ale unui information system i aceste cerine sunt translatate n arhitectur de date i de aplicaie i infrastructur tehnologic.

Data modeling Rspunde la un set de ntrebri specifice: Care sunt obiectele de date primare procesate iniial de sistem? Care e compoziia fiecrui obiect de date i ce atribute descriu obiectul? Unde stau n mod curent obiectele? Care sunt relaiile dintre obiecte? Care sunt relaiile dintre obiecte i procesele care le transform? Apeleaz la diagrama relaiilor dintre entiti (ERD Entity Relationship Diagram)

4GT (Fourth Generation Techniques) Termenul 4GT cuprinde o gam larg de instrumente software care au un lucru n comun: fiecare permite inginerului software s specifice anumite caracteristici ale software-ului la un nivel nalt. Instrumentul (tool) genereaz apoi automat cod surs bazat pe specificaiile dezvoltatorului. Paradigma 4GT pentru ingineria software pune accentul pe abilitatea de a specifica software folosind forme de limbaj specializat sau notaii grafice ce descriu problema propus spre rezolvare n termeni pe care clientul poate s-i neleag. n mod curent, un mediu de dezvoltare software ce suport paradigma 4GT include o parte dintre urmtoarele instrumente (tools): limbaje neprocedurale pentru interogrile bazei de date; capabiliti grafice de nivel nalt; capabiliti de tip spreadsheet; generare automat a HTML i a limbajelor similare folosite pentru crearea site-urilor Web utiliznd instrumente software avansate.

4GT (Fourth Generation Techniques) (continuare) Concluzii privind paradigma 4GT: 1) Folosirea 4GT e o abordare viabil pentru multe zone de aplicaii. Combinat cu alte instrumente CASE i generatoare de cod, 4GT reprezint o soluie de ncredere pentru multe probleme software. 2) Folosind 4GT, timpul necesar pentru producerea software-ului e mult redus pentru aplicaii mici i mijlocii i de asemenea efortul pentru design i analiz pentru aplicaiile mult e mult redus.. 3) Folosirea 4GT pentru dezvoltarea unui software complex necesit la fel de mult sau chiar mai mult munc pentru analiz, design i testri, n ciuda timpului salvat obinut din eliminarea codului.

4) Modele pentru procese software evolutive: sunt iterative, adic permit dezvoltarea cresctoare a unor versiuni din ce n ce mai complete ale software-ului. a) Modelul incremental: combin elemente ale modelului cascad (aplicat repetat) cu filozofia iterativ a modelului prototipului.

Fiecare secven liniar produce un increment livrabil al software-ului.

Exemplu : Software pentru editor de texte, poate livra managementul de baz al fiierelor i editarea la primul increment; editare mai sofisticat la al doilea increment; spelling i verificare gramatical n al treilea increment i capabiliti avansate de proiectare a paginii la al patrulea increment. Obs. Primul increment e adesea un miez al produsului (core product), adic cerinele de baz sunt ndeplinite, dar mai multe capabiliti (unele cunoscute, altele necunoscute) rmn nepredate. Acest core product e folosit de client. Ca rezultat al utilizrii sau al evalurii, se dezvolt un plan pentru urmtorul increment, care stabilete modificarea core product-ului pentru ndeplinirea mai bun a cerinelor clientului i furnizarea funcionalitilor adiionale. Acest proces e repetat dup livrarea fiecrui increment, pn se contureaz ntregul produs. Concluzii. Modelul incremental e iterativ (ca i modelul prototipului), dar se concentreaz pe livrarea unui produs operaional la fiecare increment. Versiunile iniiale nu se regsesc n produsul final, dar furnizeaz capabiliti nesecare utilizatorului. Modelul incremental e util cnd echipa de dezvoltatori nu e disponibil toat perioada. Core product-ul poate fi realizat cu mai puini oameni.

b) Modelul spiral: combin natura prototipului cu aspectele sistematice controlate ale modelului cascad. Software-ul e dezvoltat ntr-o serie de livrri incrementale. n timpul primelor iterri, livrarea poate fi un model pe hrtie sau un prototip. n timpul iterrilor ulterioare, sunt produse versiuni don ce n ce mai complexea sistemului.

Sunt ntre 3 i 6 task regions ntr-un proiect tipic.

Cele 6 regiuni reprezentate n figur sunt: Comunicarea cu clientul: tasks pentru stabilirea unei comunicri efective ntre dezvoltator i client Planificarea: tasks pentru definirea resurselor, a planificrilor temporale i a altor informaii n legtur cu proiectul Analiza riscurilor: tasks pentru stabilirea n egal msur a riscurilor ehnice i manageriale Tehnologia (engineering): tasks pentru construirea uneia sau a mai multor reprezentri ale aplicaiei Construirea i livrarea: tasks pentru construirea, testarea, instalarea i asigurarea suportului utilizatorului (ex: documentaie i training) Evaluarea clientului: tasks pentru obinerea unui feed-back din partea clientului, bazat pe evaluarea reprezentrilor software create n timpul etapei de engineering i implementate n timpul etapei de instalare

Echipa de dezvoltatori se mic n spiral n sensul acelor de ceasornic, ncepnd din centru. Primul circuit n jurul spiralei ajut la dezvoltarea specificaiilor produsului. Urmtoarele circuite ajut la dezvoltarea prototipului i apoi, progresiv, la versiuni mai sofisticate ale software-ului. Fiecare trecere prin dreptul zonei de planificare (planning region) produce rezultate n ajustarea planului proiectului. Costul i planificarea temporal sunt ajustate pe baza feedback-ului derivat din evaluarea clientului. Managerul proiectului ajusteaz numrul de iteraii necesare pentru a completa software-ul. Obs. Spre deosebire de modelele clasice, care se termin cu livrarea software-ului, modelul spiral poate fi adaptat pentru a fi folosit pe ntreaga durat de via a software-ului.

O privire alternativ asupra modelului spiral se obine examinnd axele punctelor de intrare n proiect (project entry point axis).

Fiecare cub plasat de-a lungul axelor poate fi utilizat pentru a reprezenta punctul de plecare pentru diferite tipuri de proiect. Un concept development project pornete de la miezul spiralei i continu pn ce devine complet dezvoltarea conceptului.

Concluzii Modelul spiral e o abordare potrivit pentru sistemele de mari dimensiuni. Modelul spiral folosete prototipul ca un mecanism de reducere a riscurilor dar, mai important, permite dezvoltatorului s aplice abordarea prototipului la orice etap din evoluia proiectului. Modelul spiral menine abordarea sugerat de ciclul de via clasic, dar o incorporeaz ntr-un cadru iterativ care reflect mai realist lumea. Modelul spiral cere luarea n calcul a riscurilor tehnice n toate etapele proiectului i, dac se aplic corect, ar trebui s reduc riscurile nainte s devin problematice. Modelul spiral nu este folosit aa cum se folosesc modelul liniar secvenial i modelul prototipului.

c) Modelul WINWIN Eliciting software requirements demands negotiation occurs when both sides win . negociation. Successful

Stakeholder = cineva din organizaie care are un interes de afaceri direct n construirea sistemului sau produsului i care va fi recompensat pentru succes i criticat pentru un eec. Modelul spiral al lui Boehm (Boehm, B., Using the WINWIN Spiral Model: A Case Study, Computer, vol. 31, no. 7, July 1998, pp. 3344) definete o serie de activiti de negociere la nceputul fiecrei treceri n jurul spiralei: 1. Identificarea stakeholders ai sistemului sau subsistemului. 2. Determinarea condiiilor de ctig (win conditions) ale stakeholders. 3. Negocierea acestor condiii pentru a le reconcilia ntr-un set de condiii win-win pentru toi cei implicai (inclusiv pentru echipa proiectului software).

n afar de cele 3 activiti de negociere menionate, modelul spiral mai introduce 3 anchor points: Life cycle objectives (LCO): definete un set de obiective pentru fiecare activitate major de inginerie software. Life cycle architecture (LCA): definete obiectivele de trebuie ndeplinite cnd se definete arhitectura software-ului. Initial operational capability (IOC): definete obiective n legtur cu pregtirea pentru instalarea / distribuirea software-ului i asisten.

d) Modelul de dezvoltare concurent (numit i concurrent engineering) Most software development process models are driven by time; the later it is,
the later in the development process you are. A concurrent process model is driven by user needs, management decisions, and review results. (Davis, A., P. Sitaram, 1994)

Toate activitile exist concurent, dar se gsesc n diferite stri.

Modelul concurent se folosete ca paradigm pentru dezvoltarea aplicaiilor client-server.

Concepii i principii orientate-obiect

CLASE, OBIECTE, INSTANE

O clas descrie structura i comportarea unei mulimi de obiecte similare. Un obiect este o instan prezent la rulare i care aloc memorie pentru varibilele instanei; se comport conform protocolului clasei sale.

Clas (class)

Obiect (Object)

Class

instance of

Object

ATRIBUTE, OPERAII, RESTRICII, RELAII (Attributes, Operations, Constraints, Relationships)

Principiul ncapsulrii (encapsulation): Clasele combin atribute i operaii ntr-o singur unitate. Atributele sunt accesibile doar prin intermediul operaiilor (adic indirect). Atribute: definesc structura obiectelor, i.e. componentele lor i informaia sau datele coninute n ele Operaii: descriu comportarea (behaviour) obiectelor; se pot folosi termenii servicii, metode sau (eronat) proceduri sau funcii Restricii: condiiile, cerinele i regulile pe care obiectele trebuie s le satisfac Relaii: de motenire (inheritance), asociere i de asemnare (like).

Exemplu
Un cerc pe care vrem s-l reprezentm are urmtoarele proprieti (printre altele): Atribute: raza i poziia pe ecran (x,y). Operaii: posibilitatea afirii, tergerii, repoziionrii i redimensionrii. Restricii: raza s fie strict pozitiv (r > 0). Relaii: nu este cazul.
Numele clasei Numele atributelor Restricie Valoare iniial

Tip de atribut Operaii

Parametri (Nume: tip=valoare iniial)

Pe de o parte, n timpul analizei i design-ului, clasele sunt modelate, adic se iau n considerare proprietile i relaiile.

Pe de alt parte, diagramele use case i altele sunt folosite pentru a reprezenta interaciunea dintre clase i s simuleze procesele selectate. n loc de clase, aceste diagrame folosesc obiecte, care se reprezint precum clasele (doar c sunt subliniate), cu posibilitatea de a introduce valori pentru atribute.

Numele instanei Numele atributelor

Numele clasei Valori ale atributelor

Identitatea obiectelor
Principiul identitii obiectelor: Fiecare obiect e prin definiie unic diferit de toate celelalte obiecte, independent de valorile concrete ale atributelor sale.

Principiul coerenei
Principiul coerenei: Fiecare clas trebuie s fie responsabil pentru (exact) un aspect (logic) al ntregului sistem. Proprietile situate n aceast arie de responsabiliti trebuie grupate ntr-o singur clas i nu disipate n mai multe clase. Mai mult, o clas nu trebuie s conin proprieti care nu sunt n aria ei de responsabilitate. Responsabilitile trebuie formulate succint i n modul general.

Taxonomie i motenire (inheritance)

Principiul motenirii: Clasele pot reprezenta specializri ale altor clase, i.e. clasele pot fi organizate ierarhic i motenesc (inherit) proprieti ale claselor situate deasupra; la nevoie, pot fi suprascrise (overwrite), dar nu eliminate. Principiul substituiei: Obiectele din subclase pot fi ntotdeauna folosite n locul obiectelor din supraclasa(e). Motenirea = reutilizarea proprietilor

Relaia de motenire e reprezentat printr-o sgeat, cu subclasa punctnd pe supraclas. Evitai motenirea dac avei alternative.

Exemplu (motenire simpl)

Obs. Operaiile display(), remove() trebuie s fie operaii abstracte n GeomFigure, doar n clasele Circle ... ele devin operaii concrete. Obs. Operaia setPosition() se poate imple-menta in GeomFigure.

Clasa GeomFigure e o generalizare a clasei Circle, i clasa Circle e o specializare a clasei GeomFigure.

Motenire: restricii i probleme

Principiul responsabilitii restriciilor: O subclas nu trebuie s includ nici o restricie asupra proprietilor supraclasei.

Clase abstracte
Principiul claselor abstracte: Clasele pentru care nici o instan concret nu poate fi creat se numesc clase abstracte.

Clase

Instane

Asocieri
O asociere e o relaie ntre diferitele obiecte ale uneia sau ale mai multor clase.

O asociere primete un nume i o specificaie numeric (cardinalitate) care arat cte obiecte dintr-o parte a asocierii sunt asociate cu cte obiecte din cealalt parte. Se pot aduga i nume de roluri, care descriu semnificaia claselor.

Obs. Dac nu e specificat direcia n asociere, se consider a fi o asociere bidirecional.

Agregri
O agregare e o form special de asociere. Este tot o asociere ntre dou clase, cu observaia c aceste clase se refer una la alta precum ntregul la prile sale.

Un form special e cea n care prile individuale depind de ntreg pentru existena lor; se numete compoziie (composition)
Compoziie

Agregare

Obs. Cel puin la nceput, e permis cardinalitatea 0 pentru un agregat.

Agregri (continuare)
ntr-o agregare, partea ntregului e marcat cu un romb. Compoziiile sunt marcate de un romb plin i au totdeauna o multiplicitate 1 (sau 0..1) de partea unde rombul e reprezentat.

1)

2)

Schimb de mesage (Message Exchange)

Principiul schimbului de mesaje: Obiectele sunt uniti independente care coopereaz i interacioneaz prin intermediul mesajelor pe care i le trimit unul altuia.

Un mesaj e reprezentat de numele operaiei (cu argumente ntre paranteze, dac e cazul) i o sgeat care arat sensul mesajului.

Obs. Un mesaj nu e o operaie (adic, n sensul clasic, un apel de procedur sau funcie).

Colecii
Coleciile sunt clase definite uzual n librriile de clase standard i au n comun faptul c ele adun i gestioneaz mulimi de obiecte. Se mai numesc i clase container (container classes). Coleciile au toate operaiile pentru adugarea i tergerea obiectelor, verificarea dac un obiect dat e coninut n mulime i determinarea a cte obiecte sunt coninute curent n mulime. Secveniale: obiectele sunt secvenial - ex: tablou (array) adunate ntr-o structur

Colecii

Asociative: pstreaz obiectele, dar i o cheie pentru fiecare obiect prin intermediul creia poate fi identificat - ex:dicionar

Polimorfism
Polimorfismul nseamn c o operaie se poate comporta diferit (n clase diferite). Polimorfism static: suprancrcarea operatorilor, funcii su signaturi diferite dinamic:o precondiie este late binding D.p.d.v. fizic, binding e punctul n viaa unui program la care caller-ul unei operaii e dat de adresa de memorie a operaiei. Uzual, se ntmpl la compilare sau link-are. Acest tip de binding se numete early binding. n late binding, locaia de memorie a unei operaii e determinat doar cnd apelul are loc, i.e. atunci cnd mesajul corespunztor e trimis obiectului. Prin urmare, asocierea ntre mesaj i operaie apare dinamic la rulare, nu la compilare. Motenirea nseamn c o clas motenete toate proprietile supraclasei sale. i este permis totui s redefineasc o operaie motenit i s-o rescrie cu o nou definiie. Care dintre aceste operaii se va folosi ca rspuns pentru un mesaj (adic din ce clas vine operaia apelat) se decide doar la rulare.

Polimorfism dinamic (continuare) n momentul n care mesajul display() ntlnete un obiect, decide ce operaie concret va fi folosit: de exemplu, pentru un dreptunghi, se va apela Rectangle.display(). Se folosete totdeauna operaia din clasa cea mai specializat. Acesta e principiul polimorfismului (vezi figura de mai jos)

Cercuri i dreptunghiuri

Paradigma OO
- completri -

Clase Numele claselor este, de obicei, un substantiv la singular, care trebuie s fie ct mai sugestiv fa de abstracia modelat. Atributele sunt de dou feluri: atribute de instaniere, care au valori specifice unui obiect particular; atribute de clas, care au valori comune tuturor instanelor clasei i se reprezint subliniat Atributele au urmtoarele tipuri: integer real boolean string enumerare boolean alte tipuri sau chiar clase

Sintaxa unui atribut va fi urmtoarea:

[vizibilitate] nume:tip_expresie [=valoarea_iniial {list de proprieti}]

Atributele clasei se pot clasifica dup gradul de vizibilitate n: -atribute publice, care sunt atribute vizibile, pot fi folosite i n alte clase i sunt precedate de semnul "+"; mulimea acestora se mai numete i interfa; -atribute private (informaionale), care pot fi accesate numai n clasa respectiv i care sunt precedate de semnul "-"; -atribute protejate, care pot fi accesate de clasa care le-a definit, precum i de generalizrile sau de specializrile ei, i sunt precedate de semnul "#". Exemplu. Clasa Asigurri poate avea urmtoarele atribute:

Mesaje i metode Obiectele nu sunt izolate, ele acioneaz asupra altor obiecte i/sau permit s se acioneze asupra lor. Relaiile dintre obiecte se numesc linkuri sau legturi, iar comunicarea dintre obiecte se numete stimul. Comportamentul se refer la modul n care un obiect reacioneaz (schimb starea) la cererile altor obiecte din sistem, precum i la modul cum acioneaz (trimite mesaje altor obiecte). Un mesaj este o comunicare ntre clase via asocieri, aa cum un stimul este comunicarea dintre obiecte via legturi. Operaia este abstractizarea unui mesaj care poate fi trimis clasei. La primirea unui mesaj, o clas execut o operaie. Sintaxa unei operaii este:
[vizibilitate] nume_operaie ([arg1 :tip1,............argn :tipn ] ): [tip]

public (+) privat (-) partajat (#)

Mesaje i metode (continuare) Implementarea operaiei se numete metod, adic o metod este o unitate de cod, scris ntr-un limbaj de programare orientat pe obiecte. Dac, ntr-un limbaj de programare, se definete o funcie i se scrie codul care determin ce trebuie s execute funcia, atunci declaraia funciei este o operaie, iar corpul funciei este o metod. Metodele se clasific n:
se aplic numai clasei

a) Constructori - sunt metode care creaz noi instane ale clasei. Unei
clase i pot corespunde mai muli costructori.

b) Destructori c) Selectori

- sunt metode care elimin un obiect din memorie. - sunt metode care acceseaz starea unui obiect fr a o modifica.

d) Modificatori - sunt metode care schimb starea obiectului.

Mesaje i metode (continuare) Ceea ce obiectele tiu i pot s fac se numete caracteristic. structurale Caracteristicile sunt de dou tipuri comportamentale Asocierile i atributele alctuiesc caracteristicile structurale (structural features), deoarece ele indic structura clasei, similar cu modelarea structural, care indic structura modelului realizat Operaiile i metodele sunt caracteristici dinamice (behavioral features), deoarece comunic comportamentul clasei, asemntor cu modelarea dinamic, folosit pentru a comunica comportamentul unui sistem

Interfee Mesajele primite de obiect pot fi: mesaje publice mesaje care pot fi recepionate de obiect, indiferent de cine trimite mesajul; mesaje private mesaje trimise obiectului de diferite pri ale sistemului sau chiar de el nsui. Interfaa unui obiect cuprinde mesajele publice ale obiectului. Obs. Obiectele din aceeai clas au aceeai interfa, aadar, interfaa unui obiect poate fi considerat ca o interfa a clasei. Obs. Interfaa conine numai operaiile, nu i metodele (codul) care implementeaz operaiile. Obs. n UML, interfeele vor fi redate printr-un cerc, cruia i se ataeaz numele interfeei. Obs. Accesul ctre datele obiectului se poate face prin serviciile (operaiile) pe care acesta le ofer clienilor si. Aceste operaii care gsesc i seteaz valorile atributelor se numesc getters i setters. n acest caz, starea obiectului este privat, n timp ce serviciile sale sunt publice.

Clase abstracte O clas care are, cel puin, o operaie abstract (operaie pentru care nu e dat dect signatura) se numete clas abstract. Obs. O clas abstract nu poate fi instaniat. Obs. Clasa care motenete o clas abstract va trebui s implementeze operaile abstracte din superclas; n caz contrar, i ea devine clas abstract.

Motenire Atributele i operaiile cu vizibilitate public (precedate de '+') din superclas vor fi publice i n subclas, pe cnd cele private (precedate de '-') vor fi motenite n subclas, dar nu vor fi accesibile acesteia. Atributele i operaiile cu vizibilitate protejat (precedate de '#') nu pot fi accesate de alte clase, ci numai de clasa respectiv i de subclasele ei. Cnd o clas are o singur superclas, spunem c exist o motenire simpl. Poate s existe i o ierarhie de clase, adic o clas s fie att subclas, ct i superclas, i, n acest caz, avem o motenire multipl. Exist mai multe scenarii de motenire : adugarea unor noi metode i/sau stri subclasei; rescrierea unor metode din superclas, din motive de eficien.

Polimorfism Polimorfismul const n abilitatea de a folosi mai multe metode pentru o operaie (de exemplu: desenarea unei figuri sau calculul ariei). Datorit polimorfismului, o subclas poate s redefineasc o operaie motenit chiar dac operaia nu este abstract n superclas. Implementarea unei operaii va fi aleas n funcie de obiectul cruia i se aplic operaia. Se caut metoda nti n clasa cea mai specializat a obiectului; dac aceasta nu se gsete, se merge la superclasa imediat urmtoare, pn la gsirea ei n ierarhia de clase definit. Se constat dac exist o clas abstract de baz, toate celelalte clase abstracte i concrete pot deriva din aceast clas de baz.

Inginerie software
-generaliti-

Ingineria software cuprinde metodele, instrumentele i tehnicile folosite pentru dezvoltarea software. Software software de sistem: e software-ul care se comport ca instrument de ajutor pentru construcia software-ului de aplicaie. Exemple: SO, baze de date, compilatoare etc. software de aplicaie: e software-ul care ajut s se efectueze task-uri utile sau de recreere. Exemple: jocuri, ATM, software de control n avioane, software pentru e-mail, editoare de texte etc.

In cadrul software-ului de aplicaie, trebuie identificate categoriile de software: jocuri sisteme de informaie sisteme de stocheaz i acceseaz o cantitate mare de date (ex: sistem de rezervare a locurilor) sisteme n timp real, n care computerul trebuie s raspund repede (ex: controlul software al unei staii de putere) sisteme ncorporate (embedded systems), n care computerul joac un rol mai mic n cadrul unui sistem mai mare (ex: software ntr-un celular) software de birou (office software): editor de texte, spreadsheets software tiinific: calcule, modelare, predicie

Scopurile pe care dezvoltarea software caut sa le ndeplineasc sunt: a) satisfacerea cerinelor utilizatorilor b) cost redus de realizare a software-ului c) performan nalt d) portabilitate e) cost redus de mentenan f) fiabilitate sporit g) livrare la timp

a) Satisfacerea cerinelor utilizatorilor

Principala problem e analiza cerinelor

Sarcina ncercrii de a asigura c software-ul face ce vor utilizatorii s fac se numete validare.

b) Costul realizrii software-ului

Se estimeaz c n lume se cheltuiete pentru producerea de software aproximativ 1500 miliarde dolari i c n fiecare an se prognozeaz o cretere a acestei cifre cu 15%. Se estimeaz c productivitatea unui programator mediu este de 10-20 linii de program pe zi, datorit urmtoarelor aspecte: - un software de sistem se scrie mult mai greu dect un software de aplicaie ; - n studiul efectuat exist mari diferene ntre programatorii individuali. - aceast cifr include i timpul petrecut pentru clarificarea problemelor, designul, codul, testarea etc..

Privire paralel hardware - software

b) Costul realizrii software-ului (continuare)

Costuri relative n dezvoltarea software-ului

Numrul relativ de erori facute n dezvoltarea software

Costul relativ de reparare a diverselor erori

c) Performanele software : trebuie s fim siguri c:

un sistem interactiv rspunde ntr-un timp rezonabil de scurt un joc ruleaz suficient de repede pentru ca animaia s nu fie suprtoare o anumit sarcin nu ia 15 ore n loc de una Tem: Identificai sisteme software n care viteza e un factor important Obs. Viteza mare i economia de memorie sunt contradictorii

d) Portabilitate: cum pot transfera software de la un tip de computer la altul cu

minimum de efort

e) Mentenana: e termenul pentru efortul care trebuie pus n software, dup ce

acesta a fost scris i pus n aplicare. de remediere (corectarea bug-urilor) Mentenan de adaptare (care modific software-ul fie la cererea utilizatorilor, fie la schimbarea SO etc.)

e) Mentenana (continuare)
Obs. Mentenana de remediere e practic inevitabil, datorit faptului c testarea e dificil i consumatoare de timp i las cu siguran elemente de software cu bug-uri Obs. Se estimeaz c mentenana reprezint 67% din totalul timpului necesar pentru dezvoltarea diferitelor pri ale software-ului. Exemplu de mentenan: Problema anului 2000. Ce tip de mentenan este?

f) Fiabilitatea
O parte a software-ului e fiabil dac lucreaz fr s produc lucruri indezirabile. Uzual se vorbete de bugs n software, dar pentru claritate se definesc si termenii: eroare (error) - o decizie greit luat n timpul dezvoltrii software; defect (fault) - o problem care face ca software-ul s se ndeprteze de comportarea dorit; poate s nu apar pn cnd condiiile nu sunt potrivite; e sinonim cu bug. eec (failure) un eveniment care face ca software-ul s se ndeprteze de comportarea dorit

f) Fiabilitatea (continuare)
O eroare cauzeaz unul sau mai multe defecte. Un defect cauzeaz unul sau mai multe eecuri. Eecurile apar cnd sistemul este testat. Obs. ndepratea bug-urilor i ncercarea de a asigura fiabilitatea se numete verificare. Obs. Deoarece este practic imposibil de ndepratare a tuturor bug-urilor, s-a impus conceptul de good enough software (software suficient de bun), adic lansarea software-ului se produce cnd numrul i severitatea defectelor (faults) devin acceptabile Obs. Exist i conceptul de zero defect software

Obs. Se estimeaz c hardware-ul pic de trei ori mai repede dect software-ul.

f) Fiabilitatea (continuare)
Sunt anumite aplicaii care necesit o fiabilitate ridicat, safety-critical systems. Exemple: sistemele pentru controlul avioanelor; controlul proceselor critice (software de comunicaii ce joac un rol critic n situaiile de urgen) controlul echipamentelor medicale Tem. Identificai sisteme ce trebuie s fie fiabile i altele care nu trebuie s fie.

g) Livrare la timp
E una dintre problemele majore, poate chiar principala problem. Se estimeaz c aproximativ 60% dintre proiecte depesc perioada de livrare i aproximativ 50% ncalc flagrant termenul de predare.

Interaciunea om-computer
n ultimul timp, multe interfee au devenit grafical user interfaces (GUIs) care utilizeaz ferestre cu instrumente gen butoane i bare de scroll. Se pune problema designului acestor interfee grafice, care s fie simple i uor de utilizat. Tem. Identificai sisteme care sunt mai greu de utilizat i altele mai uor de utilizat.

Scopuri conflictuale i complementare

Concluzii
Dezvoltarea software ridic probleme mari. Metodele i instrumentele necesare pentru mbuntirea acestei situaii sunt cunoscute ca inginerie software. Dintre aceste idei, amintim: accent crescut pe realizarea sistematic a tuturor etapelor de dezvoltare realizare de instrumente software pentru dezvoltare accent crescut pe determinarea ct mai exact a cerinelor utilizatorilor (requirements engineering i validation) prezentarea unei versiuni prototip utilizatorilor folosirea unor limbaje de programare noi, inovatoare

Diagrame de clas
- exemple -

Tem. Modelai enunurile urmtoare (ndeplinite simultan) :

1) Fiierele, shortcut-urile i directoare i au un nume;

directoarele

sunt

coninute

2) Un shortcut implic (se refera la) un fiier sau un director;

3) ntr-un anumit director, un nume poate identifica doar un element (fiier, shortcut sau director);

1) Fiierele, shortcut-urile i directoare i au un nume;

directoarele

sunt

coninute

Conceptele de fisier, shortcut, director trebuie modelate n clase. Din moment ce un fiier, shortcut sau director nu poate fi inclus dect ntr-un director (n alte directoare pot fi eventual copii ale acestora), iar odat cu dispariia directorului printe dispar i fiierele, shortcut-urile i (sub)directoarele coninute n el, relaia dintre clasele Fisier, Shortcut, Director cu clasa Director trebuie s fie compunere.

2) Un shortcut implic un fiier sau un director;

Obs. Asocierea exclusiv sau asocierea XOR este o constrngere a dou

sau a mai multor asocieri i specific faptul c o clas poate participa la cel mult o asociere la un moment dat.

3) ntr-un anumit director, un nume poate identifica doar un element (fiier, shortcut sau director);

Asocierea calificat este folosit n relaiile one-to-many i many-to-many i indic modul n care va fi identificat un anumit element al prii many a unei asocieri. Un calificativ este un atribut al unei clase de asociere, care trebuie s reduc multiplicitatea asocierii care a generat clasa de asociere. Un calificativ este folosit ca un index pentru a gsi obiectele de la cellalt capt al unei asocieri.

Prima viziune a modelului va arta ca n figura de mai jos:

Obs. n aceast variant, dou fiiere sau shortcut-uri nu pot avea acelai nume n interiorul unui director, dar un fisier si un shortcut pot avea acelai nume.

Soluia vine din propoziia a 3-a: 3) ntr-un anumit director, un nume poate identifica doar un element (fiier, shortcut sau director); Adugnd o supraclas, Element, care s generalizeze clasele Fisier, Shortcut i Director, cele 3 compuneri se pot mbina ntr-una singur.

n aceast soluie: Director e composite n relaie cu Element Director e subclas a clasei Element

Ce este pattern-ul composite? E o soluie elegant pentru a modela ierarhii de elemente/compuneri. Designerul poate lucra cu obiecte individuale (frunze leaves) i cu combinaiile lor (composite) n acelai fel.

Diagrame de clas
- exemple -

Tem. Modelai enunul : O ar are o capital.

ara va fi o clas cu unul dintre atributele sale capitala. Aceast soluie e util doar dac vrem s avem acces la numele capitalei unei ri.

Eventual se pot completa, ulterior, alte atribute: nume, moned, limba etc. Pe de alt parte, ce se ntmpl dac vrem s adugm proprieti conceptului de capital, cum ar fi populaie, suprafa etc.

Capital va deveni clas

Asocierea are poate fi o agregare sau compunere?

Da, compunere.

Pe de alt parte, modelul de mai sus nu amintete, n vreun fel, noiunea de ora: dac o capital nu mai e capital (din diverse motive), oraul n sine nu dispare, ci doar statutul su de capital.

Vom modela aadar faptul c o capital e un ora cu un anumit rol.

Vom aduga apoi o agregare multipl ntre Tara i Oras i o restricie care s arate c o capital e aleas dintre oraele unei tri.

De e e agregare i nu compunere?

Pentru c un ora poate aparine, n cazul general, n timp, mai multor ri. Exemplu: Berlin

n final, dac vrem s artm c o capital e un ora i are proprieti specifice oraului, atunci putem face clasa Capitala ca o specializare a clasei Oras.

Dependena <<refine>> indic faptul c multiplicitatea 1 din partea clasei Tara n compunerea cu Capitala nlocuiete mai puin restrictiva multiplicitate 1..* din partea clasei Tara pentru orae. Obs. Clasa Oras din figura de mai sus nu e o clas abstract

Diagrame de clas
- exemple -

Tem. Modelai enunurile urmtoare (ndeplinite simultan) :

1) Fiierele, shortcut-urile i directoare i au un nume;

directoarele

sunt

coninute

2) Un shortcut implic (se refera la) un fiier sau un director;

3) ntr-un anumit director, un nume poate identifica doar un element (fiier, shortcut sau director);

1) Fiierele, shortcut-urile i directoare i au un nume;

directoarele

sunt

coninute

Conceptele de fisier, shortcut, director trebuie modelate n clase. Din moment ce un fiier, shortcut sau director nu poate fi inclus dect ntr-un director (n alte directoare pot fi eventual copii ale acestora), iar odat cu dispariia directorului printe dispar i fiierele, shortcut-urile i (sub)directoarele coninute n el, relaia dintre clasele Fisier, Shortcut, Director cu clasa Director trebuie s fie compunere.

2) Un shortcut implic un fiier sau un director;

Obs. Asocierea exclusiv sau asocierea XOR este o constrngere a dou

sau a mai multor asocieri i specific faptul c o clas poate participa la cel mult o asociere la un moment dat.

3) ntr-un anumit director, un nume poate identifica doar un element (fiier, shortcut sau director);

Asocierea calificat este folosit n relaiile one-to-many i many-to-many i indic modul n care va fi identificat un anumit element al prii many a unei asocieri. Un calificativ este un atribut al unei clase de asociere, care trebuie s reduc multiplicitatea asocierii care a generat clasa de asociere. Un calificativ este folosit ca un index pentru a gsi obiectele de la cellalt capt al unei asocieri.

Prima viziune a modelului va arta ca n figura de mai jos:

Obs. n aceast variant, dou fiiere sau shortcut-uri nu pot avea acelai nume n interiorul unui director, dar un fisier si un shortcut pot avea acelai nume.

Soluia vine din propoziia a 3-a: 3) ntr-un anumit director, un nume poate identifica doar un element (fiier, shortcut sau director); Adugnd o supraclas, Element, care s generalizeze clasele Fisier, Shortcut i Director, cele 3 compuneri se pot mbina ntr-una singur.

n aceast soluie: Director e composite n relaie cu Element Director e subclas a clasei Element

Ce este pattern-ul composite? E o soluie elegant pentru a modela ierarhii de elemente/compuneri. Designerul poate lucra cu obiecte individuale (frunze leaves) i cu combinaiile lor (composite) n acelai fel.

Diagrame de clas i de obiecte

- Concepte, exemple -

Studiu de caz: Sistem de rezervare (booking) a biletelor de avion pentru o agenie de voiaj (varianta simplificat)
Cunotinele experilor n fenomen se pot concretiza n propoziiile:

Pasul 1. Modelarea propoziiilor 1 i 2

Clase: AirlineCompany i Flight

Obs. Se prefer multiplicitatea 1..* n loc de 0..*, pentru c se iau n considerare doar companiile care ofer cel puin un zbor.

Noiunile open i close sunt concepte dinamice. Ele privesc schimbrile n starea unui obiect Flight prin ordinul altui obiect AirlineCompany.

Se va insera un atribut state, de tip enumerare, ilustrat n figura de mai jos:

Obs1. Soluia de mai sus nu e totui cea mai fericit. De aceea noiunea de stare (state) va fi modelat cu ajutorul diagramelor de stare (state
diagram).

Obs2. n diagramele de clas, singurele elemente dinamice se realizeaz prin intermediul operaiilor.

(continuare) Mesajele vor circula ntre obiectele ce reprezint instane ale claselor, astfel:

Pasul 2. Modelarea propoziiilor 6, 7 i 10

Obs. Se respect principiul: if we can ask an element for its value only, it
concerns a simple attribute; if several questions apply to it, though, an object that possesses several attributes itself is involved, as well as links with other objects.

Obs. Deoarece noiunea de airport e complex i implic nu doar un nume, ci i capacitate etc, e de preferat s se creeze clasa Airport dect
atributele DepartureAirport i ArrivalAirport n clasa Flight.

Obs. E necesar restricia {ordered} la clasa Airport, pentru a indica c

cele dou aeroporturi legate zborului sunt ordonate (cel de sosire e dup cel de plecare).

(continuare) O soluie tentant ar fi s se creeze dou subclase din clasa Airport:

Obs. Soluia e incorect, deoarece fiecare aeroport e un aeroport de

plecare pentru anumite zboruri i aeroport de sosire pentru alte zboruri, prin urmare clasele DepartureAirport i ArrivalAirport au aceleai instane.

(continuare) Se va folosi noiunea de rol, care se potrivete perfect situaiei:

Obs. Rmne problema multiplicitii n partea stng a asocierii serves:

De cte aeroporturi e servit un ora?

Obs. Dac se consider c verbul a servi se refer la mijlocul de

transport aerian care se gseste la cel mult 30 km de un ora, atunci multiplicitatea este 0..*, ca n figura de mai jos:

Pasul 3. Modelarea propoziiilor 8 i 9

Obs. O escal (stopover) e n conexiune cu zborurile i aeroporturile, deci

e indicat s se creeze o clas Stopover:

Obs. O escal se produce ntr-un i numai un aeroport i un aeroport

poate fi folosit pentru mai multe escale.

ntrebare. O escal aparine unui zbor i numai unul ? Rspuns. Nu, exist contraexemple date de specialiti. Aadar o escal
poate aparine mai multor zboruri. Pentru a completa diagrama, facem observaiile: asocierea dintre Flight i Stopover e o agregare, dar nu e compunere; escalele sunt ordonate conform cu zborurile

Obs. Clasa Stopover e strns legat de clasa Airport (multiplicitate 1) i

nu exist ea nsi, ci ca parte a clasei Flight. O idee ar fi s considerm clasa Stopover ca specializare a clasei Airport:

Obs. Nu e soluia recomandat, din cauza aa numitei moteniri de

implementare.

Se poate folosi noiunea de escal (stopover) ca al treilea rol jucat de un aeroport cu privire la zboruri.

Obs. Clasa Stopover dispare, fiind nlocuit de o clas de asociere, numit

StopoverInfo.

Pasul 4. Modelarea propoziiilor 3,4 i 5

Obs. Trebuie s se fac distincie ntre customer i passenger (exemplu:

un client (customer) poate fi un angajat al celui care cltorete) Obs. Din propoziia 4, reies multiplicitile: single flight, single passenger.

Obs. Propoziia 5 poate fi ndeplinit prin adugarea a dou operaii n

clasa Booking.

Obs. O soluie mai simpl se obine dac vom considera pasagerul

(passenger) ca atribut n clasa Booking.

Obs. Totui, dac vrem s gestionm informaii legate de pasager (cum ar

fi: adresa, numar telefom, e-mail etc) e mai recomandabil s folosim clasa Passenger, cum am descris anterior.

Revenim la: nceputul propoziiei e confuz, deoarece pare c implic direct un customer i flight. De aceea, pentru evitarea confuziei, propoziia poate fi reformulat:

Obs. O rezervare (booking) este fcut de (doar) un customer i acelai

zbor (flight) poate fi afectat de 0 sau mai multe rezervri.

Adugnd i clasa Passenger, se pune ntrebarea: Cte rezervri poate s aib un pasager?

Rspuns. La prima vedere, cel puin una (altfel nu ar fi pasager). Rspuns complet. E necesar s anticipm c putem avea 0..*.

Pasul 5. Adugarea atributelor (attributes), restriciilor (constraints) i calificatorilor (qualifiers)

Relum modelul preliminar obinut pn acum:

Pentru fiecare clas, identificm principalele atributele (folosind conveniile UML):

Completm modelul cu atribute derivate Un atribut derivat (vezi Glosar de termeni) este o proprietate, interesant
pentru analist, dar redundant ca valoare, pentru c poate fi calculat din alte elemente existente n model.

Exemplu: durata unui zbor (length), care se obine ca diferen ntre

arrivalTime i departureTime, innd cont (eventual) i de arrivalDate i departureDate.

Atribute derivate (continuare)

Cum convertim un atribut derivat ntr-o metod de design? Designer-ul are de ales ntre dou metode: pstreaz un atribut concret n design, care va avea metodele sale de acces (set i get); trebuie activat procesul de update ori de cte ori un item din informaie, de care depinde atributul, se modific; - se folosete dac e necesar ca valoarea atributului derivat s fie prezent n permanen sau dac se calculeaz greu; nu stocheaz valoarea redundant, dar o calculeaz la cerere, folosind o metod public; - se folosete dac nu e cerut prea des sau dac se poate calcula cu uurin

Adugarea restriciilor (constraints) i calificativilor (qualifiers) Pentru a schimba un zbor (flight) sau client (customer), rezervarea respectiv trebuie anulat i creat una nou. Acest fapt se poate realiza folosind restricia {frozen} pe asocierea potrivit. (vezi Glosar de termeni) Pe de alt parte, fiecare zbor e identificat n mod unic printr-un numr. Putem s convertim atributul number (n clasa Flight) n calificativ (qualifier) (vezi Glosar de termeni) al asocierii offers dintre clasele AirlineCompany i Flight. Nu trebuie exagerat cu restriciile. Se recomand folosirea acelora care sunt foarte importante, altfel diagrama poate deveni greu de urmrit.

Pasul 6. Folosirea analysis pattern

Clasa Flight are mai multe responsabiliti: a) Prima privete toate informaiile ce pot fi gsite n planificarea zborurilor pentru fiecare companie aerian: ntr-adevr, exist un zbor n fiecare luni, s zicem, ntre oraele A i B, oferit de compania din oraul A. b) A doua se refer la informaiile privind rezervrile: cineva nu rezerv un zbor A-B ntr-o zi de luni, ci rezerv un zbor A-B n ziua de 09.11.2009 (de exemplu). De aceea vom vedea un tip de relaie de instaniere dintre clasa GenericFlight, care are responsabilitile descrise la punctul a) i clasa Flight, care s aib responsabilitile de la punctul b). n plus, s presupunem c o companie anuleaz nite zboruri, din oraul X, din motive de modernizare a aeroportului, timp de cteva luni. n varianta iniial, trebuia s scpm de toate instanele clasei Flight. La sfritul lucrrilor, trebuiau recreate; n varianta a doua pur i simplu instanele pentru zborurile ce pleac din oraul X nu vor exista.

Clasa Flight n versiunea iniial

Separarea responsabilitilor clasei Flight

Pentru updatarea modelului, trebuie: distribuirea atributelor, operaiilor i asocierilor clasei Flight ntre clasele
GenericFlight i Flight;

adugarea unei asocieri 1-* ntre clasele GenericFlight i Flight; n plus, adugm dou atribute n clasa GenericFlight care s indice n ce zi a sptmnii e planificat zborul i n ce perioad a anului are loc zborul (validityPeriod). E adugat o restricie care leag valorile atributului departureDate din clasei Flight i din clasa GenericFlight Obs. validityPeriod nu e un atribut simplu: putem fi interesai de nceputul perioadei, sfritul, durata etc. Soluia ar fi crearea unei clase TimePeriod:

Trebuie adugat o asociere ntre Flight i AirlineCompany.

Distribuirea reponsabilitilor ntre clasele GenericFlight i Flight

Metaclass pattern Separarea responsabilitilor poate fi generalizat n forma unui analysis pattern, care poate reutilizat n alte ocazii. Fie o clas XX, cu multe responsabiliti, care nu sunt prezente n fiecare instan.

Adugm o clas TypeXX, distribuim proprietile ntre aceste clase i le legm ntr-o asociere de tipul *-1. TypeXX se numete metaclas, deoarece conine informaii ce descriu clasa XX.

Pasul 7. Structurarea n pachete

Structurarea trebuie s in seama de dou principii: coerena i independena. Criteriile de coeren presupun a fi ndeplinite:
obiective: clasele trebuie s returneze servicii de aceeai natur ctre utilizatori; stabilitate: izolm clasele care sunt stabile de cele care trebuie dezvoltate pe parcursul proiectului durata de via a obiectelor.

Independena presupune c divizarea n pachete trebuie fcut astfel nct s fie minimizate dependenele dintre pachete. Propunem divizarea n dou pachete:
primul privete definirea zborurilor, foarte stabile (cele din GenericFlight) al doilea se refr la rezervri, mpreu cu toate asocierile lor

O soluie posibil:

Pasul 8. Generalizarea i reutilizarea

Se pune problema: putem reutiliza modelul de rezervare bilete pentru o cltorie cu avionul la o problem legat de rezervarea biletelor pentru o cltorie cu autobuzul. O cltorie cu autobuzul are un ora de plecare i un ora de destinaie, respectiv timp i dat de plecare i destinaie. Un client poate rezerva una sau mai multe cltorii pentru unul sau mai muli pasageri.

Modelul va fi foarte asemntor cu modelul cltoriei cu avionul, dar puin mai simplu, datorat urmtoarelor aspecte: noiunea de aeroport nu are echivalent, iar clasa City e direct asociat cu clasa JourneyByBus; distincia dintre GenericFlight i Flight nu e transferabil, deoarece cltoriile cu autobuzul nu sunt aa regulate i nu sunt planificate n avans.

Propunerea unei arhitecturi logice mbinate Urmrim obiectivele: izolarea claselor care sunt mprite (shared) ntr-un nou pachet, pentru a fi reutilizate factorizarea proprietilor mprite ntr-o clas abstract.

Izolarea clasei City

Pe de alt parte, clasele Customer i Passenger n ambele tipuri de rezervare. De aceea, e bine s le izolm ntr-un nou pachet, dar nu n acelai (Geography), ci separat.

Exist asemnare ntre pachetele FlightBookings i BusBookings (singura diferen fiind la clasele FlightBooking (redenumit pentru claritate din Booking) i BusBooking: au aceleai atribute i aproape aceleai asocieri

Se va crea aadar o supraclas abstract Bookings

Soluia final va fi urmtoarea:

Glosar de termeni
Restricii de schimbare (changeability):

{frozen}: nseamn c odat o valoare de atribut sau legtur inserat, nu

poate fi updatat sau tears i nu pot fi adugate valori sau legturi atributului, respectiv asocierii; {addOnly}: nseamn c dei valoarea original sau legtura original nu poate fi updatat sau tears, alte valori sau legturi pot fi adugate atributului sau asocierii (pentru instana obiectului cu restricii); addOnly are efect doar dac multiplicitatea maxim a atributului / rolului asocierii depete multiplicitatea minim.

Asociere calificat (qualifier): este folosit n relaiile one-to-many i manyto-many i indic modul n care va fi identificat un anumit element al prii many a unei asocieri. Un calificativ este un atribut al unei clase de asociere, care trebuie s reduc multiplicitatea asocierii care a generat clasa de asociere. Un calificativ este folosit ca un index pentru a gsi obiectele de la cellalt capt al unei asocieri i se reprezint printr-un dreptunghi mic ataat clasei, unde un obiect al clasei, mpreun cu valoarea calificativului, reduce multiplicitatea la cealalt extremitate a asocierii. inapoi

Glosar de termeni Un element derivat, de exemplu atribute sau asocieri, este precedat de slash
/. Un atribut derivat nu va fi stocat n obiectele clasei, ci va fi calculat de fiecare dat. Vezi figura de mai jos

Asocierea derivat mai poate fi reprezentat i printr-o relaie de dependen, etichetat cu stereotipul <<derive>>.

inapoi

Studiu de caz
-ATM (Automatic teller machine)-

Enunarea problemei
Se presupune c un ATM ofer urmtoarele servicii:
1) Distribuirea banilor ctre orice posesor de card (smartcard), prin intermediul unui cititor de card 2) Consultarea soldului contului, faciliti de plat i de depozitare a cecurilor pentru clienii bncii (bank customers) care dein un card (smardcard)

Trebuie avut n vedere c:

3) Toate tranzaciile trebuie fcute n siguran 4) E necesar uneori ca bancomatul s se reumple etc.

De aceea, trebuie ndeplinite sarcinile:

S se identifice actorii S se identifice cazurile de utilizare S se construiasc o diagram use-case S se descrie textual cazurile de utilizare

Obs. Enunul problemei poate fi incomplet (aa cum se ntmpl n realitate)

S se completeze descrierile cu diagrame dinamice S se organizeze i s se structureze cazurile de utilizare

Pasul 1. Identificarea actorilor

1.1 Care sunt entitile externe care interacioneaz direct cu ATM-ul? Prima propoziie indic i primul actor : 1) Distribuirea banilor ctre orice posesor de card (smardcard), prin
intermediul unui cititor de card

Atenie! Cititorul de card face parte din ATM, deci nu poate fi actor! ntrebare. Este cardul un actor (deoarece este extern ATM i interacioneaz cu el)? Rspuns. Poate fi, dar se aplic urmtorul principiu: eliminai actorii fizici n dauna actorilor logici!, deoarece actorii reprezint cineva sau ceva ce beneficiaz n urma utilizrii sistemului.

Cardul nu beneficiaz prin folosirea ATM, ci cel care deine cardul, aadar cardul nu va fi considerat actor. Aadar, primul actor va fi posesorul de card (CardHolder)

Pasul 1. Identificarea actorilor (continuare)

A doua propoziie specific :
2) Consultarea soldului contului, faciliti de plat i de depozitare a cecurilor pentru clienii bncii (bank customers) care dein un card (smardcard)

Aadar, se contureaz i alt actor: clientul bncii (bank customer) A treia propoziie specific :
3) Toate tranzaciile trebuie fcute n siguran

Cine ofer siguran? n exemplul considerat (preluat dup sistemul bancar din Frana) se identific ali doi actori: Visa authorisation system (VISA AS) pentru tranzacii de retragere prin
intermediul unui smatcard Visa

Sistemul informaional al bncii (Bank IS) care s autorizeze toate

tranzaciile fcute de un client prin intermediul smartcard-ului su, dar i accesarea soldului

Pasul 1. Identificarea actorilor (continuare)

A patra propoziie specific :
4) E necesar uneori ca bancomatul s se reumple etc.

Aceasta sugereaz c e nevoie activitate de mentenan: umplerea

bancomatului, recuperarea smartcard-urilor care au fost nghiite etc.

Aceste sarcini identific un alt actor: Operatorul (Maintenance Operator)

CardHolder Bank Customer Concluzie. Actorii sunt: Visa AS Bank IS Maintenance Operator

Pasul 1 bis. Reprezentarea unei diagrame

Pentru o mai bun nelegere a celor deduse la pasul 1, e mai util desenarea unei diagrame, pe care o s-o numim diagram static de context (static context diagram)

Pasul 1 bis. Reprezentarea unei diagrame (continuare)

O alt soluie, mai elaborat, ar fi s considerm Bank customer ca specializarea a lui CardHolder. Se rezolv astfel problema excluderii mutuale dintre cei doi actori.

Pasul 2. Identificarea cazurilor de utilizare

Un caz de utilizare reprezint specificarea unei secvene de aciuni, incluznd variante, pe care sistemul le poate efectua, interacionnd cu actorii din sistem. Vom lua actorii, unul cte unul, i vom lista modurile n care acetia interacioneaz cu sistemul:

1) CardHolder: retrage bani 2) Bank customer: retrage bani consultarea soldului depozitarea banilor (cash) depozitarea cecurilor

3) Maintenance operator: reumple cu bani bancomatul recuperarea cardurilor care au fost nghiite recuperarea cecurilor care au fost depozitate 4) Visa AS: niciuna 5) Bank IS: niciuna Actor primar sau secundar? Numim actor primar pe acela pentru care cazul de utilizare produce un rezultat observabil. Ceilali participani la cazul de utilizare se numesc actori secundari. Exemplu: Visa AS i Bank IS sunt actori secundari. Nu pot ei nii s foloseasc ATM.

Pasul 3. Crearea diagramelor use case

O diagrama use case arat relaiile dintre actori i sistem, precum i cazurile de utilizare (use cases). ATM
Retragere bani

Consultare sold

Umple bancomatul

Depoziteaz bani

Recupereaz carduri

Frontiera sistemului

Depoziteaz cecuri

Recupereaz cecuri

Pasul 3. Crearea diagramelor use case (continuare)

O variant se obine considernd Bank customer ca specializare a CardHolder. ATM
Retragere bani

Consultare sold

Umple bancomatul

Depoziteaz bani

Recupereaz carduri

Depoziteaz cecuri

Recupereaz cecuri

Obs. Vom redenumi actorul CardHolder n Visa CardHolder

Pasul 3. Crearea diagramelor use case (continuare)

Adugarea actorilor secundari Recomandri: Implicit, rolul unui actor e principal (primary); dac nu e aa, indicai c rolul e secundar (secondary) pe asociere, de partea actorului Pe ct e posibil, plasai actorii principali n stnga diagramei, iar pe cei secundari n dreapta Obs. Dac actorul principal e Visa CardHolder, atunci Visa AS trebuie solicitat; pe de alt parte, ATM va solicita Bank IS direct, dac e vorba de un client al bncii (bank customer).
O soluie ar consta n adugarea unei asocieri cu fiecare dintre aceti actori secundari.

Adugarea unei asocieri cu fiecare dintre aceti actori secundari.

O alt soluie ar fi s se fac disticie ntre cele dou cazuri de utilizare referitoare la retragerea banilor: Retragere bani cu Visa card Retragere bani cu un card bancar

Pasul 4. Descrierea textual a cazurilor de utilizare

Cazul de utilizare trebuie s aib un nceput i un sfrit identificabile clar. Trebuie specificate, de asemenea, variante posibile, cum ar fi scenariu de succes, secvene alternative, n timp ce, simultan, se ncearc s se aranjeze descrierile ntr-o ordine secvenial, pentru a mbunti nelegerea lor.

Scenarii
Numim fiecare unitate de descriere a secvenelor de aciune secven. Un scenariu reprezint o succesiune particular a secvenelor, care e rulat de la nceputul la sfritul unui caz de utilizare. Un scenariu poate fi folosit pentru a ilustra o interaciune sau o execuie a unei instane a unui caz de utilizare.

Pasul 4. Descrierea textual a cazurilor de utilizare (continuare)

nregistrarea descrierii textuale nu e standardizat n UML. Se recomand: a) Rezumatul de identificare (Identification summary) (obligatoriu): include titlu, rezumat, datele de creare i modificare, versiunea, persoana responsabil, actorii... b) Fluxul de evenimente (Flow of events) (obligatoriu): descrie principalul scenariu de succes (main success scenario sau basic flow of events sau normal path), secvenele alternative i secveele de erori, precum i precondiiile i postcondiiile. c) Cerine UI (UI requirements) (opional): adugarea constrngerilor pentru GUI. d) Cerine nefuncionale (Non-functional constraints) (opional): se pot aduga informaiile: frecven, disponibilitate, acuratee, integritate, confidenialitate, performan etc.

a) Rezumatul de identificare (Identification summary) Titlu: Retragere bani folosind Visa card Rezumat: Acest caz de utilizare permite unui posesor de card Visa (Visa CardHolder), care nu e client al bncii, s retrag bani n limita zilnic. Actori: Visa CardHolder (primary), Visa AS (secondary). Creation date: xx/11/09 Date of update: zz/11/09 Version: 2.2 Person in charge: Nume Prenume

b) Fluxul evenimentelor (Flow of events) Precondiii: ATM e aprovizionat cu bani Nu e niciun card n cititorul de card Main success scenario: 1. Visa CardHolder introduce cardul n cititor. 2. ATM verific dac este valabil cardul. 3. ATM cere Visa CardHolder pin-ul. 4. Visa CardHolder introduce pin-ul. 5. ATM verific dac datele sunt corecte. 6. ATM cere autorizaie de la VISA authorisation system. 7. VISA authorisation system confirm i indic limita zilnic de retragere. 8. ATM cere Visa CardHolder s introduc suma dorit. 9. Visa CardHolder introduce suma dorit. 10. ATM verific dac suma e sub limita zilnic. 11. ATM ntreab Visa CardHolder dac dorete chitan. 12. Visa CardHolder cere chitana. 13. ATM returneaz cardul ctre Visa CardHolder. 14. Visa CardHolder ia cardul. 15. ATM ofer banii i chitana. 16. Visa CardHolder ia banii i chitana.

O alt prezentare posibil const n separarea aciunii actorilor i sistemului: 1. Visa CardHolder introduce cardul 2. ATM verific dac este valabil cardul. n cititor. 3. ATM cere Visa CardHolder pin-ul. 4. Visa CardHolder introduce pin-ul. 5. ATM verific dac datele sunt corecte. 6. ATM cere autorizaie de la VISA authorisation system.

7. VISA authorisation system 8. ATM cere Visa CardHolder s introduc confirm i indic limita zilnic de suma dorit. retragere. 9. Visa CardHolder introduce suma 10. ATM verific dac suma e sub limita dorit. zilnic. 11. ATM ntreab Visa CardHolder dac dorete chitan. 12. Visa CardHolder cere chitana. 14. Visa CardHolder ia cardul. 16. Visa CardHolder ia banii i chitana. 13. ATM returneaz cardul ctre Visa CardHolder. 15. ATM ofer banii i chitana.

b) Fluxul evenimentelor (Flow of events) (continuare) Secvene alternative: A1) Numr de pin incorect: intervine la pasul 5 6. ATM informeaz CardHolder c pin-ul e incorect pentru prima i a doua oar. 7. ATM nregistreaz eecul pentru card. Scenariul se rentoarce la pasul 3. A2) Suma cerut e mai mare dect limita zilnic: intervine la pasul 10 11. ATM informeaz CardHolder c suma cerut e mai mare dect limita zilnic. Scenariul se rentoarce la pasul 8. A3) Visa CardHolder nu vrea chitan: intervine la pasul 11 12. Visa CardHolder declin oferta de a primi o chitan. 13. ATM returneaz cardul ctreVisa CardHolder. 14. Visa CardHolder ia cardul. 15. ATM ofer banii. 16. Visa CardHolder ia banii.

Secvene de erori: E1) Card invalid: intervine la pasul 2 3. ATM informeaz Visa CardHolder c nu e valid cardul (nu se poate citi, expirat etc.) i l confisc, cazul de utilizare eueaz (fails). E2) Numr de pin invalid dup ncercri repetate: intervine la pasul 5 6. ATM informeaz Visa CardHolder c pin-ul e incorect pentru a treia oar. 7. ATM confisc (smart)cardul. 8. E notificat VISA AS; cazul de utilizare eueaz (fails). E3) Retragere neautorizat: intervine la pasul 6 7. VISA AS interzice orice retragere. 8. ATM scoate cardul; cazul de utilizare eueaz (fails). E4) Cardul nu e luat napoi de Visa CardHolder: intervine la pasul 13 14. Dup 15 secunde, ATM confisc (smart)cardul. 15. VISA AS e notificat; cazul de utilizare eueaz (fails). E5) Banii nu sunt ridicai de Visa CardHolder: intervine la pasul 15 14. Dup 30 secunde, ATM ia banii napoi. 15. VISA AS e notificat; cazul de utilizare eueaz (fails). Postcondiii: nu sunt prea evidente

c) Cerine UI (UI Requirements) Mecanismul de intrare/ieire disponibil pentru Visa CardHolder trebuie s fie: Un cititor de (smart)card. O tastatur numeric (pentru a introduce pin-ul) cu tastele enter, corect i cancel. Un ecran pe care s se afieze mesajele ATM-ului. Taste n jurul ecranului, a.. posesorul de card s selecteze suma dorit. Un distribuitor de chitane. Un distribuitor de bani. d) Restricii nefuncionale (Non-functional constraints) Timpul de rspuns: Interfaa ATM trebuie s rspund n limita maxim de 2 secunde. O tranzacie nominal trebuie s se termine n cel mult 2 minute. Disponibilitatea ATM trebuie s fie accesibil 24/7 Lipsa hrtiei pentru tiprirea chitanelor nu trebuie s fie un obstacol pentru un posesor de card r retrag bani. Integritatea Interfaa ATM trebuie s fie destul de robust pentru a evita vandalizarea. Confidenialitatea Rata de eroare a procedurii de comparare a numrului de pin introdus cu acela de pe card s fie sub 10-6.

Pasul 5. Descrierea grafic a cazurilor de utilizare

Dei descrierea textual a cazurilor de utilizare e esenial, are totui dezavantajul c nu specific n ce ordine vor fi secvenele sau n ce moment intervin actorii secundari.

E recomandat s completm descrierea textual cu una sau mai multe diagrame UML mai dinamice.

Obs. Pentru cazurile de utilizare se recomand diagramele de activitate (Activity

diagram), dar pot fi utile diagramele de secvene (Sequence diagram).

Obs. Pentru anumite scenarii se recomand Sequence diagram, care se va numi

System sequence diagram, n care se reprezint sistemul ca o cutie neagr, actorul principal la stnga, iar actorii secundari n dreapta sistemului.

Crearea unei System sequence diagram care s descrie un main success scenario pentru cazul Retragere bani folosind un Visa card.

Activity state; Action state O activity state modeleaz realizarea unei activiti care: e complex i poate fi divizat n mai multe activiti; poate fi ntrerupt de un eveniment. O action state modeleaz realizarea unei activiti care: e simpl i nu poate fi divizat; nu poate fi ntrerupt de un eveniment.

Completarea diagramei de secvene

Se introduc: -activitile principale ale sistemului (prin mesajele trimise ctre sistem); -referine la secvenele alternative i de eroare (prin note).

Organizarea cazurilor de utilizare

Identificarea prii comune pe care cazurile de utilizare le au n comun i adugarea relaiei include.

Relaia extend e opional, spre deosebire de include, care e obligatorie.

Cazul de utilizare Consultare sold poate fi inserat n cazul de utilizare Retragere bani cu card bancar, la punctul de extensie: verifica suma Punctul de extensie trebuie declarat n descrierea textual: ... 8. ATM cere Bank customer s introduc suma dorit. Punct de extensie: Verifica suma. 9. Bank customer introduce suma.

Identificarea unei relaii de generalizare ce implic cazuri de utilizare

Considerm cazurile de utilizare: Depunere cash i Depunere cecuri. Ambele implic aceiai actori: Bank customer ca actor principal i Bank IS ca actor secundar.

Structurarea cazurilor de utilizare folosind pachete

Strategii posibile: gruparea dup actor, dup domeniu funcional etc. n acest exemplu, folosim gruparea dup actorii principali

Crearea cazurilor de utilizare pentru pachetul Visa Withdrawal.

Crearea cazurilor de utilizare pentru pachetul Customer Transactions.

Crearea cazurilor de utilizare pentru pachetul Maintenance.

Diagrame de activitate

Introducere
Diagramele de activitate descriu activitile i responsabilitile elementelor care alctuiesc sistemul. O diagram de activitate reprezint interaciunile dintre activiti, adic fluxul de control al trecerii de la o activitate la alta. Spre deosebire de diagrama de stare nfieaz strile unui obiect i tranziiile dintre ele, diagrama de activitate evideniaz activitile i tranziiile dintre ele. Diagramele de activitate pot fi folosite n urmtoarele scopuri: - pentru a modela comportamentul intern al unei metode (implementarea unei operaii). Acesta este i cel mai folosit caz cnd apelm la acest tip de diagram; - pentru analiza interaciunii activitilor unui caz de utilizare; - pentru a ilustra modul de organizare a mai multor cazuri de utilizare i legturile dintre acestea.

Elementele unei diagrame de activiti

O diagram de activitate este o extensie a unei diagrame de stri. Aceasta nseamn c o diagram de activitate va avea toate caracteristicile unei diagrame de stare, plus unele noi.

Elementele componente ale unei diagrame de activitate sunt urmtoarele: 1) stri de aciune 2) tranziii 3) bloc de decizii 4) linii de sincronizare 5) culoare

1) Stri de aciune i stri de activitate

Prin activitate nelegem o prelucrare (procesare) neatomic, n curs de desfurare, n cadrul unei maini de stare. Activitile se pot descompune i nu sunt atomice, n sensul c pot fi ntrerupte. Activitile sunt alctuite din secvene de aciuni, care sunt prelucrri atomice i care au ca rezultat schimbarea strii sau returnarea unei valori. Exist trei tipuri de aciuni, i anume: simple, iniiale i finale. O activitate poate fi alctuit dintr-o aciune iniial, una sau mai multe aciuni simple i finale. Reprezentare Activitate

O aciune iniial reprezint prima aciune ntr-o diagram de stare. n UML, o aciune iniial se reprezint ca i o stare iniial, adic printr-un cerc plin.

O aciune final reprezint ultima aciune dintr-o diagram de activitate. n UML, o aciune final se reprezint ca i o stare final, prin dou cercuri mici concentrice, din care cel interior este plin.

2) Tranziii

Tranziiile sunt legturile dintre aciuni i se reprezint ca i tranziiile din diagramele de stare, printr-o sgeat ndreptat spre aciunea urmtoare. n diagramele de activitate, tranziiile nu sunt etichetate, deoarece ele reprezint ncheierea activitii respective. Tranziiile pot, ns, s fie etichetate cu condiii, reprezentate printr-o afirmaie scris ntre paranteze drepte, care restricioneaz tranziia spre aciunea urmtoare.

Exist dou tipuri de fluxuri de tranziii: a) fluxul de control; b) fluxul obiectelor.

a) Fluxul de control al tranziiilor

Fluxul de control al tranziiilor indic ordinea aciunilor n secven. Fluxul tranziiilor arat cum sunt ordonate aciunile n secven. ntr-o diagram de activitate, activitile sunt legate prin tranziii automate, spre deosebire de diagramele de stare, unde tranziiile ntre stri sunt declanate de evenimente. Atunci cnd o aciune este ncheiat, se va executa aciunea specific ieirii, dac exist, dup care tranziia este declanat ctre urmtoarea aciune sau activitate. Urmeaz executarea aciunii specifice intrrii n noua stare, dac exist i executarea aciunii sau a activitii asociate noii stri, etc.

Exemplu. Pentru un anumit sistem, aflat n starea de generare a

rapoartelor, avem urmtoarele activiti: - iniial - stabilirea criteriilor raportului - generarea raportului - tiprirea raportului - final

b) Fluxul tranziiilor obiectelor

O aciune poate produce, modifica sau folosi obiecte. Aceste obiecte de intrare sau de ieire sunt conectate de aciuni prin relaii de dependen, adic printr-o linie punctat ntre aciune i obiect. Pentru o aciune care folosete un obiect de intrare, tranziia se reprezint printr-o linie punctat cu o sgeat ndreptat spre aciune. Pentru o aciune care actualizeaz sau produce un obiect, tranziia este reprezentat printr-o sgeat punctat, de la aciune la obiect.

Fig. Fluxul de control i fluxul tranziiei obiectelor

Fluxul de control al tranziiilor se poate omite atunci cnd exist un flux al obiectelor care s indice ordinea aciunilor, adic atunci cnd o aciune creeaz un obiect de ieire, care s fie obiect de intrare pentru urmtoarea aciune din secven.

3) Bloc de decizii O decizie reprezint selectarea unui anumit flux de control al tranziiilor, din mai multe, n funcie de o condiie de gard. ntr-o diagram de activiti, blocul deciziei este reprezentat printr-un romb mic, n care intr o singur tranziie, i pot iei dou sau mai multe tranziii. Fiecare tranziie de ieire, este etichetat cu o condiie de gard, scris ntre paranteze drepte, i care indic condiia care trebuie ndeplinit pentru ca tranziia s se produc. n cazul n care lipsesc condiiile de gard, acestea sunt considerate, implicit, ca fiind false.

Exemplu. S calculm S= 0!+1!+2!++n!

pentru n N, dat.

4) Linii de sincronizare
Concurena (concurrency) implic faptul c mai multe tranziii se petrec simultan. n UML, sincronizarea ntre fluxurile de control se reprezint cu ajutorul barelor de sincronizare. O bar de sincronizare permite mbinarea (join) i bifurcarea (fork) ramificaiilor paralele n interiorul unui fir de execuie al unui caz de utilizare sau al unei metode. Tranziiile care pleac dintr-o baz de sincronizare se declaneaz simultan. Dac mai multe tranziii intr ntr-o baz de sincronizare, acestea trebuie s se ntmple, nainte ca bara s fie trecut de una sau mai multe tranziii de ieire din bara de sincronizare. Bara de sincronizare se reprezint printr-o linie ngroat. Dac o bar are o singur tranziie de intrare i dou sau mai multe de ieire, aceasta indic faptul c toate tranziiile de ieire se petrec o dat cu tranziia de intrare. Acest flux se numete splitting control. Dac o bar are mai multe intrri i o singur ieire, aceasta indic faptul c toate intrrile trebuie s se produc nainte s se produc tranziia de ieire. Acest flux se numete synchronization control.

5) Culoare
Deoarece o diagram de activitate nu ofer indicii referitoare la elementul care este responsabil pentru fiecare activitate, UML compenseaz aceast slbiciune, oferind tehnica culoarelor (swimlanes). Aceasta const n mprirea unei diagrame de activitate n zone paralele, numite culoare de activiti (aa cum o piscin este mprit n culoare de nataie) pentru a evidenia care element este responsabil pentru aciunea din interiorul fiecrei zone. Fiecare responsabilitate este repartizat unei clase sau unei organizaii i fiecare activitate este alocat unui culoar. Poziia relativ a culoarelor nu are nici o semnificaie, tranziiile fiind libere s traverseze culoarele la care nu se refer. n UML, culoarele se reprezint prin regiuni verticale, paralele, separate prin linii solide. Fiecare culoar are, n partea de sus, o etichet care indic elementul responsabil pentru acea activitate (o clas, un actor sau un departament al unei organizaii).

Exemplu.

Semnale
UML ofer dou simboluri pentru semnale. Primul simbol mesaj indic recepionarea unui semnal. Numele semnalului este trecut ntr-un pentagon concav (un dreptunghi cu o latur n form de triunghi concav). Recepionarea unui semnal este reprezentat ntr-o diagram de activitate, printr-o relaie de dependen de la obiectul care trimite semnalul, la simbolul semnalului, urmat de o tranziie de la simbolul semnalului la urmtoarea aciune. Al doilea simbol semnal indic trimiterea unui semnal. Numele semnalului este trecut ntr-un pentagon convex. Trimiterea unui semnal este reprezentat ntr-o diagram de activitate, printr-o relaie de dependen de la simbolul semnalului spre obiectul care primete semnalul.

Exemplu de diagram de activitate

Pentru exemplul discutat anterior (vezi figura alturat) se adug cerinele: - dup realizarea unui raport, se poate cere execuia altuia; - simultan cu generarea unui raport se poate genera i alt operaie (interogare, actualizare, etc); - un raport se listeaz la imprimant i interogarea la monitor; - un raport i o interogare pot fi listate numai dac generarea a fost fcut cu succes; - se trimit semnale ctre imprimant i monitor i se primesc semnale la generatoarele de rapoarte i de interogri.

Diagrame de stare

Introducere
O diagram de stare poate fi ataat oricrei clase care are stri bine identificate i un comportament complex. O diagram de stare descrie o istorie a vieii obiectelor unei clase i poate fi considerat un graf, bazat pe stri conectate prin tranziii. Diagramele de stare specific modul n care reacioneaz un obiect la primirea unui mesaj.

O diagram de stare are o singur stare iniial, una sau mai multe stri simple, una sau mai multe stri finale i tranziii ntre stri.

Elementele unei diagrame de stare

Elementele principale ale unei diagrame de stare sunt urmtoarele: 1) stri 2) tranziii 3) evenimente 4) aciuni 1) Stri Starea acoper toate proprietile statice ale unui obiect i valorile curente pentru fiecare proprietate. Toate instanele unei clase exist n aceeai stare. Starea curent a unui element se numete stare activ. Stare a) simpl b) iniial c) final

a) Stare simpl: este o condiie special sau o situaie a unui obiect de-a lungul ciclului lui de via. Exemplu de stri de obiecte: obiectul bec poate avea strile: aprins i stins; obiectul factur poate avea strile: pltit i nepltit; obiectul lift poate avea strile: staioneaz, urc, coboar; obiectul calculator poate avea strile: inactiv calculatorul nu este pornit sau nu este accesibil utilizatorilor; activ calculatorul este pornit i este funcional pentru utilizatorii si; blocat calculatorul nu este alimentat sau are unele erori majore. Reprezentarea grafic a unei stri simple: dreptughi cu colurile rotunjite

b) Stare iniial: indic starea unui element i momentul crerii lui. Exist o singur stare iniial. Se reprezint, n UML, sub forma unui cerc plin, de la care pleac o sgeat.

c) Stare final: indic starea unui element la sfritul vieii sale, cnd el este distrus. ntr-o diagram de stare, putem avea zero sau mai multe stri finale. Se reprezint, n UML, printr-un mic cerc plin, concentric altui cerc gol, la care sosesc sgei de la strile sistemului, astfel:

2) Tranziii Tranziiile sunt relaiile dintre stri. O tranziie reprezint schimbarea strii surs a unui obiect, n urma unor aciuni, datorit producerii unui eveniment. Tranziiile dintre stri se produc n felul urmtor:
- un obiect este n stare surs; - se produce un eveniment (de exemplu recepionarea unui mesaj); - se execut o aciune; - obiectul intr n starea int.

ntr-o diagram de stare pot exista:

- una sau mai multe tranziii dintr-o stare, deoarece fiecare este declanat de un eveniment unic; n acest caz, spunem c exist tranziii cu mai multe inte; - din mai multe stri pleac aceeai tranziie, deoarece acelai eveniment poate declana o tranziie de la mai multe stri surs; n acest caz, avem tranziia cu mai multe surse; - tranziie de la o stare la ea nsi.

Tranziiile se reprezint, n UML, printr-o sgeat solid, de la starea surs spre starea int, etichetat cu numele evenimentului i al aciunii, separat prin caracterul slash (/), astfel:

Elementele etichetei sunt opionale, dar nu poate exista numai aciunea. n cazul n care un eveniment cauzeaz o tranziie fr aciune asociat, atunci trebuie s lipseasc i / din eticheta unei tranziii. Uneori, o tranziie se produce nu datorit unui eveniment, ci datorit faptului c o stare completeaz o aciune. n acest caz, tranziiile fr etichet se numesc tranziii automate (automatic transitions).

3) Evenimente Un eveniment este ceva ce se produce asupra unui element. Cele mai frecvente evenimente sunt mesajele recepionate de un obiect. n UML, un eveniment are urmtoarea sintax: nume eveniment (list parametri) [condiia de gard] unde: -nume eveniment este, de obicei, acelai cu numele operaiei elementului care corespunde n diagrama de stare i care se execut pentru evenimentul respectiv (de exemplu, achitarea unei facturi, pornirea unui calculator, etc); -lista de parametri este opional i conine parametrii evenimentului separai prin virgul. Fiecare parametru poate fi o valoare explicit sau o variabil. Dac evenimentul nu are parametri, se omit i parantezele; - condiia de gard este, de asemenea, opional i indic o condiie care trebuie satisfcut pentru ca o tranziie s aib loc. O condiie poate fi exprimat n limbaj natural, n limbaj de programare sau OCL.

n exemplul unui calculator, putem avea evenimentele urmtoare: -Startup indic faptul c un calculator trece din starea surs, inactiv, n starea int, activ. Dac calculatorul este parolat, atunci exist parametrul UserID. De asemenea, exist posibilitatea ca un calculator s nu poat fi pornit din anumite motive (pan de curent), atunci se impune condiia de gard: dac calculatorul poate fi pornit. -Shutdown indic faptul c un calculator, din starea activ, trece n starea inactiv. Acest eveniment poate avea parametrul UserID. De asemenea, exist posibilitatea ca un calculator s nu poate fi nchis din anumite motive (de exemplu, nu au fost nchise toate aplicaiile), atunci se impune condiia de gard: dac calculatorul poate fi nchis. -Reset indic faptul c respectivul calculator poate trece din starea blocat n starea activ. - Eroare Sistem indic faptul c respectivul calculator are erori grave i trece din starea activ n starea blocat.

4) Aciuni: reprezint o prelucrare executat de un obiect aflat ntr-o stare surs, declanat n urma producerii unui eveniment (de exemplu, recepionarea unui mesaj). O aciune nu poate fi ntrerupt de evenimente. n UML, o aciune are urmtoarea sintax: Valoare_returnat:= element_int.nume_aciune (list argumente) unde: - Valoare_returnat este opional i indic numele pentru valoarea rezultat de aciunea declanat de un eveniment. Dac se omite acest cmp sau dac aciunea nu ntoarce nici o valoare, atunci se vor omite i caracterele :=. - Element_int este numele elementului care va executa aciunea. Dac elementul care enun aciunea este acelai cu elementul care primete evenimentul declanator al aciunii respective, atunci acest cmp se omite, mpreun cu caracterul punct (.). - Nume aciune este, de obicei, acelai cu numele operaiei elementului respectiv sau al operaiei elementului int, dac acesta este specificat. - List de argumente este opional i indic parametrii care particip la aciune, separai prin virgul. Fiecare parametru poate fi o variabil sau o valoare explicit.

variabil

Tipuri de evenimente i aciuni

n UML, exist patru tipuri de evenimente: a)apeluri de operaii; b)semnale; c)schimbarea condiiilor; d)scurgerea unui interval de timp. a) Eveniment apel de operaie Apelul de operaie este un eveniment care, atunci cnd se produce, determin schimbri n starea elementului care primete apelul. Acest tip de eveniment este numit mesaj, se implementeaz, de obicei, ca un mesaj sincron i apare n eticheta unei tranziii. Astfel, cnd un obiect transmite un mesaj altui obiect (sau lui nsui) i invoc o operaie, controlul trece de la obiectul expeditor la obiectul destinatar. Obiectul apelat execut tranziia asociat evenimentului respectiv, i schimb starea i transmite apelantului controlul. Apelurile de operaii pot fi mesaje asincrone, dac limbajul care le implementeaz suport calcul paralel.

b) Eveniment semnal Semnalul este un obiect expediat asincron de un obiect i recepionat de alt obiect. Acest tip de eveniment se numete tot mesaj i apare ca o semntur de eveniment ntr-o stare de tranziie. Semnalul poate declana o aciune obiectului receptor ntr-o main de stare, n urma creia obiectul respectiv i schimb starea, sau poate fi un mesaj asincron ntr-o diagram de interaciune. Semnalele pot avea parametri, care se scriu ntre paranteze rotunde. Semnalele sunt definite ca un tip special de clas, stereotipizate cu <<signal>>. Aceste clase sunt folosite numai pentru trimiterea mesajelor, nu pot avea operaii, iar eventualii parametri ai semnalului sunt trecui n compartimentul atributelor. Se poate construi o ierarhie de clase signal, adic ntre semnale pot exista relaii de generalizare, dar sunt excluse orice relaii cu clasele obinuite.

Dac o tranziie are o semntur de eveniment semnal, atunci toate subsemnalele vor putea fi recepionate prin acelai semnal, aa cum este ilustrat n figura de mai jos:

c) Eveniment schimbare Un eveniment schimbare reprezint trecerea unui obiect n alt stare, n funcie de satisfacerea unei condiii. Condiia apare n condiia de gard a semnturii unei tranziii. n UML, un astfel de eveniment este modelat cu cuvntul cheie when, urmat de o expresie boolean. Se poate folosi o expresie boolean pentru a indica o valoare (exemplu [when x=1]) sau pentru testarea continu a unei expresii (ca de exemplu, [when x<100]). d) Eveniment temporal Un eveniment temporal este o ntmplare care depinde de scurgerea timpului. El se reprezint n UML prin cuvntul cheie after, urmat de un interval de timp care reprezint timpul scurs din momentul tranziiei pn la schimbarea strii. Intervalul de timp poate fi redat n limbaj natural, expresie de timp, sau n orice mod, dar trebuie s fie ct mai explicit. Aceast combinaie after+expresie_timp se trece n semntura unei tranziii, la condiia de gard.
De exemplu, putem reprezenta evenimentele temporale, [after 5 secunde], [after 2 secunde de la prsirea strii], etc. ntr-un eveniment temporal, expresia din condiia de gard poate s nu fie precedat de cuvntul cheie after (de exemplu, putem scrie [timp = timpdat], n loc de [after timpdat]).

Activitile strilor
Pentru reprezentarea unei stri, se folosete tot dreptunghiul cu colurile rotunjite, compartimentat n trei zone: - Compartimentul superior este dedicat numelui strii, care trebuie s fie scris indiferent dac dreptunghiul este compartimentat sau nu. - n compartimentul din mijloc se scriu eventualele variabile de stare (contori, date, constrngeri, etc.). - n zona inferioar se trec activitile, unde vor fi specificate evenimentele i aciunile.

n cazul descrierii activitilor, evenimentele i aciunile au aceeai sintax ca i n cazul tranziiilor i anume: Nume eveniment (list_parametri) [condiie_gard] /element_int.nume aciune (list_argumente) Nume eveniment poate fi orice, dar, de obicei, exist trei evenimente standard care pot declana aciuni strilor, i anume: - entry specific aciunea care se produce atunci cnd obiectul intr n starea respectiv; - exit specific aciunea care se execut atunci cnd obiectul prsete starea respectiv; - do specific aciunea care se execut atunci cnd obiectul se afl n starea respectiv.

Diagrame de stare
- Concepte i exemple -

Studiu de caz: ceas cu alarm

1. Putem seta alarma pornit sau oprit; 2. La timpul setat, alarma sun continuu; 3. Putem opri soneria.

Pasul 1. Desenarea unei diagrame de stare

Modelarea propoziiei 1: Putem seta alarma pornit sau oprit

Modelarea propoziiei 2: La timpul setat, alarma sun continuu

Obs. Alarma trebuie s se opreasc si singur, dup trecerea unui anumit interval de timp O activitate n cadrul unei stri poate fi: continu: se produce doar atunci cnd un eveniment are loc i face ca obiectul s ias din stare; finit: poate fi oprit de un eveniment, dar se poate opri i singur dup trecerea unui anumit interval de timp sau la ndeplinirea unei condiii.

n exemplul de fa, se adaug o activitate Sun n starea Sonerie i o tranziie automat care s ias din starea Sonerie. O astfel de tranziie se mai numete completion transition i se reprezint n UML fr nume de eveniment sau cuvnt cheie.

Obs. Dac se dorete dezactivarea alarmei n timp ce sun, va trebui adaugat o tranziie din starea Sonerie n starea Oprit.

Desenarea diagramei statice de context extinse (extended static context diagram).

Diagrame de stare
- Concepte i exemple -

Studiu de caz: ceas digital

1. Modul curent e modul Afiare; 2. Cnd se apas o dat butonul, ecranul trece n schimb ora. Se poate schimba ora (prin incrementare cu 1) prin apsarea repetat a butonului de Avans; 3. Dac apsai butonul de mod din nou, ecranul trece n schimbare minute. Apsnd butonul Avans repetat, se modific minutele cu o unitate. 4. Apsnd nc o dat butonul Mod, ceasul trece n Afiare.

Desenarea diagramei de stare

Obs. n starea Afiare, e posibil s fie apsat butonul Avans, dar apsarea lui nu produce nici un eveniment, de aceea nu s-a mai reprezentat.

Se consider urmtoarea comportare: dac se apas lung butonul Avans (mai mult de 2 secunde), incrementarea orei sau minutelor se poate face mai repede Cum poate fi modelat un asemenea comportament? n exemplul de fa, apsarea butonului Avans o dat e echivalent cu perechea apasa i elibereaz. n condiiile noului comportament, se introduce evenimentul elibereaz buton pentru a gestiona eficient timpul de apsare. O prim soluie ar fi inserarea unei condiii asupra duratei de apsare, precum i a unei noi stri, numite Incrementare rapid (vezi figura de pe pagina urmtoare).

Obs. Soluia de mai sus e incorect, pentru c apsarea butonului nu poate fi contorizat n timp (aciunile sunt atomice).

Soluii posibile: introducerea unei activiti finite , ateapt 2 sec; folosirea cuvntului cheie after.

S presupunem acum c se introduc alte dou faciliti ceasului: buton de lumin i buton de alarm.

n acest caz, avem 3 comportamente concurente: 1. controlul afisrii; 2. controlul alarmei; 3. controlul luminii.

Le tratm n ordinea simplitii: 3. Controlul luminii

Obs. Controlul luminii poate fi modelat independent de controlul afirii i controlul alarmei. 1. Controlul alarmei se poate face ca n exemplul Ceas cu alarm.

1. Controlul afirii depinde de strile de pn acum, n sensul n care putem modifica, prin apsarea butonului Mod, i timpul de declanare a alarmei (prin modificarea orei i minutelor). De aceea, trebuie introduse 2 noi stri.

S punem toate comportamentele mpreun. - O prim soluie: prin intermediul unei diagrame de clas

- A doua soluie: artnd regiunile concurente din cadrul diagramei de stare. E

mai puin folosit dect prima soluie.

Diagrame de componente i de desfurare

Diagrame de componente
O diagram de componente prezint dependenele existente ntre diverse componente software (cod surs, cod binar, executabile, librrii cu legturi dinamice-DLL, etc.) care compun un sistem software. Aceste dependene sunt statice (au loc n etape de compilare sau link-editare) sau dinamice (au loc n timpul execuiei). O component este o parte fizic dintr-un sistem, un lucru real, care exist pe un calculator. n UML, noiunea de component poate s desemneze att un tip (o categorie) de obiecte, ct i fiecare obiect din tipul respectiv (instana tipului). De exemplu, o aplicaie executabil este o component care reprezint un tip (o categorie), n timp ce o aplicaie care se execut la un moment dat, care are o identitate n momentul execuiei, este o instan a acelui tip.

Reprezentare

Exemplu

Relaia dintre componente i clase Asemnri: - Au un nume format dintr-un ir de caractere. - Au instane, care au un nume separat prin : de numele clasei, respectiv al componentei. - Pot realiza interfee. - Pot participa la relaii de asociere, de generalizare, de dependen, de realizare i de agregare (clase sau componente incluse n alte clase, respectiv componente). Deosebiri: - Clasele sunt abstracii ale unui set de atribute i de operaii; componentele sunt pri fizice dintr-un sistem, rezidente ntr-un nod. Se utilizeaz componente cnd modelm un lucru rezident ntr-un nod; n celelalte cazuri, folosim, n modelare, clase. - Clasele au atribute i operaii, pe cnd componentele au numai operaii, accesibile numai prin intermediul interfeelor lor. - O component este implementarea fizic a uneia sau a mai multor entiti conceptuale, cum sunt clasele i colaborrile; ntre componente i implementrile ei exist o relaie de dependen.

Componentele folosite n UML pot fi mprite n trei categorii: Componente fundamentale (desfurare) care formeaz baza sistemelor executabile, ca de exemplu: executabile, DLL-uri, controale ActiveX, JavaBeans, componente COM+, pagini WEB, tabelele bazelor de date, etc. Componente create de utilizator care sunt produse rezultate din procesul de dezvoltare i care formeaz componentele fundamentale, ca de exemplu: fiiere cu codul surs i de date. Aceste componente sunt folosite n crearea, n modificarea i n dezvoltarea executabilelor. Componente de execuie create ca o consecin a folosirii unui sistem executabil. UML folosete i stereotipuri standard: <<executable>> - pentru o component care poate fi executat n noduri; <<library>> - pentru o component care reprezint biblioteci; <<file>> - pentru o component care reprezint un fiier de date sau fiier surs; <<table>> - pentru o component care reprezint o tabel a unei baze de date; <<document>> - pentru o component care reprezint un fiier document.

Interfee Componentele au numai operaii, care pot fi accesate numai prin intermediul interfeelor lor. Interfeele unei entiti (clase sau componente) reprezint un set de operaii pe care entitatea le pune la dispoziia celorlalte entiti i care sunt ascunse prin ncapsulare. Reprezentare

O interfa realizat de o component se numete interfa de export, n sensul c interfaa furnizeaz serviciile componentei celorlalte componente. O component poate furniza mai multe interfee de export. O interfa folosit de o component se numete interfa de import, n sensul c o component care acceseaz serviciile alteia trebuie s se conformeze interfeei acesteia.

Relaiile de dependen dintre componente Relaia de dependen dintre componente este o relaie de la o component client la o component furnizor (server) i semnific faptul c entitile (clasele) incluse n componenta client pot moteni, instania sau utiliza clasele incluse n componenta furnizor (server).

Dependenele dintre componente se reprezint, ca i n cazul claselor, prin linii punctate ntre componenta utilizator (client) i componenta furnizor de servicii (server), cu o sgeat orientat spre componenta furnizor. Se folosesc trei tipuri speciale de dependene stereotipizate, i anume: a) dependene de utilizare (use dependencies); b) dependene de apartenen (reside dependencies); c) dependene de desfurare (deploy dependencies).

a) Dependene de utilizare (use dependencies)

O dependen de utilizare este o relaie de la componenta utilizator (client) la componenta furnizor (server), care indic faptul c componenta client folosete sau depinde de componenta furnizor. O dependen de utilizare este reprezentat n mod asemntor cu relaia de dependen dintre clase, printr-o linie punctat, cu o sgeat spre componenta furnizor sau spre interfaa acesteia.

b) Dependene de apartenen (reside dependencies)

O dependen de apartenen este o relaie de la o component client la un element UML furnizor i indic faptul c elementul furnizor aparine componentei (asemntor relaiei de agregare dintre clase). Elementul furnizor poate fi o clas concret sau o clas stereotip (<<type>>, <<implementation class>>, <<interface>>), pachete sau subsisteme. Exemplu componente: - Interfaa Utilizator, care furnizeaz o interfa prin care utilizatorul poate interaciona cu sistemul; - Date pentru implementarea funcionalitii datelor memorate; pachete i subsisteme: - Interfaa Utilizator, care grupeaz clasele care furnizeaz interfaa cu utilizatorul; - Utiliti conine date, timpul i alte clase de utiliti; - Date - subsistem pentru prelucrarea datelor. interfee: IProduse produse realizate (create sau scrise); IConsumabile produse folosite (citite sau distruse).

- pachetul Utiliti aparine ambelor componente; - componenta Date conine i subsistemul Date, care este reprezentat n interiorul componentei (modul doi de reprezentare), n timp ce pachetul Utiliti este legat printr-o relaie de dependen de componenta client Date (modul nti de reprezentare); - deoarece ntre pachetele Utiliti i Interfa Utilizator exist o relaie de dependen, ele trebuie s fac parte din aceeai component, altfel pachetul Interfa Utilizator nu va putea fi utilizat.

Diagrame de desfurare
Diagrama de desfurare descrie structura sistemului n momentul execuiei. Ea prezint dispunerea fizic a diferitelor elemente hardware, numite noduri, care intr n componena unui sistem, i repartizarea programelor executabile pe aceste elemente. n diagrama de desfurare, se indic nodurile i conexiunile unui model. Noduri Un nod este resursa care este disponibil n timpul execuiei unui sistem software i reprezint un procesor sau un dispozitiv, pe care vor fi desfurate i executate componentele sistemului. Un procesor este un nod care poate executa o component (calculatoare n reea). Fiecare nod trebuie s aib un nume. La nivelul fiecrui procesor pot fi identificate procese. Un procesor trebuie s aib memorie i anumite capabiliti de procesare (dispozitive de calcul, resurse umane, etc.) Un dispozitiv (echipament periferic) reprezint un element hardware care, n sistemul din care face parte, nu are putere de calcul. Fiecare dispozitiv trebuie s aib un nume, care poate fi generic, ca de exemplu: monitor, imprimant, tastatur, modem, etc.

Distincia dintre un dispozitiv i un procesor depinde de punctul de vedere asupra acestora. De exemplu: un terminal T va fi privit ca un dispozitiv de ctre utilizatorul terminalului i ca un procesor pentru un produs software care se execut pe procesorul terminalului T. n UML, un nod se reprezint printr-un paralelipiped (de multe ori este un cub), care este etichetat cu numele nodului, ca n figura de mai jos:

Observaii privind numele unui nod: - n cazul n care nodul este o clas, numele poate fi stereotipizat; - n cazul n care nodul face parte dintr-un pachet, numele este prefixat de numele pachetului i separat de acesta prin simbolul ::; - n cazul n care nodul este un nod exemplu, numele su este urmat de simbolul : i de numele clasei de noduri, avnd toate prile numelui subliniate; ambele nume sunt opionale, iar simbolul : este prezent numai dac este specificat numele clasei de noduri;

Exemple

Clase de noduri: - Client tip procesor, pe care se execut componenta Interfa Utilizator; - ServerBaze tip procesor, pe care se execut componenta Date; - Imprimant tip dispozitiv, folosit de sistem pentru a lista rapoarte; Instane de clase de noduri: - Andrei: Client; Ana: Client; - O instan a nodului Server; - Hp100: Imprimant.

Organizarea nodurilor i legturile dintre ele Nodurile pot fi organizate n pachete, n acelai mod ca i clasele i componentele. O conexiune reprezint un tip hardware care realizeaz cuplarea ntre dou noduri. Conexiunea poate fi direct, ca de exemplu prin cablu, reea Ethernet, linii telefonice, etc., sau indirect, ca de exemplu conexiunea prin satelit.

unde T-connector

Dependene de desfurare O dependen de desfurare este o relaie de la o component, numit i component client, la un nod, numit nod furnizor, i indic faptul c nodul conine componenta respectiv. O dependen de desfurare poate fi reprezentat n dou moduri: - printr-o relaie de dependen (o linie punctat cu o sgeat) de la component la nod i avnd stereotipul <<desfurare>> sau <<deploy>>; - componenta este reprezentat n interiorul nodului pe care este desfurat (modul cel mai des utilizat).

Exemplu de diagram de componente i de desfurare Se consider, iniial, pachetele: Interfa Utilizator i Utiliti i subsistemul Raportare, care furnizeaz interfeele: IVizualizare (pentru vizualizarea pe ecran a rapoartelor) i IPrintare (pentru printarea rapoartelor). Pe parcurs se rafineaz diagrama cu urmtoarele cerine: 1. Pachetul Interfa Utilizator folosete interfeele IVizualizare i IPrintare, furnizate de subsistemul Raportare. 2. Pachetele Interfa Utilizator i Utiliti aparin componentei InterfaUtilizator. 3. Subsistemul Raportare i pachetul Utiliti aparin de componenta Raportare. 4. Componenta Interfa Utilizator este desfurat pe nodul Client. 5. Componenta Raportare este desfurat pe nodul Server Raport. 6. Nodul Client este conectat la nodul Server Raport, iar nodul Server Raport este conectat la nodul Imprimant .

Diagrame de interaciune

Introducere
Diagramele de interaciune permit specificarea n detaliu a modului n care obiectele interacioneaz pentru a executa un task. UML furnizeaz 2 tipuri de diagrame de interaciune: - diagrame de colaborare - diagrame de secven. Principala utilizare a acestor diagrame este de a ilustra modul n care sistemul realizeaz un caz de utilizare sau un anumit scenariu dintr-un caz de utilizare.

Diagrame de colaborare
Obiectele care interacioneaz pentru a executa un task mpreun cu legturile dintre ele formeaz o colaborare. Interaciunea este reprezentat de secven de mesaje care sunt transmise ntre obiecte. Diagrama de colaborare cuprinde urmtoarele elemente: a) Obiecte: dreptunghi n care sunt scrise numele obiectului i numele clasei, separate prin :, toate subliniate. Dac numele obiectului nu are o anumit semnificaie, poate fi omis (:NumeClasa); nu este indicat aceast utilizare dac exist dou obiecte din aceeai clas. b) Legturi: se reprezint la fel ca asocierile c) Actori: se reprezint la fel ca n diagramele use-case. n cazul n care colaborarea descrie un caz de utilizare, actorii din colaborare vor corespunde cu actorii din diagrama use-case corespunztoare. Pot exista mai muli actori, ns numai unul singur va iniia cazul de utilizare.

d) Mesaje: pe o diagram de colaborare, numele mesajelor se reprezint alturi de liniile ce descriu legaturile dintre obiecte, iar direcia de transmitere a mesajului e indicat printr-o sgeat. Dac un mesaj este transmis de la un obiect a:A ctre obiectul b:B, obiectul destinatar (b) trebuie s neleag mesajul, adic este necesar ca n clasa din care face parte obiectul (B) s existe o operaie corespunztoare mesajului. Cu alte cuvinte, construirea unor diagrame de interaciune contribuie la identificarea asocierilor dintre clase i a operaiilor claselor. E posibil ca prima soluie s nu fie cea optim. Cum circul mesajele? (n varianta procedural) Un obiect ncepe s lucreze atunci cnd primete un mesaj; se spune c n acel moment obiectul este activat. n cele din urm, el trebuie s trimit un rspuns celui care a trimis mesajul, iar ntre timp el poate fie s lucreze, fie poate trimite mesaje altor obiecte pentru a le face pe acestea s lucreze. Dac trimite un mesaj, el va fi n continuare activ, dar nu va putea s lucreze pn cnd nu va primi rspuns la acest mesaj. Cu alte cuvinte, mesajul este sincron, adic la transmiterea unui mesaj se transmite controlul celui care primete mesajul. n fiecare moment, totul poate fi imaginat ca o stiv de activri, fiecare activare fiind asociat cu un obiect care a primit un mesaj la care nu a rspuns nc. Obiectul asociat cu activarea aflat n vrful stivei are controlul i poate s lucreze; obiectele asociate cu celelalte activri ateapt rspuns la mesajele pe care le-au trimis.

Dac obiectul asociat activrii din vrful stivei trimite un mesaj, obiectul care primete mesajul primete i controlul, iar activarea sa va fi poziionat n vrful stivei. Pe de alt parte, obiectul asociat activrii din vrful stivei poate s-i termine lucrul i s rspund la mesajul care l-a activat, fiind astfel nlturat din stiv. n acest caz, urmtoarea activare va deveni vrful stivei, iar obiectul asociat acesteia va recpta controlul. Obs. Nu este necesar reprezentarea mesajelor de rspuns ntr-o diagram de colaborare. Pentru a ine evidena numrului de stive de activare, mesajele sunt numerotate, folosind urmtoarea regul: primul mesaj transmis de la un obiect la altul este numerotat cu 1 (nu este socotit primul mesaj de la actorul care iniiaz interaciunea la un obiect). Cnd un obiect a primete un mesaj, numrul acelui mesaj va fi folosit ca prefix pentru toate mesajele trimise pn cnd a rspunde la acest mesaj. Exemplu: dac mesajul care l activeaz pe a este numerotat cu 2.1, atunci toate mesajele trimise ntre acest moment i rspunsul la acest mesaj vor fi numerotate cu 2.1.n.

Fig. Exemplu de numerotare a mesajelor

Diagrame de secven
O astfel de diagram pune n eviden transmiterea mesajelor de-a lungul timpului.

Obiectele i actorii sunt reprezentai la captul de sus al unor linii punctate, care reprezint linia de via a obiectelor, adic timpul aa cum este perceput el de obiecte. Timpul ct este activat un obiect este reprezentat ca un dreptunghi subire ce acoper linia de via.

Opional, pri din acest dreptunghi pot fi haurate, pentru a indica perioada de timp ct acesta lucreaz. Tot opional pot fi reprezentate i rspunsurile la mesaje, printr-o linie punctat.

Faciliti suplimentare ale diagramelor de interaciune Mesaje de la un obiect ctre el nsui

ntr-o diagram de colaborare, se reprezint printr-o legtur ntre obiectul respectiv i el nsui. ntr-o diagram de secven, se reprezint printr-o sgeat de la linia de via a obiectului ctre ea nsi. n acest caz, dreptunghiul subire reprezentnd noua activare este puin deplasat fa de cel reprezentnd vechea activare.

Reprezentarea valorilor returnate de mesaje

n UML o valoare returnat este reprezentat pe sgeata reprezentnd mesajul iniial ca o atribuire ctre o variabil avnd un nume nou (vezi figura de pe pagina urmtoare).

Crearea i distrugerea obiectelor

a) Diagramele de colaborare arat care obiecte sunt create i distruse n timpul interaciunii folosind stereotipurile create i destroy naintea mesajelor corespunztoare. Alternativ, faptul c un obiect a fost creat sau distrus n cadrul interaciunii se poate reprezenta prin constrngerile {new}, respectiv {destroyed} plasate n dreptunghiul care reprezint obiectul (vezi figura de pe pagina urmtoare). Dac un obiect este att creat ct i distrus n timpul interaciunii, se poate folosi constrngerea {transient}. b) Diagramele de secven arat c un obiect este creat prin plasarea acestuia n josul paginii. Distrugerea unui obiect este reprezentat printr-un X la sfritul dreptunghiului reprezentnd perioada de activare. Dac un obiect e distrus de alt obiect va exista un mesaj de la obiectul care efectueaz operaia de distrugere ctre semnul X.

Reprezentarea constrngerilor de timp

La diagramele de secven, e util de tiut i momentele efective la care apar mesajele. Modalitatea eficient furnizat de UML este scrierea unor constrngeri de timp.

Reprezentarea la diferite nivele de abstracie

Pentru ca interaciunea s fie descris la un nivel mai nalt de abstracie, se poate folosi o subcolaborare, adic o submulime de obiecte mpreun cu legturile dintre ele. O subcolaborare poate fi privit ca un singur element i poate fi reprezentat ca un pachet.

Exprimarea condiiilor
n UML transmiterea unui mesaj poate depinde de ndeplinirea unei condiii. n cadrul diagramei, condiiile vor aprea n paranteze drepte i vor fi poziionate n faa mesajelor corespunztoare. Dintr-un punct pot pleca orice numr de mesaje, cu condiia ca acestea s aib condiii disjuncte. O diagram de secven cu mesaje alternative nsoite de condiii poate fi implementat folosind structuri if-else sau case. n cazul n care mai multe mesaje alternative sunt trimise aceluiai obiect, pentru a scoate n eviden c una dintre alternativele respective nu poate fi aleas dect una i ele nu pot exista simultan, n diagramele de secven linia de via a obiectului destinatar va avea mai multe ramificaii, fiecare corespunznd unei alternative.

Exemplu. S presupunem exemplu cu centrul de nchirieri CD-uri i casete, adugm ipoteza c exist 2 tipuri de CD-uri: obinuite i speciale. CD-urile obinuite pot fi mprumutate pentru o perioad mai lung (3 sptmni), n timp ce CD-urile speciale mai puin (1 sptmn).

Iteraii
Pentru a arta c un mesaj poate fi trimis n mod repetat se folosete un asterisc poziionat dup numrul mesajului. n plus, dup asterisc se poate indica o clauz de iteraie (plasat ntre paranteze drepte), care determin de cte ori va fi trimis mesajul. Exemple: [n<10]: este echivalentul condiiei while; [not x]; [i:=1..10]: este echivalentul condiiei for; [y in Y]: mesajul e trimis n mod repetat pentru fiecare y din colecia Y

Figura de mai jos reprezint diagrama de secven pentru cazul unui client care cumpr un numr de produse dintr-un magazin.

Dac un mesaj care e transmis n mod repetat are ca rezultat transmiterea unui alt mesaj, atunci transmiterea acestuia din urm va fi repetat ori de cte ori e transmis i primul mesaj, dar acest lucru nu va fi artat pe diagram. Exemplul1. Ce rezultat va avea figura de mai jos?

Rspuns: xyxy.

Exemplul1. Ce rezultat va avea figura de mai jos?

Rspuns: xyyxyy.

Concurena
Pn acum s-a considerat tipuri de interaciune procedural, n care, dup transmiterea unui mesaj, obiectul care trimite mesajul ateapt rspunsul nainte de a-i continua funcionarea. Este cazul cel mai ntlnit n practic, deoarece majoritatea sistemelor funcioneaz pe un singur procesor. n cadrul sistemelor concurente, exist cazurile: un obiect trimite simultan mai multe mesaje: se reprezint prin mai multe sgei care pleac din acelai loc, fr a avea asociate condiii un actor sau un obiect activ trimite un mesaj la un anumit moment, dei obiectul care lucreaz n acel moment este alt obiect din sistem un obiect trimite un mesaj asincron, adic un mesaj care poate face ca alt obiect s lucreze fr ca obiectul care atrimis mesajul s-i nceteze lucrul. n primul caz, schema de numerotare mbricat descris mai devreme va fi extins, n sensul posibilitii ca la numerotarea mesajelor s apar nume sau litere care s diferenieze mesajele trimise simultan. n ultimele 2 situaii, schema de numerotare mbricat i pierde sensul, putndu-se folosi numerotarea secevnial.

Tipuri de mesaje
Exist mai multe tipuri de mesaje n UML: mesaje sincrone : specifice funcionrii procedurale mesaje de rspuns : reprezentarea e opional mesaje asincrone : nu ateapt rspuns, obiectul rmne activ mesaje simple : nu ateapt rspuns, obiectul pierde controlul

Exemplul1. La centrul de nchirieri se consider c exist i o component de statistic, responsabil cu evidena CD-urilor care devin indisponibile la un moment dat (toate copiile au fost mprumutate).

Figura arat folosirea unui mesaj asincron.

Exemplul2 (pentru folosirea mesajelor simple). Automat pentru buturi: cerine casa de bani va verifica dac suma de bani introdus de client corespunde cu preul buturii selectate; dac suma este egal cu preul, containerul de buturi va livra produsul; dac suma este mai mare dect preul, casa de bani va calcula restul i va verifica dac acesta e disponibil n cas; n cazul n care restul e disponibil, casa de bani returneaz acest rest, iar magazia ofer produsul selectat; dac restul nu e disponibil, casa de bani va returna banii clientului; dac suma introdus de client e mai mic dect preul produsului, casa de bani va atepta mai muli bani i nu va face nimic.