Sintaxa şi semantica limbajului de modelare UML

Alfabet şi cuvinte

Alfabetul defineşte cele mai mici părţi ale limbajului; UML este alcătuit din simboluri (dreptunghiuri, linii şi alte elemente grafice) şi din şiruri de caractere. Cuvântul este cea mai mică unitate semantică de limbaj. Un cuvânt este un grup format din elementele alfabetului, care are un înţeles.

În UML, cuvintele sunt grupate în două categorii mari:• entităţi sau concepte – desemnează o serie de abstracţii şi sunt reprezentate prin simboluri etichetate cu nume;• relaţiile dintre entităţi – desemnează tipurile de legături care pot exista între entităţi. Ele sunt reprezentate prin linii de legătură între simboluri şi au un nume. Cuvintele limbajului alcătuiesc vocabularul limbajului.

Propoziţii şi paragrafe

Propoziţiile UML sunt fragmente de diagrame sau diagrame simple .

• O companie de asigurări 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 orientării pe obiecte. !

În UML, diagramele fac parte din două categorii:

• Diagrame statice sau structurale - descriu structura, responsabilităţile sistemului informatic, componentele executabile ale sistemului, locaţiile fizice de execuţie ş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 interacţiunile dintre diverse entităţi 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 relaţiile invariante dintre componentele unui sistem. Din punct de vedere al modelării sistemelor orientate pe obiecte din perspectiva UML, aspectele statice sunt: clasele şi relaţiile dintre clase, interfeţele, topologia hard necesară execuţiei aplicaţiei.

A1) Diagrama claselor (Class Diagram)• Descrie structura unui sistem în general. În componenţa ei intră clase, stereotipuri şi relaţiile dintre acestea. Acest tip de diagrame este cel mai des întâlnit î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 instanţe ale ei şi este formată din obiecte şi relaţiile (legăturile) dintre ele. Este folosită în exemplificarea unei diagrame a claselor de complexitate mare, permiţând vizualizări statice ale instanţelor actuale şi ale relaţiilor.

A3) Diagrama cazurilor de utilizare (Use Case Diagram)

• Descrie funcţionalitatea unui sistem.

• Prezintă actorii externi, cazurile de utilizare identificate numai din punct de vedere al actorilor (comportamentul sistemului, aşa cum este perceput de utilizatorii lui), nu şi din interior, precum şi relaţiile dintre actori şi cazurile de utilizare.

• Un actor poate fi orice sau oricine interacţionează cu sistemul (trimite sau recepţionează mesaje de la sistem sau schimbă informaţii 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 iniţiat 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 relaţii î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 relaţiile dintre acestea.

• Acest tip de diagramă realizează o mapare de la view-ul static (logic) la view-ul componentelor. O componentă poate să conţină un cod sursă sau să fie sub formă binară sau executabilă. O componentă se mapează, de obicei, pe una sau mai multe clase, interfeţe sau colaborări; din această cauză, diagrama componentelor are legătură cu diagrama claselor.

• Diagramele de componente reflectă vederea statică de implementare asupra sistemului.

5) Diagrama de desfăţurare (Deployment Diagram)

• Diagrama de desfăşurare 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 interacţiune (Interaction Diagram)• Descrie interacţiunile în timp între obiecte, relaţiile şi mesajele care circulă între acestea. Diagramele de interacţiune 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 număr de obiecte, punând accentul pe secvenţe de mesaje trimise între acestea pe măsura 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 interacţiune, dar, pe lângă interacţiunea dintre obiecte (schimbul de mesaje), prezintă şi obiectele şi legăturile dintre ele. Când trebuie să decidem ce tip de diagramă trebuie folosit pentru a ilustra o interacţiune, avem în vedere aspectul cel mai important de evidenţiat.

Obs. Se vor folosi diagramele de secvenţă dacă cel mai important aspect este timpul sau secvenţa de mesaje şi vom folosi diagramele de colaborare când trebuie evidenţiat contextul.

B2) Diagrama de stare (State Diagram)• Descrie ciclul de viaţă al unui element (al obiectelor, al subsistemelor şi al sistemelor), prin specificarea stărilor în care se găseşte un element şi a evenimentelor (mesaje, erori, condiţii care devin adevărate) care îi modifică starea (tranziţie).

Obs. Este indicat să se construiască diagrame de stare numai pentru clasele din sistem care au un număr de stări bine definit şi în care comportamentul clasei este influenţat de acestea. Aceste diagrame intră în modurile de vizualizare design şi de proces asupra sistemului.

B3) Diagrama de activitate (Activity Diagram)• Prezintă activităţile şi responsabilităţile elementelor sistemului.

• Diagramele de activitate au ca elemente constitutive stări de acţiune (Action States) şi mesaje care vor fi trimise sau recepţionate ca parte a acţiunii realizate.

• Reflectă vederea dinamică de design şi de proces şi sunt utilizate pentru modelarea funcţiilor sistemului.

Secţiuni (Views)Secţiunile 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.

Secţiunile UML sau modurile de vizualizare sunt grupuri de diagrame care se adresează unei anumite mulţimi de concepte (entităţi).

Modelul capturează cunoştinţe şi le comunică sub formă de mod de vizualizare sau, pe scurt, “view” (arhitectural views).

Fiecare view focalizează atenţia 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 instituţii.

Un sistem poate fi descris luând în considerare următoarele aspecte: • funcţional - este descrisă structura statică şi comportamentul dinamic al sistemului;• non-funcţional - 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 număr de diagrame care conţin informaţii 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 funcţionalitatea sistemului, aşa cum este ea percepută de actorii externi care interacţionează cu sistemul, precum şi de utilizatorii acestuia, de diferiţi membri ai echipei realizatoare sau de alte sisteme.

• În componenţa lui intră diagramele cazurilor de utilizare pentru descrierea statică a aspectului funcţional şi ocazional.

• Se pot folosi şi diagrame de activitate pentru a încapsula latura dinamică a funcţionalităţii.

• Cei interesaţi de această perspectivă sunt clienţii, 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 cerinţele funcţionale ale acestuia, adică prezintă serviciile asigurate de sistem utilizatorilor săi.

• Vizualizarea logică tratează din interior sistemul şi descrie atât structura internă a acestuia, formată din clase, obiecte şi relaţii, cât şi colaborările care apar în urma schimbului de mesaje între obiecte, pentru a realiza funcţionalitatea dorită.

• Structura statică este descrisă de diagramele de clasă şi de obiecte, care includ elementele şi relaţiile care alcătuiesc sistemul.

• Pentru modelarea dinamicii sistemului, se vor folosi diagrame de stare, de secvenţă, de colaborare sau de activitate.

• Cei care sunt interesaţi 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, dependenţele care există între ele, resursele alocate acestora, precum şi rezolvarea unor probleme legate de reutilizarea, portabilitatea codului, informaţii administrative, cum ar fi un desfăşurător al muncii de dezvoltare.

• Este folosit de dezvoltatorii sistemului, iar în componenţa 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 cerinţele 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 interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şi interogatorii de sistem.

V5) Modul de vizualizare desfăşurare sau mediu(The deployment or environment view)

• În acest mod de vizualizare sunt surprinse desfăşurarea 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 desfăşurare, care indică modul de implementare a sistemului. În acest sens, ele poartă etichete care specifică repartizarea pe tipuri de activitate şi informaţii despre procesele executate în noduri.

• De acest tip de vizualizare sunt interesaţi dezvoltatorii, interogatorii de sistem, precum şi cei care realizează testarea sistemului.

Documente (Modele)

Un document este format dintr-un număr de secţiuni care descriu un subiect comun şi pot fi cărţi, articole etc.

Documentele UML sunt modele. Un model este o reprezentare a unui sistem. View-urile (secţiunile) sunt grupate formând 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 defineşte 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 când ar fi proprietatea lui.

Putem stabili relaţii între pachete, dar numai între tipuri, nu şi între instanţe (pachetele nu au semantică definită de instanţe).

Un pachet poate să aibă vizibilitate, ca şi clasele, prin care se precizează modalitatea prin care alte pachete pot să-i acceseze conţinutul.

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 proiectării.

Notele sunt corespondentul comentariilor din limbajele de programare.

Notele pot conţine orice informaţie, 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 colţul dreapta sus îndoit, în interiorul căruia se află informaţia dorită.

Nota este ataşată 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 înţeles specific asociat unui element. El se reprezintă printr-un cuvânt între paranteze unghiulare duble (“<< >>”), scris deasupra sau dedesubtul numelui elementului asociat.

Obs. Un stereotip transformă un element în altul cu un înţeles nou.

Exemplu. Dacă se ataşează stereotipul <<table>> clasei Examene, acesta va reprezenta o bază de date tabelară.

Proprietăţi

Proprietăţile sunt elemente de extindere UML, care lărgesc proprietăţile şi semantica unui element UML.

Ele se reprezintă printr-o listă de şiruri de caractere între acolade ({ }), scrise deasupra sau dedesubtul elementului UML.

Şirurile de caractere care reprezintă proprietăţile pot fi de două forme:• valoare etichetată (tagged value) - se exprimă prin perechea "string = valoare" şi reprezintă caracteristicile unui element şi valorile sale;• constrângeri (constraints) - se exprimă în OCL (Object Constraint Language) şi reprezintă condiţiile pe care trebuie să le satisfacă elementul.

Exemplu. valorile etichetate ale clasei EXAMENE sunt versiunea şi autorul, iar constrângerea 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 anddesigners, 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 implicaţi şi cei cărora li se adresează.

De ce este important procesul software?Deoarece dovedeşte stabilitate, control şi organizare.

Care sunt paşii?Depind de software-ul pe care îl construim.

Care este produsul muncii?În ochii inginerului de sistem produsul este format din programe,documentaţie şi datele produse ca urmare a activităţii de inginerie software definită de proces.

Proces software – o tehnologie pe nivele

IEEE defineşte astfel Ingineria software: (1)Aplicarea unei abordări sistematice, disciplinate, cuantificabile

asupra dezvoltării, punerii în funcţiune şi mentenanţei software-ului(2)Studiul abordărilor de la (1).

Nivelul Proces: defineşte un cadru pentru o mulţime de zone cheie de proces (key process areas). Aceste zone formează baza controlului managementului proiectului software şi stabileşte contextul în care sunt aplicate metodele tehnice, sunt obţinute produsele muncii (modele, documente, date, rapoarte, forme etc.), sunt stabilite “pietrele de hotar”(milestones), e asigurată calitatea şi se administrează potrivit schimbările.

Nivelul Metode: răspunde la întrebarea : Cum construim software-ul? şi cuprinde un spectru larg de sarcini, care includ: analiza cerinţelor, designul, construirea programului şi testarea. Metodele de inginerie software includ activităţi de modelare şi alte tehnici descriptive.

Nivelul Instrumente: furnizează suport automat pentru proces şi metode. Când instrumentele sunt integrate, astfel încât informaţiile 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 conţine informaţii importante despre analiză, design, construcţia programului şi testare).

Modele de procese software

1) Modelul secvenţial 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 secvenţial liniar (cascadă)

Presupune activităţile:

i) Ingineria de sistem şi modelarea: stabilirea cerinţelor pentru elementele sistemului

ii) Analiza cerinţelor software: trebuie înţelese comportarea software-ului, interfaţa, performanţele dorite etc.

iii) Design: e de fapt un proces în mai mulţi paşi, ce se concentrează pe : structura datelor, arhitectura software-ului, reprezentarea interfeţei şi detaliul procedural (algoritmic).

iv) Generarea codului: care translatează design-ul în program.

v) Testarea: depistarea eventualelor erori (errors), defecte (faults) şi eşecuri (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 cerinţele• O versiune care să poate fi prezentată poate veni după mult timp

• Natura liniară a modelului poate conduce la stări de blocaj, când o echipă implicată în proiect este nevoită să aştepte rezultatele altor echipe

Obs. Modelul secvenţial liniar e cunoscut în literatură sub denumirea classic life cycle.

2) Modelul prototipului

Adesea, un client defineşte o serie de obiective pentru software, dar nu identifică în detaliu cerinţele de input, de procesare sau de ieşire. În alte cazuri, dezvoltatorul poate să aibă îndolieli cu privire la eficienţa algoritmului, adaptabilitatea la un SO sau la forma de interacţiune om/calculator. Pentru aceste e indicat acest model.

Clientul şi dezvoltatorul se întâlnesc pentru a stabili obiectivele de ansamblu şi a identifica oricare dintre cerinţele 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 aşteaptă la input şi formatul output-ului).

Apare un prototip. Prototipul e evaluat de client şi folosit pentru a rafina cerinţele.

Apare iteraţia, care pune în acord cerinţele clientului cu proiectul şi ajută pe dezvoltator să înţeleagă mai bine ce se doreşte.

Ce facem cu prototipul dacă îndeplineşte condiţiile?

“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 Man-Month, Addison-Wesley, 1975.)

Concluzie. Deşi pot apărea 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 secvenţial liniar.

Modelul RAD cuprinde următoarele etape:

i) Business modeling. Fluxul informaţiilor printre funcţiile business e modelat într-un mod ce răspunde la întrebările:

• Ce informaţii conduc procesul de business?• Ce informaţii sunt generate?• Cine le generează?• Unde se duc informaţiile?• Cine le procesează?

ii) Data modeling. Fluxul informaţiilor ca parte a etapei de business modeling sunt rafinate într-o mulţime de obiecte de date necesare pentru a susţine business-ul.

iii) Process modeling. Obiectele de date obţinute în etapa anterioară sunt transformate pentru a obţine fluxul de informaţii necesar pentru a implementa o funcţie business. Descrierile de proces sunt create pentru adăugarea, modificarea, ştergerea şi găsirea unui obiect de date.

iv) Generarea aplicaţiei. 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, aşa încât timpul total de testare este redus considerabil. Totuşi noile componente trebuie testate şi toate interfeţele trebuie atent verificate.

Fiecare funcţie 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 numărul corect de echipe RAD.

• RAD necesită dezvoltatori şi clienţi care se obligă la activităţi rapide necesare pentru a obţine un sistem complet într-un timp redus

• Nu toate aplicaţiile sunt potrivite pentru RAD. Dacă un sistem nu poate fi modularizat, construirea componentelor necesare pentru RAD devine problematică.

• RAD nu e potrivit când riscurile tehnice sunt mari. Acest lucru apare când o nouă aplicaţie foloseşte intens o nouă tehnologie sau când un software nou cere un grad înalt de interoperabilitate cu programele existente.

Business modelingScopul business process engineering (BPE) este să definească arhitectura ce va permite business să utilizeze eficient informaţiile.

Se analizează şi se specifică design-ul pentru

Arhitectura datelorArhitectura aplicaţiilorInfrastructura tehnologică

1) Arhitectura datelor are ca blocuri constitutive obiectele de date (data object). Un obiect de date conţine o mulţime de atribute care descriu un anumit aspect, calitate, caracteristică a datelor ce sunt descrise.

Exemplu: obiectul Customer

O relaţie (relationship) indică cum sunt conectate obiectele unul cu altul. Exemplu: pentru obiectele Customer şi produsA, o relaţie poate fi cumpără.

2) Arhitectura aplicaţiei cuprinde acele elemente ale sistemului care transformă obiectele în cadrul arhitecturii datelor pentru un anumit scop de business.

3) Infrastructura tehnologică asigură fundaţia pentru arhitecturile datelor şi aplicaţiei. Cuprinde hardware-ul şi software-ul care sunt folosite: computere, SO, reţele, legături de telecomunicaţii, tehnologii de stocare şi arhitectura (ex: client – server).

Pentru a modela arhitecturile descrise, se defineşte o ierarhie a activităţilor ingineriei proceselor business.

World view e obţinută prin Information strategy planning (ISP). ISP vede întreg întregul business ca o entitate şi izolează domeniile business-ului (ex: inginerie, manufacturare, marketing etc.). ISP defineşte obiectele de date care sunt vizibile la nivelul întreprinderii şi relaţiile dintre ele .

Domain view se obţine cu o activitate a BPE numită business area analysis (BAA), care identifică în detaliu datele (sub forma tipurilor entităţilor, adică a obiectelor de date) şi cerinţele funcţiilor (sub forma proceselor) ale domeniilor de business în timpul ISP şi stabileşte interacţiunile dintre ele.

Odată un information system izolat, BPE face o tranziţie spre ingineria software. Invocând pasul business system design (BSD), sunt modelate cerinţele de bază ale unui information system şi aceste cerinţe sunt translatate în arhitectură de date şi de aplicaţie şi infrastructură tehnologică.

Data modeling

Răspunde la un set de întrebări specifice:

• Care sunt obiectele de date primare procesate iniţial de sistem?• Care e compoziţia fiecărui obiect de date şi ce atribute descriu obiectul?• Unde “stau” în mod curent obiectele?• Care sunt relaţiile dintre obiecte?• Care sunt relaţiile dintre obiecte şi procesele care le transformă?

Apelează la diagrama relaţiilor dintre entităţi (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 specificaţiile dezvoltatorului.

Paradigma 4GT pentru ingineria software pune accentul pe abilitatea de a specifica software folosind forme de limbaj specializat sau notaţii grafice ce descriu problema propusă spre rezolvare în termeni pe care clientul poate să-i înţeleagă.

În mod curent, un mediu de dezvoltare software ce suportă paradigma 4GT include o parte dintre următoarele instrumente (tools): • limbaje neprocedurale pentru interogările bazei de date;• capabilităţi grafice de nivel înalt;• capabilităţi de tip spreadsheet;• generare automată a HTML şi a limbajelor similare folosite pentru crearea site-urilor Web utilizând instrumente software avansate.

4GT (Fourth Generation Techniques) (continuare)

Concluzii privind paradigma 4GT:1) Folosirea 4GT e o abordare viabilă pentru multe zone de aplicaţii. Combinată cu alte instrumente CASE şi generatoare de cod, 4GT reprezintă o soluţie de încredere pentru multe probleme software.

2) Folosind 4GT, timpul necesar pentru producerea software-ului e mult redus pentru aplicaţii mici şi mijlocii şi de asemenea efortul pentru design şi analiză pentru aplicaţiile 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 testări, în ciuda timpului salvat obţinut din eliminarea codului.

4) Modele pentru procese software evolutive: sunt iterative, adică permit dezvoltarea crescătoare 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 fişierelor şi editarea la primul increment; editare mai sofisticată la al doilea increment; spelling şi verificare gramaticală în al treilea increment şi capabilităţi avansate de proiectare a paginii la al patrulea increment.

Obs. Primul increment e adesea un miez al produsului (core product), adică cerinţele de bază sunt îndeplinite, dar mai multe capabilităţi (unele cunoscute, altele necunoscute) rămân nepredate.Acest core product e folosit de client. Ca rezultat al utilizării sau al evaluării, se dezvoltă un plan pentru următorul increment, care stabileşte modificarea core product-ului pentru îndeplinirea mai bună a cerinţelor clientului şi furnizarea funcţionalităţilor adiţionale. Acest proces e repetat după livrarea fiecărui increment, până se conturează întregul produs.Concluzii.• Modelul incremental e iterativ (ca şi modelul prototipului), dar se concentrează pe livrarea unui produs operaţional la fiecare increment. Versiunile iniţiale nu se regăsesc în produsul final, dar furnizează capabilităţi nesecare utilizatorului.• Modelul incremental e util când echipa de dezvoltatori nu e disponibilă toată perioada. Core product-ul poate fi realizat cu mai puţini oameni.

b) Modelul spirală: combină natura prototipului cu aspectele sistematice controlate ale modelului cascadă. Software-ul e dezvoltat într-o serie de livrări incrementale. În timpul primelor iterări, livrarea poate fi un model pe hârtie sau un prototip. În timpul iterărilor 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 comunicări efective între dezvoltator şi client

• Planificarea: tasks pentru definirea resurselor, a planificărilor temporale şi a altor informaţii în legătură cu proiectul

• Analiza riscurilor: tasks pentru stabilirea în egală măsură a riscurilor ehnice şi manageriale

• Tehnologia (engineering): tasks pentru construirea uneia sau a mai multor reprezentări ale aplicaţiei

• Construirea şi livrarea: tasks pentru construirea, testarea, instalarea şi asigurarea suportului utilizatorului (ex: documentaţie şi training)

• Evaluarea clientului: tasks pentru obţinerea unui feed-back din partea clientului, bazat pe evaluarea reprezentărilor software create în timpul etapei de engineering şi implementate în timpul etapei de instalare

Echipa de dezvoltatori se mişcă în spirală în sensul acelor de ceasornic, începând din centru.

Primul circuit în jurul spiralei ajută la dezvoltarea specificaţiilor produsului.

Următoarele 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ă numărul de iteraţii 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 obţine examinând 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” porneşte de la miezul spiralei şi continuă până ce devine completă dezvoltarea conceptului.

Concluzii

• Modelul spirală e o abordare potrivită pentru sistemele de maridimensiuni.• Modelul spirală foloseşte prototipul ca un mecanism de reducere a riscurilor dar, mai important, permite dezvoltatorului să aplice abordarea prototipului la orice etapă din evoluţia proiectului.

• Modelul spirală menţine 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 aşa cum se folosesc modelul liniar secvenţial şi modelul prototipului.

c) Modelul WINWIN

“Eliciting software requirements demands negociation. Successful negotiation occurs when both sides « win ».”

Stakeholder = cineva din organizaţie care are un interes de afaceri direct în construirea sistemului sau produsului şi care va fi recompensat pentru succes şi criticat pentru un eşec.

Modelul spiral al lui Boehm (Boehm, B., “Using the WINWIN Spiral Model: A Case Study,” Computer, vol. 31, no. 7, July 1998, pp. 33–44) defineşte o serie de activităţi de negociere la începutul fiecărei treceri în jurul spiralei:

1. Identificarea stakeholders ai sistemului sau subsistemului.

2. Determinarea condiţiilor de câştig (“win conditions”) ale stakeholders.

3. Negocierea acestor condiţii pentru a le reconcilia într-un set de condiţii win-win pentru toţi cei implicaţi (inclusiv pentru echipa proiectului software).

În afară de cele 3 activităţi de negociere menţionate, modelul spirală mai introduce 3 anchor points:• Life cycle objectives (LCO): defineşte un set de obiective pentru

fiecare activitate majoră de inginerie software.• Life cycle architecture (LCA): defineşte obiectivele de trebuie

îndeplinite când se defineşte arhitectura software-ului.• Initial operational capability (IOC): defineşte obiective în legătură cu

pregătirea 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)

Modelul concurent se foloseşte ca paradigmă pentru dezvoltarea aplicaţiilor client-server.

Toate activităţile există concurent, dar se găsesc în diferite stări.

Concepţii şi principiiorientate-obiect

CLASE, OBIECTE, INSTANŢE

O clasă descrie structura şi comportarea unei mulţimi de obiecte similare.

Un obiect este o instanţă prezentă la rulare şi care alocă memorie pentru varibilele instanţei; se comportă conform protocolului clasei sale.

Clasă (class) Obiect (Object)

Class Object«instance of»

ATRIBUTE, OPERAŢII, RESTRICŢII, RELAŢII

(Attributes, Operations, Constraints, Relationships)

Principiul încapsulării (encapsulation): Clasele combină atribute şi operaţii într-o singură unitate. Atributele sunt accesibile doar prin intermediul operaţiilor (adică indirect).

•Atribute: definesc structura obiectelor, i.e. componentele lor şi informaţia sau datele conţinute în ele

•Operaţii: descriu comportarea (behaviour) obiectelor; se pot folosi termenii servicii, metode sau (eronat) proceduri sau funcţii

•Restricţii: condiţiile, cerinţele şi regulile pe care obiectele trebuie să le satisfacă

•Relaţii: de moştenire (inheritance), asociere şi de asemănare (like).

ExempluUn cerc pe care vrem să-l reprezentăm are următoarele proprietăţi (printre altele):

•Atribute: raza şi poziţia pe ecran (x,y).

•Operaţii: posibilitatea afişării, ştergerii, repoziţionării şi redimensionării.

•Restricţii: raza să fie strict pozitivă (r > 0).

•Relaţii: nu este cazul.

Numele clasei

Numele atributelor

Tip de atribut

Restricţie

Valoare iniţială

Parametri

(Nume: tip=valoare iniţială)Operaţii

Pe de o parte, în timpul analizei şi design-ului, clasele sunt modelate, adică se iau în considerare proprietăţile şi relaţiile.

Pe de altă parte, diagramele use case şi altele sunt folosite pentru a reprezenta interacţiunea 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 instanţei

Numele atributelor

Numele clasei

Valori ale atributelor

Identitatea obiectelor

Principiul identităţii obiectelor: Fiecare obiect e prin definiţie unic diferit de toate celelalte obiecte, independent de valorile concrete ale atributelor sale.

Principiul coerenţei

Principiul coerenţei: Fiecare clasă trebuie să fie responsabilă pentru (exact) un aspect (logic) al întregului sistem. Proprietăţile situate în această arie de responsabilităţi trebuie grupate într-o singură clasă şi nu disipate în mai multe clase. Mai mult, o clasă nu trebuie să conţină proprietăţi care nu sunt în aria ei de responsabilitate.

Responsabilităţile trebuie formulate succint şi în modul general.

Taxonomie şi moştenire (inheritance)

Principiul moştenirii: Clasele pot reprezenta specializări ale altor clase, i.e. clasele pot fi organizate ierarhic şi “moştenesc” (inherit) proprietăţi ale claselor situate deasupra; la nevoie, pot fi suprascrise (overwrite), dar nu eliminate.

Principiul substituţiei: Obiectele din subclase pot fi întotdeauna folosite în locul obiectelor din supraclasa(e).

Moştenirea = reutilizarea proprietăţilor

Relaţia de moştenire e reprezentată printr-o săgeată, cu subclasa punctând pe supraclasă.

Evitaţi moştenirea dacă aveţi alternative.

Exemplu (moştenire simplă)

Obs. Operaţiile display(), remove() trebuie să fie operaţii abstracte în GeomFigure, doar în clasele Circle ... ele devin operaţii concrete.

Obs. Operaţia setPosition() se poate imple-menta in GeomFigure.

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

Moştenire: restricţii şi probleme

Principiul responsabilităţii restricţiilor: O subclasă nu trebuie să includă nici o restricţie asupra proprietăţilor supraclasei.

Clase abstracte

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

ClaseInstanţe

Asocieri

O asociere e o relaţie între diferitele obiecte ale uneia sau ale mai multor clase.

O asociere primeşte un nume şi o specificaţie numerică (cardinalitate) care arată câte obiecte dintr-o parte a asocierii sunt asociate cu câte obiecte din cealaltă parte.

Se pot adăuga şi nume de roluri, care descriu semnificaţia claselor.

Obs. Dacă nu e specificată direcţia în asociere, se consideră a fi o asociere bidirecţională.

Agregări

O agregare e o formă specială de asociere. Este tot o asociere între două clase, cu observaţia că aceste clase se referă una la alta precum întregul la părţile sale.

Un formă specială e cea în care părţile individuale depind de întreg pentru existenţa lor; se numeşte compoziţie (composition)

Compoziţie

Agregare

Obs. Cel puţin la început, e permisă cardinalitatea 0 pentru un agregat.

Agregări (continuare)Într-o agregare, partea întregului e marcată cu un romb. Compoziţiile 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 unităţi independente care cooperează şi interacţionează prin intermediul mesajelor pe care şi le trimit unul altuia.

Un mesaj e reprezentat de numele operaţiei (cu argumente între paranteze, dacă e cazul) şi o săgeată care arată sensul mesajului.

Obs. Un mesaj nu e o operaţie (adică, în sensul clasic, un apel de procedură sau funcţie).

Colecţii

Colecţiile sunt clase definite uzual în librăriile de clase standard şi au în comun faptul că ele adună şi gestionează mulţimi de obiecte. Se mai numesc şi clase container (container classes).

Colecţiile au toate operaţiile pentru adăugarea şi ştergerea obiectelor, verificarea dacă un obiect dat e conţinut în mulţime şi determinarea a câte obiecte sunt conţinute curent în mulţime.

Secvenţiale: obiectele sunt adunate într-o structură secvenţială - ex: tablou (array)Colecţii

Asociative: păstrează obiectele, dar şi o cheie pentru fiecare obiect prin intermediul căreia poate fi identificat - ex:dicţionar

Polimorfism

Polimorfismul înseamnă că o operaţie se poate comporta diferit (în clase diferite).

Polimorfism static: supraîncărcarea operatorilor, funcţii su signaturi diferite

dinamic:o precondiţie este late binding

D.p.d.v. fizic, binding e punctul în viaţa unui program la care caller-ul unei operaţii e dat de adresa de memorie a operaţiei. Uzual, se întâmplă la compilare sau link-are. Acest tip de binding se numeşte early binding.

În late binding, locaţia de memorie a unei operaţii e determinată doar când apelul are loc, i.e. atunci când mesajul corespunzător e trimis obiectului. Prin urmare, asocierea între mesaj şi operaţie apare dinamic la rulare, nu la compilare.

Moştenirea înseamnă că o clasă moşteneşte toate proprietăţile supraclasei sale. Îi este permis totuşi să redefinească o operaţie moştenită şi s-o rescrie cu o nouă definiţie. Care dintre aceste operaţii se va folosi ca răspuns pentru un mesaj (adică din ce clasă vine operaţia apelată) se decide doar la rulare.

Polimorfism dinamic (continuare)

În momentul în care mesajul display() întâlneşte un obiect, decide ce opera-ţie concretă va fi folosită: de exemplu, pentru un dreptunghi, se va apela Rectangle.display(). Se foloseşte totdeauna operaţia din clasa cea mai specializată. Acesta e principiul polimorfismului (vezi figura de mai jos)

Cercuri şi dreptunghiuri

Paradigma OO

- completări -

ClaseNumele claselor este, de obicei, un substantiv la singular, care trebuie să fie cât mai sugestiv faţă de abstracţia modelată.

Atributele sunt de două feluri:• atribute de instanţiere, care au valori specifice unui obiect particular;• atribute de clasă, care au valori comune tuturor instanţelor clasei şi se reprezintă subliniat

Atributele au următoarele tipuri:• integer• real• boolean• string• enumerare• boolean• alte tipuri sau chiar clase

Sintaxa unui atribut va fi următoarea:[vizibilitate] nume:tip_expresie [=valoarea_iniţială {listă de proprietăţi}]

Atributele clasei se pot clasifica după gradul de vizibilitate în:-atribute publice, care sunt atribute vizibile, pot fi folosite şi în alteclase şi sunt precedate de semnul "+"; mulţimea acestora se mainumeşte şi interfaţă;-atribute private (informaţionale), care pot fi accesate numai în clasarespectivă şi care sunt precedate de semnul "-";

-atribute protejate, care pot fi accesate de clasa care le-a definit, precum şi de generalizările sau de specializările ei, şi sunt precedatede semnul "#".

Exemplu. Clasa Asigurări poate avea următoarele atribute:

Mesaje şi metode

Obiectele nu sunt izolate, ele acţionează asupra altor obiecte şi/saupermit să se acţioneze asupra lor. Relaţiile dintre obiecte se numesc linkuri sau legături, iar comunicarea dintre obiecte se numeşte stimul.

Comportamentul se referă la modul în care un obiect reacţionează(schimbă starea) la cererile altor obiecte din sistem, precum şi la modul cum acţionează (trimite mesaje altor obiecte).

Un mesaj este o comunicare între clase via asocieri, aşa cum un stimul este comunicarea dintre obiecte via legături.

Operaţia este abstractizarea unui mesaj care poate fi trimis clasei. La primirea unui mesaj, o clasă execută o operaţie.

Sintaxa unei operaţii este:[vizibilitate] nume_operaţie ([arg1 :tip1,............argn :tipn ] ): [tip]

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

Mesaje şi metode (continuare)

Implementarea operaţiei se numeşte 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 defineşte o funcţie şi se scrie codul care determină ce trebuie să execute funcţia, atunci declaraţia funcţiei este o operaţie, iar corpul funcţiei este o metodă.

Metodele se clasifică în:a) Constructori

b) Destructori

- sunt metode care crează noi instanţe ale clasei. Unei clase îi pot corespunde mai mulţi costructori.

- sunt metode care elimină un obiect din memorie.

se aplică numai clasei

c) Selectori - sunt metode care accesează starea unui obiect fără a o modifica.

d) Modificatori - sunt metode care schimbă starea obiectului.

Mesaje şi metode (continuare)

Ceea ce obiectele ştiu şi pot să facă se numeşte caracteristică.

Caracteristicile sunt de două tipuristructurale

comportamentale

Asocierile şi atributele alcătuiesc caracteristicile structurale (structural features), deoarece ele indică structura clasei, similar cu modelarea structurală, care indică structura modelului realizat

Operaţiile şi metodele sunt caracteristici dinamice (behavioral features), deoarece comunică comportamentul clasei, asemănător cu modelarea dinamică, folosită pentru a comunica comportamentul unui sistem

Interfeţe

Mesajele primite de obiect pot fi:• mesaje publice – mesaje care pot fi recepţionate de obiect, indiferent de cine trimite mesajul;• mesaje private – mesaje trimise obiectului de diferite părţi ale sistemului sau chiar de el însuşi.

Interfaţa unui obiect cuprinde mesajele publice ale obiectului.

Obs. Obiectele din aceeaşi clasă au aceeaşi interfaţă, aşadar, interfaţa unui obiect poate fi considerată ca o interfaţă a clasei.

Obs. Interfaţa conţine numai operaţiile, nu şi metodele (codul) care implementează operaţiile.

Obs. În UML, interfeţele vor fi redate printr-un cerc, căruia i se ataşează numele interfeţei.

Obs. Accesul către datele obiectului se poate face prin serviciile (operaţiile) pe care acesta le oferă clienţilor săi. Aceste operaţii care găsesc ş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 puţin, o operaţie abstractă (operaţie pentru care nu e dată decât signatura) se numeşte clasă abstractă.

Obs. O clasă abstractă nu poate fi instanţiată.

Obs. Clasa care moşteneşte o clasă abstractă va trebui să implementeze operaţile abstracte din superclasă; în caz contrar, şi ea devine clasă abstractă.

Moştenire

Atributele şi operaţiile cu vizibilitate publică (precedate de '+') din superclasă vor fi publice şi în subclasă, pe când cele private (precedate de '-') vor fi moştenite în subclasă, dar nu vor fi accesibile acesteia. Atributele şi operaţiile cu vizibilitate protejată (precedate de '#') nu pot fi accesate de alte clase, ci numai de clasa respectivă şi de subclasele ei.

Când o clasă are o singură superclasă, spunem că există o moşteniresimplă.

Poate să existe şi o ierarhie de clase, adică o clasă să fie atât subclasă, cât şi superclasă, şi, în acest caz, avem o moştenire multiplă.

Există mai multe scenarii de moştenire : • adăugarea unor noi metode şi/sau stări subclasei; • rescrierea unor metode din superclasă, din motive de eficienţă.

Polimorfism

Polimorfismul constă în abilitatea de a folosi mai multe metode pentru o operaţie (de exemplu: desenarea unei figuri sau calculul ariei).

Datorită polimorfismului, o subclasă poate să redefinească o operaţiemoştenită chiar dacă operaţia nu este abstractă în superclasă.

Implementarea unei operaţii va fi aleasă în funcţie de obiectul căruia i se aplică operaţia. Se caută metoda întâi în clasa cea mai specializată a obiectului; dacă aceasta nu se găseşte, se merge la superclasa imediat următoare, până la găsirea 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

-generalităţi-

Ingineria software cuprinde metodele, instrumentele şi tehnicile folosite pentru dezvoltarea software.

software de sistem: e software-ul care se comportă ca instrument de ajutor pentru construcţia software-ului de aplicaţie. Exemple: SO, baze de date, compilatoare etc.

Software

software de aplicaţie: 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 aplicaţie, trebuie identificate categoriile de software:• jocuri

• sisteme de informaţie – 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 staţii 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 ştiinţific: calcule, modelare, predicţie

Scopurile pe care dezvoltarea software caută sa le îndeplinească sunt:

a) satisfacerea cerinţelor 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 cerinţelor utilizatorilorPrincipala problemă e analiza cerinţelor

Sarcina încercării de a asigura că software-ul face ce vor utilizatorii să facă se numeşte validare.

b) Costul realizării software-ului

• Se estimează că în lume se cheltuieşte pentru producerea de software aproximativ 1500 miliarde dolari şi că în fiecare an se prognozează o creştere a acestei cifre cu 15%.

• Se estimează că productivitatea unui programator mediu este de 10-20 linii de program pe zi, datorită următoarelor aspecte:

- un software de sistem se scrie mult mai greu decât un software de aplicaţie ;

- în studiul efectuat există mari diferenţe între programatorii individuali.

- această cifră include şi timpul petrecut pentru clarificarea problemelor, designul,

codul, testarea etc..

• Privire paralelă hardware - software

b) Costul realizării software-ului (continuare)

• Costuri relative în dezvoltarea software-ului

• Numărul relativ de erori facute în dezvoltarea software

• Costul relativ de reparare a diverselor erori

c) Performanţele software : trebuie să fim siguri că:

• un sistem interactiv răspunde într-un timp rezonabil de scurt

• un joc rulează suficient de repede pentru ca animaţia să nu fie supărătoare

• o anumită sarcină nu ia 15 ore în loc de una

Temă: Identificaţi 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) Mentenanţa: e termenul pentru efortul care trebuie pus în software, după ce acesta a fost scris şi pus în aplicare.

de remediere (corectarea bug-urilor)

de adaptare (care modifică software-ul fie la cererea utilizatorilor, fie la schimbarea SO etc.)

Mentenanţă

e) Mentenanţa (continuare)

Obs. Mentenanţa 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ă mentenanţa reprezintă 67% din totalul timpului necesar pentru dezvoltarea diferitelor părţi ale software-ului.

Exemplu de mentenanţă: Problema anului 2000. Ce tip de mentenanţă este?

f) FiabilitateaO parte a software-ului e fiabilă dacă lucrează fără să producă lucruri indezirabile.

Uzual se vorbeşte de bugs în software, dar pentru claritate se definesc si termenii:

• eroare (error) - o decizie greşită luată în timpul dezvoltării software;

• defect (fault) - o problemă care face ca software-ul să se îndepărteze de comportarea dorită; poate să nu apară până când condiţiile nu sunt potrivite; e sinonim cu bug.• eşec (failure) – un eveniment care face ca software-ul să se îndepărteze de comportarea dorită

f) Fiabilitatea (continuare)

• O eroare cauzează unul sau mai multe defecte.

• Un defect cauzează unul sau mai multe eşecuri.

• Eşecurile apar când sistemul este testat.

Obs. Îndepăratea bug-urilor şi încercarea de a asigura fiabilitatea se numeşte verificare.

Obs. Deoarece este practic imposibil de îndepăratare a tuturor bug-urilor, s-a impus conceptul de good enough software (software suficient de bun), adică lansarea software-ului se produce când numărul ş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 decât software-ul.

f) Fiabilitatea (continuare)

Sunt anumite aplicaţii care necesită o fiabilitate ridicată, safety-critical systems.

Exemple:

• sistemele pentru controlul avioanelor;

• controlul proceselor critice (software de comunicaţii ce joacă un rol critic în situaţiile de urgenţă)

• controlul echipamentelor medicale

Temă. Identificaţi 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 depăşesc perioada de livrare şi aproximativ 50% încalcă flagrant termenul de predare.

Interacţiunea om-computerÎn ultimul timp, multe interfeţe au devenit grafical user interfaces (GUIs) care utilizează ferestre cu instrumente gen butoane şi bare de scroll. Se pune problema designului acestor interfeţe grafice, care să fie simple şi uşor de utilizat.

Temă. Identificaţi sisteme care sunt mai greu de utilizat şi altele mai uşor de utilizat.

Scopuri conflictuale şi complementare

Concluzii

Dezvoltarea software ridică probleme mari. Metodele şi instrumentele necesare pentru îmbunătăţirea acestei situaţii 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 cât mai exactă a cerinţelor utilizatorilor (requirements engineering şi validation)

• prezentarea unei versiuni prototip utilizatorilor

• folosirea unor limbaje de programare noi, inovatoare

Diagrame de clasă

- exemple -

Temă. Modelaţi enunţurile următoare (îndeplinite simultan) :

1) Fişierele, shortcut-urile şi directoarele sunt conţinute în directoare şi au un nume;

2) Un shortcut implică (se refera la) un fişier sau un director;

3) Într-un anumit director, un nume poate identifica doar un element (fişier, shortcut sau director);

1) Fişierele, shortcut-urile şi directoarele sunt conţinute în directoare şi au un nume;

Conceptele de fisier, shortcut, director trebuie modelate în clase.

Din moment ce un fişier, shortcut sau director nu poate fi inclus decât într-un director (în alte directoare pot fi eventual copii ale acestora), iar odată cu dispariţia directorului părinte dispar şi fişierele, shortcut-urile şi (sub)directoarele conţinute în el, relaţia dintre clasele Fisier, Shortcut, Director cu clasa Director trebuie să fie compunere.

2) Un shortcut implică un fişier sau un director;

Obs. Asocierea exclusivă sau asocierea XOR este o constrângere 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 (fişier, shortcut sau director);

Asocierea calificată este folosită în relaţiile one-to-many şi many-to-manyşi indică modul în care va fi identificat un anumit element al părţii 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 găsi obiectele de la celălalt capăt al unei asocieri.

Prima viziune a modelului va arăta ca în figura de mai jos:

Obs. În această variantă, două fişiere sau shortcut-uri nu pot avea acelaşi nume în interiorul unui director, dar un fisier si un shortcut pot avea acelaşi nume.

Soluţia vine din propoziţia a 3-a: 3) Într-un anumit director, un nume poate identifica doar un element

(fişier, shortcut sau director);

Adăugând o supraclasă, Element, care să generalizeze clasele Fisier, Shortcut şi Director, cele 3 compuneri se pot îmbina într-una singură.

În această soluţie:

• Director e “composite” în relaţie cu Element

• Director e subclasă a clasei Element

Ce este pattern-ul “composite”?E o soluţie elegantă pentru a modela ierarhii de elemente/compuneri.

Designerul poate lucra cu obiecte individuale (frunze – leaves) şi cu combinaţiile lor (composite) în acelaşi fel.

Diagrame de clasă

- exemple -

Temă. Modelaţi enunţul : “O ţară are o capitală.”

Ţara va fi o clasă cu unul dintre atributele sale capitala. Această soluţie 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 întâmplă dacă vrem să adăugăm proprietăţi conceptului de capitală, cum ar fi populaţie, 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 aminteşte, în vreun fel, noţiunea de oraş: dacă o capitală nu mai e capitală (din diverse motive), oraşul în sine nu dispare, ci doar statutul său de capitală.

Vom modela aşadar faptul că o capitală e un oraş cu un anumit rol.

Vom adăuga apoi o agregare multiplă între Tara şi Oras şi o restricţie care să arate că o capitală e aleasă dintre oraşele unei tări.

De e e agregare şi nu compunere?Pentru că un oraş poate aparţine, în cazul general, în timp, mai multor ţări. Exemplu: Berlin

În final, dacă vrem să arătăm că o capitală e un oraş şi are proprietăţi specifice oraşului, atunci putem face clasa Capitala ca o specializare a clasei Oras.

Dependenţa <<refine>> indică faptul că multiplicitatea “1” din partea clasei Tara în compunerea cu Capitala înlocuieşte mai puţin restrictiva multiplicitate “1..*” din partea clasei Tara pentru oraşe.

Obs. Clasa Oras din figura de mai sus nu e o clasă abstractă

Diagrame de clasă

- exemple -

Temă. Modelaţi enunţurile următoare (îndeplinite simultan) :

1) Fişierele, shortcut-urile şi directoarele sunt conţinute în directoare şi au un nume;

2) Un shortcut implică (se refera la) un fişier sau un director;

3) Într-un anumit director, un nume poate identifica doar un element (fişier, shortcut sau director);

1) Fişierele, shortcut-urile şi directoarele sunt conţinute în directoare şi au un nume;

Conceptele de fisier, shortcut, director trebuie modelate în clase.

Din moment ce un fişier, shortcut sau director nu poate fi inclus decât într-un director (în alte directoare pot fi eventual copii ale acestora), iar odată cu dispariţia directorului părinte dispar şi fişierele, shortcut-urile şi (sub)directoarele conţinute în el, relaţia dintre clasele Fisier, Shortcut, Director cu clasa Director trebuie să fie compunere.

2) Un shortcut implică un fişier sau un director;

Obs. Asocierea exclusivă sau asocierea XOR este o constrângere 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 (fişier, shortcut sau director);

Asocierea calificată este folosită în relaţiile one-to-many şi many-to-manyşi indică modul în care va fi identificat un anumit element al părţii 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 găsi obiectele de la celălalt capăt al unei asocieri.

Prima viziune a modelului va arăta ca în figura de mai jos:

Obs. În această variantă, două fişiere sau shortcut-uri nu pot avea acelaşi nume în interiorul unui director, dar un fisier si un shortcut pot avea acelaşi nume.

Soluţia vine din propoziţia a 3-a: 3) Într-un anumit director, un nume poate identifica doar un element

(fişier, shortcut sau director);

Adăugând o supraclasă, Element, care să generalizeze clasele Fisier, Shortcut şi Director, cele 3 compuneri se pot îmbina într-una singură.

În această soluţie:

• Director e “composite” în relaţie cu Element

• Director e subclasă a clasei Element

Ce este pattern-ul “composite”?E o soluţie elegantă pentru a modela ierarhii de elemente/compuneri.

Designerul poate lucra cu obiecte individuale (frunze – leaves) şi cu combinaţiile lor (composite) în acelaşi fel.

Diagrame de clasă şi de obiecte

- Concepte, exemple -

Studiu de caz: Sistem de rezervare (booking) a biletelor de avion pentru o agenţie de voiaj (varianta simplificată)

Cunoştinţele experţilor în fenomen se pot concretiza în propoziţiile:

Pasul 1. Modelarea propoziţiilor 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 puţin un zbor.

Noţiunile open şi close sunt concepte dinamice. Ele privesc schimbările î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. Soluţia de mai sus nu e totuşi cea mai fericită. De aceea noţiunea 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 operaţiilor.

(continuare)

Mesajele vor circula între obiectele ce reprezintă instanţe ale claselor, astfel:

Pasul 2. Modelarea propoziţiilor 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 noţiunea de airport e complexă şi implică nu doar un nume, ci şi capacitate etc, e de preferat să se creeze clasa Airport decât atributele DepartureAirport şi ArrivalAirport în clasa Flight.

Obs. E necesară restricţia {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 soluţie tentantă ar fi să se creeze două subclase din clasa Airport:

Obs. Soluţia 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 aceleaşi instanţe.

(continuare)

Se va folosi noţiunea de rol, care se potriveşte perfect situaţiei:

Obs. Rămâne problema multiplicităţii în partea stângă a asocierii serves: De câte aeroporturi e servit un oraş?

Obs. Dacă se consideră că verbul “a servi” se referă la mijlocul de transport aerian care se găsesşte la cel mult 30 km de un oraş, atunci multiplicitatea este 0..*, ca în figura de mai jos:

Pasul 3. Modelarea propoziţiilor 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ă aparţine unui zbor şi numai unul ?Răspuns. Nu, există contraexemple date de specialişti. Aşadar o escală poate aparţine mai multor zboruri.

Pentru a completa diagrama, facem observaţiile:• asocierea dintre Flight şi Stopover e o agregare, dar nu e compunere;• escalele sunt ordonate conform cu zborurile

Obs. Clasa Stopover e strâns legată de clasa Airport (multiplicitate 1) şi nu există ea însăşi, ci ca parte a clasei Flight.

O idee ar fi să considerăm clasa Stopover ca specializare a clasei Airport:

Obs. Nu e soluţia recomandată, din cauza aşa numitei “moşteniri de implementare”.

Se poate folosi noţiunea 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 propoziţiilor 3,4 şi 5

Obs. Trebuie să se facă distincţie între customer şi passenger (exemplu: un client (customer) poate fi un angajat al celui care călătoreşte)Obs. Din propoziţia 4, reies multiplicităţile: single flight, single passenger. Obs. Propoziţia 5 poate fi îndeplinită prin adăugarea a două operaţii în clasa Booking.

Obs. O soluţie mai simplă se obţine dacă vom considera pasagerul (passenger) ca atribut în clasa Booking.

Obs. Totuşi, dacă vrem să gestionăm informaţii 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 propoziţiei e confuz, deoarece pare că implică direct un customer şi flight. De aceea, pentru evitarea confuziei, propoziţia poate fi reformulată:

Obs. O rezervare (booking) este făcută de (doar) un customer şi acelaşi zbor (flight) poate fi afectat de 0 sau mai multe rezervări.

Adăugând şi clasa Passenger, se pune întrebarea:

Câte rezervări poate să aibă un pasager?

Răspuns. La prima vedere, cel puţin una (altfel nu ar fi pasager).

Răspuns complet. E necesar să anticipăm că putem avea 0..*.

Pasul 5. Adăugarea atributelor (attributes), restricţiilor(constraints) şi calificatorilor (qualifiers)

Reluăm modelul preliminar obţinut până acum:

Pentru fiecare clasă, identificăm principalele atributele (folosind convenţiile UML):

Completăm modelul cu atribute derivateUn 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 obţine ca diferenţă între arrivalTime şi departureTime, ţinând 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:

• păstrează un atribut concret în design, care va avea metodele sale de acces (set şi get); trebuie activat procesul de update ori de câte ori un item din informaţie, de care depinde atributul, se modifică; - se foloseşte 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 foloseşte dacă nu e cerut prea des sau dacă se poate calcula cu uşurinţă

Adăugarea restricţiilor (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 restricţia {frozen} pe asocierea potrivită.(vezi Glosar de termeni)

Pe de altă parte, fiecare zbor e identificat în mod unic printr-un număr. 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 restricţiile. Se recomandă folosirea acelora care sunt foarte importante, altfel diagrama poate deveni greu de urmărit.

Pasul 6. Folosirea analysis pattern

Clasa Flight are mai multe responsabilităţi:

a) Prima priveşte toate informaţiile ce pot fi găsite în planificarea zborurilor pentru fiecare companie aeriană: într-adevăr, există un zbor în fiecare luni, să zicem, între oraşele A şi B, oferit de compania din oraşul A.b) A doua se referă la informaţiile privind rezervările: 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 relaţie de instanţiere dintre clasa GenericFlight, care are responsabilităţile descrise la punctul a) şi clasa Flight, care să aibă responsabilităţile de la punctul b).

În plus, să presupunem că o companie anulează nişte zboruri, din oraşul X, din motive de modernizare a aeroportului, timp de câteva luni. În varianta iniţială, trebuia să scăpăm de toate instanţele clasei Flight. La sfârşitul lucrărilor, trebuiau recreate; în varianta a doua pur şi simplu instanţele pentru zborurile ce pleacă din oraşul X nu vor exista.

Clasa Flight în versiunea iniţială

Separarea responsabilităţilor clasei Flight

Pentru updatarea modelului, trebuie:• distribuirea atributelor, operaţiilor şi asocierilor clasei Flight între clasele GenericFlight şi Flight;

• adăugarea unei asocieri “1-*” între clasele GenericFlight şi Flight;

În plus, adăugăm două atribute în clasa GenericFlight care să indice în ce zi a săptămânii e planificat zborul şi în ce perioadă a anului are loc zborul (validityPeriod).

E adăugată o restricţie care leagă valorile atributului departureDate din clasei Flight şi din clasa GenericFlight

Obs. validityPeriod nu e un atribut simplu: putem fi interesaţi de începutul perioadei, sfârşitul, durata etc. Soluţia ar fi crearea unei clase TimePeriod:

Trebuie adăugată o asociere între Flight şi AirlineCompany.

Distribuirea reponsabilităţilor între clasele GenericFlight şi Flight

Metaclass pattern

Separarea responsabilităţilor poate fi generalizată în forma unui “analysis pattern”, care poate reutilizat în alte ocazii.

Fie o clasă XX, cu multe responsabilităţi, care nu sunt prezente în fiecare instanţă.

Adăugăm o clasă TypeXX, distribuim proprietăţile între aceste clase şi le legăm într-o asociere de tipul “*-1”. TypeXX se numeşte metaclasă, deoarece conţine informaţii ce descriu clasa XX.

Pasul 7. Structurarea în pachete

Structurarea trebuie să ţină seama de două principii: coerenţa şi independenţa.Criteriile de coerenţă presupun a fi îndeplinite:• obiective: clasele trebuie să returneze servicii de aceeaşi natură către utilizatori;• stabilitate: izolăm clasele care sunt stabile de cele care trebuie dezvoltate pe parcursul proiectului• durata de viaţă a obiectelor.

Independenţa presupune că divizarea în pachete trebuie făcută astfel încât să fie minimizate dependenţele dintre pachete.

Propunem divizarea în două pachete:• primul priveşte definirea zborurilor, foarte stabile (cele din GenericFlight)

• al doilea se refră la rezervări, împreuă cu toate asocierile lor

O soluţie posibilă:

Pasul 8. Generalizarea şi reutilizareaSe pune problema: putem reutiliza modelul de rezervare bilete pentru o călătorie cu avionul la o problemă legată de rezervarea biletelor pentru o călătorie cu autobuzul.

O călătorie cu autobuzul are un oraş de plecare şi un oraş de destinaţie, respectiv timp şi dată de plecare şi destinaţie. Un client poate rezerva una sau mai multe călătorii pentru unul sau mai mulţi pasageri.

Modelul va fi foarte asemănător cu modelul călătoriei cu avionul, dar puţin mai simplu, datorat următoarelor aspecte:

• noţiunea de aeroport nu are echivalent, iar clasa City e direct asociată cu clasa JourneyByBus;

• distincţia dintre GenericFlight şi Flight nu e transferabilă, deoarece călătoriile cu autobuzul nu sunt aşa regulate şi nu sunt planificate în avans.

Propunerea unei arhitecturi logice îmbinate

Urmărim obiectivele: • izolarea claselor care sunt împărţite (shared) într-un nou pachet, pentru a fi reutilizate• factorizarea proprietăţilor împărţite î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 izolăm într-un nou pachet, dar nu în acelaşi (Geography), ci separat.

Există asemănare între pachetele FlightBookings şi BusBookings (singura diferenţă fiind la clasele FlightBooking (redenumită pentru claritate din Booking) şi BusBooking: au aceleaşi atribute şi aproape aceleaşi asocieri

Se va crea aşadar o supraclasă abstractă Bookings

Soluţia finală va fi următoarea:

Glosar de termeniRestricţii de schimbare (changeability):

• {frozen}: înseamnă că odată o valoare de atribut sau legătură inserată, nu poate fi updatată sau ştearsă şi nu pot fi adăugate valori sau legături atributului, respectiv asocierii;

• {addOnly}: înseamnă că deşi valoarea originală sau legătura originală nu poate fi updatată sau ştearsă, alte valori sau legături pot fi adăugate atributului sau asocierii (pentru instanţa obiectului cu restricţii); addOnly are efect doar dacă multiplicitatea maximă a atributului / rolului asocierii depăşeşte multiplicitatea minimă.

Asociere calificată (qualifier): este folosită în relaţiile one-to-many şi many-to-many şi indică modul în care va fi identificat un anumit element al părţii 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 găsi obiectele de la celălalt capăt al unei asocieri şi se reprezintă printr-un dreptunghi mic ataşat 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 relaţie de dependenţă, etichetată cu stereotipul <<derive>>.

inapoi

Studiu de caz

-ATM (Automatic teller machine)-

Enunţarea problemeiSe presupune că un ATM oferă următoarele servicii:1) Distribuirea banilor către orice posesor de card (smartcard), prin intermediul

unui cititor de card2) Consultarea soldului contului, facilităţi de plată şi de depozitare a cecurilor

pentru clienţii băncii (bank customers) care deţin un card (smardcard)

Trebuie avut în vedere că:3) Toate tranzacţiile trebuie făcute î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

• Să se completeze descrierile cu diagrame dinamice

• Să se organizeze şi să se structureze cazurile de utilizare

Obs. Enunţul problemei poate fi incomplet (aşa cum se întâmplă în realitate)

Pasul 1. Identificarea actorilor

1.1 Care sunt entităţile externe care interacţionează direct cu ATM-ul?

Prima propoziţie indică şi primul actor :1) Distribuirea banilor către orice posesor de card (smardcard), prin

intermediul unui cititor de card

Atenţie! Cititorul de card face parte din ATM, deci nu poate fi actor!

Întrebare. Este cardul un actor (deoarece este extern ATM şi interacţionează cu el)?

Răspuns. Poate fi, dar se aplică următorul principiu: eliminaţi actorii “fizici”în dauna actorilor “logici”!, deoarece actorii reprezintă cineva sau ceva ce beneficiază în urma utilizării sistemului.

Cardul nu beneficiază prin folosirea ATM, ci cel care deţine cardul, aşadar cardul nu va fi considerat actor.Aşadar, primul actor va fi posesorul de card (CardHolder)

Pasul 1. Identificarea actorilor (continuare)

A doua propoziţie specifică :2) Consultarea soldului contului, facilităţi de plată şi de depozitare a cecurilor

pentru clienţii băncii (bank customers) care deţin un card (smardcard)

Aşadar, se conturează şi alt actor: clientul băncii (bank customer)

A treia propoziţie specifică :3) Toate tranzacţiile trebuie făcute în siguranţăCine oferă siguranţă?

În exemplul considerat (preluat după sistemul bancar din Franţa) se identifică alţi doi actori:

• Visa authorisation system (VISA AS) pentru tranzacţii de retragere prin intermediul unui smatcard Visa

• Sistemul informaţional al băncii (Bank IS) care să autorizeze toate tranzacţiile făcute de un client prin intermediul smartcard-ului său, dar şi accesarea soldului

Pasul 1. Identificarea actorilor (continuare)

A patra propoziţie 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 “înghiţite” 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ă înţelegere 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ă soluţie, mai elaborată, ar fi să considerăm 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 secvenţe de acţiuni, incluzând variante, pe care sistemul le poate efectua, interacţionând cu actorii din sistem.

Vom lua actorii, unul câte unul, şi vom lista modurile în care aceştia interacţionează 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 “înghiţite”

• 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. Ceilalţi participanţi la cazul de utilizare se numesc actori secundari.

Exemplu: Visa AS şi Bank IS sunt actori secundari. Nu pot ei înşişi să folosească ATM.

Pasul 3. Crearea diagramelor use caseO diagrama use case arată relaţiile dintre actori şi sistem, precum şi cazurile de utilizare (use cases).

ATM

Retragere bani

Consultare sold

Depozitează bani

Depozitează cecuri

Umple bancomatul

Recuperează carduri

Recuperează cecuriFrontiera sistemului

Pasul 3. Crearea diagramelor use case (continuare)O variantă se obţine considerând Bank customer ca specializare a CardHolder.

ATM

Retragere bani

Consultare sold

Depozitează bani

Depozitează cecuri

Umple bancomatul

Recuperează carduri

Recuperează cecuri

Obs. Vom redenumi actorul CardHolder în Visa CardHolder

Pasul 3. Crearea diagramelor use case (continuare)Adăugarea actorilor secundari

Recomandări:• Implicit, rolul unui actor e “principal” (“primary”); dacă nu e aşa, indicaţi că rolul e “secundar” (“secondary”) pe asociere, de partea actorului• Pe cât e posibil, plasaţi actorii principali în stânga 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 băncii (bank customer).

O soluţie ar consta în adăugarea unei asocieri cu fiecare dintre aceşti actori secundari.

Adăugarea unei asocieri cu fiecare dintre aceşti actori secundari.

O altă soluţie ar fi să se facă disticţie î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 utilizareCazul de utilizare trebuie să aibă un început şi un sfârşit identificabile clar. Trebuie specificate, de asemenea, variante posibile, cum ar fi scenariu de succes, secvenţe alternative, în timp ce, simultan, se încearcă să se aranjeze descrierile într-o ordine secvenţială, pentru a îmbunătăţi înţelegerea lor.

ScenariiNumim fiecare unitate de descriere a secvenţelor de acţiune secvenţă.Un scenariu reprezintă o succesiune particulară a secvenţelor, care e rulat de la începutul la sfârşitul unui caz de utilizare.Un scenariu poate fi folosit pentru a ilustra o interacţiune sau o execuţie a unei instanţe 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), secvenţele alternative şi secveţele de erori, precum şi precondiţiile şi postcondiţiile.

c) Cerinţe UI (UI requirements) (opţional): adăugarea constrângerilor pentru GUI.

d) Cerinţe nefuncţionale (Non-functional constraints) (opţional): se pot adăuga informaţiile: frecvenţă, disponibilitate, acurateţe, integritate, confidenţialitate, 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 băncii, 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)Precondiţii:• 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 autorizaţie 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ă doreşte chitanţă.12. Visa CardHolder cere chitanţa.13. ATM returnează cardul către Visa CardHolder.14. Visa CardHolder ia cardul.15. ATM oferă banii şi chitanţa.16. Visa CardHolder ia banii şi chitanţa.

O altă prezentare posibilă constă în separarea acţiunii actorilor şi sistemului:

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 autorizaţie 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ă doreşte chitanţă.

12. Visa CardHolder cere chitanţa. 13. ATM returnează cardul către Visa CardHolder.

14. Visa CardHolder ia cardul. 15. ATM oferă banii şi chitanţa.

16. Visa CardHolder ia banii şi chitanţa.

b) Fluxul evenimentelor (Flow of events) (continuare)Secvenţe alternative:

A1) Număr de pin incorect: intervine la pasul 56. ATM informează CardHolder că pin-ul e incorect pentru prima şi a doua oară.7. ATM înregistrează eşecul pentru card.Scenariul se reîntoarce la pasul 3.

A2) Suma cerută e mai mare decât limita zilnică: intervine la pasul 10

11. ATM informează CardHolder că suma cerută e mai mare decât limita zilnică.Scenariul se reîntoarce la pasul 8.

A3) Visa CardHolder nu vrea chitanţă: intervine la pasul 1112. Visa CardHolder declină oferta de a primi o chitanţă.13. ATM returnează cardul cătreVisa CardHolder.14. Visa CardHolder ia cardul.15. ATM oferă banii. 16. Visa CardHolder ia banii.

Secvenţe de erori:E1) Card invalid: intervine la pasul 23. ATM informează Visa CardHolder că nu e valid cardul (nu se poate citi, expirat etc.) şi îl confiscă, cazul de utilizare eşuează (fails).E2) Număr de pin invalid după încercări repetate: intervine la pasul 56. 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 eşuează (fails).

E3) Retragere neautorizată: intervine la pasul 6

7. VISA AS interzice orice retragere.8. ATM scoate cardul; cazul de utilizare eşuează (fails).

E4) Cardul nu e luat înapoi de Visa CardHolder: intervine la pasul 1314. După 15 secunde, ATM confiscă (smart)cardul.15. VISA AS e notificat; cazul de utilizare eşuează (fails).

E5) Banii nu sunt ridicaţi de Visa CardHolder: intervine la pasul 1514. După 30 secunde, ATM ia banii înapoi.15. VISA AS e notificat; cazul de utilizare eşuează (fails).

Postcondiţii:• nu sunt prea evidente

c) Cerinţe UI (UI Requirements)Mecanismul de intrare/ieşire 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 afişeze mesajele ATM-ului.• Taste în jurul ecranului, a.î. posesorul de card să selecteze suma dorită.• Un distribuitor de chitanţe.• Un distribuitor de bani.

d) Restricţii nefuncţionale (Non-functional constraints)Timpul de răspuns: • Interfaţa ATM trebuie să răspundă în limita maximă de 2 secunde.• O tranzacţie nominală trebuie să se termine în cel mult 2 minute.Disponibilitatea• ATM trebuie să fie accesibil 24/7• Lipsa hârtiei pentru tipărirea chitanţelor nu trebuie să fie un obstacol pentru un posesor de card ră retragă bani.Integritatea• Interfaţa ATM trebuie să fie destul de robustă pentru a evita vandalizarea.Confidenţialitatea• Rata de eroare a procedurii de comparare a numărului de pin introdus cu acela de pe card să fie sub 10-6.

Pasul 5. Descrierea grafică a cazurilor de utilizare

Deşi descrierea textuală a cazurilor de utilizare e esenţială, are totuşi dezavantajul că nu specifică în ce ordine vor fi secvenţele sau în ce moment intervin actorii secundari.

E recomandat să completăm 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 secvenţe (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 stânga, 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 activităţi care:

• e complexă şi poate fi divizată în mai multe activităţi;

• poate fi întreruptă de un eveniment.

O action state modelează realizarea unei activităţi care:

• e simplă şi nu poate fi divizată;

• nu poate fi întreruptă de un eveniment.

Completarea diagramei de secvenţe

Se introduc: -activităţile principale ale sistemului (prin mesajele trimise către sistem);-referinţe la secvenţele alternative şi de eroare (prin note).

Organizarea cazurilor de utilizareIdentificarea părţii comune pe care cazurile de utilizare le au în comun şi adăugarea relaţiei include.

Relaţia extend e opţională, 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 sumaPunctul 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 relaţii de generalizare ce implică cazuri de utilizare

Considerăm cazurile de utilizare: Depunere cash şi Depunere cecuri. Ambele implică aceiaşi actori: Bank customer ca actor principal şi Bank IS ca actor secundar.

Structurarea cazurilor de utilizare folosind pacheteStrategii posibile: gruparea după actor, după domeniu funcţional 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 activităţile şi responsabilităţile elementelor care alcătuiesc sistemul.

O diagramă de activitate reprezintă interacţiunile dintre activităţi, adică fluxul de control al trecerii de la o activitate la alta.

Spre deosebire de diagrama de stare înfăţişează stările unui obiect şi tranziţiile dintre ele, diagrama de activitate evidenţiază activităţile şi tranziţiile dintre ele.

Diagramele de activitate pot fi folosite în următoarele scopuri:- pentru a modela comportamentul intern al unei metode (implementarea unei operaţii). Acesta este şi cel mai folosit caz când apelăm la acest tip de diagramă;- pentru analiza interacţiunii activităţilor unui caz de utilizare;- pentru a ilustra modul de organizare a mai multor cazuri de utilizare şi legăturile dintre acestea.

Elementele unei diagrame de activităţi

O diagramă de activitate este o extensie a unei diagrame de stări. 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 următoarele:

1) stări de acţiune2) tranziţii3) bloc de decizii4) linii de sincronizare5) culoare

1) Stări de acţiune şi stări de activitate

Prin activitate înţelegem o prelucrare (procesare) neatomică, în curs de desfăşurare, în cadrul unei maşini de stare. Activităţile se pot descompune şi nu sunt atomice, în sensul că pot fi întrerupte. Activităţile sunt alcătuite din secvenţe de acţiuni, care sunt prelucrări atomice şi care au ca rezultat schimbarea stării sau returnarea unei valori.

Există trei tipuri de acţiuni, şi anume: simple, iniţiale şi finale. O activitate poate fi alcătuită dintr-o acţiune iniţială, una sau mai multe acţiuni simple şi finale.

ActivitateReprezentare

O acţiune iniţială reprezintă prima acţiune într-o diagramă de stare. În UML, o acţiune iniţială se reprezintă ca şi o stare iniţială, adică printr-un cerc plin.

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

2) Tranziţii

Tranziţiile sunt legăturile dintre acţiuni şi se reprezintă ca şi tranziţiile din diagramele de stare, printr-o săgeată îndreptată spre acţiunea următoare. În diagramele de activitate, tranziţiile nu sunt etichetate, deoarece ele reprezintă încheierea activităţii respective. Tranziţiile pot, însă, să fie etichetate cu condiţii, reprezentate printr-o afirmaţie scrisă între paranteze drepte, care restricţionează tranziţia spre acţiunea următoare.

Există două tipuri de fluxuri de tranziţii:

a) fluxul de control;

b) fluxul obiectelor.

a) Fluxul de control al tranziţiilor

Fluxul de control al tranziţiilor indică ordinea acţiunilor în secvenţă. Fluxul tranziţiilor arată cum sunt ordonate acţiunile în secvenţă. Într-o diagramă de activitate, activităţile sunt legate prin tranziţii automate, spre deosebire de diagramele de stare, unde tranziţiile între stări sunt declanşate de evenimente.

Atunci când o acţiune este încheiată, se va executa acţiunea specifică ieşirii, dacă există, după care tranziţia este declanşată către următoarea acţiune sau activitate. Urmează executarea acţiunii specifice intrării în noua stare, dacă există şi executarea acţiunii sau a activităţii asociate noii stări, etc.

Exemplu. Pentru un anumit sistem, aflat în starea de generare a rapoartelor, avem următoarele activităţi:- iniţială- stabilirea criteriilor raportului- generarea raportului- tipărirea raportului- finală

b) Fluxul tranziţiilor obiectelorO acţiune poate produce, modifica sau folosi obiecte. Aceste obiecte de intrare sau de ieşire sunt conectate de acţiuni prin relaţii de dependenţă, adică printr-o linie punctată între acţiune şi obiect. Pentru o acţiune care foloseşte un obiect de intrare, tranziţia se reprezintă printr-o linie punctată cu o săgeată îndreptată spre acţiune.Pentru o acţiune care actualizează sau produce un obiect, tranziţia este reprezentată printr-o săgeată punctată, de la acţiune la obiect.

Fig. Fluxul de control şi fluxul tranziţiei obiectelor

Fluxul de control al tranziţiilor se poate omite atunci când există un flux al obiectelor care să indice ordinea acţiunilor, adică atunci când o acţiune creează un obiect de ieşire, care să fie obiect de intrare pentru următoarea acţiune din secvenţă.

3) Bloc de decizii

O decizie reprezintă selectarea unui anumit flux de control al tranziţiilor, din mai multe, în funcţie de o condiţie de gardă.

Într-o diagramă de activităţi, blocul deciziei este reprezentat printr-un romb mic, în care intră o singură tranziţie, şi pot ieşi două sau mai multe tranziţii.

Fiecare tranziţie de ieşire, este etichetată cu o condiţie de gardă, scrisă între paranteze drepte, şi care indică condiţia care trebuie îndeplinită pentru ca tranziţia să se producă. În cazul în care lipsesc condiţiile de gardă, acestea sunt considerate, implicit, ca fiind false.

Exemplu. Să calculăm S= 0!+1!+2!+……+n! pentru n ∈ N, dat.

4) Linii de sincronizare

Concurenţa (concurrency) implică faptul că mai multe tranziţii 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)ramificaţiilor paralele în interiorul unui fir de execuţie al unui caz de utilizare sau al unei metode.

Tranziţiile care pleacă dintr-o bază de sincronizare se declanşează simultan. Dacă mai multe tranziţii intră într-o bază de sincronizare, acestea trebuie să se întâmple, înainte ca bara să fie trecută de una sau mai multe tranziţii de ieşire din bara de sincronizare. Bara de sincronizare se reprezintă printr-o linie îngroşată.

Dacă o bară are o singură tranziţie de intrare şi două sau mai multe de ieşire, aceasta indică faptul că toate tranziţiile de ieşire se petrec o dată cu tranziţia de intrare. Acest flux se numeşte splitting control.

Dacă o bară are mai multe intrări şi o singură ieşire, aceasta indică faptul că toate intrările trebuie să se producă înainte să se producă tranziţia de ieşire. Acest flux se numeşte synchronization control.

5) Culoare

Deoarece o diagramă de activitate nu oferă indicii referitoare la elementul care este responsabil pentru fiecare activitate, UML compensează această slăbiciune, oferind tehnica culoarelor (swimlanes). Aceasta constă în împărţirea unei diagrame de activitate în zone paralele, numite culoare de activităţi (aşa cum o piscină este împărţită în culoare de nataţie) pentru a evidenţia care element este responsabil pentru acţiunea din interiorul fiecărei zone.

Fiecare responsabilitate este repartizată unei clase sau unei organizaţii şi fiecare activitate este alocată unui culoar. Poziţia relativă a culoarelor nu are nici o semnificaţie, tranziţiile 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 organizaţii).

Exemplu.

SemnaleUML oferă două simboluri pentru semnale.

Primul simbol mesaj indică recepţionarea unui semnal. Numele semnalului este trecut într-un pentagon concav (un dreptunghi cu o latură în formă de triunghi concav). Recepţionarea unui semnal este reprezentată într-o diagramă de activitate, printr-o relaţie de dependenţă de la obiectul care trimite semnalul, la simbolul semnalului, urmată de o tranziţie de la simbolul semnalului la următoarea acţiune.

Al doilea simbol semnal indică trimiterea unui semnal. Numele semnalului este trecut într-un pentagon convex. Trimiterea unui semnal estereprezentată într-o diagramă de activitate, printr-o relaţie de dependenţă de la simbolul semnalului spre obiectul care primeşte semnalul.

Exemplu de diagramă de activitatePentru exemplul discutat anterior (vezi figura alăturată) se adugă cerinţele:- după realizarea unui raport, se poate cere execuţia altuia;- simultan cu generarea unui raport se poate genera şi altă operaţie (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 făcută cu succes;- se trimit semnale către imprimantă şi monitor şi se primesc semnale la generatoarele de rapoarte şi de interogări.

Diagrame de stare

Introducere

O diagramă de stare poate fi ataşată oricărei clase care are stări bine identificate şi un comportament complex. O diagramă de stare descrie o istorie a vieţii obiectelor unei clase şi poate fi considerată un graf, bazată pe stări conectate prin tranziţii.

Diagramele de stare specifică modul în care reacţionează un obiect la primirea unui mesaj.

O diagramă de stare are o singură stare iniţială, una sau mai multe stări simple, una sau mai multe stări finale şi tranziţii între stări.

Elementele unei diagrame de stare

Elementele principale ale unei diagrame de stare sunt următoarele:1) stări2) tranziţii3) evenimente4) acţiuni

1) Stări

Starea acoperă toate proprietăţile statice ale unui obiect şi valorile curente pentru fiecare proprietate. Toate instanţele unei clase există în aceeaşi stare. Starea curentă a unui element se numeşte stare activă.

a) simplăb) iniţialăc) finală

Stare

a) Stare simplă: este o condiţie specială sau o situaţie a unui obiect de-a lungul ciclului lui de viaţă.

Exemplu de stări de obiecte:• obiectul bec poate avea stările: aprins şi stins;• obiectul factură poate avea stările: plătit şi neplătit;• obiectul lift poate avea stările: staţionează, urcă, coboară;• obiectul calculator poate avea stările:

inactiv – calculatorul nu este pornit sau nu este accesibil utilizatorilor;

activ – calculatorul este pornit şi este funcţional pentru utilizatorii săi;

blocat – calculatorul nu este alimentat sau are unele erori majore.

Reprezentarea grafică a unei stări simple: dreptughi cu colţurile rotunjite

b) Stare iniţială: indică starea unui element şi momentul creării lui. Există o singură stare iniţială. Se reprezintă, în UML, sub forma unui cerc plin, de la care pleacă o săgeată.

c) Stare finală: indică starea unui element la sfârşitul vieţii sale, când el este distrus. Într-o diagramă de stare, putem avea zero sau mai multe stări finale. Se reprezintă, în UML, printr-un mic cerc plin, concentric altui cerc gol, la care sosesc săgeţi de la stările sistemului, astfel:

2) Tranziţii

Tranziţiile sunt relaţiile dintre stări. O tranziţie reprezintă schimbarea stării sursă a unui obiect, în urma unor acţiuni, datorită producerii unui eveniment. Tranziţiile dintre stări se produc în felul următor:- un obiect este în stare sursă;- se produce un eveniment (de exemplu recepţionarea unui mesaj);- se execută o acţiune;- obiectul intră în starea ţintă.

Într-o diagramă de stare pot exista:- una sau mai multe tranziţii dintr-o stare, deoarece fiecare este declanşată de un eveniment unic; în acest caz, spunem că există tranziţii cu mai multe ţinte;- din mai multe stări pleacă aceeaşi tranziţie, deoarece acelaşi eveniment poate declanşa o tranziţie de la mai multe stări sursă; în acest caz, avem tranziţia cu mai multe surse;- tranziţie de la o stare la ea însăşi.

Tranziţiile se reprezintă, în UML, printr-o săgeată solidă, de la starea sursă spre starea ţintă, etichetată cu numele evenimentului şi al acţiunii, separată prin caracterul slash (‘/’), astfel:

Elementele etichetei sunt opţionale, dar nu poate exista numai acţiunea. În cazul în care un eveniment cauzează o tranziţie fără acţiune asociată, atunci trebuie să lipsească şi ‘/’ din eticheta unei tranziţii.

Uneori, o tranziţie se produce nu datorită unui eveniment, ci datorită faptului că o stare completează o acţiune. În acest caz, tranziţiile fără etichetă se numesc tranziţii automate (automatic transitions).

3) Evenimente

Un eveniment este ceva ce se produce asupra unui element. Cele mai frecvente evenimente sunt mesajele recepţionate de un obiect.

În UML, un eveniment are următoarea sintaxă:nume eveniment (listă parametri) [condiţia de gardă]

unde:-nume eveniment – este, de obicei, acelaşi cu numele operaţiei 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 opţională şi conţine parametrii evenimentului separaţi prin virgulă. Fiecare parametru poate fi o valoare explicită sau o variabilă. Dacă evenimentul nu are parametri, se omit şi parantezele;

- condiţia de gardă – este, de asemenea, opţională şi indică o condiţie care trebuie satisfăcută pentru ca o tranziţie să aibă loc. O condiţie poate fi exprimată în limbaj natural, în limbaj de programare sau OCL.

În exemplul unui calculator, putem avea evenimentele următoare:

-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 condiţia 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 aplicaţiile), atunci se impune condiţia 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) Acţiuni: reprezintă o prelucrare executată de un obiect aflat într-o stare sursă, declanşată în urma producerii unui eveniment (de exemplu, recepţionarea unui mesaj). O acţiune nu poate fi întreruptă de evenimente.

În UML, o acţiune are următoarea sintaxă:Valoare_returnată:= element_ţintă.nume_acţiune (listă argumente)

unde:- Valoare_returnată – este opţională şi indică numele pentru valoarea rezultată de acţiunea declanşată de un eveniment. Dacă se omite acest câmp sau dacă acţiunea nu întoarce nici o valoare, atunci se vor omite şi caracterele “:=”.- Element_ţintă – este numele elementului care va executa acţiunea. Dacă elementul care enunţă acţiunea este acelaşi cu elementul care primeşte evenimentul declanşator al acţiunii respective, atunci acest câmp se omite, împreună cu caracterul punct (‘.’).- Nume acţiune – este, de obicei, acelaşi cu numele operaţiei elementului respectiv sau al operaţiei elementului – ţintă, dacă acesta este specificat.- Listă de argumente – este opţională şi indică parametrii care participă la acţiune, separaţi prin virgulă. Fiecare parametru poate fi o variabilă sau o valoare explicită.

variabilă

Tipuri de evenimente şi acţiuniÎn UML, există patru tipuri de evenimente: a)apeluri de operaţii; b)semnale; c)schimbarea condiţiilor; d)scurgerea unui interval de timp.

a) Eveniment – apel de operaţie

Apelul de operaţie este un eveniment care, atunci când se produce, determină schimbări în starea elementului care primeşte apelul.

Acest tip de eveniment este numit mesaj, se implementează, de obicei, ca un mesaj sincron şi apare în eticheta unei tranziţii. Astfel, când un obiect transmite un mesaj altui obiect (sau lui însuşi) şi invocă o operaţie, controlul trece de la obiectul expeditor la obiectul destinatar. Obiectul apelat execută tranziţia asociată evenimentului respectiv, îşi schimbă starea şi transmite apelantului controlul. Apelurile de operaţii 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 recepţionat de alt obiect. Acest tip de eveniment se numeşte tot mesaj şi apare ca o semnătură de eveniment într-o stare de tranziţie. Semnalul poate declanşa o acţiune obiectului receptor într-o maşină de stare, în urma căreia obiectul respectiv îşi schimbă starea, sau poate fi un mesaj asincron într-o diagramă de interacţiune. 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 operaţii, iar eventualii parametri ai semnalului sunt trecuţi în compartimentul atributelor. Se poate construi o ierarhie de clase signal, adică între semnale pot exista relaţii de generalizare, dar sunt excluse orice relaţii cu clasele obişnuite.

Dacă o tranziţie are o semnătură de eveniment semnal, atunci toate subsemnalele vor putea fi recepţionate prin acelaşi semnal, aşa cum este ilustrat în figura de mai jos:

c) Eveniment – schimbareUn eveniment schimbare reprezintă trecerea unui obiect în altă stare, în funcţie de satisfacerea unei condiţii. Condiţia apare în condiţia de gardă a semnăturii unei tranziţii. În UML, un astfel de eveniment este modelat cu cuvântul 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 – temporalUn eveniment temporal este o întâmplare care depinde de scurgerea timpului. El se reprezintă în UML prin cuvântul cheie after, urmat de un interval de timp care reprezintă timpul scurs din momentul tranziţiei până la schimbarea stării. Intervalul de timp poate fi redat în limbaj natural, expresie de timp, sau în orice mod, dar trebuie să fie cât mai explicit. Această combinaţie after+expresie_timp se trece în semnătura unei tranziţii, la condiţia de gardă.

De exemplu, putem reprezenta evenimentele temporale, [after 5 secunde], [after 2 secunde de la părăsirea stării], etc. Într-un eveniment temporal, expresia din condiţia de gardă poate să nu fie precedată de cuvântul cheie after (de exemplu, putem scrie [timp = timpdat], în loc de [after timpdat]).

Activităţile stărilor

Pentru reprezentarea unei stări, se foloseşte tot dreptunghiul cu colţurile rotunjite, compartimentat în trei zone:

- Compartimentul superior este dedicat numelui stării, care trebuie să fie scris indiferent dacă dreptunghiul este compartimentat sau nu.

- În compartimentul din mijloc se scriu eventualele variabile de stare (contori, date, constrângeri, etc.).

- În zona inferioară se trec activităţile, unde vor fi specificate evenimentele şi acţiunile.

În cazul descrierii activităţilor, evenimentele şi acţiunile au aceeaşi sintaxă ca şi în cazul tranziţiilor şi anume:

Nume eveniment (listă_parametri) [condiţie_gardă]/element_ţintă.nume acţiune (listă_argumente)

Nume eveniment poate fi orice, dar, de obicei, există trei evenimente standard care pot declanşa acţiuni stărilor, şi anume:- entry – specifică acţiunea care se produce atunci când obiectul intră în starea respectivă;- exit – specifică acţiunea care se execută atunci când obiectul părăseşte starea respectivă;- do – specifică acţiunea care se execută atunci când 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 stareModelarea propoziţiei 1: Putem seta alarma “pornit” sau “oprit”

Modelarea propoziţiei 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 stări poate fi:

• “continuă”: se produce doar atunci când 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 condiţii.

În exemplul de faţă, se adaugă o activitate “Sună” în starea Sonerie şi o tranziţie automată care să iasă din starea Sonerie. O astfel de tranziţie se mai numeşte completion transition şi se reprezintă în UML fără nume de eveniment sau cuvânt cheie.

Obs. Dacă se doreşte dezactivarea alarmei în timp ce sună, va trebui adaugată o tranziţie 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 “Afişare”;

2. Când se apasă o dată butonul, ecranul trece în “schimbă ora”. Se poate schimba ora (prin incrementare cu 1) prin apăsarea repetată a butonului de Avans;

3. Dacă apăsaţi butonul de mod din nou, ecranul trece în “schimbare minute”. Apăsând butonul Avans repetat, se modifică minutele cu o unitate.

4. Apăsând încă o dată butonul Mod, ceasul trece în “Afişare”.

Desenarea diagramei de stare

Obs. În starea Afişare, e posibil să fie apăsat butonul Avans, dar apăsarea lui nu produce nici un eveniment, de aceea nu s-a mai reprezentat.

Se consideră următoarea 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ţă, apăsarea butonului Avans o dată e echivalent cu perechea «apasa» şi «eliberează». În condiţiile noului comportament, se introduce evenimentul “eliberează buton” pentru a gestiona eficient timpul de apăsare.

O primă soluţie ar fi inserarea unei condiţii asupra duratei de apăsare, precum şi a unei noi stări, numite “Incrementare rapidă” (vezi figura de pe pagina următoare).

Obs. Soluţia de mai sus e incorectă, pentru că apăsarea butonului nu poate fi contorizată în timp (acţiunile sunt atomice).

Soluţii posibile:• introducerea unei activităţi finite , “aşteaptă 2 sec”;• folosirea cuvântului cheie «after».

Să presupunem acum că se introduc alte două facilităţi ceasului: buton de lumină şi buton de alarmă.

În acest caz, avem 3 comportamente concurente:

1. controlul afisării;

2. controlul alarmei;

3. controlul luminii.

Le tratăm în ordinea simplităţii:

3. Controlul luminii

Obs. Controlul luminii poate fi modelat independent de controlul afişării şi controlul alarmei.

1. Controlul alarmei se poate face ca în exemplul “Ceas cu alarmă”.

1. Controlul afişării depinde de stările de pînă acum, în sensul în care putem modifica, prin apăsarea butonului Mod, şi timpul de declanşare a alarmei (prin modificarea orei şi minutelor). De aceea, trebuie introduse 2 noi stări.

Să punem toate comportamentele împreună.- O primă soluţie: prin intermediul unei diagrame de clasă

- A doua soluţie: arătând “regiunile concurente” din cadrul diagramei de stare. E mai puţin folosită decât prima soluţie.

Diagrame de componente şi de desfăşurare

Diagrame de componente

O diagramă de componente prezintă dependenţele existente între diverse componente software (cod sursă, cod binar, executabile, librării cu legături dinamice-DLL, etc.) care compun un sistem software. Aceste dependenţe sunt statice (au loc în etape de compilare sau link-editare) sau dinamice (au loc în timpul execuţiei).

O componentă este o parte fizică dintr-un sistem, un lucru real, care există pe un calculator. În UML, noţiunea de componentă poate să desemneze atât un tip (o categorie) de obiecte, cât şi fiecare obiect din tipul respectiv (instanţa tipului).

De exemplu, o aplicaţie executabilă este o componentă care reprezintă un tip (o categorie), în timp ce o aplicaţie care se execută la un moment dat, care are o identitate în momentul execuţiei, este o instanţă a acelui tip.

Reprezentare

Exemplu

Relaţia dintre componente şi clase

Asemănări:- Au un nume format dintr-un şir de caractere.- Au instanţe, care au un nume separat prin “:” de numele clasei, respectiv al componentei.- Pot realiza interfeţe.- Pot participa la relaţii de asociere, de generalizare, de dependenţă, de realizare şi de agregare (clase sau componente incluse în alte clase, respectiv componente).

Deosebiri:- Clasele sunt abstracţii ale unui set de atribute şi de operaţii; componentele sunt părţi fizice dintr-un sistem, rezidente într-un nod. Se utilizează componente când modelăm un lucru rezident într-un nod; în celelalte cazuri, folosim, în modelare, clase.- Clasele au atribute şi operaţii, pe când componentele au numai operaţii, accesibile numai prin intermediul interfeţelor lor.- O componentă este implementarea fizică a uneia sau a mai multor entităţi conceptuale, cum sunt clasele şi colaborările; între componente şi implementările ei există o relaţie de dependenţă.

Componentele folosite în UML pot fi împărţite în trei categorii:• Componente fundamentale (desfăşurare) – 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: fişiere cu codul sursă şi de date. Aceste componente sunt folosite în crearea, în modificarea şi în dezvoltarea executabilelor.

• Componente de execuţie – create ca o consecinţă a folosirii unui sistem executabil.

UML foloseşte ş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 fişier de date sau

fişier sursă;• <<table>> - pentru o componentă care reprezintă o tabelă a unei baze de

date;• <<document>> - pentru o componentă care reprezintă un fişier

document.

InterfeţeComponentele au numai operaţii, care pot fi accesate numai prin intermediul interfeţelor lor. Interfeţele unei entităţi (clase sau componente) reprezintă un set de operaţii pe care entitatea le pune la dispoziţia celorlalte entităţi şi care sunt ascunse prin încapsulare.

Reprezentare

O interfaţă realizată de o componentă se numeşte interfaţă de export, în sensul că interfaţa furnizează serviciile componentei celorlalte componente. O componentă poate furniza mai multe interfeţe de export.

O interfaţă folosită de o componentă se numeşte interfaţă de import, în sensul că o componentă care accesează serviciile alteia trebuie să se conformeze interfeţei acesteia.

Relaţiile de dependenţă dintre componente

Relaţia de dependenţă dintre componente este o relaţie de la o componentă client la o componentă furnizor (server) şi semnifică faptul că entităţile (clasele) incluse în componenta client pot moşteni, instanţia sau utiliza clasele incluse în componenta furnizor (server).

Dependenţele dintre componente se reprezintă, ca şi în cazul claselor, prin linii punctate între componenta utilizator (client) şi componenta furnizor de servicii (server), cu o săgeată orientată spre componenta furnizor.

Se folosesc trei tipuri speciale de dependenţe stereotipizate, şi anume:a) dependenţe de utilizare (use dependencies);b) dependenţe de apartenenţă (reside dependencies);c) dependenţe de desfăşurare (deploy dependencies).

a) Dependenţe de utilizare (use dependencies)

O dependenţă de utilizare este o relaţie de la componenta utilizator (client) la componenta furnizor (server), care indică faptul că componenta client foloseşte sau depinde de componenta furnizor.

O dependenţă de utilizare este reprezentată în mod asemănător cu relaţia de dependenţă dintre clase, printr-o linie punctată, cu o săgeată spre componenta furnizor sau spre interfaţa acesteia.

b) Dependenţe de apartenenţă (reside dependencies)

O dependenţă de apartenenţă este o relaţie de la o componentă client la un element UML furnizor şi indică faptul că elementul furnizor aparţine componentei (asemănător relaţiei de agregare dintre clase). Elementul furnizor poate fi o clasă concretă sau o clasă stereotip (<<type>>, <<implementation class>>, <<interface>>), pachete sau subsisteme.

Exemplucomponente:- Interfaţa Utilizator, care furnizează o interfaţă prin care utilizatorul poate interacţiona cu sistemul;- Date – pentru implementarea funcţionalităţii datelor memorate;

pachete şi subsisteme:- Interfaţa Utilizator, care grupează clasele care furnizează interfaţa cu utilizatorul;- Utilităţi – conţine date, timpul şi alte clase de utilităţi;- Date - subsistem pentru prelucrarea datelor.

interfeţe:IProduse – produse realizate (create sau scrise);IConsumabile – produse folosite (citite sau distruse).

- pachetul Utilităţi aparţine ambelor componente;- componenta Date conţine şi subsistemul Date, care este reprezentat în interiorul componentei (modul doi de reprezentare), în timp ce pachetul Utilităţi este legat printr-o relaţie de dependenţă de componenta client Date (modul întâi de reprezentare);- deoarece între pachetele Utilităţi şi Interfaţă Utilizator există o relaţie de dependenţă, ele trebuie să facă parte din aceeaşi componentă, altfel pachetul Interfaţă Utilizator nu va putea fi utilizat.

Diagrame de desfăşurareDiagrama de desfăşurare descrie structura sistemului în momentul execuţiei. Ea prezintă dispunerea fizică a diferitelor elemente hardware, numite noduri, care intră în componenţa unui sistem, şi repartizarea programelor executabile pe aceste elemente. În diagrama de desfăşurare, se indică nodurile şi conexiunile unui model.

NoduriUn nod este resursa care este disponibilă în timpul execuţiei unui sistem software şi reprezintă un procesor sau un dispozitiv, pe care vor fi desfăşurate şi executate componentele sistemului.

Un procesor este un nod care poate executa o componentă (calculatoare în reţea). Fiecare nod trebuie să aibă un nume. La nivelul fiecărui procesor pot fi identificate procese. Un procesor trebuie să aibă memorie şi anumite capabilităţi 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.

Distincţia 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 către 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:

Observaţii 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 său este urmat de simbolul “:” şi de numele clasei de noduri, având toate părţile numelui subliniate; ambele nume sunt opţionale, iar simbolul “:” este prezent numai dacă este specificat numele clasei de noduri;

Exemple

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

Clase de noduri:

Instanţe de clase de noduri:

- Andrei: Client; Ana: Client;- O instanţă a nodului Server;- Hp100: Imprimantă.

Organizarea nodurilor şi legăturile dintre ele

Nodurile pot fi organizate în pachete, în acelaşi 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, reţea Ethernet, linii telefonice, etc., sau indirectă, ca de exemplu conexiunea prin satelit.

T-connector

unde

Dependenţe de desfăşurare

O dependenţă de desfăşurare este o relaţie de la o componentă, numită şi componentă client, la un nod, numit nod furnizor, şi indică faptul că nodul conţine componenta respectivă.

O dependenţă de desfăşurare poate fi reprezentată în două moduri: - printr-o relaţie de dependenţă (o linie punctată cu o săgeată) de la componentă la nod şi având stereotipul <<desfăşurare>> sau <<deploy>>;- componenta este reprezentată în interiorul nodului pe care este desfăşurată (modul cel mai des utilizat).

Exemplu de diagramă de componente şi de desfăşurare

Se consideră, iniţial, pachetele: Interfaţă Utilizator şi Utilităţi şi subsistemul Raportare, care furnizează interfeţele: IVizualizare (pentru vizualizarea pe ecran a rapoartelor) şi IPrintare (pentru printarea rapoartelor). Pe parcurs se rafinează diagrama cu următoarele cerinţe:

1. Pachetul Interfaţă Utilizator foloseşte interfeţele IVizualizare şi IPrintare, furnizate de subsistemul Raportare.

2. Pachetele Interfaţă Utilizator şi Utilităţi aparţin componentei InterfaţăUtilizator.

3. Subsistemul Raportare şi pachetul Utilităţi aparţin de componenta Raportare.

4. Componenta Interfaţă Utilizator este desfăşurată pe nodul Client.5. Componenta Raportare este desfăşurată pe nodul Server Raport.6. Nodul Client este conectat la nodul Server Raport, iar nodul Server

Raport este conectat la nodul Imprimantă .

Diagrame de interacţiune

Introducere

Diagramele de interacţiune permit specificarea în detaliu a modului în care obiectele interacţionează pentru a executa un task.

UML furnizează 2 tipuri de diagrame de interacţiune:

- 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 interacţionează pentru a executa un task împreună cu legăturile dintre ele formează o colaborare.

Interacţiunea este reprezentată de secvenţă de mesaje care sunt transmise între obiecte.

Diagrama de colaborare cuprinde următoarele elemente:

a) Obiecte: dreptunghi în care sunt scrise numele obiectului şi numele clasei, separate prin “:”, toate subliniate. Dacă numele obiectului nu are o anumită semnificaţie, poate fi omis (:NumeClasa); nu este indicată această utilizare dacă există două obiecte din aceeaşi clasă.

b) Legături: 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 corespunzătoare. Pot exista mai mulţi actori, însă numai unul singur va iniţia cazul de utilizare.

d) Mesaje: pe o diagramă de colaborare, numele mesajelor se reprezintă alături de liniile ce descriu legaturile dintre obiecte, iar direcţia de transmitere a mesajului e indicată printr-o săgeată.Dacă un mesaj este transmis de la un obiect a:A către obiectul b:B, obiectul destinatar (b) trebuie să înţeleagă mesajul, adică este necesar ca în clasa din care face parte obiectul (B) să existe o operaţie corespunzătoare mesajului. Cu alte cuvinte, construirea unor diagrame de interacţiune contribuie la identificarea asocierilor dintre clase şi a operaţiilor claselor. E posibil ca prima soluţie să nu fie cea optimă.

Cum circulă mesajele? (în varianta procedurală)Un obiect începe să lucreze atunci când primeşte un mesaj; se spune că în acel moment obiectul este activat. În cele din urmă, el trebuie să trimită un răspuns 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 până când nu va primi răspuns la acest mesaj. Cu alte cuvinte, mesajul este sincron, adică la transmiterea unui mesaj se transmite controlul celui care primeşte mesajul. În fiecare moment, totul poate fi imaginat ca o stivă de activări, fiecare activare fiind asociată cu un obiect care a primit un mesaj la care nu a răspuns încă. Obiectul asociat cu activarea aflată în vârful stivei are controlul şi poate să lucreze; obiectele asociate cu celelalte activări aşteaptă răspuns la mesajele pe care le-au trimis.

Dacă obiectul asociat activării din vârful stivei trimite un mesaj, obiectul care primeşte mesajul primeşte şi controlul, iar activarea sa va fi poziţionată în vârful stivei.Pe de altă parte, obiectul asociat activării din vârful stivei poate să-şi termine lucrul şi să răspundă la mesajul care l-a activat, fiind astfel înlăturat din stivă. În acest caz, următoarea activare va deveni vârful stivei, iar obiectul asociat acesteia va recăpăta controlul.Obs. Nu este necesară reprezentarea mesajelor de răspuns într-o diagramă de colaborare.

Pentru a ţine evidenţa numărului de stive de activare, mesajele sunt numerotate, folosind următoarea regulă: primul mesaj transmis de la un obiect la altul este numerotat cu 1 (nu este socotit primul mesaj de la actorul care iniţiază interacţiunea la un obiect). Când un obiect a primeşte un mesaj, numărul acelui mesaj va fi folosit ca prefix pentru toate mesajele trimise până când a răspunde la acest mesaj.

Exemplu: dacă mesajul care îl activează pe a este numerotat cu 2.1, atunci toate mesajele trimise între acest moment şi răspunsul 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 reprezentaţi la capătul de sus al unor linii punctate, care reprezintă linia de viaţă a obiectelor, adică timpul aşa cum este perceput el de obiecte. Timpul cât este activat un obiect este reprezentat ca un dreptunghi subţire ce acoperă linia de viaţă.

Opţional, părţi din acest dreptunghi pot fi haşurate, pentru a indica perioada de timp cât acesta lucrează. Tot opţional pot fi reprezentate şi răspunsurile la mesaje, printr-o linie punctată.

Facilităţi suplimentare ale diagramelor de interacţiune

Mesaje de la un obiect către el însuşiÎntr-o diagramă de colaborare, se reprezintă printr-o legătură între obiectul respectiv şi el însuşi. Într-o diagramă de secvenţă, se reprezintă printr-o săgeată de la linia de viaţă a obiectului către ea însăşi. În acest caz, dreptunghiul subţire reprezentând noua activare este puţin deplasat faţă de cel reprezentând vechea activare.

Reprezentarea valorilor returnate de mesajeÎn UML o valoare returnată este reprezentată pe săgeata reprezentând mesajul iniţial ca o atribuire către o variabilă având un nume nou (vezi figura de pe pagina următoare).

Crearea şi distrugerea obiectelora) Diagramele de colaborare arată care obiecte sunt create şi distruse în timpul interacţiunii folosind stereotipurile «create» şi «destroy» înaintea mesajelor corespunzătoare. Alternativ, faptul că un obiect a fost creat sau distrus în cadrul interacţiunii se poate reprezenta prin constrângerile {new}, respectiv {destroyed} plasate în dreptunghiul care reprezintă obiectul (vezi figura de pe pagina următoare). Dacă un obiect este atât creat cât şi distrus în timpul interacţiunii, se poate folosi constrângerea {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 sfârşitul dreptunghiului reprezentând perioada de activare. Dacă un obiect e distrus de alt obiect va exista un mesaj de la obiectul care efectuează operaţia de distrugere către semnul X.

Reprezentarea constrângerilor 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 constrângeri de timp.

Reprezentarea la diferite nivele de abstracţie

Pentru ca interacţiunea să fie descrisă la un nivel mai înalt de abstracţie, se poate folosi o subcolaborare, adică o submulţime de obiecte împreună cu legăturile dintre ele. O subcolaborare poate fi privită ca un singur element şi poate fi reprezentată ca un pachet.

Exprimarea condiţiilor

În UML transmiterea unui mesaj poate depinde de îndeplinirea unei condiţii. În cadrul diagramei, condiţiile vor apărea în paranteze drepte şi vor fi poziţionate în faţa mesajelor corespunzătoare.

Dintr-un punct pot pleca orice număr de mesaje, cu condiţia ca acestea să aibă condiţii disjuncte. O diagramă de secvenţă cu mesaje alternative însoţite de condiţii poate fi implementată folosind structuri “if-else” sau “case”.

În cazul în care mai multe mesaje alternative sunt trimise aceluiaşi obiect, pentru a scoate în evidenţă că una dintre alternativele respective nu poate fi aleasă decât una şi ele nu pot exista simultan, în diagramele de secvenţă linia de viaţă a obiectului destinatar va avea mai multe ramificaţii, fiecare corespunzând unei alternative.

Exemplu. Să presupunem exemplu cu centrul de închirieri CD-uri şi casete, adăugăm ipoteza că există 2 tipuri de CD-uri: obişnuite şi speciale. CD-urile obişnuite pot fi împrumutate pentru o perioadă mai lungă (3 săptămâni), în timp ce CD-urile speciale mai puţin (1 săptămână).

IteraţiiPentru a arăta că un mesaj poate fi trimis în mod repetat se foloseşte un asterisc poziţionat după numărul mesajului. În plus, după asterisc se poate indica o clauză de iteraţie (plasată între paranteze drepte), care determină de câte ori va fi trimis mesajul.

Exemple:

• [n<10]: este echivalentul condiţiei while;

• [not x];

• [i:=1..10]: este echivalentul condiţiei for;

• [y in Y]: mesajul e trimis în mod repetat pentru fiecare y din colecţia Y

Figura de mai jos reprezintă diagrama de secvenţă pentru cazul unui client care cumpără un număr 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 câte ori e transmis şi primul mesaj, dar acest lucru nu va fi arătat pe diagramă.

Exemplul1. Ce rezultat va avea figura de mai jos?

Răspuns: xyxy.

Exemplul1. Ce rezultat va avea figura de mai jos?

Răspuns: xyyxyy.

Concurenţa

Până acum s-a considerat tipuri de interacţiune procedurală, în care, după transmiterea unui mesaj, obiectul care trimite mesajul aşteaptă răspunsul înainte de a-şi continua funcţionarea. Este cazul cel mai întâlnit în practică, deoarece majoritatea sistemelor funcţionează pe un singur procesor.

În cadrul sistemelor concurente, există cazurile:

• un obiect trimite simultan mai multe mesaje: se reprezintă prin mai multe săgeţi care pleacă din acelaşi loc, fără a avea asociate condiţii

• un actor sau un obiect activ trimite un mesaj la un anumit moment, deşi 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 fără ca obiectul care atrimis mesajul să-şi înceteze lucrul.

În primul caz, schema de numerotare îmbricată descrisă mai devreme va fi extinsă, în sensul posibilităţii ca la numerotarea mesajelor să apară nume sau litere care să diferenţieze mesajele trimise simultan. În ultimele 2 situaţii, schema de numerotare îmbricată îşi pierde sensul, putându-se folosi numerotarea secevnţială.

Tipuri de mesaje

Există mai multe tipuri de mesaje în UML:

• mesaje sincrone : specifice funcţionării procedurale

• mesaje de răspuns : reprezentarea e opţională

• mesaje asincrone : nu aşteaptă răspuns, obiectul rămâne activ

• mesaje simple : nu aşteaptă răspuns, obiectul pierde controlul

Exemplul1. La centrul de închirieri se consideră că există şi o componentă de statistică, responsabilă cu evidenţa 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 băuturi: cerinţe

• casa de bani va verifica dacă suma de bani introdusă de client corespunde cu preţul băuturii selectate;

• dacă suma este egală cu preţul, containerul de băuturi va livra produsul;

• dacă suma este mai mare decât preţul, 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ă decât preţul produsului, casa de bani va aştepta mai mulţi bani şi nu va face nimic.