24867036 curs tehnici de program are software

8/6/2019 24867036 Curs Tehnici de Program Are Software

http://slidepdf.com/reader/full/24867036-curs-tehnici-de-program-are-software 1/288

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 ungrup 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 suntreprezentate prin simboluri etichetate cu nume;• relaţ iile dintre entit ăţ i – desemnează tipurile de legături care pot exista întreentităţ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ăţilesistemului informatic, componentele executabile ale sistemului, locaţiilefizice 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. Dinaceastă categorie, fac parte diagramele de secvenţă, de colaborare, destare şi de activitate.



A) Modelare structurală (modelare statică)

• Se refer ă la vizualizarea, la specificarea, la construirea şi la documentareaaspectelor statice ale unui sistem, adică la relaţiile invariante dintre componenteleunui sistem. Din punct de vedere al modelării sistemelor orientate pe obiecte dinperspectiva 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ă esteo variantă a diagramei claselor, care, în locul unei clase, prezintă mai multeinstanţ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 devedere al actorilor (comportamentul sistemului, aşa cum este perceput deutilizatorii 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 saurecepţionează mesaje de la sistem sau schimbă informaţii cu acesta).

• Actorul are un rol în cadrul unui sistem, nu este un utilizator individual alacestuia, şi din acest motiv, el este o entitate (o clasă), nu o instanţă. Un caz deutilizare 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 decod şi relaţiile dintre acestea.

• Acest tip de diagramă realizează o mapare de la view-ul static (logic) la view-ulcomponentelor . O component

ăpoate s

ăcon

ţină

un cod sursă

sau să

fie subformă binar ă sau executabilă. O componentă se mapează, de obicei, pe una saumai multe clase, interfeţe sau colabor ări; din această cauză, diagramacomponentelor are legătur ă cu diagrama claselor .

• Diagramele de componente reflectă vederea statică de implementare asuprasistemului.

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

• Diagrama de desf ăşurare indică arhitectura fizică pe care este implementatsistemul, calculatoarele, device-urile (noduri ale sistemului) şi conexiunile dintreele.



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 şide 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 învedere aspectul cel mai important de evidenţiat.

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



B2) Diagrama de stare (State Diagram)

• Descrie ciclul de viaţă al unui element (al obiectelor, al subsistemelor şi alsistemelor), 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 claseieste 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 pentrumodelarea 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 maimulte paragrafe.

Obs. Un model UML descrie ce trebuie să facă un sistem, nu cum să seimplementeze sistemul.

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

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

Fiecare view focalizează atenţia echipei de realizatori asupra unui anumit tip deprobleme ş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ţiireferitoare 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ă deactorii 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 descriereastatică a aspectului funcţional şi ocazional.

• Se pot folosi şi diagrame de activitate pentru a încapsula latura dinamică afuncţ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ă serviciileasigurate 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 înurma 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 şidezvoltatorii.



V3) Modul de vizualizare componente sistem sau implementare

(The implementation or component view)

• View-ul componentelor se concentrează pe descrierea componentelor careimplementează sistemul, dependenţele care există între ele, resursele alocateacestora, precum şi rezolvarea unor probleme legate de reutilizarea, portabilitateacodului, informaţii administrative, cum ar fi un desf ăşur ător al muncii dedezvoltare.

• 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 sauconcurenţă (The behavioral or dinamic or process or concurent view)

• Acest mod de vizualizare ia în considerare cerinţele de performanţă, defiabilitate, de utilitate, etc.

• Pentru descrierea comportamentului şi a dinamicii sistemului, se folosescdiagramele de stare, de secvenţă, de colaborare şi de activitate.

• În reprezentarea acestui mod de vizualizare a sistemului, se folosesc şidiagramele de implementare (ale componentelor).

• Cei interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şiinterogatorii 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, cecalculatoare şi ce tipuri de device-uri (noduri) vor fi folosite pentru implementareasistemului, cum sunt acestea conectate, precum şi ce componente (procese) sevor executa în fiecare nod.

• Acest tip de vizualizare este reprezentat cu ajutorul unor diagrame dedesf ăşurare, care indică modul de implementare a sistemului. În acest sens, elepoartă etichete care specifică repartizarea pe tipuri de activitate şi informaţiidespre procesele executate în noduri.

• De acest tip de vizualizare sunt interesaţi dezvoltatorii, interogatorii de

sistem, precum şi cei care realizează testarea sistemului.



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 grupurilegate semantic. Rezultă că un element de modelare nu poate fi prins în maimulte 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-undreptunghi 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 vareprezenta o bază de date tabelar ă.



Proprietăţi

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

Ele se reprezintă printr-o listă de şiruri de caractere între acolade ({ }), scrisedeasupra 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)



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 knowledgethat must become the software is brought together and embodied in

the software. The process provides interaction between users and

designers, between users and evolving tools, and between designers

and evolving tools [technology]. It is an iterative process in which theevolving 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 .

C f ?



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.



Ni l l P d fi t d t lţi d h i d



Nivelul Proces: defineşte un cadru pentru o mulţime de zone cheie deproces (key process areas). Aceste zone formează baza controluluimanagementului proiectului software şi stabileşte contextul în care suntaplicate 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? şicuprinde 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 AidedSoftware Engineering), care combină software, hardware şi o bază dedate a ingineriei software (ce conţine informaţii importante despre analiză,design, construcţia programului şi testare).

M d l d ft



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



1) Modelul secvenţial liniar (cascadă)

Presupune activităţile:

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

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 :



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 şidetaliul procedural (algoritmic).

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

v) Testarea: depistarea eventualelor erori (errors), defecte (faults) şieş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



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 altecazuri, dezvoltatorul poate să aibă îndolieli cu privire la eficienţaalgoritmului, adaptabilitatea la un SO sau la forma de interacţiuneom/calculator. Pentru aceste e indicat acest model.



Clientul şi dezvoltatorul se întâlnesc pentru a stabili obiectivele deansamblu ş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ă pereprezentarea acelor aspecte ale software-ului care care sunt vizibileclientului (ex: ce anume se aşteaptă la input şi formatul output-ului).

Apare un prototip. Prototipul e evaluat de client şi folosit pentru arafina 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?



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 tostart 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 fiparadigma eficientă pentru ingineria software.

3) Modelul RAD



3) Modelul RAD

Rapid application development (RAD) e un model de proces de

dezvoltare software incrementală, care pune accentul pe ciclul dedezvoltare 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 emodelat î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 necesarepentru 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 aimplementa o funcţie business. Descrierile de proces sunt create pentruadă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 refolosicomponentele 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 totalde testare este redus considerabil. Totuşi noile componente trebuietestate şi toate interfeţele trebuie atent verificate.



Fiecare funcţie majoră e acoperită separat de o echipă şi apoi e



Fiecare funcţie major ă e acoperită separat de o echipă şi apoi eintegrată î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 rapidenecesare pentru a obţine un sistem complet într-un timp redus

• Nu toate aplicaţiile sunt potrivite pentru RAD. Dacă un sistem nu poatefi modularizat, construirea componentelor necesare pentru RAD devineproblematică.

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

Business modeling

S l b i i i (BPE) t ă d fi ă



Scopul 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 datelor

Arhitectura aplicaţiilor

Infrastructura 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 unanumit 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 ficumpăr ă.

2) Arhitectura aplicaţiei cuprinde acele elemente ale sistemului caret f ă bi t l î d l hit t ii d t l t it



transformă obiectele în cadrul arhitecturii datelor pentru un anumit scopde 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 aactivităţ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 obiectelede 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şteinteracţiunile dintre ele.



Odată un information system izolat, BPE face o tranziţie spre ingineria

software. Invocând pasul business system design (BSD), sunt modelatecerinţ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 descriuobiectul?• 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)



( q )

Termenul 4GT cuprinde o gamă largă de instrumente software care au

un lucru în comun: fiecare permite inginerului software să specificeanumite caracteristici ale software-ului la un nivel înalt. Instrumentul(tool) generează apoi automat cod sursă bazat pe specificaţiiledezvoltatorului.

Paradigma 4GT pentru ingineria software pune accentul pe abilitatea dea specifica software folosind forme de limbaj specializat sau notaţiigrafice 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ă paradigma4GT 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.



Exemplu : Software pentru editor de texte, poate livra managementul debază al fişierelor şi editarea la primul increment; editare mai sofisticată la



ş ş p ;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 (unelecunoscute, altele necunoscute) r ămân nepredate.

Acest core product e folosit de client. Ca rezultat al utilizării sau alevaluării, se dezvoltă un plan pentru următorul increment, care stabileştemodificarea core product-ului pentru îndeplinirea mai bună a cerinţelor

clientului şi furnizarea funcţionalităţilor adiţionale. Acest proces e repetatdupă 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.



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 maimultor reprezentări ale aplicaţiei

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

• Evaluarea clientului: tasks pentru obţinerea unui feed-back din parteaclientului, bazat pe evaluarea reprezentărilor software create în timpuletapei 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, laversiuni mai sofisticate ale software-ului.

Fiecare trecere prin dreptul zonei de planificare ( planning region) producerezultate în ajustarea planului proiectului.

Costul şi planificarea temporală sunt ajustate pe baza feedback-uluiderivat 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 livrareasoftware-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 axelepunctelor de intrare în proiect (project entry point axis)



punctelor de intrare în proiect ( project entry point axis).

Fiecare cub plasat de-a lungul axelor poate fi utilizat pentru a reprezentapunctul de plecare pentru diferite tipuri de proiect.

Un “concept development project” porneşte de la miezul spiralei şicontinuă până ce devine completă dezvoltarea conceptului.

C l ii



Concluzii

• Modelul spirală e o abordare potrivită pentru sistemele de maridimensiuni.

• Modelul spirală foloseşte prototipul ca un mecanism de reducere ariscurilor dar, mai important, permite dezvoltatorului să aplice abordareaprototipului 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 etapeleproiectului ş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



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 pentrusucces şi criticat pentru un eşec.

Modelul spiral al lui Boehm (Boehm, B., “Using the WINWIN Spiral Model: ACase 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ţiiwin-win pentru toţi cei implicaţi (inclusiv pentru echipa proiectuluisoftware).



În afar ă de cele 3 activităţi de negociere menţionate, modelul spirală maiintroduce 3 anchor points:

• Life cycle objectives (LCO): defineşte un set de obiective pentrufiecare 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 ă cupregă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



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 caparadigmă 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 obiectesimilare.

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 şioperaţ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ţiasau datele conţinute în ele

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

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

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

Exemplu



Un 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,di ă i î id i tăţil i l ţiil



adică se iau în considerare proprietăţile şi relaţiile.

Pe de altă parte, diagramele use case şi altele sunt folosite pentru areprezenta interacţiunea dintre clase şi să simuleze procesele

selectate. În loc de clase, aceste diagrame folosesc obiecte, care sereprezintă precum clasele (doar că sunt subliniate), cu posibilitateade 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 diferitde 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 înaceastă arie de responsabilităţi trebuie grupate într-o singur ă clasă şi nudisipate î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 aleclaselor situate deasupra; la nevoie, pot fi suprascrise (overwrite), dar nueliminate.

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 subclasapunctâ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 înGeomFigure, doar în clasele Circle ... eledevin operaţii concrete.

Obs. Operaţia setPosition() se poateimple-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.

Clase Instanţ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âteobiecte 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 întregulla păr ţile sale.

Un formă specială e cea în care păr ţile individuale depind de întreg pentruexistenţ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 unromb plin şi au totdeauna o multiplicitate 1 (sau 0..1) de partea unde rombul e reprezentat.



1)

2)



Colecţii

C l ţiil t l d fi it l î lib ă iil d l t d d i î



Colec ţ iile sunt clase definite uzual în libr ăriile de clase standard şi au încomun faptul că ele adună şi gestionează mulţimi de obiecte. Se mainumesc ş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âteobiecte 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 fiecareobiect prin intermediul căreia poate fi identificat - ex:dicţionar

Polimorfism

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



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

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

dinamic :o precondiţie este late binding

D.p.d.v. fizic, binding e punctul în viaţa unui program la care caller-ul uneioperaţii e dat de adresa de memorie a operaţiei. Uzual, se întâmplă lacompilare 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 trimisobiectului. 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ăţilesupraclasei sale. Îi este permis totuşi să redefinească o operaţiemoş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ţiaapelată) se decide doar la rulare.

Polimorfism dinamic (continuare)

În momentul în care mesajul display()



Î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 apelaRectangle.display(). Se foloseşte

totdeauna operaţia din clasa cea maispecializată. Acesta e principiulpolimorfismului (vezi figura de mai jos)

Cercuri şi dreptunghiuri



Clase

Numele claselor este, de obicei, un substantiv la singular, care trebuiesă fie cât mai sugestiv faţă de abstracţia modelată



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:



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/sau



permit să se acţioneze asupra lor. Relaţiile dintre obiecte se numesclinkuri 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. Laprimirea 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 ounitate de cod scris într-un limbaj de programare orientat pe obiecte



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 scriecodul care determină ce trebuie să execute funcţia, atunci declaraţiafuncţ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ă numaiclasei

c) Selectori - sunt metode care accesează starea unui obiect f ăr ă ao 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ă



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 modelareastructurală, 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 sistemuluisau 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ţaunui obiect poate fi considerată ca o interfaţă a clasei .

Obs. Interfaţa conţine numai operaţiile, nu şi metodele (codul) careimplementează 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 edată 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ă implementezeoperaţ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 dealte clase, ci numai de clasa respectivă şi de subclasele ei.

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

simpl ă.

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 seaplică operaţia. Se caută metoda întâi în clasa cea mai specializată aobiectului; 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 şiconcrete pot deriva din această clasă de bază.



Inginerie software

-generalităţi-

Ingineria software cuprinde metodele, instrumentele şi tehnicile folosite pentrudezvoltarea software.

software de sistem: e software-ul care se comportă caSoftware



instrument de ajutor pentru construcţia software-ului de aplicaţie.Exemple: SO, baze de date, compilatoare etc.

software de aplicaţie: e software-ul care ajută să se efectuezetask-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 cantitatemare 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-uncelular)

• 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



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 aacestei cifre cu 15%.

• Se estimează că productivitatea unui programator mediu este de 10-20 linii deprogram 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



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

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

j l ă fi i t d d t i ţi ă fi ă ăt



• 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ă ceacesta 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 edificilă ş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) Fiabilitatea

O 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 decomportarea dorită; poate să nu apar ă până când condiţiile nu sunt potrivite; esinonim 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 ca ea ă n l sa mai m lte eşec ri



• 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 impusconceptul de good enough software (software suficient de bun), adică lansarea

software-ului se produce când numărul şi severitatea defectelor (faults) devinacceptabile

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:



Exemple:• sistemele pentru controlul avioanelor;

• controlul proceselor critice (software de comunicaţ ii ce joac ă un rol critic în situaţ iilede 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 şiaproximativ 50% încalcă flagrant termenul de predare.



Diagrame de clasă

- exemple -

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



1) Fişierele, shortcut-urile şi directoarele sunt conţinute îndirectoare ş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 unelement (fişier, shortcut sau director);



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 aveaacelaşi nume în interiorul unui director, dar un fisier si un shortcut

pot avea acelaşi nume.



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, încazul general, în timp, mai multor ţări.Exemplu: Berlin



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

Conceptele defisier

,shortcut

,director

trebuie modelate în clase.Din moment ce n fişier shortc t sa director n poate fi incl s decât



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 lacel mult o asociere la un moment dat.



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



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 l ţi l tă t d l i hii d l t / i



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.



Studiu de caz: Sistem de rezervare (booking) a biletelor de avionpentru 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 înconsiderare doar companiile care ofer ă cel puţin un zbor.



(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âtatributele DepartureAirport şi ArrivalAirport în clasa Flight .



p p ş p g

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 deplecare 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 detransport aerian care se găsesşte la cel mult 30 km de un oraş, atuncimultiplicitatea 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, decie indicat să se creeze o clasă Stopover:



e indicat să se creeze o clasă Stopover :

Obs. O escală se produce într-un şi numai un aeroport şi un aeroportpoate 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:



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) şinu 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”.



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.



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:



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 alteelemente existente în model.

Exemplu: durata unui zbor (length), care se obţine ca diferenţă întrearrivalTime şi departureTime, ţinând cont (eventual) şi de arrivalDate şidepartureDate.



Clasa Flight în versiunea iniţială



Pentru updatarea modelului, trebuie:• distribuirea atributelor, operaţiilor şi asocierilor clasei Flight între claseleGenericFlight ş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 zia săptămânii e planificat zborul şi în ce perioadă a anului are loc zborul



p p ş p(validityPeriod ).

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

Obs. validityPeriod nu e un atribut simplu: putem fi interesaţi de începutulperioadei, 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



Pasul 7. Structurarea în pacheteStructurarea trebuie să ţină seama de două principii: coerenţ a şiindependenţ a.

Criteriile de coerenţă presupun a fi îndeplinite:• obiective: clasele trebuie să returneze servicii de aceeaşi natur ă cătreutilizatori;



• 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 ocă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 unasau mai multe călătorii pentru unul sau mai mulţi pasageri



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ă cuclasa JourneyByBus;

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



Pe de altă parte, clasele Customer şi Passenger în ambele tipuri derezervare. De aceea, e bine să le izolăm într-un nou pachet, dar nu înacelaşi (Geography ), ci separat.



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



Glosar de termeniRestricţii de schimbare (changeability):

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

• {addOnly}: înseamnă că deşi valoarea originală sau legătura originală nupoate 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ştemultiplicitatea 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 ţiimany a unei asocieri. Un calificativ este un atribut al unei clase de asociere,care trebuie să reducă multiplicitatea asocierii care a generat clasa deasociere. 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şatclasei, unde un obiect al clasei, împreună cu valoarea calificativului, reducemultiplicitatea la cealaltă extremitate a asocierii.

inapoi

Glosar de termeniUn 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 defiecare 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şacum se întâmplă înrealitate)

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), prinintermediul 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 şiinteracţ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 cebeneficiază î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) seidentifică 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 toatetranzacţiile f ăcute de un client prin intermediul smartcard-ului său, dar şiaccesarea soldului



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ă decontext (static context diagram)



Pasul 1 bis. Reprezentarea unei diagrame (continuare)

O altă soluţie, mai elaborată, ar fi să consider ăm Bank customer caspecializarea a lui CardHolder. Se rezolvă astfel problema excluderii

mutuale dintre cei doi actori.



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 numescactori 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 şicazurile 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)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 trebuiesolicitat; 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 actorisecundari.

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 utilizarereferitoare 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 aranjezedescrierile într-o ordine secvenţială, pentru a îmbunătăţi înţelegerea lor.

Scenarii

ţ ţ ţă



Numim fiecare unitate de descriere a secvenţelor de acţiune secvenţă.Un scenariu reprezintă o succesiune particular ă a secvenţelor, care e rulat dela î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.



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

C ti d t /11/09



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 ifi ă d ă d t l t t



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

7. VISA authorisation systemconfirmă şi indică limita zilnică deretragere

8. ATM cere Visa CardHolder să introducă suma dorită.



retragere.

9. Visa CardHolder introduce sumadorită.

10. ATM verifică dacă suma e sub limitazilnică.

11. ATM întreabă Visa CardHolder dacă doreşte chitanţă.

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

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



A2) Suma cerută e mai mare decât limita zilnică: intervine la pasul 1011. 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 11

12. 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, expiratetc.) şi îl confiscă, cazul de utilizare eşuează (fails).

E2) Număr de pin invalid după încercări repetate: intervine la pasul 5

6. ATM informează Visa CardHolder că pin-ul e incorect pentru a treia oar ă.7. ATM confiscă (smart)cardul.8. E notificat VISA AS; cazul de utilizare eşuează (fails).

E3) Retragere neautorizată: intervine la pasul 6



E3) Retragere neautorizată: intervine la pasul 67. 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 13

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

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



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 unposesor 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şidezavantajul 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 multediagrame UML mai dinamice.

Obs. Pentru cazurile de utilizare se recomandă diagramele de activitate (Activitydiagram), dar pot fi utile diagramele de secvenţe (Sequence diagram).



Obs. Pentru anumite scenarii se recomandă Sequence diagram, care se va numiSystem 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



sequence diagram caresă descrie un main

success scenario pentrucazul 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 desecvenţe

Se introduc:-activităţile principale alesistemului (prin mesajele

trimise către sistem);



trimise c tre sistem);-referinţe la secvenţelealternative şi de eroare (prinnote).

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



Identificarea unei relaţii de generalizare ce implică cazuri de utilizareConsider ăm cazurile de utilizare: Depunere cash şi Depunere cecuri. Ambeleimplică aceiaşi actori: Bank customer ca actor principal şi Bank IS ca actor secundar.



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



Diagrame de activitate

IntroducereDiagramele 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 şitranziţ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 (implementareaunei operaţii). Acesta este şi cel mai folosit caz când apelăm la acest tip dediagramă;- pentru analiza interacţiunii activităţilor unui caz de utilizare;

- pentru a ilustra modul de organizare a mai multor cazuri de utilizare şilegăturile dintre acestea.



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

Prin activitate înţelegem o prelucrare (procesare) neatomică, în curs dedesf ăş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 rezultatschimbarea stării sau returnarea unei valori.

Există trei tipuri de acţiuni, şi anume: simple, iniţiale şi finale. O activitatepoate 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. ÎnUML, o acţiune finală se reprezintă ca şi o stare finală, prin două cercurimici 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 elereprezintă încheierea activităţii respective. Tranziţiile pot, însă, să fieetichetate 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ţă. Fluxultranziţiilor arată cum sunt ordonate acţiunile în secvenţă. Într-o diagramă deactivitate, activităţile sunt legate prin tranziţii automate, spre deosebire de

diagramele de stare, unde tranziţiile între stări sunt declanşate deevenimente.

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 nouastare, dacă există şi executarea acţiunii sau a activităţii asociate noii stări,



sta e, dacă e stă ş e ecuta ea acţ u sau a act tăţ asoc ate o stă ,etc.

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

- tipărirea raportului- finală

b) Fluxul tranziţiilor obiectelor

O acţiune poate produce, modifica sau folosi obiecte. Aceste obiecte deintrare 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 estereprezentată 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 alobiectelor care să indice ordinea acţiunilor, adică atunci când o acţiunecreează un obiect de ieşire, care să fie obiect de intrare pentru următoareaacţ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-unromb 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 degardă, 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 petrecsimultan. În UML, sincronizarea între fluxurile de control se reprezintă cuajutorul 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 utilizaresau 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 deieş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 deieş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 elementulcare 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 deactivit ăţ i (aşa cum o piscină este împăr ţită în culoare de nataţie) pentru aevidenţia care element este responsabil pentru acţiunea din interiorulfiecărei zone.

Fiecare responsabilitate este repartizată unei clase sau unei organizaţii şifiecare activitate este alocată unui culoar Poziţia relativă a culoarelor nu



fiecare activitate este alocată unui culoar. Poziţia relativă a culoarelor nuare nici o semnificaţie, tranziţiile fiind libere să traverseze culoarele la carenu se refer

ă.

În UML, culoarele se reprezintă prin regiuni verticale, paralele, separate prinlinii solide. Fiecare culoar are, în partea de sus, o etichetă care indică

elementul responsabil pentru acea activitate (o clasă, un actor sau undepartament al unei organizaţii).

Exemplu.



SemnaleUML ofer ă două simboluri pentru semnale.

Primul simbol mesaj indică recepţionarea unui semnal. Numele semnaluluieste trecut într-un pentagon concav (un dreptunghi cu o latur

ăîn form

ăde

triunghi concav). Recepţionarea unui semnal este reprezentată într-odiagramă de activitate, printr-o relaţie de dependenţă de la obiectul caretrimite semnalul, la simbolul semnalului, urmată de o tranziţie de lasimbolul 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 activitate

Pentru exemplul discutatanterior (vezi figura alăturată)se adugă cerinţele:- după realizarea unui raport,se poate cere execuţia altuia;- simultan cu generarea unuiraport se poate genera şi altă operaţie (interogare,

actualizare, etc);- un raport se listează laimprimantă şi interogarea la



imprimantă şi interogarea lamonitor;

- un raport şi o interogare potfi listate numai dacă generarea a fost f ăcută cusucces;- se trimit semnale către

imprimantă şi monitor şi seprimesc semnale lageneratoarele de rapoarte şide interogări.



Diagrame de stare



g

Introducere

O diagramă de stare poate fi ataşată oricărei clase care are stări bineidentificate şi un comportament complex. O diagramă de stare descrie oistorie 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



g p ţprimirea unui mesaj.

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

Elementele unei diagrame de stareElementele principale ale unei diagrame de stare sunt următoarele:1) stări

2) tranziţii3) evenimente4) acţiuni

1) Stări

Starea acoperă toate proprietăţile statice ale unui obiect şi valorile



Starea acoper ă toate proprietăţile statice ale unui obiect şi valorilecurente 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 utilizatoriisăi;



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 unuicerc 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 multestări finale. Se reprezintă, în UML, printr-un mic cerc plin, concentricaltui cerc gol, la care sosesc săgeţi de la stările sistemului, astfel:

2) TranziţiiTranziţiile sunt relaţiile dintre stări. O tranziţie reprezintă schimbareastării sursă a unui obiect, în urma unor acţiuni, datorită producerii unuieveniment.

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

Î t di ă d t t i t



Î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 maimulte ţinte;- din mai multe stări pleacă aceeaşi tranziţie, deoarece acelaşi evenimentpoate 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).



4) Acţiuni: reprezintă o prelucrare executată de un obiect aflat într-o staresursă, declanşată în urma producerii unui eveniment (de exemplu,recepţionarea unui mesaj). O acţiune nu poate fi întreruptă deevenimente.

Î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 acestcâmp sau dacă acţiunea nu întoarce nici o valoare, atunci se vor omite şicaracterele “:=”.



- Element_ţ int ă – este numele elementului care va executa acţiunea.

Dacă elementul care enunţă acţiunea este acelaşi cu elementul careprimeşte evenimentul declanşator al acţiunii respective, atunci acest câmpse 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ă laacţiune, separaţi prin virgulă. Fiecare parametru poate fi o variabilă sau ovaloare 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, caun mesaj sincron şi apare în eticheta unei tranziţii. Astfel, când un obiectt it j lt i bi t ( l i î i) i i ă ţi



transmite un mesaj altui obiect (sau lui însuşi) şi invocă o operaţie,

controlul trece de la obiectul expeditor la obiectul destinatar. Obiectulapelat execută tranziţia asociată evenimentului respectiv, î şi schimbă starea şi transmite apelantului controlul. Apelurile de operaţii pot fi mesajeasincrone, dacă limbajul care le implementează suportă calcul paralel.

b) Eveniment – semnal

Semnalul este un obiect expediat asincron de un obiect şi recepţionat dealt 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 poatedeclanşa o acţiune obiectului receptor într-o maşină de stare, în urmacăreia obiectul respectiv î şi schimbă starea, sau poate fi un mesajasincron într-o diagramă de interacţiune. Semnalele pot avea parametri,

care se scriu între paranteze rotunde.

S l l t d fi it ti i l d l ă t ti i t



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 încompartimentul 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 esteilustrat în figura de mai jos:



c) Eveniment – schimbare

Un eveniment schimbare reprezintă trecerea unui obiect în altă stare, înfuncţie de satisfacerea unei condiţii. Condiţia apare în condiţia de gardă asemnăturii unei tranziţii. În UML, un astfel de eveniment este modelat cucuvântul cheie when, urmat de o expresie booleană. Se poate folosi o

expresie booleană pentru a indica o valoare (exemplu [when x=1]) saupentru testarea continuă a unei expresii (ca de exemplu, [when x<100]).

d) Eveniment – temporal

Un eveniment temporal este o întâmplare care depinde de scurgereatimpului. El se reprezintă în UML prin cuvântul cheie after , urmat de uninterval de timp care reprezintă timpul scurs din momentul tranziţiei până



p p p ţ pla 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 uneitranziţ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 cheieafter (de exemplu, putem scrie [timp = timpdat], în loc de [after timpdat]).



Î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 evenimentestandard care pot declanşa acţiuni stărilor, şi anume:- entry – specifică acţiunea care se produce atunci când obiectul intr ă înstarea respectivă;

- exit – specifică acţiunea care se execută atunci când obiectul păr ăseştestarea respectivă;- do – specifică acţiunea care se execută atunci când obiectul se află înt ti ă



starea respectivă.



Studiu de caz: ceas cu alarmă1. Putem seta alarma “pornit” sau “oprit”;2. La timpul setat, alarma sună continuu;3. Putem opri soneria.

Pasul 1. Desenarea unei diagrame de stare

Modelarea 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 unuianumit interval de timp



O activitate în cadrul unei stări poate fi:• “continuă”: se produce doar atunci când un eveniment are loc şiface 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 uneicondiţii.



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



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ă abutonului 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 ounitate.

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



Se consider ă următoarea comportare: dacă se apasă lung butonulAvans (mai mult de 2 secunde), incrementarea orei sau minutelor sepoate face mai repede

Cum poate fi modelat un asemenea comportament?

În exemplul de faţă, apăsarea butonului Avans o dată e echivalent cuperechea «apasa» şi «eliberează». În condiţiile noului comportament,se introduce evenimentul “eliberează buton” pentru a gestionaeficient timpul de apăsare.



O primă soluţie ar fi inserarea unei condiţii asupra duratei deapă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 nupoate 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 delumină ş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 aalarmei (prin modificarea orei şi minutelor). De aceea, trebuie introduse 2noi 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. Emai 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 întrediverse componente software (cod sursă, cod binar, executabile, libr ăriicu 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, careexistă 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 dintipul 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 momentdat, 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, respectival componentei.

- Pot realiza interfeţe.- Pot participa la relaţii de asociere, de generalizare, de dependenţă, derealizare ş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. Seutilizează componente când modelăm un lucru rezident într-un nod; în



utilizează componente când modelăm un lucru rezident într un nod; încelelalte 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 şiimplementă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ă bazasistemelor executabile, ca de exemplu: executabile, DLL-uri, controaleActiveX, JavaBeans, componente COM+, pagini WEB, tabelele bazelor de date, etc.

• Componente create de utilizator – care sunt produse rezultate dinprocesul de dezvoltare şi care formează componentele fundamentale, cade exemplu: fişiere cu codul sursă şi de date. Aceste componente suntfolosite î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ţe

Componentele au numai operaţii, care pot fi accesate numai prinintermediul 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 celorlalteentităţi şi care sunt ascunse prin încapsulare.

Reprezentare



O interfaţă realizată de o componentă se numeşte interfaţă de export , însensul 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 , însensul că o componentă care accesează serviciile alteia trebuie să seconformeze interfeţei acesteia.

Relaţiile de dependenţă dintre componente

Relaţ ia de dependenţă dintre componente este o relaţie de la ocomponentă client la o componentă furnizor (server) şi semnifică faptulcă 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 componentafurnizor de servicii (server), cu o săgeată orientată spre componentafurnizor.



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 clientfoloseşte sau depinde de componenta furnizor.

O dependenţă de utilizare este reprezentată în mod asemănător cu relaţiade dependenţă dintre clase, printr-o linie punctată, cu o săgeată sprecomponenta 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 unelement UML furnizor şi indică faptul că elementul furnizor apar ţinecomponentei (asemănător relaţiei de agregare dintre clase). Elementulfurnizor 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 poateinteracţiona cu sistemul;- Dat e – pentru implementarea funcţionalităţii datelor memorate;

pachete şi subsisteme:



- Interfaţ a Utilizator, care grupează clasele care furnizează interfaţa cuutilizatorul;- 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ţă decomponenta client Date (modul întâi de reprezentare);- deoarece între pachetele Utilităţi şi Interfaţă Utilizator există o relaţiede dependenţă, ele trebuie să facă parte din aceeaşi componentă, altfelpachetul Interfaţă Utilizator nu va putea fi utilizat.

Diagrame de desf ăşurareDiagrama de desf ăşurare descrie structura sistemului în momentulexecuţiei. Ea prezintă dispunerea fizică a diferitelor elemente hardware,numite noduri , care intr ă în componenţa unui sistem, şi repartizareaprogramelor executabile pe aceste elemente. În diagrama de desf ăşurare,

se indică nodurile şi conexiunile unui model.

Noduri

Un nod este resursa care este disponibilă în timpul execuţiei unui sistem

software şi reprezintă un procesor sau un dispozitiv , pe care vor fidesf ăşurate şi executate componentele sistemului.

Un procesor este un nod care poate executa o componentă (calculatoare înreţea). Fiecare nod trebuie să aibă un nume. La nivelul fiecărui procesor pot

ă ă



fi identificate procese. Un procesor trebuie să aibă memorie şi anumitecapabilităţi de procesare (dispozitive de calcul, resurse umane, etc.)

Un dispozitiv (echipament periferic) reprezintă un element hardware care, însistemul din care face parte, nu are putere de calcul. Fiecare dispozitivtrebuie 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 decătre utilizatorul terminalului şi ca un procesor pentru un produs softwarecare se execută pe procesorul terminalului T.

În UML, un nod se reprezintă printr-un paralelipiped (de multe ori este uncub), care este etichetat cu numele nodului, ca în figura de mai jos:

ţ l



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 prefixatde numele pachetului şi separat de acesta prin simbolul “::”;- în cazul în care nodul este un nod exemplu, numele său este urmat desimbolul “:” şi de numele clasei de noduri, având toate păr ţile numeluisubliniate; ambele nume sunt opţionale, iar simbolul “:” este prezentnumai dacă este specificat numele clasei de noduri;

Exemple

Clase de noduri:



- Client – tip procesor, pe care se execută componenta Interfaţă Utilizator;- ServerBaze – tip procesor, pe care se execută componenta Date;- Imprimant ă – tip dispozitiv, folosită de sistem pentru a lista rapoarte;

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

O conexiune reprezintă un tip hardware care realizează cuplarea între două

noduri. Conexiunea poate fi directă, ca de exemplu prin cablu, reţeaEthernet, linii telefonice, etc., sau indirectă, ca de exemplu conexiunea prinsatelit.



T-connector

unde



Dependenţe de desf ăşurare

O dependenţă de desf ăşurare este o relaţie de la o componentă, numită şicomponentă client , la un nod, numit nod furnizor , şi indică faptul că nodulconţ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 lacomponentă 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 subsistemulRaportare, care furnizează interfeţele: IVizualizare (pentru vizualizarea peecran 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 componenteiInterfaţăUtilizator.

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

4 Componenta Interfaţă Utilizator este desfăşurată pe nodul Client



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 careobiectele 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 caresistemul realizează un caz de utilizare sau un anumit scenariu dintr-un cazde utilizare.



Diagrame de colaborare

Obiectele care interacţionează pentru a executa un task împreună culegăturile dintre ele formează o colaborare.

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

Diagrama de colaborare cuprinde următoarele elemente:

a) Obiecte: dreptunghi în care sunt scrise numele obiectului şi numeleclasei, separate prin “:”, toate subliniate. Dacă numele obiectului nu are oanumită 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 existamai 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 detransmitere a mesajului e indicată printr-o săgeată.

Dacă un mesaj este transmis de la un obiect a:A către obiectul b:B, obiectuldestinatar (b) trebuie să înţeleagă mesajul, adică este necesar ca în clasa

din care face parte obiectul (B) să existe o operaţie corespunzătoaremesajului. Cu alte cuvinte, construirea unor diagrame de interacţiunecontribuie la identificarea asocierilor dintre clase şi a operaţiilor claselor. Eposibil 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ă înacel moment obiectul este activat . În cele din urmă, el trebuie să trimită unr ăspuns celui care a trimis mesajul, iar între timp el poate fie să lucreze, fiepoate 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



Dacă trimite un mesaj, el va fi în continuare activ, dar nu va putea să lucrezepână când nu va primi r ăspuns la acest mesaj. Cu alte cuvinte, mesajul estesincron, adică la transmiterea unui mesaj se transmite controlul celui careprimeşte mesajul. În fiecare moment, totul poate fi imaginat ca o stivă deactivări, fiecare activare fiind asociată cu un obiect care a primit un mesaj lacare nu a r ăspuns încă. Obiectul asociat cu activarea aflată în vârful stiveiare controlul şi poate să lucreze; obiectele asociate cu celelalte activăriaş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 fipoziţionată în vârful stivei.

Pe de altă parte, obiectul asociat activării din vârful stivei poate să-şitermine 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 suntnumerotate, folosind următoarea regulă: primul mesaj transmis de la unobiect la altul este numerotat cu 1 (nu este socotit primul mesaj de laactorul 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



un mesaj, num rul acelui mesaj va fi folosit ca prefix pentru toate mesajeletrimise până când a r ăspunde la acest mesaj.

Exemplu: dacă mesajul care îl activează pe a este numerotat cu 2.1, atuncitoate mesajele trimise între acest moment şi r ăspunsul la acest mesaj vor finumerotate cu 2.1.n.



Fig. Exemplu de numerotare a mesajelor

Diagrame de secvenţăO astfel de diagramă pune în evidenţă transmiterea mesajelor de-a lungultimpului.



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 esteperceput el de obiecte.

Timpul cât este activat un obiect este reprezentat ca un dreptunghi subţirece 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 ăspunsurilela 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 obiectulrespectiv şi el însuşi. Într-o diagramă de secvenţă, se reprezintă printr-osă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ţă decel reprezentând vechea activare.



Reprezentarea valorilor returnate de mesaje

În UML o valoare returnată este reprezentată pe săgeata reprezentândmesajul iniţial ca o atribuire către o variabilă având un nume nou (vezifigura de pe pagina următoare).

Crearea şi distrugerea obiectelor a) Diagramele de colaborare arată care obiecte sunt create şi distruse întimpul interacţiunii folosind stereotipurile «create» şi «destroy» înainteamesajelor 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 (vezifigura 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



) g p pacestuia în josul paginii. Distrugerea unui obiect este reprezentată printr-unX la sfâr şitul dreptunghiului reprezentând perioada de activare. Dacă unobiect 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, sepoate folosi o subcolaborare, adică o submulţime de obiecte împreună culegăturile dintre ele. O subcolaborare poate fi privită ca un singur element şipoate 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 fipoziţ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 fialeasă 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, fiecarecorespunzând unei alternative.



p

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-urileobişnuite pot fi împrumutate pentru o perioadă mai lungă (3 săptămâni), întimp ce CD-urile speciale mai puţin (1 săptămână).



Iteraţii

Pentru a ar ăta că un mesaj poate fi trimis în mod repetat se foloseşte unasterisc poziţionat după numărul mesajului. În plus, după asterisc se poateindica 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 decâte ori e transmis şi primul mesaj, dar acest lucru nu va fi ar ătat pediagramă.

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şiobiectul care lucrează în acel moment este alt obiect din sistem

• un obiect trimite un mesaj asincron, adică un mesaj care poate face ca altobiect să lucreze f ăr ă ca obiectul care atrimis mesajul să-şi înceteze lucrul.



În primul caz, schema de numerotare îmbricată descrisă mai devreme va fiextinsă, în sensul posibilităţii ca la numerotarea mesajelor să apar ă nume

sau litere care să diferenţieze mesajele trimise simultan. În ultimele 2situaţii, schema de numerotare îmbricată î şi pierde sensul, putându-sefolosi 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 laun 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 corespundecu 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 vaverifica 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.

24867036 curs tehnici de program are software

Documents