Tehnicile orientate obiect constituie un nou mod de abordare a produselor informatice, bazat pe abstractii ce corespund lumii reale. Obiectele din domeniul aplicatiei formeaza cadrul de lucru pentru definirea unui model si ulterior conduc la implementare. In timp ce in faza de definire a modelelor sistemului real obiectele cu caracteristici comune sunt grupate in clase, in faza de implementare obiectele sunt definite ca instante ale claselor, partajand proprietati si metode.
Pana in faza finala dezvoltarea orientata obiect este un proces conceptual independent de limbajul de programare. Poate servi ca mediu pentru analiza si documentare, pentru definirea interfetei cu utilizatorul, sau pentru programare. Greutatea consta in identificarea si organizarea conceptelor din domeniul aplicatie. Reprezentarea finala intr-un limbaj de programare, (orientat obiect sau nu) si stabilirea detaliilor de structurare a datelor ocupa un loc secundar.
Metodele orientate obiect acopera intregul ciclul de viata impartit in trei etape: analiza, proiectare, implementare. In aceste etape se intalnesc, in planuri conceptuale diferite, elemente orientate obiect, notatii din domeniul aplicatiei si al computerelor. In faza de analiza se construieste un model pentru abstractizarea aspectelor esentiale din domeniul aplicatiei. Modelul nu cuprinde detalii de implementare. Pentru a descrie si optimiza implementarea, acestea sunt adaugate in etapa de proiectare.
analiza
In faza de analiza se construieste un model precis, concis si inteligibil al lumii reale, un model complet al aplicatiei. Analistul descrie ce trebuie sa faca sistemul si nu cum o face, urmareste definirea a ceea ce urmeaza sa realizeze, si nu a algoritmilor care vor fi folositi. Obiectele sunt concepte din domeniul aplicatiei, si nu din domeniul programarii. Atentia este indreptata asupra conceptelor care vor forma nucleul unei solutii ce utilizeaza tehnici orientate obiect.
Analiza este selectiva, neacordandu-se aceeasi importanta tuturor componentelor si insusirilor. Lumea reala se descompune in entitati distincte, se stabilesc legaturile dintre ele si functiile indeplinite. Sunt examinate cerintele, analizate implicatiile, retinute doar aspectele esentiale. Rezultatul este un model cu clase si asocieri, folosirea acestora facandu-se in partea de proiectare si implementare.
Putem distinge :
.Analiza cerintelor, faza ȋn care se face o analiza preliminara a comportamentului extern al sistemului si se include in contextual concret ȋn care va functiona; este ca un contract intre dezvoltatori si beneficiari. Exprima ce poate face sistemul, in termeni din domeniul aplicatiei.
Cerintele sunt clasificate in cerinte functionale, care evidentiaza ce face sistemul si cerinte nefunctionale, ce vieaza performantele sistemului ( fiabilitate, calitate a interfetei, etc)
.Analiza de sistem, faza ȋn care se defineste comportamentul sistemului si interactiunea cu celelalte subsisteme din organizatie. Exprima ce poate face sistemul in termeni din domeniul computerelor, intr-un limbaj al dezvoltatorilor.
proiectarea
Proiectarea se ocupa de cum va opera sistemul si-l descompune in componente ce pot fi dezvoltate individual, oferind totodata o vedere de ansamblu asupra sistemului.
Scopul principal al proiectarii orientate obiect este sa maximizeze posibilitatea reutilizarii claselor in proiecte ulterioare, sa identifice in relatiile de mostenire superclasele care faciliteaza reutilizarea in cadrul aceluiasi proiect.
Proiectarea se efectueaza in doua etape: proiectarea sistemului si proiectarea obiectelor.
Proiectarea sistemului implica impartirea sa in subsisteme, si alocarea resurselor hardware si software.
Proiectarea obiectelor continua strategia aleasa in etapa de proiectare a sistemului si rafineaza detaliile.
Se pastreaza structura claselor stabilita in partea de analiza, luand in considerare minimizarea timpului de executie si folosirea rationala a memoriei.
Operatiile identificate in etapa de analiza sunt exprimate algoritmic, cele complexe sunt descompuse in operatii interne simple. Atributele si asocierile sunt prezentate intr-o forma ce permite ulterior implementare ca structuri de date specifice.
Clasele sunt rearanjate prin evidentierea unor relatii de agregare sau de generalizare, sunt completate cu noi operatii si noi atribute, rezultate din abstractizarea comportamentului comun.
Modelul claselor poate fi rafinat prin introducerea de noi clase, care pastreaza rezultate intermediare de calcul.
Considerand clasele ca niste ,,cutii negre" a caror interfata externa este publica, dar ale caror detalii interne sunt ascunse, proiectantul decide atributele care sunt vizibile din exterior. Ascunderea informatiei interne permite ca implementarea unei clase sa fie modificata, fara a cere clientilor clasei sa-si modifice codul. Este necesara o noua documentare a claselor, pe baza celei din partea de analiza, care sa contina si modificarile care au aparut in faza de proiectare.
Intr-o ultima faza a proiectarii, clasele si asocierile se regrupeaza in module.
implementarea
Implementarea isi propune sa prezinte un set de componente integrate intr-o constructie, in concordanta cu specificatiile din etapa de proiectare.
In timp ce primele doua etape sunt independente de mediul de programare, in aceasta etapa trebuie aleasa solutia informatica pentru realizarea efectiva a sistemului. Clasele si relatiile sunt translatate intr-un limbaj de programare, de regula orientat obiect. In cele mai multe cazuri, scrierea secventelor de cod intr-un limbaj orientat obiect se face aproape automat, pe baza deciziilor luate in fazele anterioare.
Modelul obiect s-a dezvoltat pe baza principiilor preluate din programarea orientata obiect inca de la sfarsitul anilor '60. Implicarea unor date complexe (documente electronice, date in format multimedia), necesitatea definirii unor tipuri de date-utilizator si reutilizarea componentelor existente, sunt doar cateva din realitatile care au impus in proiectarea sistemelor informatice modelele obiect. Elementul central al modelului il constituie obiectul.
Un obiect este o abstractie, un concept, folosit pentru reprezentarea lumii reale si furnizarea unei baze practice pentru implementarea cu ajutorul tehnicii de calcul. Descompunerea sistemului real in obiecte depinde de modelator si de natura concreta a problemei.
Exemple:
persoana IONESCU, produsul CALCULATOR, factura AS-1234 din 12/03/04 sunt obiecte din lumea reala, ce se regasesc in sistemul informatic privind personalul angajat, gestiunii resurselor si respectiv vanzarii de produse.
Caracteristicile unui obiect sunt: identitate, stare, comportament
Modelul obiect poate fi definit ca o reprezentare directa a realitatii cu ajutorul unor componente elementare cu identitate proprie si caracterizate prin stare si comportament.
Identitatea unui obiect este acea proprietate a obiectului care il 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 si nu se confunda cu diferitele nume utilizate de programator pentru a-l numi.
Identitatea organizeaza obiectele intr-un spatiu manipulat de limbajele orientate obiect. Spatiul obiectelor se construieste pornind de la obiecte de baza. Ca entitati complexe, obiectele sunt constituite din alte obiecte si/sau din valori. Ele sunt create de utilizatori, prin derivare din tipuri de obiecte create anterior, sau printr-o operatie explicita de creare.
Starea este o abstractie a valorilor atributelor si a legaturilor unui obiect. Starea obiectului reprezinta multimea valorilor tuturor atributelor si legaturilor sale la un moment dat. Starea este adesea asociata cu valoarea unui obiect satisfacand anumite conditii.
Exemple:
▪ persoana IONESCU apartinand unui sistem informatic de evidenta a personalului poate fi in starea angajat cu carte de munca sau pensionar, in functie de valorile atributului varsta. Prin raportare la o firma, poate fi in starea angajat sau somer.
▪ factura AS-1234 din 12/03/04 poate fi in starea achitata sau neachitata, stare determinata de factori externi, reprezentati prin incasarea sau nu a contravalorii sale.
Comportamentul este determinat de ansamblul operatiilor pe care obiectul le poate executa. Exprima modul in care un obiect actioneaza si reactioneaza.
Exemple:
▪ pentru persoana IONESCU, operatia afiseaza permite calcularea si afisarea pe ecran valorii atributului vechime in munca. Prin operatia valoare, se pot calcula retinerile din salariu sau sporurile.
▪ pentru factura AS-1234 din 12/03/04, cu ajutorul operatiilor definite se pot afisa datele de identificare ale furnizorului sau se poate calcula valoarea totala in functie de articolele facturate si de cota tva.
Comportamentul este cel care altereaza starea unui obiect, determina schimbarea starii sale. Corespunzatoare comportamentului global al obiectului, multimea valorilor grupate intr-o stare, specifica raspunsul obiectului la evenimentul primit.
Pornind de la componentele elementare, modelul obiect al sistemului real se obtine folosind instrumente specifice tehnicilor orientate obiect. Acestea sunt: abstractizarea, incapsularea si ierarhizarea.
abstractizarea
Abstractizarea este o operatie a gandirii prin care se desprind si se retin caracteristicile si relatiile esentiale ale obiectului cercetat [DEX]. In cazul sistemelor reale complexe, prin abstractizare se poate ajunge la modele inteligibile, usor de studiat, ce permit simularea desfasurarii activitatii folosind tehnica de calcul electronica. Caracteristicile selectate difera in functie de scopul urmarit. Pot astfel exista mai multe abstractizari pentru acelasi sistem real.
In cazul tehnicilor orientate obiect, prin abstractizare se evidentiaza caracteristicile esentiale ale unui obiect, cele care-l disting de alte obiecte. Practic, problema se abstractizeaza prin gruparea obiectele in clase. Abstractizarea da putere modelarii si capacitate de generalizare de la cateva cazuri particulare la cazuri similare. Definitiile comune (numele atributelor) sunt memorate o singura data pentru clasa, in loc sa fie memorate pentru fiecare instanta. Operatiile pot fi scrise o singura data si toate obiectele beneficiaza de codul reutilizat.
clase si obiecte
O clasa de obiecte descrie o multime de obiecte cu aceleasi proprietati (atribute), acelasi comportament (operatii) si relatii similare fata de alte obiecte. Fiecare obiect se mai numeste instanta a clasei. In termeni implementationali, fiecare obiect contine un pointer la clasa din care provine, deci are acces la toate caracteristicile clasei sale.
Clasa serveste la definirea si manipularea multimii instantelor, similar relatiilor din bazele de date relationale, si aminteste notiunea de clasa de la modelele semantice, care descrie insa doar structura, nu si comportamentul instantelor.
Spre deosebire de bazele de date relationale, in cazul modelarii orientate obiect nu exista o teorie matematica ce asigura un set standard de operatori. Acestia sunt reprezentati de operatiile definite la nivelul claselor, si pot fi grupati in patru categorii: constructori, destructori, modificatori si selectori.
O clasa este definita prin:
. numele clasei
. atributele, expresie a valorilor diferitelor stari ale instantelor de clasa
. operatiile pentru manipularea instantelor de clase, numite metode. Specificarea metodei poarta numele de semnatura, iar codul care implementeaza operatiile constituie corpul metodei.
Notiunea de clasa este mai mult utilizata de faza de executie, presupunand doua aspecte: generarea de obiecte si stocarea setului de obiecte care reprezinta instantele claselor. Cu ajutorul clasei se descriu obiectele. Obiectul poseda propriile lui valori, lista atributelor si metodele fiind gestionate de clasa.
incapsularea
Fiecarei clase ii este asociata o multime de operatii prin care obiectele acesteia pot fi manipulate, care permite schimbul de mesaje intre obiecte si asigura functionalitatea modelului. Corespunzator, obiectul este divizat in doua: continut (structura si modul de actiune al operatiilor) si interfata (atributele si operatiile vizibile din exterior).
Incapsularea este un proces de grupare a elementelor unei clase in elemente accesibile din exterior si elemente proprii.
.permite separarea aspectului extern, accesibil altor obiecte, de implementarea interna.
. ofera posibilitatea de a masca atributele proprii ale unui obiect, precum si modul in care se executa operatiile. Implementarea poate fi astfel schimbata fara a afecta aplicatia.
. garanteaza integritatea datelor continute in obiect, datele incapsulate fiind protejate de accese nedorite.
. constituie una din premisele de baza ale reutilizarii. Un obiect poate evolua in timp fara a afecta restul sistemului.
Notatia UML permite reprezentarea nivelului de vizibilitate a datelor, definind trei drepturi de acces:
. public - functiile din toate clasele pot accede la aceste date sau metode
. protejat - accesul la date este rezervat functiilor din clase intre care exista o relatie de generalizare (functiile claselor si subclaselor)
. privat - accesul la date este limitat la metodele clasei.
Corespunzator, caracterul ce reprezinta vizibilitatea este:
+ defineste un atribut public
# defineste un atribut protejat
defineste un atribut privat
CLASA
+ atribut public
# atribut protejat
- atribut privat
ierarhizarea
Ierarhizarea este o operatie de ordonare a abstractiilor. Ajuta la identificarea relatiilor intr-o ierarhie, la clarificarea si buna intelegere a problemei.
Spre deosebire de abordarea conventional procedurala care defineste structuri ierarhice pentru date si pentru proceduri, combinarea datelor si a comportamentului intr-o singura entitate fac modelul mai expresiv si implementarea mai flexibila, dand nastere la o singura ierarhie:
Abordare conventional procedurala: Abordare orientata obiect:
structura ierarhica de date
ierarhie
de clase
structura ierarhica de proceduri
In modelarea sistemelor reale, cele mai importante tipuri de relatii prezente in ierarhia claselor sunt generalizarea si agregarea.
Agregarea este o relatie de tip parte-intreg, in care obiecte care reprezinta componente ale unui intreg, sunt asociate cu intregul.
Agregarea este o forma de asociere in care exista un obiect agregat, format din componentele sale, componentele fiind vazute ca parte a agregatului. O aceeasi parte poate apartine mai multor agregari. Semantic agregatul este vazut ca un obiect, tratat ca o unitate in multe operatii, desi fizic este format din mai multe obiecte.
Agregarea nu este un concept independent, ci o forma speciala de asociere.
generalizarea
Este o relatie dintre o clasa de baza si una sau mai multe clase derivate ale ei. Atributele si operatiile comune sunt grupate in superclasa, fiind mostenite de clase.
Observatii:
In timp ce in cazul agregarii una din clase are un rol predominant in raport cu celelalte, in cazul generalizarii clasele sunt integral coerente, subclasa aducand eventuale informatii aditionale, specifice.
Agregarea implica doua clase, una fiind parte a celeilalte. Generalizarea este un mijloc de structurare a descrierilor pentru o clasa. Superclasa si clasa specifica proprietatile unui obiect, obiectul fiind instanta a superclasei si instanta a clasei.
Amandoua dau nastere la arbori prin tranzitivitate. Un arbore al agregarii este compus din instante obiect, toate parte al unui obiect compus. Arborele generalizarii este compus din clase care descriu un obiect.
mostenirea
Partajarea atributelor si operatiilor de-a lungul unei ierarhii intre clase si subclase este evidentiata cu ajutorul conceptului de mostenire.
Mostenirea permite constituirea de noi tipuri de obiecte si clase, evitand rescrierea si recodificarea. Noua clasa poate mosteni atat operatii (metode), cat si variabile de instanta (atribute). In primul caz se poate vorbi de partajarea codului intre metode (code sharing), iar in al doilea caz, de partajarea structurii intre atribute (structure sharing).
Exemplu: in sistemul informatic privind contractarea si vanzarea produselor, documentele pe cere se consemneaza activitatile desfasurate sunt contractul si factura de vanzare. Prin generalizare se poate defini o clasa DOCUMENT, care are drept atribute NumarDocument si DataDocument. Operatiile sunt: CautaData(NrDoc) si StergeDocument(NrDoc). Clasele CONTRACT si FACTURA mostenesc atributele si operatiile clasei DOCUMENT. In plus, clasa CONTRACT are atributele TermenContract si ValoareContract, iar clasa FACTURA are in plus atributul StareFactura.
Mostenirea intre clase poate fi privita sub doua aspecte:
.. structural, cand o clasa are atribute mostenite de la superclasa
.. comportamental, cand o clasa are metode mostenite de la superclasa.
Mostenirea poate fi implementata static sau dinamic. Mostenirea statica presupune adaugarea campurilor mostenite. In timp ce executia este rapida neimplicand parcurgerea legaturilor de mostenire, redefinirea unei clase este dificila, implicand actualizarea tuturor subclaselor. Mostenirea dinamica se realizeaza fara copierea campurilor mostenite, si presupune parcurgerea legaturilor de mostenire. Actualizarea este mai usoara, dar executia este mai putin eficienta.
Observatii:
Generalizarea si mostenirea sunt abstractii puternice folosite pentru transmiterea similaritatilor de la o clasa la alta, pastrand totusi diferentele dintre acestea. Subclasele mostenesc trasaturile superclasei, dar pot avea propriile lor atribute si operatii.
In timp ce generalizarea se refera la relatia dintre aceeasi clasa si subclasele sale, mostenirea se refera la mecanismul de a transmite atribute si operatii de-a lungul unei relatii de generalizare. In implementare, mostenirea este sinonima cu notiunea de reutilizare a codului. Trasaturile reutilizabile sunt grupate in superclase.
polimorfism
In stransa legatura cu mostenirea, polimorfismul defineste caracteristica unei operatii de a se comporta in mod diferit in functie de clasa de obiecte careia ii apartine. Polimorfismul permite invocarea pentru obiecte de diferite tipuri a operatiilor cu acelasi nume (semnatura), dar semantica si implementare diferita. La primirea mesajului, stabilirea metodei care se aplica se face in mod dinamic, in functie de clasa obiectului in cauza. Instante ale unor clase diferite pot fi adresate uniform, primind aceleasi mesaje, dar manifesta comportamente diferite.
Unified Modeling Language (UML) este succesorul unui val de metode de analiza si proiectare orientate obiect, aparute la sfarsitul anilor 80 si inceputul anilor 90. Este un limbaj unificat de modelare, rezultatul unui proces de introducere a standardizarii in analiza si proiectarea orientate obiect. Este punctul de pornire in dezvoltarea viitoarelor limbaje grafice.
Contributii esentiale in definirea limbajului unificat de modelare au avut Grady Booch, Jim Rumbaugh si Ivar Jacobson.
Grady Booch, cercetator stiintific la Rational Software Corporation a construit numeroase exemple pentru dezvoltarea sistemului Ada. A definit o metoda de analiza si proiectare a sistemelor orientate obiect Object Oriented Design (OOD).
Jim Rumbaugh a condus o echipa de cercetare in laboratorul General Electric, punand bazele metodei Object Modeling Technique (OMT).
Ivar Jacobson, in urma experientei dobandite in domeniul telefoniei, a introdus pentru prima data diagramele de utilizare, in lucrarea "Object-Oriented Software Engineerig - A Use Case Driven Approach".
Metodele existente in acea perioada erau similare, dar conceptele de baza apareau cu mici diferente de notatii ce dadeau nastere la confuzii intre utilizatori.
La OOPSLA'95 Grady Booch si Jim Rumbaugh au prezentat public versiunea 0.8 a documentatiei pentru o metoda standard de modelare, Unified Method (UM). Metoda consta intr-un limbaj de modelare si un proces. Limbajul de modelare era (in special cel grafic) notatia folosita de metoda. Procesul exprima pasii facuti.
Studiul acestei metode i-au determinat sa considere ca partea de proces a metodei este nesemnificativa, ca nu e nevoie si de un proces standard, desi armonizari in vocabular sunt necesare. In acelasi timp, au considerat ca un limbaj de modelare standard este necesar si important. Si astfel, incepand cu 1966, cei doi impreuna cu Ivar Jacobson, au lucrat pentru un limbaj de modelare standard, Unified Modeling Language (UML).
La 17 noiembrie 1997, Object Management Group (OMG) a anuntat adoptarea specificatiei UML ca limbaj standard de modelare.
Ca limbaj de modelare standardizat, UML este deschis la extensibilitate pe scara larga, permite practicienilor cresterea eficientei, avand consistenta, standardizare si instrumente suportate de limbaj de modelare.
UML nu este o metoda, este o notatie grafica care acopera majoritatea tipurilor de diagrame necesare in timpul ciclului de viata al dezvoltarii software.
Punctele forte:
▪▪ este un cadru de analiza obiect, oferind:
.. diferite perspective complementare ale sistemului, care ghideaza utilizarea conceptelor obiect
.. numeroase nivele de abstractizare, care permit controlul complexitatii cu ajutorul solutiilor obiect
▪▪ este un suport de comunicatie
.. notatia grafica permite exprimarea vizuala a unei solutii obiect
.. aspectul formal al notatiei sale limiteaza ambiguitatile
.. aspectul vizual faciliteaza evaluarea si compararea solutiilor
▪▪ este un limbaj formal si normalizat care:
.. castiga precizie
.. castiga stabilitate
.. incurajeaza utilizarea instrumentelor CASE
▪▪ asigura independenta fata de limbajul de implementare si de domeniul aplicatiei
Puncte slabe:
▪ punerea in practica a limbajului UML necesita pregatire complexa de specialitate
▪ permite reprezentarea modelelor, dar nu defineste procesul de elaborare al modelelor. Este un demers iterativ si incremental, ghidat de cerintele/nevoile utilizatorilor de sistem
▪ nu descrie cum se dezvolta software-ul, dar se poate folosi cu orice proces.
Diagramele UML sunt mijloacele de reprezentare si vizualizare a elementelor de modelare. In acest subcapitol diagramele UML sunt construite cu OBJECTEERING, aflat pe Internet la adresa www.objecteering.com.
Cazurilor de utilizare descriu comportamentul unui sistem din punctul de vedere al utilizatorului. Ii permit sa-si structureze cerintele, sa defineasca modul in care va interactiona cu sistemul pentru a obtine rezultatul dorit. Precizeaza limitele sistemului, relatiile dintre sistem si mediu. Un caz de utilizare este initiat intotdeauna de un actor si exprima o functie a sistemului, declansata ca raspuns.
Functionalitatea completa a sistemului este data de totalitatea cazurilor de utilizare. Diagrama cazurilor de utilizare include actorii si cazurile de utilizare. Fiecare diagrama contine un set complet de evenimente initiate de unul sau mai multi actori si specifica interactiunea care are loc intre actori si sistem.
Ca abstractii ale dialogului intre actori si sistem, cazurile de utilizare descriu interactiuni potentiale fara a intra in detaliile fiecarui scenariu. Specifica doar cand se declanseaza evenimentele si ce actiuni determina, fara a cuprinde detalii functionale.
Actorii sunt elementele din sistem care genereaza sau primesc evenimente. Se determina dintre utilizatorii directi ai sistemului, dintre cei care-l interogheaza sau exploateaza. Alaturi de utilizatori, pot fi actori alte sisteme sau chiar un eveniment.
Reprezentare:
Actor participare caz de utilizare
Livrare marfa
Furnizor
Aceeasi persoana poate juca rolul mai multor actori, initiind mai multe cazuri de utilizare.
Exemplu:
gestionarul unui depozit receptioneaza marfa si o inregistreaza in fisa de magazie:
Receptioneaza
marfa
Gestionar
Inregistreaza
marfa
Un caz de utilizare poate avea mai multi actori, fiecare cu rolul sau
Exemplu:
la incheierea unui contract pentru livrarea marfurilor participa clientul si inginerul de vanzari.
Client Inginer de vanzari
Incheiere
contract
UML defineste trei tipuri de relatii intre actori si cazurile de utilizare:
.. Relatia de comunicare: actorul participa direct la cazul de utilizare;
Exemple:
clientul achita, functionarul comercial receptioneaza marfa
.. Relatia de incluziune: o instanta a cazului de utilizare sursa include si comportamentul descris de un alt caz de utilizare. Acest tip de relatie se foloseste pentru simplificarea diagramei cazurilor de utilizare in situatii complexe.
Exemple
in diagrama cazurilor de utilizare corespunzatoare aprovizionarii cu marfuri (fig 1),
cazul de utilizare - Incheie contract - include si cazul de utilizare
- Semneaza contract -
cazul de utilizare - Livrare marfa - include si cazul de utilizare
- Receptioneaza marfa -
cazul de utilizare - Intocmeste Nir- este inclus in cazul de utilizare
- Receptioneaza marfa -
cazul de utilizare -Incheiere contract- definit in sistemul informatic privind aprovizionarea cu marfuri include si cazul de utilizare
-Semnare contract- din acelasi sistem informatic.
.. Relatia de extensie: cazul de utilizare sursa poate fi extins cu comportamentul unui alt caz de utilizare destinatie. Prin relatia de extensie poate fi introdus, sub forma unui caz de utilizare distinct, un nou caz de utilizare.
Exemplu:
in diagrama cazurilor de utilizare corespunzatoare aprovizionarii cu marfuri (fig 1 ), cazul de utilizare - Receptioneaza marfa -poate fi extins cu cazul de utilizare - Returneaza marfa-
Descrierea unui caz de utilizare consta in unul sau mai multe "scenarii", numite instante ale cazului de utilizare, si include urmatoarele elemente:
. inceputul cazului de utilizare - evenimentul care declanseaza cazul de utilizare;
. sfarsitul cazului de utilizare - evenimentul care provoaca sfarsitul cazului de utilizare;
. interactiunea actorilor in cadrul cazului de utilizare;
. schimbul de informatii in timpul interactiunilor intre sistem si actori;
. cronologia si originea informatiilor, momentul inregistrarii lor in interiorul sau in exteriorul sistemului;
. repetarile de comportament, care pot fi descrise in secvente de cod prin structuri repetitive
. situatiile optionale, folosind o formulare de tipul: 'Actorul alege unul dintre evenimentele urmatoare, eventual de mai multe ori".
fig 1
Descrierile pot fi textuale. In aceasta situatie trebuie sa se verifice daca cerintele exprimate formal au fost alocate cazului de utilizare specificat. Fiind prezentate in limbajul utilizatorului, necontinand un vocabular orientat obiect, pot fi aplicate oricarui sistem dinamic, daca exista sau nu intentia de construire a unui sistem orientat obiect.
Descrierea cazurilor de utilizare trebuie sa cuprinda:
▪ denumire sau titlu
▪ scop
▪ actori
▪ punct initial
▪ punct final
▪ descriere derulare
▪ rezultat masurabil
Nu este posibil sa descriem un caz de utilizare scriind toate scenariile ; se descriu cele reprezentative si mai ales cele care comporta un risc.
In practica modelarii exista doua nivele de descriere :
descrierea generala a unui caz de utilizare evidentiind diferite drumuri ce pot fi reunite in acelasi caz
descrierea celor mai semnificative scenarii
Exemplu:
in cazul acordarii unui credit pentru o firma, descrierea cazului de utilizare -Analiza documentatiei depuse- este:
Denumire : Analiza documentatiei depuse
Scop : Calcularea coeficientului de risc
Actori: Inspectorul de credite
Punct initial: Inspectorul de credite solicita documentatia depusa de firma
Punct final: Obtinerea valorii coeficientului de risc
Descriere derulare
. inspectorul de credite solicita documentatia depusa de firma;
. daca firma este un client al bancii se verifica informatiile existente despre client; daca nu, baza de date este actualizata cu datele generale ale clientului;
. din documentatie se selecteaza informatia care contribuie la calcularea coeficientului de risc;
. in cazul unui coeficient de risc ridicat, cererea este respinsa;
. se analizeaza suma ceruta de firma prin comparatie cu posibilitatile bancii de a acorda creditul solicitat;
. daca rezultatul este favorabil (nivel de responsabilitate < 100.000.000) cererea de credit este admisa si inregistrata;
Rezultat masurabil: Cererea de credit este admisa si inregistrata, sau respinsa
Pentru acest caz de utilizare avem diagrama cazului de utilizare in figura 2
fig. 2
Clasa corespunde semantic entitatilor din sistemul real. O clasa desemneaza un grup de obiecte care au proprietati similare (atribute), un comportament comun (operatii), relatii comune cu alte obiecte si o aceeasi semantica.
Structura statica a sistemului, privita ca ansamblu al claselor de obiecte si al relatiilor dintre clase, este reprezentata cu ajutorul a doua tipuri de diagrame: diagrama claselor si diagrama obiectelor.
Diagrama claselor prezinta structura sistemului dintr-un punct de vedere general. In stransa legatura cu ea, diagrama obiectelor evidentiaza obiectele si legaturile dintre ele. Diagramele obiectelor prezinta cazuri particulare, faciliteaza intelegerea structurilor de date complexe.
UML permite definirea a trei tipuri de clase:
▪ clase "frontiera" (intefata) - servesc la modelarea interactiunilor intre sistem si actori.
▪ clase "de control" - servesc pentru a reprezenta coordonarea, secventializarea si controlul altor obiecte.
▪ clase "entitate" - servesc la modelarea informatiilor durabile si persistente
In aceasta categorie intra:
- obiectele specifice domeniului (contract, comanda ..)
- concepte din domeniul studiat ce influenteaza functionalitatea sistemului (lasa urma?)
- evenimente produse sau potential produse, care declanseaza un anume comportament al obiectelor
Reprezentarea unei clase presupune specificarea atributelor ce-i definesc structura, a operatiilor ce-i definesc comportamentul si a relatiilor cu celelalte clase.
In UML, o clasa este reprezentata printr-un dreptunghi in care se specifica numele clasei, atributele si operatiile.
Nume clasa Furnizori
Atribute cod
nume
Operatii CitesteCod
ScrieNume
Desemnarea obiectelor se face prin nume individuale sau prin nume generice in locul numelor individuale; numele obiectului este subliniat.
401_furnizor : Furnizori
Fiecare atribut poate lua o valoare dintr-un domeniu de definitie specificat in reprezentarea clasei. Implicit, atributele sunt incapsulate in obiecte, interactiunile avand loc numai prin intermediul operatiilor. Nivelul de vizibilitate al fiecarui atribut (privat, protejat si public) se precizeaza in reprezentarile grafice ale claselor cu ajutorul caracterelor -, #, respectiv +.
Operatiile sunt reprezentate impreuna cu numarul, ordinea si tipul argumentelor necesare definirii actiunii lor. In cazul cand operatia este o functie, se specifica si tipul valorii returnate.
Asocierea este o conexiune semantica bidirectionala intre clase. Ea este reprezentata printr-o linie continua intre clasele implicate, de-a lungul careia se scrie numele asocierii. Daca sensul de transmitere a mesajelor este unic, acesta se evidentiaza printr-o sageata de la emitator la receptor.
Dintre proprietatile unei asocieri, multiplicitatea este cel mai des intalnita in diagramele de structura. Este determinata de context si evidentiaza numarul instantelor unei clase ce se pot asocia cu o singura instanta a altei clase. Multiplicitatea restrange numarul de obiecte ce se afla in legatura, de aceea, cand mai multe instante ale unei clase sunt legate la o instanta a clasei asociate se foloseste cazul general (n). In aplicatii cea mai importanta distinctie se face intre multiplicitatea "zero" si multiplicitatea "mai multi".
In diagrama claselor, multiplicitatea se specifica printr-o cifra urmata eventual de semnul "+", printr-un interval sau printr-o succesiune de cifre. Astfel,
inseamna ca o instanta a unei clasei este legata la o singura instanta a clasei asociate;
inseamna ca una sau mai multe instante ale unei clase sunt legate cu o instanta a clasei asociate;
inseamna ca doua pana la cinci instante ale unei clase sunt legate cu o instanta a clasei asociate;
inseamna ca una, doua sau trei instante ale unei clase sunt legate cu o instanta a clasei asociate.
Asocierile pot fi caracterizate prin atribute si pot avea propriile lor operatii. In acest caz se reprezinta ca o clasa, ce are acelasi nume cu asocierea si se conecteaza printr-o linie intrerupta de asociere.
Exemplu:
in cazul in care intr-o societate comerciala se contracteaza produse, pretul unitar si cantitatea depind de produs dar si de conditiile specificate la incheierea contractului, sunt deci atribute ale asocierii. Reprezentarea clasei asociere este:
contracteaza
Produse Contracte
contracteaza
cantitate
pret unitar
Exemplu:
Figura 3 prezinta diagrama claselor in cazul sistemului informatic privind aprovizionarea cu marfuri
fig 3
Agregarea si generalizarea, ca forme de asociere prezente in procesul de ierarhizare a claselor, sunt reprezentate in diagramele de structura cu simboluri specifice.
Agregarea, ca relatie de tip "parte-intreg", evidentiaza o asociere intre o clasa cu rol predominant (clasa agregat) si componentele sale (agregate). Relatia de agregare este o relatie intre clasa intregului si clasa unei componente. Unui intreg cu mai multe componente ii corespund mai multe relatii de agregare. Definind apartenenta componentei la intreg se poate specifica si multiplicitatea fiecarei componente fata de intreg. Acest mod de a defini agregarea ii confera statutul de forma speciala a asocierii.
Agregarea este reprezentata printr-un romb plasat la capatul de asociere al clasei agregat.
Exemplu - in figura 4 apar urmatoarele detalieri:
▪ intre clasa CContract si clasa MarfaContract este o relatie de agregare
▪ intre clasa CFactura si clasa MarfaFactura este o relatie de agregare
Generalizarea, ca relatie intre o clasa si subclasele sale, este prezenta ori de cate ori se semnaleaza de-a lungul unei ierarhii proprietati comune sau operatii ce evidentiaza comportament comun. Este reprezentata printr-un triunghi ce puncteaza spre superclasa.
Exemplu - se considera clasele:
Factura, cu:
atribute: numar factura, data facturii, cota Tva
operatii: IncarcaDate, AfiseazaData, ValoareFactura
Contract, cu :
atribute: NumarContract, DataContract
operatii: IncarcaDate, AfiseazaData, AfisezTermen
Se observa ca aceste doua clase au atribute si metode comune. Se poate astfel construi o superclasa, Documente, care sa contina atributele si metodele comune, mostenite de subclasele Factura si Contract. (fig. 4)
fig 4
Pentru a defini metode ce trebuie sa fie mostenite de catre subclase UML permite definirea claselor abstracte.
O clasa abstracta este o clasa care nu este instantiabila dar ale carei clase descendente pot avea instante. Clasele abstracte pot fi particularizate prin specializare si extindere in clase concrete. O clasa este desemnata ca abstracta prin adaugarea proprietatii 'Abstract' pentru fiecare element generalizabil al clasei.
Diagrama de colaborare prezinta un grup de obiecte si interactiunile dintre ele. Mesajele schimbate intre obiecte sunt reprezentate de-a lungul legaturilor. Ordinea de trimitere a diferitelor mesaje este indicata printr-un numar amplasat la inceputul mesajului.
Numele mesajului corespunde unei operatii definite in clasa obiectului destinatar al mesajului, argumentele sale corespunzand parametrilor actuali ai operatiei. Argumentele mesajelor sunt reprezentate in diagrame fie in pseudocod fie in sintaxa limbajului de programare.
De exemplu (fig.5), diagrama de colaborare definita pentru a evidentia aprovizionarea cu materiale si pastrarea lor in gestiune este:
Furnizor
1:se primeste factura
Materiale 3:
transfer(BPTR)
2: depozitare (NRCD)
Gestiune
fig 5
Pentru a evidentia declansarea interactiunilor de catre un element extern sistemului, in diagramele de colaborare pot fi cuprinsi actori. Fara a se intra in detaliile obiectelor de interfata cu utilizatorul, in acest caz primul mesaj de interactiune este trimis de actor.
In faza de analiza, diagramele de colaborare urmaresc scenarii definite pornind de la cazurile de utilizare. De cele mai multe ori completeaza modelul de analiza, adaugand noi clase: de frontiera (pentru interactiunile dintre sistem si actori) si de control.
Impreuna cu diagramele de secvente alcatuiesc asa zisele diagrame de interactiune, ce evidentiaza mesajele trimise intre obiecte. In timp ce o diagrama de secvente se construieste pentru un singur scenariu in care pot fi implicate mai multe obiecte, diagramele de colaborare contin un grup restrans de obiecte, ce pot fi implicate in mai multe scenarii.
Exemplu:
in sistemul informatic privind vanzarea produselor, se poate defini o diagrama de colaborare intre obiectele claselor Clienti, Facturi si DocumenteIncasare, pentru a reprezenta modul in care au fost incasate facturile emise pentru clienti (fig.6 )
fig 6
In faza de proiectare, diagrama de colaborare furnizeaza un punct de vedere complet al dinamicii sistemului, evidentiind comportamentul claselor ca raspuns la aparitia unor evenimente, noi operatii si clasele carora le apartin.
Colaborarile definite pentru a urmarii anumite cerinte ale utilizatorilor pot conduce la aparitia sau disparitia unor obiecte, la modificarea proprietatilor unui obiect, la actualizarea restrictiilor de integritate sau la modificarea relatiilor dintre obiecte. In cazul in care obiecte apartinand aceleiasi clase participa la colaborari diferite, in functiile de scenarii diferite ale aceluiasi caz de utilizare, se pot specifica impreuna cu mesajele conditii ce aduc detalii suplimentare pentru implementare.
Diagrama de secvente ilustreaza interactiunile dintre obiecte din punct de vedere temporal. Este intocmita pentru scenarii ale unui caz de utilizare, arata obiectele si interactiunile dintre ele de-a lungul unui scenariu.
Mesajele corespund operatiilor prin care obiectele comunica. Reprezinta apeluri ale operatiilor descrise la nivelul claselor. Pentru fiecare mesaj, in clasa obiectului destinatar trebuie sa existe o operatie corespunzatoare, reactia obiectului la mesajul primit.
Fiecare obiect este reprezentat printr-un dreptunghi in care se inscrie numele. Linia de viata a obiectului se specifica printr-o bara verticala.
Mesajele sunt reprezentate prin sageti orizontale de la emitator la receptor. Convenind ca timpul se scurge de sus in jos, ordinea de trimitere este data de pozitia pe axa verticala.
Exemplu:
in sistemul informatic privind aprovizionarea cu marfuri, succesiunea operatiilor de la formularea unei cereri de marfa si pana la livrarea efectiva a marfii poate fi prezentata in diagrama de secvente din figura 7.
fig 7
Diagrama schimbarilor de stare descrie comportamentul obiectelor unei clase prin stari si evenimente. Se construieste doar pentru clasele cu comportament interesant dinamic, completand descrierea unui caz de utilizare.
Diagramele de stari modeleaza ciclul de viata al unei singure clase, evidentiind si eventualele evenimente trimise de ea la alta clasa din sistem.
Fiecare obiect este la un moment dat intr-o stare particulara. Starea este definita de valorile atributelor si de legaturile sale cu alte obiecte Este un raspuns la aparitia unui eveniment extern.
Exemplu:
in sistemul informatic privind gestiunea stocurilor, starea curenta a unui tip de material poate fi: in aprovizionare, depozitat in gestiune, sau in consum la sectie. Este determinata de valoarea atributului document, ce contine numele documentului pe care materialul este consemnat la un moment dat.
Daca documentul este "Nir", clasa Material este asociata cu clasa Gestiune prin asocierea Depozitat in:
Gestiune <Depozitat in Material
1..* document
In diagrama de stare sunt descrise operatiile ce reprezinta raspuns la evenimente externe clasei. Corespund unor operatii descrise in diagrama claselor, vizibile din afara clasei (publice).
Starea este descrisa printr-un nume care o identifica si o lista de actiuni/activitati ce sunt executate la aparitia unui eveniment. Intr-o diagrama de stare exista o singura stare initiala si una sau mai multe stari finale, determinate de conditiile de aparitie ale evenimentelor.
Tranzitia de stare reprezinta schimbarea starii datorita unui eveniment. Evenimentul corespunde aparitiei unei situatii date in domeniul problemei. El nu are durata. Trecerea dintr-o stare in alta este instantanee, sistemul fiind intotdeauna intr-o stare cunoscuta.
Tranzitia de stare este reprezentata printr-o sageata de la starea sursa la starea destinatie etichetata cu:
▪ numele evenimentului care a generat tranzitia
▪ conditia de aparitie a evenimentului
▪
actiunea ce se executa la aparitia evenimentului
Exemplu: in sistemul informatic privind aprovizionarea, diagrama de stari pentru o factura este cea din figura 8:
acceptare
Sosita Inregistrata
Do: ConsultaFz livrare Do: IncarcaDateFz
: VerificaFz : IncarcaDateFact
[sume OP<ValFact]
In curs de achitare
achitare partiala Do: CalcValFact
:AfisezAchitat
: SumePartiale
[sume OP=ValFact]
Achitata
Do: ListaSume
: AfiseazaData
: SeteazaStare
fig 8
Diagrama de activitati descrie comportamentul sistemului introducand elemente de implementare. Atasata unui caz de utilizare, ii detaliaza actiunile si procesele corespunzatoare. Atasata unei clase cu comportament dinamic semnificativ, descrie tranzitia de la o stare la alta sau algoritmul de prelucrare al operatiilor.
Foloseste urmatoarele elemente: actiune, tranzitie, decizie.
Actiunea corespunde unei etape in executia unui algoritm. Fiecare operatie, privita ca o inlantuire de actiuni, poate fi detaliata in operatii elementare. Pentru simplificarea diagramelor, actiuni omogene pot fi grupate in subactivitati.
Tranzitia de la o actiune la alta se reprezinta printr-o sageata etichetata eventual cu:
▪ numele evenimentului care determina tranzitia
▪ conditia de aparitie a evenimentului
Decizia indica ramificarea unei tranzitii in functie de indeplinirea unei conditii.
In faza de analiza, diagramele de activitati completeaza descrierea cazurilor de utilizare. Pentru prezentarea derularii actiunilor sunt folositi termeni apropiati utilizatorului.
Exemplu: ▪ diagrama de activitati din figura 9 evidentiaza activitatile desfasurate pentru aprovizionarea cu marfa si inregistrarea ei in gestiune. Poate folosi pentru completarea descrierii cazurilor de utilizare din sistemul informatic privind aprovizionarea, sau poate insoti diagrama de secvente din cadrul aceluiasi sistem informatic.
se inreg. factura
se verifica marfa
?
se inreg. marfa in Nir se refuza marfa
se intocmeste OP se storneaza factura
fig 9
▪ diagrama de activitati din figura 10 evidentiaza activitatile desfasurate in analiza ofertei unui furnizor cu care se doreste incheierea unui contract. Poate folosi pentru completarea descrierii cazului de utilizare - Incheiere contract - legat de actorul Furnizor.
Analiza oferta
Alegere furnizor
?
Incarca furnizor nou Actualizeaza furnizor
Intocmeste contract
fig 10
In faza de proiectare, diagramele de activitati apar atasate unei clase si contin elemente de implementare ale operatiilor descrise in clase. Actiunile pot fi descrise in limbaj natural, in pseudocod sau intr-un limbaj de programare (C++, Visual Basic). Echivalente schemelor logice utilizate in programarea structurata, diagramele de activitati contin structurile fundamentale de programare: liniara, repetitiva sau alternativa.
In cazul unei clase cu comportament dinamic semnificativ, pentru cazul in care modificarile de stare au o determinare interna, rezultata din efectuarea sau incheierea unor operatii, starea este descrisa printr-o lista de actiuni/activitati, ce se executa la aparitia unui eveniment. Tranzitia de la o stare la alta este determinata de incheierea acestor actiuni sau subactivitati (tranzitii interne). In aceste cazuri, diagramele de activitati insotesc diagramele de stare.
O societate comerciala fabrica componente pentru calculatoare. Una din cele 4 sectii monteaza calculatoarele.
.Compartimentul vanzari primeste zilnic comenzile clientilor. Comenzile cu regim de prioritate pot fi onorate cu o crestere a pretului de vanzare cu 10%. .Clientii care au mai mult de 10 comenzi sunt tratati automat cu prioritate.
.Pentru onorarea comenzilor, sectia de montaj se aprovizeoneaza cu:
. componente fabricate in alte sectii ale societatii;
. componente de la terte societati.
.Comanda finala este transmisa sectiei de montaj, care o finalizeaza dupa receptia componentelor aprovizionate.
.Numarul comenzii finalizate este transmis compartimentului de vanzari. Compartimentul vanzari se ocupa si de facturare.
.Modificari intr-o comanda pot veni si dupa inregistrarea comenzii. Ele pot viza:
.. codul articolelor, (in cazul unor imbunatatiri tehnice survenite in timp)
.. alte caracteristici: intarzieri, cantitatea comandata, etc.
Diagrama cazurilor de utilizare este:
Diagrama claselor este:
Descrierea scenariului "Tratarea unei comenzi printr-o diagrama de secvente este:
Tema:
Propuneti scenarii pentru cazurile de utilizare definite mai sus.
Construiti alte diagrame UML pentru scenariile propuse de dvs.
|
Politica de confidentialitate |
 .com |
Copyright ©
2024 - Toate drepturile rezervate. Toate documentele au caracter informativ cu scop educational. |
Personaje din literatura |
| Baltagul – caracterizarea personajelor |
| Caracterizare Alexandru Lapusneanul |
| Caracterizarea lui Gavilescu |
| Caracterizarea personajelor negative din basmul |
Tehnica si mecanica |
| Cuplaje - definitii. notatii. exemple. repere istorice. |
| Actionare macara |
| Reprezentarea si cotarea filetelor |
Geografie |
| Turismul pe terra |
| Vulcanii Și mediul |
| Padurile pe terra si industrializarea lemnului |
| Termeni si conditii |
| Contact |
| Creeaza si tu |
