Transcript
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.
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
Descrierea derulării:
.. 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
Descrierea derulării:
.. 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ă
Descrierea derulării:
. 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
Descrierea derulării:
. 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
top related