metode de dezvoltare software.pdf

METODE DE DEZVOLTARE SOFTWARE

Prof. univ. dr. Udrica Mioara

CUPRINS

1.2 STRUCTURA GENERALĂ A UNUI SISTEM INFORMATIC .............................................. 2

2. APLICAREA METODELOR ORIENTATE OBIECT ÎN DEZVOLTAREA.......... 6

SISTEMELOR INFORMATICE ...................................................................................... 6

2.1 MODELUL ORIENTAT OBIECT .................................................................................... 7 2.1.2 Instrumente ale modelului orientat obiect ...................................................... 9

2.2 UNIFIED MODELLING LANGUAGE (UML) – LIMBAJ STANDARD DE MODELARE ... 12

Temă: ........................................................................................................................ 12 Descrieţi limbajul UML ........................................................................................... 12 2.3 Diagrame UML ............................................................................................. 13

3.1 TEHNICI DE SPECIFICARE ......................................................................................... 24 3.2 TEHNICI DE CONCEPŢIE ........................................................................................... 26 3.3 TEHNICI DE VALIDARE............................................................................................. 27

3.3.1 Verificare dinamică ........................................................................................ 27 Exemplu de aplicare a testului cutiei albe.............................................................. 28 3.3.2 Verificare statică............................................................................................. 30

BIBLIOGRAFIE .............................................................................................................. 47

1. ORGANIZAŢIA - SISTEM DESCHIS DEFINIT CA SUPORT ÎN PROCESUL DE

DEZVOLTARE SOFTWARE

1.1 Organizaţia în viziune sistemică

Etapa actuală este etapa în care economia mondială a trecut de la

societatea predominant industrială la societatea informaţională, guvernată de un

set nou de reguli, în care tehnologiile digitale permite accesarea, procesarea,

stocarea şi transmiterea informaţiilor. Complexitatea activităţilor desfăşurate la

nivelul organizaţiilor reclamă o viziune sistemică, în care fiecare componentă

este parte a unui întreg.

În cadrul teoriei generale a sistemelor, disciplină ştiinţifică care elaborează

principiile metodologice de investigare a sistemelor, care asigură o bază formal

metodologică unitară de cercetare, un loc important îl ocupă sistemele deschise,

sisteme ce pot realiza o stare de echilibru dinamic cu mediul exterior.

Organizaţiile în cadrul cărora se desfăşoară activităţi economice sunt

considerate sisteme deschise (fig. 1).

Fig. 1

. sistemul informaţional se defineşte ca un ansamblu organizat şi integrat de

operaţii de culegere, transmitere, prelucrare, sistematizare, analiză şi

păstrare, difuzare şi valorificare a informaţiilor.

. sistemul informatic este un ansamblu structurat şi corelat de proceduri şi

echipamente electronice de calcul care permit culegerea, transmiterea şi

prelucrarea datelor, obţinerea de informaţii. sistemul informatic = cuprinde ansamblul acţiunilor formale furnizoare de informaţie,

desfăşurate sau planificate în interiorul organizaţiei.

1.2 Structura generală a unui sistem informatic

Evidenţierea structurii generale a unui sistem informatic se obţine

pornind de la funcţia acestuia de a prelucra datele în vederea obţinerii

informaţiilor necesare unei desfăşurări normale a activităţilor într-o organizaţie.

Principalele componente sunt: intrări, prelucrări, ieşiri.

Intrările pot fi clasificate în tranzacţii externe şi tranzacţii interne.

Tranzacţiile externe reprezintă mulţimea datelor de intrare provenite din

exteriorul sistemului. Sunt date consemnate pe documente în cadrul sistemului

operaţional (număr factură, tip document de plată, nume client), sau sunt date

provenite din mediul exterior (cursul de schimb valutar, cotele de TVA, cotele

de impozit).

Tranzacţiile interne sunt reprezentate de date intermediare de lucru, obţinute

în urma unor prelucrări desfăşurate în cadrul sistemului informaticl (situaţia

stocurilor şi soldurilor la o anumită perioadă, valoarea totală a produselor

livrate, valoarea totală a încasărilor).

Prelucrările reprezintă un ansamblu omogen de proceduri automate cu funcţie

de:

• creare şi actualizare a bazei de date;

• consultare a bazei de date;

• reorganizare a bazei de date;

SISTEM DECIZIONAL

SISTEM INFORMAŢIONAL

SISTEM OPERAŢIONAL

MEDIUL EXTERIOR

Date Ordine

Informaţii Decizii

• salvare/restaurare a bazei de date.

Ieşirile sistemului informatic sunt reprezentate de rezultatele prelucrărilor

desfăşurate. Ieşirile pot fi obţinute în urma unor operaţii de transfer a datelor,

sau pot fi obţinute în urma operaţiilor de calcul pe baza unor algoritmi

prestabiliţi.

În funcţie de conţinutul şi forma lor de reprezentare, ieşirile pot fi

clasificate astfel:

• indicatori sintetici

• rapoarte

• grafice

• foi de calcul electronice

• ieşiri destinate altor sisteme

Dintre componente, setul de programe utilizat pentru efectuarea

prelucrărilor ocupă un loc important, impunând contextul de utilizare,

organizarea şi funcţionarea celorlalte componente. Cunoscut sub denumirea de

produs program, produs informatic sau produs software, pentru mulţi autori

substituie noţiunea de sistem informatic. Din punct de vedere structural,

cuprinde două elemente fundamentale: date şi prelucrări (Wirth N-Prentice

Hall, EngleWood Cliffs, 1976):

Structuri de date + Algoritmi de prelucrare = Produs software

Un produs software poate reprezenta un program ce rezolvă anumite

probleme, un sistem de operare, un compilator, un program utilitar, un mediu

de operare, un mediu de programare, un mediu de rezolvare, o platformă, o

procedură, un program editor, un generator de programe, un program ativirus,

un document HTML/PHP/ASP, un program de e-mail, un browser, etc.

În cadrul unei organizaţii, necesitatea unei viziuni unitare asupra

activităţii desfăşuratede impune înglobarea produsele software într-un sistem

informatic. Metodele de dezvoltare software sunt astfel incluse în metodele de

dezvoltare ale sistemelor informatice.

1.3 Metode şi modele utilizate în dezvoltarea sistemelor informatice

Dezvoltarea unui sistem informatic se face conform unei metode,

definită printr-un proces şi un sistem de notaţie.

▪ procesul specifică activităţile efectuate pentru conceperea modelelor, ordinea

în care se execută şi modul lor de corelare.

▪ sistemul de notaţie precizează conceptele şi regulile de reprezentare a

modelelor.

Într-o primă clasificare, metodele pot fi grupate în metode hard şi metode soft.

Metodele hard pun accentul pe abordarea ştiinţifică şi consideră că

realitatea, independentă de oameni, poate fi modelată, înţeleasă şi

transformată în funcţie de dorinţele acestora. Consideră că toate problemele

pot fi formalizate pe baze matematico-logice şi acordă proiritate datelor,

funcţiilor şi proceselor.

Metodele soft încearcă să rezolve probleme legate de aspectele sociale

ale dezvoltării sistemelor, de cerinţele utilizatorilor. Din punctul lor de vedere,

analistul se confruntă cu situaţii problemă şi nu cu probleme clar definite şi

gata de rezolvare. Măsurile luate într-o situaţie sunt rezultatul schimbării

organizaţionale, analistul de sistem fiind văzut nu ca un expert în domeniu ci ca

un agent al schimbării, capabil să-i stimuleze pe ceilalţi în obţinerea unor noi

percepţii asupra contextului problemei.

În funcţie de obiectivele propuse, la definirea sau reproiectarea unui

sistem informatic, există:

. metode orientate-funcţii ( metode ale descompunerii funcţionale );

. metode orientate-proces (metode ale fluxurilor de date);

. metode orientate-date (metode orientate spre informaţii);

. metode orientate-obiect (iau în calcul în principal evenimentele la care trebuie

să răspundă sistemul).

În funcţie de modalitatea în care este perceput sistemul, există:

. metode de analiză şi descompunere ierarhică (funcţională);

. metode de analiză şi reprezentare orientată-sistemic ;

. metode de analiză şi proiectare orientată-obiect.

Dintre acestea cele mai des utilizate în practică sunt metodele sistemice

şi metodele orientate obiect:

▪ medodele sistemice reprezintă cea de-a doua generaţie a metodelor de

analiză şi proiectare. Bazându-se pe teoria generală a sistemelor, în cadrul

acestor metode, datele şi prelucrările asupra datelor sunt modelate şi studiate

independent. Împreună formează un sistem. Axându-se pe conceptul de bază de

date, care oferă coerenţă şi elimină redundanţele, metodele sistemice acordă

prioritate datelor faţă de prelucrări. Dezavantajele acestor metode rezultă din

existenţa deficienţelor în modelarea prelucrărilor, în prezenţa unor discordanţe

între modelele datelor şi cele ale prelucrărilor.

Metodele sistemice respectă cele trei nivele de abstractizare introduse prin

metodologia ANSI/SPARC: conceptual, logic şi fizic. Există astfel următoarele

modele:

pentru date:

• model conceptual al datelor

• model logic al datelor

• descriere fizică a datelor

pentru prelucrări:

• model conceptual al prelucrărilor

• descriere logică a prelucrărilor

• descriere fizică a prelucrărilor

Principalele metode sistemice sunt: MERISE, AXIAL, Information

Engineering.

▪ metodele orientate obiect reprezintă cea de-a treia generaţie, utilizate

astăzi în cazul sistemelor cu comportament dinamic, dependent de timp. Se

definesc entităţi de sine stătătoare, în care sunt încapsulate datele

(proprietăţi) şi prelucrările prin care este implementat comportamentul lor

(operaţii).

Avantajul acestor metode rezultă din faptul că oferă posibilitatea

reutilizării componentelor. Existând o integrare mult mai bună a datelor cu

prelucrările, aduc o rezolvare coerentă a aspectelor dinamice. Dezavantajul

este însă că nu întotdeauna modelarea corespunde realităţii reprezentate.

Cele mai utilizate metode sunt: Object Modeling Technologie (OMT),

Object Oriented Design (OOD). Succesul utilizării metodelor orientate obiect a

determinat definirea unui limbaj standard de modelare, Unified Modeling

Language.

Indiferent de particularităţi, o metodă de dezvoltare a sistemelor

informatice poate fi definită ca un ansamblu de procedee folosite în vederea

realizării unui sistem de programe ce evidenţiază structura şi funcţionalitatea

sistemului real. Rezultatul este concretizat într-un ansamblu de documente de

concepţie, de programe şi de tehnici de testare, care:

. propun un demers, distingând etapele de dezvoltare în ciclu de viaţă al

sistemului;

. apelează la modularizare, reutilizare, abstractizare;

. propun formalisme (limbaje) şi tipuri de documente (modele) care facilitează

comunicarea, organizarea şi verificarea.

Exemple:

RAD – Rapid Aplication Develoment

RUP – Rational Unified Process

2TUP – Two Track Unified Process

XP - eXtreme Programming

Metodele de dezvoltare dezvoltare a sistemelor informatice acoperă

întregul ciclu de viaţă al sistemului: specificarea cerinţelor, analiza şi

proiectarea, implementarea, testarea şi documentaţia. La sfârşitul fiecărei

iteraţii se reevaluează priorităţile proiectului.

De exemplu, în cazul Rational Unified Process, ciclul de dezvoltare este

prezentat în figura următoare:

Temă:

Prezentaţi o metodă de dezvoltare a sistemelor informatice

2. Aplicarea metodelor orientate obiect în dezvoltarea

sistemelor informatice

Tehnicile orientate obiect constituie un nou mod de abordare a

sistemelor informatice, bazat pe abstracţii ce corespund lumii reale. Obiectele

din domeniul sistemului real formează cadrul de lucru pentru definirea unui

model şi ulterior conduc la implementare.

Până în faza finală dezvoltarea orientată obiect este un proces

conceptual independent de limbajul de programare. Poate servi ca mediu pentru

analiză şi documentare, pentru definirea interfeţei cu utilizatorul, sau pentru

programare.

Metodele orientate obiect acoperă întregul ciclul de viaţă al sistemului,

împărţit în trei faze: analiză, proiectare, implementare.

analiza

În faza de analiză se construieşte un model precis, concis şi inteligibil al

activităţii desfăşurate (business model), un model complet al sistemului ce va fi

construit.

. analistul descrie ce trebuie să facă sistemul şi nu cum o face, urmăreşte

definirea a ceea ce urmează să realizeze, şi nu a algoritmilor care vor fi folosiţi.

. obiectele sunt concepte din domeniul sistemului şi nu din domeniul

programării.

. atenţia este îndreptată asupra conceptelor care vor forma nucleul unei soluţii

ce utilizează tehnici orientate obiect.

. analiza este selectivă, neacordându-se aceeaşi importanţă tuturor

componentelor şi însuşirilor; sunt examinate cerinţele, analizate implicaţiile,

reţinute doar aspectele esenţiale.

. sistemul real se descompune în entităţi distincte, se stabilesc legăturile dintre

ele şi funcţiile îndeplinite.

. rezultatul este un model cu clase şi asocieri, folosirea acestora făcându-se în

partea de proiectare şi implementare.

proiectarea

Scopul principal al proiectării orientate obiect este să maximizeze

posibilitatea reutilizării claselor în proiecte ulterioare, să identifice în relaţiile

de moştenire superclasele care facilitează reutilizarea în cadrul aceluiaşi

proiect.

. se păstrează structura claselor stabilită în partea de analiză, luând în

considerare minimizarea timpului de execuţie şi folosirea raţională a memoriei.

. operaţiile identificate în etapa de analiză sunt exprimate algoritmic, cele

complexe sunt descompuse în operaţii interne simple. Atributele şi asocierile

sunt prezentate într-o formă ce permite ulterior implementare ca structuri de

date specifice.

. clasele sunt rearanjate prin evidenţierea unor relaţii de agregare sau de

generalizare, sunt completate cu noi operaţii şi noi atribute, rezultate din

abstractizarea comportamentului comun.

. modelul claselor poate fi rafinat prin introducerea de noi clase, care păstrează

rezultate intermediare de calcul.

. considerând clasele ca nişte ,,cutii negre” a căror interfaţă externă este

publică, dar ale căror detalii interne sunt ascunse, proiectantul decide atributele

care sunt vizibile din exterior. Ascunderea informaţiei interne permite ca

implementarea unei clase să fie modificată, fără a cere clienţilor clasei să-şi

modifice codul. Este necesară o nouă documentare a claselor, pe baza celei din

partea de analiză, care să conţină şi modificările care au apărut în faza de

proiectare.

într-o ultimă fază a proiectării, clasele şi asocierile se regrupează în module.

implementarea

În timp ce primele două etape sunt independente de mediul de

programare, în această etapă trebuie aleasă soluţia informatică pentru realizarea

efectivă a sistemului.

. clasele şi relaţiile sunt translatate într-un limbaj de programare, de regulă

orientat obiect.

. în cele mai multe cazuri, scrierea secvenţelor de cod într-un limbaj orientat

obiect se face aproape automat, pe baza deciziilor luate în fazele anterioare.

2.1 Modelul orientat obiect

Aplicarea metodelor orientate obiect în dezvoltarea sistemelor

informatice conduce la construirea unui model obiect. Elementul central al

modelului îl constituie obiectul.

2.1.1 Obiecte

Un obiect este o abstracţie, un concept, folosit pentru reprezentarea

lumii reale şi furnizarea unei baze practice pentru implementarea cu ajutorul

tehnicii de calcul. Descompunerea sistemului real în obiecte depinde de

modelator şi de natura concretă a problemei.

Exemple:

persoana IONESCU, produsul CALCULATOR, factura AS-1234 din 12/03/04

sunt obiecte din lumea reală, ce se regăsesc în sistemul informatic privind

personalul angajat, gestiunea resurselor şi respectiv vânzarea de produse.

Caracteristicile unui obiect sunt: identitate, stare, comportament.

Modelul obiect poate fi definit ca o reprezentare directă a realităţii cu ajutorul

unor componente elementare cu identitate proprie şi caracterizate prin stare şi

comportament.

Identitatea unui obiect este acea proprietate a obiectului care îl distinge

de alte obiecte. Obiectul este definit de un identificator intern unic, independent

de valoarea sau de adresa de memorie a obiectului. Identificatorul nu este

controlat direct de programator şi nu se confundă cu diferitele nume utilizate de

programator pentru a-l numi.

Starea obiectului reprezintă mulţimea valorilor tuturor atributelor şi

legăturilor sale la un moment dat. Starea este adesea asociată cu valoarea unui

obiect satisfăcând anumite condiţii.

Exemple:

▪ persoana IONESCU, caracterizată prin atributele nume, prenume, vârstă,

vechime în muncă, poate fi în starea angajat cu carte de muncă sau pensionar,

în funcţie de valorile atributului vârstă.

▪ factura AS-1234 din 12/03/09 poate fi în starea achitată sau neachitată, stare

determinată de factori externi, reprezentaţi prin încasarea sau nu a contravalorii

sale.

Comportamentul este determinat de ansamblul operaţiilor pe care

obiectul le poate executa. Exprimă modul în care un obiect acţionează şi

reacţionează.

Exemple:

▪ pentru persoana IONESCU, operaţia afişează permite calcularea şi afişarea pe

ecran valorii atributului vechime în muncă.

▪ pentru factura AS-1234 din 12/03/09, operaţia modifica_factura determină

modificări în datele înregistrate despre factură.

Comportamentul este cel care alterează starea unui obiect, determină

schimbarea stării sale. Corespunzătoare comportamentului global al obiectului,

mulţimea valorilor grupate într-o stare, specifică răspunsul obiectului la

evenimentul primit.

2.1.2 Instrumente ale modelului orientat obiect

Pornind de la componentele elementare, modelul obiect se obţine

folosind instrumente specifice tehnicilor orientate obiect. Acestea sunt:

abstractizarea, încapsularea şi ierarhizarea.

abstractizarea

Tema:

Explicaţi conceptul de abstractizare.

În cazul tehnicilor orientate obiect, prin abstractizare se evidenţiază

caracteristicile esenţiale ale unui obiect, cele care-l disting de alte obiecte.

Practic, problema se abstractizează prin gruparea obiectele în clase.

Abstractizarea dă putere modelării şi capacitate de generalizare de la câteva

cazuri particulare la cazuri similare. Definiţiile comune (numele atributelor)

sunt memorate o singură dată pentru clasă, în loc să fie memorate pentru

fiecare instanţă. Operaţiile pot fi scrise o singură dată şi toate obiectele

beneficiază de codul reutilizat.

clase şi obiecte

O clasă de obiecte descrie o mulţime de obiecte cu aceleaşi proprietăţi

(atribute), acelaşi comportament (operaţii) şi relaţii similare faţă de alte obiecte.

Fiecare obiect se mai numeşte instanţă a clasei. În termeni implementaţionali,

fiecare obiect conţine un pointer la clasa din care provine, deci are acces la

toate caracteristicile clasei sale.

O clasă este definită prin:

• numele clasei;

• atributele, expresie a valorilor diferitelor stări ale instanţelor de clasă;

• operaţiile pentru manipularea instanţelor de clase, numite metode.

Specificarea metodei poartă numele de semnătură, iar codul care

implementează operaţiile constituie corpul metodei.

Noţiunea de clasă este mai mult utilizată de faza de execuţie,

presupunând două aspecte: generarea de obiecte şi stocarea setului de obiecte

care reprezintă instanţele claselor. Cu ajutorul clasei se descriu obiectele.

Obiectul posedă propriile lui valori, lista atributelor şi metodele fiind gestionate

de clasă.

încapsularea

Încapsularea este un proces de grupare a elementelor unei clase în

elemente accesibile din exterior şi elemente proprii.

.permite separarea aspectului extern, accesibil altor obiecte, de implementarea

internă.

. oferă posibilitatea de a masca atributele proprii ale unui obiect, precum şi

modul în care se execută operaţiile. Implementarea poate fi astfel schimbată

fără a afecta aplicaţia.

. garantează integritatea datelor conţinute în obiect, datele încapsulate fiind

protejate de accese nedorite.

. constituie una din premisele de bază ale reutilizării. Un obiect poate evolua în

timp fără a afecta restul sistemului.

ierarhizarea

Ierarhizarea este o operaţie de ordonare a claselor. Ajută la

identificarea relaţiilor într-o ierarhie, la clarificarea şi buna înţelegere a

problemei.

În modelarea sistemelor reale, cele mai importante tipuri de relaţii

prezente în ierarhia claselor sunt agregarea şi generalizarea.

Agregarea este o relaţie de tip parte-întreg, în care obiecte care

reprezintă componente ale unui întreg, sunt asociate cu întregul. Este o formă

de asociere în care există un obiect agregat, format din componentele sale,

componentele fiind văzute ca parte a agregatului. O aceeaşi parte poate aparţine

mai multor agregări. Semantic agregatul este văzut ca un obiect, tratat ca o

unitate în multe operaţii, deşi fizic este format din mai multe obiecte.

Generalizarea este o relaţie dintre o clasă de bază şi una sau mai multe

clase derivate ale ei. Atributele şi operaţiile comune sunt grupate în superclasă,

fiind moştenite de clase.

Observaţii:

. Agregarea nu este un concept independent, ci o formă specială de asociere.

. În timp ce în cazul agregării una din clase are un rol predominant în raport cu

celelalte, în cazul generalizării clasele sunt integral coerente, subclasa aducând

eventuale informaţii adiţionale, specifice.

. Agregarea implică două clase, una fiind parte a celeilalte. Generalizarea este

un mijloc de structurare a descrierilor pentru o clasă. Superclasa şi clasa

specifică proprietăţile unui obiect, obiectul fiind instanţă a superclasei şi

instanţă a clasei.

moştenirea

Partajarea atributelor şi operaţiilor de-a lungul unei ierarhii între clase şi

subclase este evidenţiată cu ajutorul conceptului de moştenire.

Moştenirea permite constituirea de noi tipuri de obiecte şi clase, evitând

rescrierea şi recodificarea. Noua clasă poate moşteni atât operaţii (metode), cât

şi variabile de instanţă (atribute). În primul caz se poate vorbi de partajarea

codului între metode (code sharing), iar în al doilea caz, de partajarea

structurii între atribute (structure sharing).

Exemplu: în sistemul informatic privind contractarea şi vânzarea

produselor, documentele pe cere se consemnează activităţile desfăşurate sunt

contractul şi factura de vânzare. Prin generalizare se poate defini o clasă

DOCUMENT, care are drept atribute NumărDocument şi DatăDocument.

Operaţiile sunt: CautăDată(NrDoc) şi StergeDocument(NrDoc). Clasele

CONTRACT şi FACTURĂ moştenesc atributele şi operaţiile clasei

DOCUMENT. În plus, clasa CONTRACT are atributele TermenContract şi

ValoareContract, iar clasa FACTURĂ are în plus atributul StareFactură.

Moştenirea între clase poate fi privită sub două aspecte:

•• structural, când o clasă are atribute moştenite de la superclasă;

•• comportamental, când o clasă are metode moştenite de la superclasă.

Tema:

Construiţi exemple pentru moştenire strucutrală şi comportamentală.

Moştenirea poate fi implementată static sau dinamic.

. moştenirea statică presupune adăugarea câmpurilor moştenite. În timp ce

execuţia este rapidă neimplicând parcurgerea legăturilor de moştenire,

redefinirea unei clase este dificilă, implicând actualizarea tuturor subclaselor.

. moştenirea dinamică se realizează fără copierea câmpurilor moştenite, şi

presupune parcurgerea legăturilor de moştenire. Actualizarea este mai uşoară,

dar execuţia este mai puţin eficientă.

Tema:

Construiţi exemple pentru moştenire statică sau dinamică.

Observaţii:

. Generalizarea şi moştenirea sunt abstracţii puternice folosite pentru

transmiterea similarităţilor de la o clasă la alta, păstrând totuşi diferenţele dintre

DOCUMENT NumărDocument DatăDocument CautăDată(NrDoc) ŞtergeDocument(NrDoc)

CONTRACT TermenContract

Valoare contract

FACTURĂ

StareFactură

acestea. Subclasele moştenesc trăsăturile superclasei, dar pot avea propriile lor

atribute şi operaţii.

. În timp ce generalizarea se referă la relaţia dintre aceeaşi clasă şi subclasele

sale, moştenirea se referă la mecanismul de a transmite atribute şi operaţii de-a

lungul unei relaţii de generalizare. În implementare, moştenirea este sinonimă

cu noţiunea de reutilizare a codului. Trăsăturile reutilizabile sunt grupate în

superclase.

polimorfism

În strânsă legătură cu moştenirea, polimorfismul defineşte caracteristica

unei operaţii de a se comporta în mod diferit în funcţie de clasa de obiecte

căreia îi aparţine. Polimorfismul permite invocarea pentru obiecte de diferite

tipuri a operaţiilor cu acelaşi nume (semnătură), dar semantică şi implementare

diferită. La primirea mesajului, stabilirea metodei care se aplică se face în mod

dinamic, în funcţie de clasa obiectului în cauză. Instanţe ale unor clase diferite

pot fi adresate uniform, primind aceleaşi mesaje, dar manifestă comportamente

diferite.

2.2 Unified Modelling Language (UML) – limbaj standard de modelare

Temă:

Descrieţi limbajul UML

Unified Modeling Language (UML) este succesorul unui val de metode

de analiză şi proiectare orientate obiect, apărute la sfârşitul anilor 80 şi

începutul anilor 90. Este un limbaj unificat de modelare, rezultatul unui proces

de introducere a standardizării în analiza şi proiectarea orientate obiect. Este

punctul de pornire în dezvoltarea viitoarelor limbaje grafice.

Contribuţii esenţiale în definirea limbajului unificat de modelare au avut Grady

Booch, Jim Rumbaugh şi Ivar Jacobson.

UML nu este o metodă, este o notatie grafica care acoperă majoritatea

tipurilor de diagrame necesare în timpul ciclului de viaţă al dezvoltării

software.

Punctele forte:

▪▪ este un cadru de analiză obiect, oferind:

.. diferite perspective complementare ale sistemului, care ghidează utilizarea

conceptelor obiect;

.. numeroase nivele de abstractizare, care permit controlul complexităţii cu

ajutorul soluţiilor obiect.

▪▪ este un suport de comunicaţie

.. notaţia grafică permite exprimarea vizuală a unei soluţii obiect;

.. aspectul formal al notaţiei sale limitează ambiguităţile;

.. aspectul vizual facilitează evaluarea şi compararea soluţiilor.

▪▪ este un limbaj formal şi normalizat care:

.. câştigă precizie;

.. câştigă stabilitate;

.. încurajează utilizarea instrumentelor CASE.

▪▪ asigură independenţă faţă de limbajul de implementare şi de domeniul

aplicaţiei

Puncte slabe:

▪ punerea în practică a limbajului UML necesită pregătire complexă de

specialitate.

▪ permite reprezentarea modelelor, dar nu defineşte procesul de elaborare al

modelelor. Este un demers iterativ şi incremental, ghidat de cerinţele

utilizatorilor de sistem.

▪ nu descrie cum se dezvoltă software-ul, dar se poate folosi cu orice proces.

2.3 Diagrame UML

Ghidat de cerinţele utilizatorului de sistem, UML este folosit într-un

demers iterativ şi incremental, bazat pe nivele de abstractizare. Diagramele

UML sunt mijloacele de reprezentare şi vizualizare a elementelor de modelare.

Temă: Prezentaţi cele 4+1 perspective definite de Ph. Kruchten în 1995.

2.3.1 Diagrama cazurilor de utilizare

Diagrama cazurilor de utilizare descrie funcţionalitatea sistemului din

punctul de vedere al utilizatorului. Conţine actori şi cazuri de utilizare:

. actorii sunt elementele din sistem care generează sau primesc evenimente.

. un caz de utilizare este o secvenţă de acţiuni declanşate când un actor

apelează la sistem pentru a îndeplini un proces.

Un caz de utilizare este iniţiat întotdeauna de un actor şi exprimă o

funcţie a sistemului, declanşată ca răspuns.

Constituindu-se într-un set complet de evenimente iniţiate de unul sau

mai mulţi actori, diagrama cazurilor de utilizare precizează limitele sistemului,

specifică interacţiunea care are loc între actori şi sistem, relaţiile dintre sistem

şi mediu. In plus, permit utilizatorului să-şi structureze cerinţele, să definească

modul în care va interacţiona cu sistemul pentru a obţine rezultatul dorit.

Pentru reprezentare se folosesc următoarele simboluri:

actor participare caz de utilizare

UML defineşte trei tipuri de relaţii între actori şi cazurile de utilizare (fig. 1)

•• Relaţia de comunicare: actorul participă direct la cazul de utilizare;

•• Relaţia de incluziune: o instanţă a cazului de utilizare sursă include şi

comportamentul descris de un alt caz de utilizare. Acest tip de relaţie se

foloseşte pentru simplificarea diagramei cazurilor de utilizare în situaţii

complexe.

•• Relaţia de extensie: cazul de utilizare sursă poate fi extins cu

comportamentul unui alt caz de utilizare destinaţie. Prin relaţia de extensie

poate fi introdus, în anumite condiţii, sub forma unui caz de utilizare distinct,

un nou caz de utilizare.

Observaţii (fig. 1)

. aceeaşi persoană poate juca rolul mai multor actori, iniţiind mai multe cazuri

de utilizare.

. un caz de utilizare poate avea mai mulţi actori, fiecare cu rolul său

...

fig .1

Descrierea unui caz de utilizare constă în una sau mai multe instanţe ale

cazului de utilizare, numite“scenarii”. Scenariile sunt utilizate pentru a

evidenţia alternative într-un caz de utilizare şi pentru a testa completărilor sau

corecţiilor în cazurile de utilizare.

Un scenariu include următoarele elemente:

• începutul cazului de utilizare - evenimentul care declansează cazul de

utilizare;

• sfârşitul cazului de utilizare - evenimentul care provoacă sfârşitul cazului de

utilizare;

• interacţiunea actorilor în cadrul cazului de utilizare;

• schimbul de informaţii în timpul interacţiunilor între sistem şi actori;

• cronologia şi originea informaţiilor, momentul înregistrării lor în interiorul

sau în exteriorul sistemului;

• repetările de comportament, care pot fi descrise în secvenţe de cod prin

structuri repetitive;

• situaţiile opţionale, folosind o formulare de tipul: "Actorul alege unul dintre

evenimentele următoare, eventual de mai multe ori”.

Descrierea cazurilor de utilizare cuprinde:

▪ denumire sau titlu

▪ scop

▪ actori

▪ punct iniţial

▪ punct final

▪ descriere derulare

▪ rezultat măsurabil

Exemplu:

în sistemul informatic privind acordarea unui credit pentru o firmă,

descrierea cazului de utilizare -Analiza documentaţiei depuse- este:

Denumire : Analiza documentaţiei depuse

Scop : Calcularea coeficientului de risc

Actori: Inspectorul de credite

Punct iniţial: Inspectorul de credite solicită documentaţia depusă de firmă

Punct final: Obţinerea valorii coeficientului de risc

Descriere derulare:

• inspectorul de credite solicită documentaţia depusă de firmă;

• dacă firma este un client al băncii se verifică informaţiile existente despre

client; dacă nu, baza de date este actualizată cu datele generale ale clientului;

• din documentaţie se selectează informaţia care contribuie la calcularea

coeficientului de risc;

• în cazul unui coeficient de risc ridicat, cererea este respinsă;

• se analizează suma cerută de firmă prin comparaţie cu posibilităţile băncii de

a acorda creditul solicitat;

• dacă rezultatul este favorabil (nivel de responsabilitate < 100.000.000) cererea

de credit este admisă şi înregistrată;

Rezultat măsurabil: Cererea de credit este admisă şi înregistrată, sau respinsă

Pentru acest caz de utilizare avem diagrama cazului de utilizare în figura 2.

fig. 2

2.3.2 Diagrama claselor şi diagrama obiectelor

Structura statică a sistemului, privită ca ansamblu al claselor de obiecte

şi al relaţiilor dintre clase, este reprezentată cu ajutorul a două tipuri de

diagrame: diagrama claselor şi diagrama obiectelor.

Diagrama claselor prezintă structura sistemului dintr-un punct de vedere

general. În strânsă legătură cu ea, diagrama obiectelor evidenţiază obiectele şi

legăturile dintre ele. Diagramele obiectelor prezintă cazuri particulare,

facilitează înţelegerea structurilor de date complexe.

Clasele corespund semantic entităţilor din sistemul real. O clasă

desemnează un grup de obiecte care au proprietăţi similare (atribute), un

comportament comun (operaţii) şi relaţii comune cu alte obiecte. Reprezentarea

unei clase presupune specificarea atributelor ce-i definesc structura, a

operaţiilor ce-i definesc comportamentul şi a relaţiilor cu celelalte clase:

. fiecare atribut poate lua o valoare dintr-un domeniu de definiţie specificat în

reprezentarea clasei. Implicit, atributele sunt încapsulate în clasă, accesul la ele

fiind permis prin intermediul operaţiilor.

. operaţiile sunt reprezentate împreună cu numărul, ordinea şi tipul

argumentelor necesare definirii acţiunii lor. În cazul când operaţia este o

funcţie, se specifică şi tipul valorii returnate.

. asocierea este o conexiune semantică bidirecţională între clase. Ea este

reprezentată printr-o linie continuă între clasele implicate, de-a lungul căreia se

scrie numele asocierii. Dacă sensul de transmitere a mesajelor este unic, acesta

se evidenţiază printr-o săgeată de la emiţător la receptor.

Dintre proprietăţile unei asocieri, multiplicitatea este cel mai des

întâlnită în diagramele de structură. Este determinată de context şi evidenţiază

numărul instanţelor unei clase ce se pot asocia cu o singură instanţă din altă

clasă.

În diagrama claselor, multiplicitatea se specifică printr-o cifră urmată

eventual de semnul “+” sau semnul „*”, printr-un interval sau printr-o

succesiune de cifre. Astfel,

1 înseamnă că o instanţă a unei clasei este legată la o singură instanţă a clasei

asociate;

(1+) sau (1*) înseamnă că una sau mai multe instanţe ale unei clase sunt legate

cu o instanţă a clasei asociate;

2-5 înseamnă că două până la cinci instanţe ale unei clase sunt legate cu o

instanţă a clasei asociate;

1,2,3 înseamnă că una, două sau trei instanţe ale unei clase sunt legate cu o

instanţă a clasei asociate.

Agregarea şi generalizarea, ca forme de asociere prezente în procesul

de ierarhizare a claselor, sunt reprezentate cu simboluri specifice:

. agregarea este reprezentată printr-un romb plasat la capătul de asociere al

clasei agregat (figura 2.4);

. generalizarea este reprezentată printr-un triunghi ce punctează spre

superclasă(figura 2.4);

În UML, o clasă este reprezentată printr-un dreptunghi în care se

specifică numele clasei, atributele şi operaţiile.

Nume clasă Furnizori

Atribute cod:integer

Nume:string

Operaţii CitesteCod()

ScrieNume()

Desemnarea obiectelor se face prin nume individuale sau prin nume

generice în locul numelor individuale; numele obiectului este subliniat.

401_furnizor : Furnizori

Observaţie:

Notaţia UML permite reprezentarea nivelului de vizibilitate al atributelor şi

metodelor, definind trei drepturi de acces:

. public – funcţiile din toate clasele pot accede la aceste atribute sau metode;

. protejat – accesul este rezervat funcţiilor din clase între care există o relaţie de

generalizare (funcţiile claselor şi subclaselor);

. privat – accesul este limitat la metodele clasei.

Corespunzător, caracterul ce reprezintă vizibilitatea este:

+ pentru un atribut public;

# pentru un atribut protejat;

- pentru un atribut privat.

Figura 3 prezintă diagrama claselor în cazul sistemului informatic privind

aprovizionarea cu produse conform comenzilor primite de la clienţi

fig. 3

Teme: Completaţi diagrama claselor cu atribute şi operaţii.

Construiţi o diagramă a claselor în care să evidenţiaţi relaţia de

generalizare

2.3.3 Diagrama de secvenţe

Diagrama de secvenţe ilustrează interacţiunile dintre obiecte de-a lungul

unui scenariu al unui caz de utilizare.

. fiecare obiect este reprezentat printr-un dreptunghi în care se înscrie numele.

Linia de viaţă a obiectului se specifică printr-o bară verticală.

. mesajele sunt reprezentate prin săgeţi orizontale de la emiţător la receptor.

Convenind că timpul se scurge de sus în jos, ordinea de trimitere este dată de

poziţia pe axa verticală.

. elementele prezente în diagrama de secvenţe sunt translatate în diagrama

claselor:

. mesajele corespund operaţiilor prin care obiectele comunică;

. pentru fiecare mesaj, în clasa obiectului destinatar trebuie să existe o operaţie

corespunzătoare, reacţia obiectului la mesajul primit.

Exemplu:

în sistemul informatic privind aprovizionarea cu mărfuri, succesiunea

operaţiilor de la receptia mărfii până la înregistrarea facturii in cadrul

serviciului financiar poate fi prezentată în diagrama de secvenţe din figura 4.

fig. 4

2.3.4 Diagrama de colaborare

Diagrama de colaborare este complementară diagramei de secvenţe,

constituind un alt mod de reprezentare a relaţiilor dintre obiecte.

. prezintă un grup de obiecte şi interacţiunile dintre ele; obiectele şi legăturile

dintre ele au aceeaşi reprezentare ca în diagrama obiectelor;

. mesajele schimbate între obiecte sunt reprezentate de-a lungul legăturilor;

ordinea de trimitere a diferitelor mesaje este indicată printr-un număr amplasat

la începutul mesajului.

. numele mesajului corespunde unei operaţii definite în clasa obiectului

destinatar al mesajului, argumentele sale corespunzând parametrilor actuali ai

operaţiei;

. argumentele mesajelor sunt reprezentate ulterior fie în pseudocod fie în

sintaxa limbajului de programare;

. pentru a evidenţia declanşarea interacţiunilor de către un element extern

sistemului, în diagramele de colaborare pot fi cuprinşi actori.

De exemplu (fig.5), diagrama de colaborare definită pentru a evidenţia

aprovizionarea cu materiale şi păstrarea lor în gestiune este:

fig.5

În faza de analiză, diagramele de colaborare urmăresc scenarii definite

pornind de la cazurile de utilizare. Ele pot completa modelul de analiză,

adaugând noi clase: de frontieră (pentru interacţiunile dintre sistem şi actori) şi

de control.

În faza de proiectare, diagrama de colaborare furnizează un punct de

vedere complet al dinamicii sistemului, evidenţiind comportamentul claselor ca

răspuns la apariţia unor evenimente, noi operaţii şi clasele cărora le aparţin.

Colaborările definite pentru a urmării anumite cerinţe ale utilizatorilor

pot conduce la apariţia sau dispariţia unor obiecte, la modificarea proprietăţilor

unui obiect, la actualizarea restricţiilor de integritate sau la modificarea

relaţiilor dintre obiecte. În cazul în care obiecte aparţinând aceleiaşi clase

participă la colaborări diferite, în funcţiile de scenarii diferite ale aceluiaşi caz

de utilizare, se pot specifica împreună cu mesajele condiţii ce aduc detalii

suplimentare pentru implementare.

Diagramele de colaborare împreună cu diagramele de secvenţe

alcătuiesc aşa zisele diagrame de interacţiune, ce evidenţiază mesajele trimise

între obiecte. În timp ce o diagramă de secvenţe se construieşte pentru un

singur scenariu în care pot fi implicate mai multe obiecte, diagramele de

colaborare conţin un grup restrâns de obiecte, ce pot fi implicate în mai multe

scenarii.

2.3.5 Diagrama de stare

Diagrama de stare (diagrama schimbărilor de stare) descrie

comportamentul obiectelor unei clase prin stări şi evenimente.

. completează descrierea unui caz de utilizare;

. se construieşte doar pentru clasele cu comportament dinamic semnificativ;

. modelează ciclul de viaţă al unei singure clase, evidenţiind şi eventualele

evenimente trimise de ea la altă clasă din sistem;

. conţine o singură stare iniţială şi una sau mai multe stări finale, determinate de

condiţiile de apariţie ale evenimentelor; starea este descrisă printr-un nume care

o identifică şi o listă de acţiuni/activităţi ce sunt executate la apariţia unui

eveniment.

. tranziţia de la o stare la alta reprezintă schimbarea stării datorită unui

eveniment; ea este reprezentată printr-o săgeată de la starea sursă la starea

destinaţie etichetată cu:

.. numele evenimentului care a generat tranziţia

.. condiţia de apariţie a evenimentului

.. acţiunea ce se execută la apariţia evenimentului.

. elementele prezente în diagrama de colaborare sunt translatate în diagrama

claselor:

.. acţiunile/activităţile ce sunt executate la apariţia unui eveniment corespund

unor operaţii descrise în clasă;

.. starea unui obiect la un moment dat este evidenţiată printr-un atribut inclus

între atributele clasei

Exemplu: în sistemul informatic privind aprovizionarea, diagrama de stări

pentru o factură este cea din figura 6:

fig. 6

2.3.6 Diagrama de activităţi

Diagrama de activităţi descrie comportamentul sistemului introducând

elemente de implementare. Foloseşte următoarele elemente: acţiune, tranziţie,

decizie:

. acţiunea corespunde unei etape în execuţia unui algoritm. Fiecare operaţie,

privită ca o înlănţuire de acţiuni, poate fi detaliată în operaţii elementare.

Pentru simplificarea diagramelor, acţiuni omogene pot fi grupate în

subactivităţi.

. tranziţia de la o acţiune la alta se reprezintă printr-o săgeată etichetată

eventual cu:

▪ numele evenimentului care determină tranziţia

▪ condiţia de apariţie a evenimentului

. decizia indică ramificarea unei tranziţii în funcţie de îndeplinirea unei

condiţii.

Ataşată unui caz de utilizare, diagrama de activităţi îi detaliază acţiunile

şi procesele corespunzătoare. Pentru prezentarea derulării acţiunilor sunt

folosiţi termeni apropiaţi utilizatorului.

Exemple:

▪ diagrama de activităţi din figura 7 evidenţiază activităţile desfăşurate pentru

aprovizionarea cu marfă şi înregistrarea ei în gestiune. Poate folosi pentru

completarea descrierii cazurilor de utilizare din sistemul informatic privind

aprovizionarea, sau poate însoţi diagrama de secvenţe din cadrul aceluiaşi

sistem informatic.

fig. 7

Ataşată unei clase cu comportament dinamic semnificativ, diagrama de

activităţi descrie tranziţia de la o stare la alta sau algoritmul de prelucrare al

operaţiilor; conţine elemente de implementare ale operaţiilor descrise în clase.

Acţiunile pot fi descrise în limbaj natural, în pseudocod sau într-un limbaj de

programare (C++, Visual Basic). Echivalente schemelor logice utilizate în

programarea structurată, diagramele de activităţi conţin structurile

fundamentale de programare: liniară, repetitivă sau alternativă.

3. Tehnici de dezvoltare a sistemelor informatice (elemente de inginerie

software)

Progresele înregistrate în domeniul tehnicii de calcul şi mai ales în

domeniul limbajelor de programare, au determinat apariţia şi dezvoltarea

Ingineriei Software (Software Engineering). Privită ca un cumul de metode şi

tehnici bazate pe realizări din domeniul IT, permite trece de la o dezvoltare a

produselor ad-hoc şi imprevizibilă, la o dezvoltare structurată, constructiva şi

sistematică, cu scopul de a produce în mod industrial sisteme informatice de

cea mai bună calitate.

Termenul a fost adoptat în 1968 la NATO Software Engineering

Conference, ţinută la Garmisch, Germania. Include cunoştinţe, instrumente şi

metode pentru definirea cererilor, pentru specificarea, construirea şi întreţinerea

programelor.

Dintre definiţii menţionăm:

F. L. Bauer (prima definiţie dată ingineriei software):

Ingineria programării este stabilirea şi utilizarea de principii inginereşti solide

pentru a obţine în mod economic programe sigure şi care funcţionează eficient

pe maşini de calcul reale.

IEEE Standard Glossary of Software Engineering Technology (1983):

Ingineria software reprezintă abordarea sistematică a dezvoltării, funcţionării,

întreţinerii şi retragerii din funcţiune a programelor.

Acest domeniu:

▪▪▪ are ca scop dezvoltarea metodelor, instrumentelor şi tehnicilor ce pot

asigura un proces de producere software controlat, rezultatul fiind sisteme

software performante şi fiabile.

▪▪▪ este legat de tehnologii şi practici aparţinând ştiinţei calculatoarelor,

managementului proiectelor, ingineriei, proiectării interfeţelor şi altor domenii.

▪▪▪ este în relaţie cu alte discipline de inginerie: inginerie de sistem şi gestiune

de proiecte, siguranţa şi fiabilitatea sistemelor.

▪▪▪ se preocupă de procedeele de construire software, astfel încât să fie

îndeplinite următoarelor criterii:

▪ sistemul creat răspunde nevoilor utilizatorilor;

▪ calitatea corespunde contractului de service iniţial;

▪ costurile rămân în limitele prevăzute iniţial;

▪ întârzierile rămân în limitele prevăzute iniţial.

Temă:

Prezentati şi comentati citeva definitii/caracteristici ale ingineriei software.

Principalele ramuri ale ingineriei software acoperă:

▪ tehnicile de specificare

▪ tehnicile de concepţie

▪ tehnicile de validare/verificare

▪ gestiunea proiectelor

▪ aspectele socio-economice ale proiectelor de dezvoltare a produselor

software.

3.1 Tehnici de specificare

Prin specificare înţelegem o descriere a unor caracteristici ale

produsului final, (un program sau o aplicaţie formată dintr-un sistem de

programe) care trebuie să fie realizat în mod obligatoriu de către proiectant

(programator) pentru ca produsul să poată fi acceptat şi utilizat de beneficiarul

său.

În fiecare dintre etapele de dezvoltare a sistemelor software complexe,

scopul şi instrumentele de descriere a specificaţiilor sunt diferite.

http://ro.wikipedia.org/wiki/Inginerie

Corespunzător, există diferite tehnici de specificare, caracteristice fiecărei faze

de dezvoltare:

▪ tehnici de specificare a cerinţelor sau a exigenţelor funcţionale şi

nefuncţionale (eficacitate, dimensiuni, siguranţă în funcţionare etc.); se aplică

în faza de analiză a cerinţelor şi se exprimă, în general, în limbaj natural;

▪ tehnici de specificare a sistemului; se aplică în faza de analiză de sistem şi se

referă la natura funcţiilor oferite, la comportamentul dorit şi la datele necesare

pentru realizarea funcţiilor;

▪ tehnici de specificare a arhitecturii sistemului; se aplică în faza de

concepţie generală şi definesc modulele de arhitectură ce urmează să fie

realizate;

▪ tehnici de specificare tehnică (sau de detaliu); se aplică în faza de proiectare

detaliată a modulelor, programelor şi structurilor de date;

In teoria ingineriei software sunt recunoscute două criterii de clasificare

a specificaţiilor:

1▪ prin formalismul utilizat:

▪▪ specificaţii informale – exprimate, în general, în limbaj natural;

. permite comunicarea între nespecialişti;

. nu impune reguli sau convenţii de structurare şi este lipsită de precizie,

fiind, prin urmare, dificil de analizat.

▪▪ specificaţii semiformale – prezentate în general în forme grafice, având un

înţeles mai mult sau mai puţin precis;

. modelul nu este normalizat, fiind deschis faţă de alte metode de reprezentare

care aduc elemente specifice fără a denatura modelul;

. modelul permite specificarea structurilor de date şi a relaţiilor dintre

elementele de date care compun structurile reprezentate;

▪▪ specificaţii formale – a căror sintaxă şi semantică sunt definite în mod formal

printr-un aparat matematic adecvat.

. sunt bazate pe aparate matematice (teoria mulţimilor, logica clasică, logicile

neclasice (cum ar fi logicile temporale) etc.

. sunt utilizate pentru specificarea tipurilor de date abstracte, dar pot fi

generalizate pentru a permite specificarea unor sisteme complete (ex: limbajul

“Z”).

2 ▪ prin caracteristicile descrise:

. specificaţii declarative – descriu doar proprietăţile produsului, necesare

pentru a răspunde cerinţelor utilizatorului;

. specificaţii operaţionale – descriu comportamentul produsului în raport cu

cerinţele utilizatorului; sunt descrise printr-un model care poate fi simulat pe o

cale oarecare.

Tema:

Exemplificaţi utilizarea limbajului UML în specificarea semiformală a

produselor software

3.2 Tehnici de concepţie

Faza de concepţie constă în construirea unei prime forme a sistemului,

pe baza specificaţiilor rezultate din faza de analiză. Prin rafinarea acestei

prime forme, în etape succesive (iterativ), se obţine o imagine finală a

sitemului, imagine ce permite trecerea la etapa de realizare a programelor

(implementare).

Tehnicile de concepţie permit definirea arhitecturii logice a sistemului

proiectat într-o formă care corespunde cerinţelor funcţionale exprimate în faza

de analiză. Prin urmare, tehnicile de concepţie fac legătura între cerinţele

utilizatorului şi soluţia de programare găsită pentru implementarea aplicaţiei.

Sunt cunoscute în prezent două paradigme, de concepţie diferită, privind

modelarea conceptuală a produselor software: funcţională şi obiectuală.

Tehnicile funcţionale permit, în general, modelarea proceselor

informaţionale sub trei aspecte, care pot fi văzute separat sau complementar:

1. dinamic, referitor la fluxurile de date şi care reprezintă transformarea datelor

în sistem;

2. static, referitor la structura logică a datelor (entitate-relaţie);

3. funcţional, referitor la structura logică a prelucrărilor (componentele

programabile şi relaţiile lor în sistem).

Printre cele mai cunoscute tehnici funcţionale se numără: SADT (Structured

Analysis and Design Technique, JSD (Jackson Software Development),

MERISE.

Tehnicile obiectuale (orientate obiect) au fost concepute pentru a

permite dezvoltarea unor componente reutilizabile ale sistemelor software.

Aceste componente (module) încorporează într-o formă coerentă datele,

funcţiunile şi logica de control a modulelor programabile. Tehnicile obiectuale

pot fi considerate ca fiind, în mod egal, metode de specificare (analiză) şi

metode de concepţie (proiectare).

Abordarea obiectuală se deosebeşte de cea funcţională prin faptul că nu

tratează (separă) în mod distinct datele de prelucrări, propunând regruparea şi

asocierea datelor şi prelucrărilor în entităţi numite “obiecte”. Fiecare obiect

posedă un ansamblu de proprietăţi ale datelor cu care operează (numite

“atribute”) şi un ansamblu de operaţii predefinite (numite “metode”) care îi

permit să răspundă unor cereri de prelucrare. Obiectele comunică între ele prin

mesaje care activează metodele din obiectele receptoare. Toate obiectele care

posedă aceeaşi structură aparţin unei clase, toate obiectele similare ca structură

fiind numite instanţe ale clasei căreia îi aparţin.

Sunt cunoscute mai multe astfel de metode: metoda OMT (Object

Modeling Technique), metoda Booch, metoda OOSE (Object Oriented

Software Engineering).

Tema:

Exemplificaţi utilizarea UML în faza de concepţie a produselor software

3.3 Tehnici de validare

Verificarea sistemelor software nu se referă numai la cod (program),

acoperind toate produsele specifice fazelor ciclului de viaţă al unui proiect

informatic. Rezultatul verificării nu constă, în mod necesar, în acceptarea sau

respingerea produsului. De cele mai multe ori, se caută anomaliile posibile în

funcţionarea produsului. Identificarea unor defecţiuni posibile ale produselor

software este limitată, mai ales în cazurile programelor de mari dimensiuni.

Verificarea sistemelor software este necesară, în primul rând, pentru

descoperirea erorilor de concepţie care pot influenţa funcţionalitatea

produsului (caz în care verificarea constă în testarea comportamentului

produsului în diverse contexte de funcţionare), sau pentru identificarea cauzelor

unor defecţiuni care apar în funcţionarea curentă a produsului.

In terminologia IEEE (norma 729), termenul de defecţiune (cădere) este

folosit pentru a desemna o stare a produsului care generează o eroare

manifestată printr-o anomalie în funcţionarea programului, şi care constă în

producerea unui rezultat anormal (în raport cu o anumită normă), sau într-o

pană provocată la nivelul sistemului gazdă (blocaj unitate centrală sau

periferice, blocarea sistemului de operare etc.):

Anomalie (fault)

Defecţiune Eroare

Pană (failure)

Există două moduri de abordare a procesului de verificare, care trebuie

să fie considerate complementare:

- verificare dinamică (numită şi verificare experimentală sau testarea

produsului) a comportamentului produsului folosind seturi de date care

simulează condiţiile reale de exploatare;

- verificare statică şi analiza proprietăţilor produsului, fără simularea

execuţiei programelor componente.

3.3.1 Verificare dinamică

Se efectuează jocuri de test (de încercare) care nu pot fi, în general,

exhaustive. Jocul de test este ales astfel încât rezultatele execuţiei programului

să fie comparabile cu rezultatele aşteptate conform specificaţiilor de

funcţionare ale produsului (parţiale sau globale). Scopul este de a pune în

evidenţă eventualele erori. Testele pot să arate prezenţa erorilor dar nu pot

demonstra absenţa erorilor.

În construirea testelor se disting trei moduri de abordare a construcţiei

jocurilor de test:

a) Abordarea aleatoare a testului

Testul este ales în mod aleator din domeniul de definiţie al datelor de

intrare ale programului. Domeniul de definiţie este stabilit pe baza

specificaţiilor de interfaţă operator-maşină ale programului (intrări-ieşiri).

Metoda nu garantează o bună acoperire a ansamblului intrărilor. In particular,

testul poate să nu surprindă unele limite sau situaţii de excepţie, având astfel o

eficacitate limitată.

b) Abordarea funcţională (sau a “cutiei negre”) :

Se iau în considerare numai specificaţiile privind funcţiunile

programului (sau CE trebuie să facă produsul). Specificaţiile trebuie să fie

suficient de clare şi complete pentru a permite verificarea fiecărei funcţiuni

predefinite. Verificarea funcţională se referă în special la date şi rezultate.

Poate să apară însă riscul unor “explozii combinatoriale”, care antrenează

necesitatea de a dispune de un volum foarte mare şi de o largă varietate de date

de intrare, şi care ar putea duce la costuri şi durate excesive de testare.

c) Abordarea structurală (sau a “cutiei albe”):

In această formă, testarea se referă la structura internă a programului

(modulului). Se pot stabili mai multe criterii de aplicare a testului:

c1) Criteriul parcurgerii instrucţiunilor – jocul de test trebuie să arate că

toate instrucţiunile elementare sunt executate cel puţin o dată;

c2) Criteriul parcurgerii arcelor şi nodurilor grafului de control –

graful de control este o reţea care cuprinde structurile de control ale

programului, cum ar fi spre exemplu:

c3) Criteriul de parcurgere a drumurilor din graful de control.

c4) Criteriul de verificare a condiţiilor.

Exemplu de aplicare a testului cutiei albe

Fie următorul program descris în pseudocod:

citeşte(x)

citeşte(y)

z = 0

semn = 1

dacă x < 0 atunci

semn = -1

x = - x

sfârşit dacă

dacă y < 0 atunci

semn = - semn

y = - y

sfârşit dacă

atâta timp cât x >= y execută

x = x - y

z = z + 1

sfârşit

z = semn * z

a) Desenaţi graful de control asociat programului şi numerotaţi nodurile.

b) Prin ce secvenţă de noduri trebuie să trecem pentru a satisface criteriul de

acoperire a instrucţiunilor? Precizaţi jocul de test minim necesar pentru

satisfacerea acestui criteriu.

c) Prin ce secvenţă de noduri trebuie să trecem pentru a satisface criteriul de

acoperire a arcelor ? Precizaţi jocul de test minim necesar pentru satisfacerea

acestui criteriu.

d) Prin ce secvenţe de noduri trebuie să trecem pentru a acoperi toate drumurile

posibile din graf ? Precizaţi jocul de test minim necesar pentru satisfacerea

acestui criteriu.

Soluţie:

a)

b) noduri 1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=-5, y=-2)

c) noduri 1 2 5 8 11 12 şi 1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=2, y=5) et (x=-5, y=-2)

d) noduri 1 2 5 8 11 12 şi 1 2 5 8 9 10 11 12 / 1 2 3 4 5 8 11 12 şi

1 2 3 4 5 8 9 10 11 12 / 1 2 5 6 7 8 11 12 şi

1 2 5 6 7 8 9 10 11 12 / 1 2 3 4 5 6 7 8 11 12 şi

1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=2, y=5) (x=5, y=2)

(x=-2, y=5) (x=-5, y=2)

(x=2, y=-5) (x=5, y=-2)

(x=-2, y=-5) (x=-5, y=-2)

3.3.2 Verificare statică

Spre deosebire de verificarea dinamică, verificarea statică are ca scop

analiza proprietăţilor produsului, fără simularea execuţiei programelor

componente.

Sunt cunoscute două tipuri de tehnici de verificare statică: tehnici

informale şi tehnici formale. Aplicarea acestor tehnici depinde de

complexitatea produsului software analizat şi de scopurile testării.

Tema: prezentaţi tehnicile informale şi tehnicile formale din cadrul

verificării statice.

4. STUDIU DE CAZ

Utilizarea limbajului UML depinde de complexitatea sistemului real ce

urmează a fi modelat, de metoda de management şi realizare a proiectelor, de

tipul sistemului informatic ce se doreşte realizat, precum şi de nivelul de

detaliere dorit în faza de proiectare.

Diagramele UML :

. pot conduce la obţinerea unui model al activităţilor desfăşurate în sistemul

real;

. pot contribui la obţinerea unei scheme concise ce răspunde problemelor cheie

ale aplicaţiei;

. pot furniza specificaţii detaliate pentru sincronizarea modelului cu codul

sursă;

. pot evidenţia erori în soluţiile sistemelor deja construite .

Fiecare diagramă se construieşte într-un anumit moment al dezvoltării

sistemului şi are o anumită utilitate în proiect. Deciziile sunt luate de echipa de

realizare a proiectului, ţinând cont de cerinţele funcţionale ale sistemului şi de

resursele disponibile.

4.1- Diagrame UML construite pentru obţinerea unui model al

activităţilor desfăşurate într-o organizaţie

In acest studiu de caz ne propunem să evidenţiem utilizarea diagramelor

UML pentru obţinerea unui model al activităţii desfăşurate într-o organizaţie.

În locul descrierii explicite a activităţii desfăşurate, am preferat să evidenţiem

procesele identificate.

Pentru fiecare etapă vom prezenta exemple şi vom propune teme ce pot fi

dezvoltate luând în calcul activitatea desfăşurată în organizaţie. Diagramele

UML construite conduc în final la o diagramă a claselor completă,

implemetabilă într-un limbaj orientat obiect. În paralel, pornind de la aceeaşi

diagramă, se poate construi un model al claselor persistente, ce conduce la baza

de date relaţională care asigură persistenţa datelor.

Ne vom opri după etapa de proiectare, considerând că soluţia de implementare

şi persistenţa datelor fac obiectul altor discipline din programa de învăţământ.

Teoretic, întregul ciclu de viaţă al sistemului informatic poate fi împărţit

în mai multe etape. Acestea sunt:

A construirea unui model al sistemului real (Business modelling);

B analiza (Analysis);

C proiectarea (Design);

D implementarea. (Implementation).

. importanţa şi amploarea etapelor se stabileşte în funcţie de dimensiunea şi

scopul sistemului;

. aceste etape se parcurg formal sau nu, conştient sau nu, dar se parcurg;

. fiecare etapă are nevoie de intrări provenite din cea anterioară şi produce

iesire pentru următoarea;

. etapele se desfăşoară succesiv; dacă însă lucrează echipe specializate pe faze

de dezvoltare, se pot desfăşura şi în paralel, pentru că dezvoltarea orientată

obiect urmează un model în spirală.

A Construirea unui model al sistemului real este etapa în care se

identifică procesele desfăşurate şi modul în care ele interacţionează.

Activităţile din cadrul proceselor se detaliază cu ajutorul diagramelor de

activităţi, în 3 etape:

..A1.. se identifică procesele şi se includ, pe mai multe nivele, într-o diagramă

generală a activităţilor desfăşurate. Diagrama este mai degrabă cuprinzătoare

decât precisă, ascunzând structura organizaţională şi descriind doar

funcţionalitatea organizaţiei.

Exemplu:

Activităţile desfăşurate conduc la identificarea mai multor procese, ce pot fi

grupate pe 3 nivele:

Nivel 1: .1- Planificare = dezvoltă şi monitorizează planul tactic şi strategic al

organizaţiei: investiţii, resurse, evaluare performanţe, monitorizare riscuri şi

oportuinităţi.

.2- Aprovizionare = cuprinde toate activităţile legate de aprovizionare, inclusiv

achitarea facturilor primite de la furnizor; include contractarea precum şi

asigurarea calităţii articolelor aprovizionate.

.3- Vânzare = înregistrează întreaga activitate de vânzare, incluzând

marketingul, comenzile de la clienţi, facturarea, distribuţia.

.4- Producţie = include producţia şi depozitarea, transportul între secţia de

producţie şi depozite.

.5- Dezvoltare = se referă la construcţii pentru fabrici, secţii de producţie,

birouri, depozite.

.6- Finanţe = vizează circuitul banilor şi controlul activităţilor financiare:

investiţii, gestiune a conturilor bancare, raportări legale.

.7- Cercetare = urmăreşte cercetările întreprinse pentru dezvoltarea şi

optimizarea activităţii desfăşurate.

Nivel 2:

De exemplu, procesul .3- Vânzare se poate detalia astfel:

.3.1 negociere contract;

. 3.2 preluare comenzi;

. 3.3 livrare articole;

.3.4 acceptare refuzuri;

. 3.5 facturare;

. 3.6 încasare facturi.

Nivel 3: De exemplu,

▪ procesul .3.2. preluare comenzi se poate detalia astfel:

.3.2.1 se confirmă alegerea clientului

.3.2.2 se preia comanda de la client

3.2.3 se negociază data livrării

3.2.4 se stabileşte data livrării

3.2.5 se confirmă detaliile din comandă

▪ procesul .3.5 facturare se poate detalia astfel:

. 3.5.1 identificare a bunurilor livrate şi acceptate;

. 3.5.2 stabilire a preţului de vânzare;

. 3.5.3 aplicare a reducerilor;

. 3.5.4 completare a fcaturilor;

. 3.5.5 editare şi trimitere a facturilor ce însoţesc produsele.

Schematic, procesele pot fi prezentate în următoarea structură ierarhică:

1 2 3Vânzare 4 ….

3.1

…

3.5 Facturare

…

3.5.2 Stabilirea preţului de vânzare

….

Tema:

Definiţi procese suplimentare pentru activitatea desfăşurată în organizaţie.

Detaliaţi câteva procese evidenţiate pe nivelele descrise.

Descrieţi activitatea desfăşurată astfel încât să evidenţiaţi într-o manieră

personală procesele cuprinse în descriere.

..A2.. se construiesc diagrame de activităţi pentru procesele analizate.

Pentru o mai bună înţelegere a structurii şi dinamicii organizaţiei se includ

obiecte. Plasând obiecte în diagrama de activităţi, putem vedea unde sunt create

şi manipulate obiectele în desfăşurarea procesului, unde se schimbă starea lor.

La acest nivel, obiectele sunt privite doar ca având o stare ce poate fi schimbată

prin acţiuni asupra obiectului.

Exemplu:

Diagrama de activităţi pentru procesul .3.2. - preluare comenzi este (fig. 1):

fig. 1

Temă:

Contruiţi diagrame de activităţi pentru alte procese

B Analiza, în sens larg, acoperă investigarea activităţii desfăşurate şi

definirea unui sistem informatic.

. începe dezvoltarea sistemului de la definirea proceselor, de la identificarea

cazurilor de utilizare care descriu aceste procese şi merge până la momentul în

care dezvoltatorii de sistem au un model comprehensiv al comportamentului

sistemului, pot prezenta utilizatorilor viitorul sistem, împreună cu tipurile de

informaţii memorate şi regăsite de el.

. se disting două faze: analiza cerinţelor şi analiza de sistem.

B1 Analiza cerinţelor, clasificate în cerinţe funcţionale, care evidenţiază ce

face sistemul şi cerinţe nefuncţionale, ce vizează performanţele sistemului (

fiabilitate, calitate a interfeţei).

. se centrează în jurul diagramei cazurilor de utilizare, cea care exprimă

interacţiunea cu mediul exterior;

. conduce la definirea comportamentul extern al sistemului şi la includerea

sistemul în contextul activităţii desfăşurate (business environment);

Schematic, intrările şi ieşirile acestei etape pot fi reprezentate ca în figura 2,

unde:

. diagrama cazurilor de utilizare prezintă actorii şi acţiunile declanşate de ei.

. descrierea unui caz de utilizare constă în prezentarea scenariilor. Se iau în

calcul următoarele recomandări :

. se clarifică toate problemele cu persoanele implicate (stakeholders);

. se identifică setul de scenarii ce acoperă toate alternativele şi excepţiile;

. pentru fiecare scenariu se construieşte o diagramă de secvenţe;

. în cazul scenariilor cu alternative şi excepţii se recomandă construirea

diagramelor de activităţi pentru evidenţierea detaliilor.

. prototipurile pentru interfaţa cu utilizatorul ajută la vizualizarea modului

în care sistemul lucrează.

Analiza cerinţelor

fig. 2

Participanţii la dezvoltarea viitorului sistem stabilesc în această etapă sarcini

pe grupuri de persoane implicate, iau decizii privind oportunitatea definirii unui

nou sistem informatic.

Exemplu:

Scop: Dezvoltarea unui sistem informatic pentru activităţile ce vizează

aprovizionarea cu componente, conform comenzilor primite de la clienţi pentru

asamblarea unor sisteme de calcul (produse finite).

Procese existente: . gestiunea comenzilor primite de la clienţi

. contractarea mărfurilor de la furnizor

. aprovizionarea cu marfă

. gestiunea mărfurilor aprovizionate

. achitarea furnizorilor

Participanţi: . utilizatori

. beneficiari

. analişti

Sarcini:

. documentarea viziunii proiectului

. construirea cazurile de utilizare

. descrierea cazurilor de utilizare

Participanţi Scop Procesele existente

Diagrama cazurilor de utilizare

Descrierea cazurilor de utilizare

Prototipuri pentru interfaţă

. definirea arhitecturii preliminare a sistemului

. analiza riscului

Decizii:

. ce îşi propune sistemul pentru fiecare din utilizatori?

. tehnic şi organizaţional este posibil?

. ce riscuri pot afecta fezabilitatea?

. beneficiile justifică costurile?

Diagrama cazurilor de utilizare pentru procesele ce vizează aprovizionarea

conform contractelor încheiate cu furnizorii este (fig. 3):

fig. 3

Descrierea cazurilor de utilizare.

Prezentăm în continuare câteva scenarii ce descriu cazuri de utilizare

reprezentative, cu eventuale alternative sau excepţii.

= scenariul 1 Denumire: Încheierea contractului pentru aprovizionarea cu componente

Descrierea derulării:

.. stabilirea necesarului de aprovizionat;

.. analiza ofertelor de la furnizori;

.. alegerea furnizorului;

.. stabilirea condiţiilor contactuale;

.. semnarea contractului de ambele părti.

= scenariul 2 Denumire: Gestiunea componentelor aprovizionate


.. se înregistrează factura cu care au sosit componentele;

.. gestionarul verifică componentele; în funcţie de calitatea şi cantitatea

existentă,

.. gestionarul înscrie componentele corespunzătoare pe NIR; pentru o

factură se completează un NIR/mai multe NIR-uri;

.. NIR-urile se păstrează în arhiva gestiunilor.

SAU

.. întocmeşte proces verbal pentru componentele necorespunzătoare

calitativ sau lipsă cantitativ;

.. furnizează informaţii pentru stornarea facturilor la compartimentul

aprovizionare.

= scenariul 3

Denumire: Gestionarea cererii de la aprovizionare/vânzare


.. gestionarul primeşte o comandă de la departamentul aprovizionare/vânzare;

.. gestionarul verifică cantitatea şi calitatea cerută;

.. gestionarul calculează preţul mediu pentru analiza ofertei în cazul

aprovizionării/preţul de vânzare pentru livrare;

.. în cazul vânzării, descarcă gestiunea după scoaterea din gestiune a mărfii.

= scenariul 4

Denumire: validarea unui client când acesta sună pentru o comandă


. clientul furnizează un număr de identificare pe care operatorul îl tastează în

fereastra de interfaţă;

. sistemul răspunde cu numele şi adresa clientului şi o parolă de acces;

. operatorul cere confirmarea pentru nume, adresă şi parolă şi închide fereastra

dacă răspunsurile date sunt conforme cu datele de pe ecran.

Alternative:

1. clientul nu are un număr de identificare pentru a fi gestionat; operatorul

trebuie să ceară clientului să aibă un număr de identificare înaintea intrării în

sistem.

2. sistemul nu poate găsi înregistrarea cu numărul de identificare dat al

clientului şi se afişează un mesaj de eroare. Operatorul cere un nou număr de

identificare şi reia operaţia de validare de la pasul 1.

3. clientul nu poate furniza numele, adresa sau parola; operatorul închide

aplicaţia. Sistemul trebuie să înregistreze încercarea nereuşită pentru a permite

cercetarea fraudei.

Excepţii:

. dacă sistemul nu e disponibil, operatorul preia numele şi numărul de telefon al

clientului şi-l sună imediat ce sistemul e disponibil.

= scenariul 5 Denumire: preluarea detaliilor unei comenzi pentru un client


. clientul furnizează codul produsului şi cantitatea; operatorul tastează aceste

informaţii pe ecran;

. clientul cere o dată anume pentru livrare, operatorul o tastează pe ecran.

Sistemul confirmă că aceata e acceptabilă/acceptată

. operatorul citeşte comanda şi comunicată data livrării clientului, care acceptă

. operatorul închide ecranul de interfaţă şi sistemul răspunde că această

comandă a fost acceptată. Operatorul mulţumeşte clientului şi întreabă dacă

există altă comandă

Alternative:

1. clientul nu are un cod al produsului, dar ştie numele produsului. Sistemul

poate permite acceptarea numelui şi regăseşte codul.

2. sistemul nu poate accepta data livrării şi oferă o dată apropiată pe care o

negociază cu clientul.

3. se constată nereguli în detaliile unei comenzi:

. clientul a făcut o greşeală în furnizarea datelor şi operatorul trebuie să facă

modificări în detalii;

. comanda excede limita de creditare a clientului sau cere un produs neinclus în

ofertă; după discuţii cu clientul se fac modificări.

4. se renunţă la comandă din diferite motive.

Observaţii:

. în situaţia în care preluarea comenzii se face prin telefon, este indicat să se

construiască o diagramă de activităţi care să ia în calcul şi alternativele

prezentate în scenariu (fig. 4).

. iesirile evidenţiate în diagramă reprezintă intrări în alte procese (procesul de

vânzare după transferul apelului)

fig.4

B2 Analiza de sistem, fază din care începem să vorbim de un proces de

“elaborare a cazurilor de utilizare”.

. exprimă comportamentul sistemului şi interacţiunea cu mediul afacerii în

termeni din domeniul computerelor, într-un limbaj al dezvoltatorilor.

. evidenţiază interacţiunile dintre obiecte pornind de la scenariile descrise

anterior; se defineşte o primă formă a structurii viitorului sistem.

. conduce la construirea unui model obiect, imagine a modului în care sistemul

se prezintă utilizatorilor, a tipurilor de informaţii memorate şi regăsite de

sistem.

Schematic, această etapă poate fi reprezentată ca în figura 5 , unde:

Diagrama cazurilor de utilizare construită în etapa de analiză a cerinţelor se

completează cu noile cazuri de utilizare rezultate din prezentarea scenariilor, în

special a excepţiilor şi a alternativelor.

Modelul obiect cuprinde: .. diagrama claselor, ce evidenţiază structura statică a sistemului;

.. diagramele de secvenţă, de colaborare şi de stare, ce evidenţiază dinamica

sistemului.

Analiza de sistem

fig.5

Pentru definirea diagramei claselor (numită şi modelul domeniului în această

etapă) ţinem cont că:

▪ o clasă este o abstracţie pentru :

.. persoane (clienţi, furnizori, studenţi …)

.. lucruri (catalog de produse, container, factură ..)

.. idei–concepte abstracte (specificaţii ale produselor, zborile aeriene,

conturi bancare)

▪ în diagrama claselor nu se definesc interacţiunile dintre clase ci doar căile de-

a lungul cărora acestea se formează.

▪ includerea unei clase în diagramă se poate face în 2 moduri:

1. clasele se aleg dintre substantivele prezente în textul ce descrie activitatea

desfăşurată. Problema este că nu toate substantivele sunt nume de

clasă(denumirea clientului este un atribut, facturare este descriere a unei de

activităţi)

2. se apelează la una din următoarele categorii de clase utilizate în activitatea

de modelare:

Categorie clasă Exemplu

Tranzacţii Vânzare, Plată

Cataloage Nomenclator de produse

Containere Container, Avion

Sisteme externe Sistem Credit-Card

Organizaţii Departament de vănzări

Locuri Depozit, magazin, avion

Rol jucat de persoane Student, client, angajat

Specificaţii/descrieri de obiecte Descrierea produsului

Obiecte tangibile Registru de vinzari, facturi

Obiecte în containere Stoc de produse, pasageri

Diagrama cazurilor de utilizare

Modelul obiect

Criterii pentru includerea claselor în diagrama claselor:

1. se defineşte o clasă doar dacă sistemul are nevoie să memoreze date despre

ea, pentru a răspunde unor cereri viitoare;

2. se defineşte o clasă corespunzătoare unui actor doar dacă sistemul are nevoie

să-şi amintească atributele actorului;

3. se exclud clasele care reprezintă ieşiri din sistem, dacă sistemul poate calcula

informaţiile când are nevoie de ele în viitor; răspunsurile sistemului la

evenimente (ieşirile din sistem) se pot defini ca atribute, atribute calculate,

mesaje.

Criterii pentru includerea atributelor în diagrama claselor

1. se defineşte un atribut doar dacă sistemul are nevoie de valoriile lui pentru a

răspunde unor cereri viitoare;

2. nu se folosesc atribute pentru a înregistra o conexiune între clase; se folosesc

asocieri;

3. un atribut se include într-o singură clasă;

4. nu se includ atribute calculate.

Teme:

Completaţi diagrama cazurilor de utilizare cu noi cazurile de utilizare.

Adăugaţi cazurilor de utilizare excepţiile şi alternativele rezultate din

prezentarea scenariilor.

Construiţi diagrama claselor pentru cazutile de utilizare descrise.

Pentru definirea diagramelor de secvenţă, de colaborare şi de stare, noţiunea

de obiect este esenţială în această etapă; obiectele sunt prezentate ca aparţinând

unui stereotip, văzut ca cel mai important dintre mecanismele de extensie.

Stereotipul permite ca elemente cu aceeaşi strucutră să poată primi semnificaţie

sau utilizare particulară.

Obiectele definite pentru descrierea unui caz de utilizare pot fi:

▪ obiecte de gestiune (entity) – stereotip << entity>>

= corespund obiectelor din sistemul real; reflectă concepte şi elemente ce

aparţin domeniului de activitate, afacerii reprezentate; sunt persistente în timp

şi sunt translatate în tabele ale bazelor de date relaţionale.

Exemple: facturi, mărfiri, clienţi.

▪ obiecte de control – stereotip << control>>

= organizează comportamentul complex al sistemului. Se definesc în situaţii

care implică mai multe obiecte de interfaţă sau obiecte de gestiune.

Exemple: un obiect ce compară conţinutul unei facturi de aprovizionare cu

datele din NIR, un obiect care identifică diferenţele rezultate din comparaţia

anterioară, un obiect care tratează situaţii posibile menţionate la excepţii.

▪ obiecte de interfaţă (boundary) – stereotip << boundary>>

= controlează interacţiunea cu mediul exterior (outside world). Rolul lor este

să translateze informaţiile furnizate de actori în evenimente interne la care

răspund obiecte de control sau obiecte de gestiune şi să prezinte răspunsul

acestor obiecte astfel încât să poată fi înţelese de actor.

Exemple: fereastră de ecran, formular, casetă de text, butoane, liste derulante.

▪ obiecte de implementare (factory)

= grupează elemente legate de structura internă a sistemului. Ele preiau

responsabilitatea pentru crearea obiectelor când sunt definite pentru prima dată

şi pentru transferul lor în/din baza de date pe timpul duratei lor de viaţă. Cel

mai des sunt utilizate ca obiecte legate de persistenţă, asigurând comunicarea

între obiecte şi baza de date.

Exemplu: Pentru a apela un obiect client dintr-o bază de date relaţională,

acesta este preluat via un obiect de control într-un obiect de implementare.

Atributul cod client este utilizat pentru a regăsi în baza de date o înregistrare cu

al cărui conţinut se populează atributele obiectului client. După ce obiectul a

fost creat în memorie, alte obiecte îl pot referii. Trebuie apoi returnat în baza de

date; obiectul de implementare poate fi chemat să transfere atributele

modificate în baza de date şi să distrugă obiectul de gestiune.

Exemple:

Prezentăm în continuare diagrame de secvenţă construite pentru câteva din

scenariile definite anterior.

▪ în diagrama de secvenţe pentru scenariul 4 (fig. 6) se include două obiecte:

un obiect de interfaţă utilizat pentru interacţiunea cu operatorul şi un obiect de

gestiune client.

1. prin intermediul obiectului de interfaţă operatorul tastează numărul clientului

şi-l trimite sistemului;

2. sistemul răspunde cu numele, adresa şi numărul clientului; aceasta implică

definirea unui obiect de gestiune (al clasei client) care să memoreze nume,

adresă, număr client.

fig. 6

Clasa Client poate fi reprezentată astfel:

3. dacă datele afişate pe ecran corespund cu cele furnizate de client, operatorul

confirmă clientul. Faptul că datele unui client trebuie validate impune definirea

unui obiect de control (Validare) care preia sarcinile confirmării:

Diagrama de secvenţe este cea din figura 7:

<<control>>

Validare

esteValidat()

fig. 7

In acest moment poate fi construită diagrama claselor din figura 8.

fig. 8

Teme:

.Construiţi diagrame de colaborare pentru clasele: interfaţă preluare

comandă, clienţi, comandă, control comandă, livrare.

.Completaţi diagrama claselor din figura 9, cu informaţii obţinute din

diagramele de colaborare.

. Construiţi diagrama de stare pentru clasa client.

. Construiţi diagrama de stare pentru produse livrate.

C Proiectarea se ocupă de cum va opera sistemul şi-l descompune în

componente ce pot fi dezvoltate individual, oferind totodată o vedere de

ansamblu asupra sistemului.

. proiectarea sistemului implică împărţirea sa în subsisteme, şi alocarea

resurselor hardware şi software.

. proiectarea obiectelor continuă strategia aleasă în etapa de proiectare a

sistemului şi rafinează detaliile.

Schematic, intrările şi ieşirile acestei etape pot fi reprezentate astfel:

Proiectare

Cazurile de utilizare interacţionează şi interferează unele cu altele, prin

intermediul unor obiecte de bază (comanda este folosită de cazul de utilizare ce

reflectă preluarea comenzii şi de de cazul de utilizare ce reflectă livrarea unei

comenzi).

Diagrama de secvenţe –

. evidenţiază noi interacţiuni între obiecte (pentru actori sau obiecte ale claselor

noi introduse după faza de analiză);

. poate evidenţia crearea unui nou obiect, distrugerea unui obiect sau apelarea

unui obiect printr-o operaţie proprie;

. verifică dacă obiectele definite în faza de analiză sunt viabile pentru

implementare sau trebuie restructurate; se adaugă informaţile schimbate;

. interacţiunile din diagramă (mesajele dintre obiecte) trebuie să se regăsească

printre operaţiile clasei obiectului destinatar.

Diagrama de colaborare –

.evidenţiază funcţionalităţile rezultate din interacţiunile cazurilor de utilizare;

. înlocuieşte mesajele specificate în faza de analiză cu operaţii adăugate

claselor de obiecte destinatar;

Diagrama de activităţi –

Specificaţii

pentru

interfaţă

Modelul componentelor

Descrierea cazurilor de utilizare

Modelul obiect

Model obiect

Modelul datelor

Vedere arhitectura

. detaliază interacţiunile dintre cazurile de utilizare;

. descrie algoritmi ai unor operaţii complexe.

Teme:

. Evidenţiaţi în diagrame cazuri de utilizare care interacţionează şi

interferează unele cu altele.

. Construiţi diagrame de colaborare pentru evidenţierea funcţionalităţilor

rezultate din interacţiunile cazurilor de utilizare.

. Construiţi diagrame de activităţi ce detaliază interacţiunile dintre cazurile

de utilizare (editarea unei facturi);

Diagrama claselor evidenţiază acum un set de obiecte legate unele de

altele şi organizate astfel încât permit implementarea scenariilor ce descriu

cazurile de utilizare; cuprinde detalii necesare implementării:

. atributelor le sunt adăugate gradele de vizibilitate, eventual valori implicite

sau valori iniţiale;

. pot exista alte obiecte ca atribute (stare,ClsMatAprov);

. operaţiile pot manipula atributele obiectelor din clasă, pot apela operaţii ale

altor obiecte sau pot manipula atribute ale altor obiecte, dacă acestea aparţin

interfeţei;

. interacţiunile dintre obiecte specificate în faza de analiză sunt reprezentate

acum prin operaţii; se specifică semnătura operaţiilor şi nu ce face operaţia;

. se fac precizări suplimentare privind asocierile dintre obiecte; ele sunt

implementate prin atribute memorate într-una ori în ambele clase care se

asociază, sau prin evidentierea legăturile dintre tabele în cazul bazelor de date

relaţionale .

Pornind de la aceste consideraţii, prezentăm în final (fig.9) o diagramă a

claselor construită pentru activitatea de contractare şi aprovizionare a

componentelor necesare asamblării prouselor comandate de clienţi.

fig.9

Teme:

. Construiţi diagrama claselor pentru activităţile ce vizează preluarea

comenzilor şi livrarea produselor.

. Construiţi diagrame ale claselor pentru procesele descrise în etapa de

analiză.

BIBLIOGRAFIE

Booch G., Rumbaugh J., Jacobson I. The Unified Language user Guide,

Addison-Wesley, 1999

Roper M. Software Testing, McGraw-Hill, 1994

Sommerville I. Software Engineering. Ed. Addison Wesley, 2001

K. Lunn. Software development with UML, Ed. Palgrave Macmillan, 2003.

Popa Gh, Udrica M. Baze de date ACCESS - culegere de probleme Ed. Cison,

Bucureşti 2006

Udrică M. Modelare orientată obiect, Ed. Cison, 2000

Zaharie D. Rosca I. Proiectare obiectuala a sistemelor informatice. Ed. Dual

Tech, Bucuresti, 2006

www.en.wikipedia.org

www.ece.cmu.edu/~koopman/des_s99/sw_testing/

www.rational.com

www.tessella.com/literature/Supplements/swdesign_UML.htm

http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/

http://www.rational.com/

http://www.tessella.com/literature/Supplements/swdesign_UML.htm

metode de dezvoltare software.pdf

Documents