Metodologii Orientate PE Obiecte Utilizate In Proiectarea Sistemelor Informatice
METODOLOGII ORIENTATE PE OBIECTE
UTILIZATE ÎN PROIECTAREA SISTEMELOR INFORMATICE
Cuprins
Prefață
Capitolul 1. Concepte de bază în proiectarea orientată obiect a sistemelor informatice
1.1. Sistemul informațional și sistemul informatic
1.2. Ciclul de viață al sistemelor informatice
1.3. Concepte de bază în abordarea obiectuală
1.3.1. Obiectul
1.3.2. Clasele
1.3.3. Metode și mesaje
1.3.4. Încapsularea
1.3.5. Abstractizarea
1.3.6. Moștenirea
1.3.7. Polimorfismul
1.3.8. Persistența
1.3.9. Relații între obiecte și clase
Capitolul 2. Metodologii de proiectare orientate obiect
2.1. Metodologia OMT (Object Modeling Technique)
2.1.1. Formalismul OMT
2.1.1.1. Modelul static
2.1.1.2. Modelul dinamic
2.1.1.3. Modelul funcțional
2.1.2. Dezvoltarea sistemelor informatice conform metodologiei OMT
2.1.2.1. Analiza
2.1.2.2. Proiectarea sistemului
2.1.2.3. Proiectarea obiectelor
2.1.2.4. Implementarea
2.2. Metodologia Booch
2.2.1. Formalismul Booch
2.2.1.1. Modelarea statică a nivelului logic
2.2.1.2. Modelarea dinamică a nivelului logic
2.2.1.3. Nivelul fizic
2.2.2. Dezvoltarea sistemelor informatice conform metodologiei Booch
2.3. Metodologia OOSE (Object-Oriented Software Engineering)
2.3.1. Formalismul OOSE
2.3.1.1. Modelul cerințelor
2.3.1.2. Modelul de analiză
2.3.1.3. Modelul de proiectare și de implementare
2.3.2. Dezvoltarea sistemelor informatice conform metodologiei OOSE
2.4. Concluzii
Capitolul 3. Limbajul Unificat de Modelare (UML)
3.1. Arhitectura UML
3.2. Modelarea cazurilor de utilizare
3.3. Modelarea statică
3.3.1. Diagrama claselor
3.3.1.1. Clasa
3.3.1.2. Atributul
3.3.1.3. Operația
3.3.1.4. Relații între clase
3.3.1.5. Interfețe
3.3.1.6. Relații derivate
3.3.1.7. Restricții de integritate
3.3.2. Diagrama de obiecte
3.3.3. Diagrama de compoziție a structurii
3.4. Modelarea dinamică
3.4.1. Diagrame de interacțiuni
3.4.1.1. Diagrama de secvențe
3.4.1.2. Diagrama de comunicare
3.4.1.3. Diagrama de ansamblu al interacțiunilor
3.4.1.4. Diagrama de sincronizare (Timing Diagram)
3.4.2. Diagrama de stare
3.4.3. Diagrama de activități
3.5. Gestionarea modelelor
3.5.1. Structurarea în pachete
3.5.2. Structurarea în subsisteme
3.5.3. Structurarea în modele
3.6. Diagrame de implementare
3.6.1. Diagrama de componente
3.6.2. Diagrama de amplasare (Deployment diagram)
3.7. Realizarea persistenței
Capitolul 4. Modelarea afacerilor (BPMN)
4.1. Cadrul general
4.2. Diagrama proceselor de afaceri (BPD)
Capitolul 5. Modelarea arhitecturii sistemelor informatice
5.1. Cadrul general
5.2. Modele de arhitectură logică
5.3. Modele de proiectare propuse pentru Repository
Capitolul 6. Implementarea diagramei claselor
6.1. Implementarea diagramei claselor în modelul relațional
6.1.1. Clasele
6.1.2. Atributele
6.1.3. Operațiile
6.1.4. Relațiile dintre clase
6.2. Implementarea diagramei claselor în limbaje de programare orientate spre obiecte
6.2.1. Clasele
6.2.2. Atributele
6.2.3. Operațiile
6.2.4. Relațiile dintre clase
Capitolul 7. Rational Unified Process (RUP)
7.1. Cadrul general
7.2. Fazele RUP
7.3. Activitățile RUP
Capitolul 8. Studiu de caz – proiectarea unui sistem informatic privind acordarea creditelor pentru persoane fizice
8.1. Modelarea proceselor de afaceri
8.2. Definirea cerințelor
8.3. Analiza/proiectarea
8.4. Implementarea
Bibliografie
Prefață
Proiectarea orientată pe obiecte s-a impus datorită evoluției continue a metodologiilor destinate modelării și conceperii sistemelor informatice complexe. Un rol deosebit de important, în acest demers, l-au avut apariția, standardizarea și permanenta dezvoltare a limbajului UML, considerat de majoritatea specialiștilor nu numai un standard de-facto, ci și o variantă optimă pentru abordarea proiectării aplicațiilor informatice prin intermediul tehnicii orientate pe obiecte.
În cele opt capitole ale lucrării sunt tratate conceptele paradigmei obiectuale, metodologiile OMT (Object Modeling Technique), Booch, OOSE (Object-Oriented Software Engineering), Limbajul Unificat de Modelare (UML), modelarea proceselor de afaceri (BPMN), precum și Procesul Unificat de Dezvoltare (RUP). Tehnicile și conceptele prezentate și exemplificate, pe parcusul capitolelor, asigură cadrul necesar analizei și proiectării sistemelor informatice din orice domeniu de activitate. De asemenea, sunt oferite și soluții concrete de implementare ale elementelor de modelare atât în limbajul de programare VisualBasic.NET, cât și în modelul relațional, ca suport al persistenței obiectelor.
Lucrarea se adresează mai ales specialiștilor în proiectarea și implementarea sistemelor informatice, dar și studenților de la facultățile de profil sau tuturor celor interesați de acest domeniu.
Autorul
Concepte de bază în proiectarea orientată obiect a sistemelor informatice
Deși a fost aplicată pentru început în domeniul programării, tehnica orientată obiect s-a impus cu succes și în domeniul proiectării sistemelor informatice atât datorită avantajelor pe care le prezintă, cât și datorită încurajărilor pe care le-a primit prin apariția bazelor de date orientate obiect. În plus, paradigma obiectuală este susținută și de implementarea limbajelor orientate obiect în unele SGBD-uri relaționale, precum și de apariția limbajului unificat de modelare (UML), singurul formalism standardizat în domeniul proiectării sistemelor informatice.
Sistemul informațional și sistemul informatic
Sistemul este un ansamblu de componente între care se stabilesc pe baza unor reguli prestabilite anumite legături dinamice în vederea realizării unor obiective specifice. În decursul timpului s-au dat mai multe definiții sistemelor. După [Oprea99], acestea sunt urmatoarele:
Ludwig von Bertalanffy a definit sistemul „ca un ansamblu de elemente aflate în interacțiune”;
W.R. Ashby a considerat sistemul „ca o parte a unui întreg”;
Alți autori au definit sistemul ca pe „o mulțime de obiecte între care există anumite relații de cauzalitate sau ca o mulțime ordonată de elemente”.
Sistemul informațional reprezintă un ansamblu de concepte, reguli, tehnici de culegere, stocare, prelucrare și transmitere a datelor în vederea obținerii de informații necesare procesului decizional.
Informațiile furnizate de către sistemul informațional trebuie să se caracterizeze prin acuratețe și realitate, concizie, relevanță, cost corespunzător în raport cu valoarea acestora etc [Stanciu01].
Sistemul informatic permite ca operațiile specifice sistemului informațional să fie executate în întregime sau parțial cu ajutorul calculatorului electronic.
Sistemul informatic reprezintă un ansamblu de concepte, reguli, tehnici de culegere, stocare, prelucrare și transmitere automată a datelor în vederea obținerii de informații.
Conform [Stanciu01], sistemul informatic cuprinde următoarele elemente:
ansamblul informațiilor interne și externe, formale sau informale utilizate in cadrul firmei, precum și datele care au stat la baza obținerii lor;
procedurile și tehnicile de obținere și de difuzare a informațiilor;
platforma hardware necesară prelucrării datelor.
Nucleul unui sistem informatic, concretizat în pachetul de programe, desemnează noțiunea de produs program sau produs software [Zaharie02]. În ultima perioadă există tendința de a substitui noțiunea de produs program cu cea de sistem informatic.
Din punct de vedere structural, un sistem informatic este format din trei componente majore:
intrări – sunt reprezentate de ansamblul datelor încărcate în sistem în vederea stocării și prelucrării;
prelucrări – reprezintă ansamblul de proceduri automate (proceduri, funcții, interogări) care să asigure prelucrarea datelor de intrare;
ieșiri – sunt rezultatele prelucrărilor efectuate de către procedurile automate ale sistemului. Ieșirile sunt concretizate în indicatori sintetici, rapoarte sau liste, grafice etc.
Figura 1.1 Structura unui sistem informatic
Ciclul de viață al sistemelor informatice
Ciclul de viață al unui sistem informatic reprezintă ansamblul etapelor ce urmează a fi parcurse de către un sistem informatic și definește perioada cuprinsă din momentul conceperii și până în momentul înlocuirii sistemului informatic. În elaborarea unui sistem informatic, pe lângă decizia de realizare, se disting două etape fundamentale (Figura 1.2) [Zaharie02]:
Dezvoltarea reprezintă perioada de timp necesară elaborării sistemului informatic
Exploatarea reprezintă perioada de timp în care sistemul informatic este utilizat efectiv. Exploatarea reprezintă cea mai lunga etapă a ciclului de viață a unui sistem informatic.
Figura 1.2 Structura ciclului de viață al sistemului informatic
Un sistem informatic poate fi achiziționat de la o societate comercială specializată în dezvoltarea de software sau poate fi realizat în cadrul compartimentului IT al firmei. În ambele variante, etapa de dezvoltare a sistemului informatic presupune mai multe faze:
Definirea cerințelor utilizator presupune definirea, de către utilizator, a obiectivelor pe care trebuie să le îndeplinească noul sistem informatic;
Analiza constă în culegerea de informații referitoare la funcționarea sistemului informațional existent, în vederea cunoașterii cât mai detaliate a cerințelor la care trebuie să răspundă noul sistem;
Proiectarea presupune elaborarea unui set de specificații și modele detaliate referitoare la programe, structuri de date, persoane și mod de lucru etc;
Implementarea constă în realizarea structurilor de date și a procedurilor automate într-un anumit sistem de gestiune a bazelor de date (s.g.b.d) sau/și limbaj de programare;
Testarea este ultima fază a etapei de dezvoltare, în care se verifică dacă noul sistem informatic respectă atât cerințele definite de către utilizator, cât și cele identificate în faza de analiză.
Dezvoltarea metodelor de analiză și proiectare orientate obiect a dus la apariția unor instrumente CASE (Computer Aided Software Engineering), care au permis automatizarea procesului de modelare obiectuală și implementare a sistemelor informatice.
Concepte de bază în abordarea obiectuală
Conceptele paradigmei orientate obiect au apărut odată cu dezvoltarea limbajului Simula67 în anii ’60, dar s-au impus în practică abia în anii ‘90. Limbajul Simula67 a introdus pentru prima dată conceptele de clase, corutine și subclase.
Elementele care au influențat dezvoltarea orientării pe obiecte sunt:
realizările din domeniul calculatoarelor;
realizările din domeniul limbajelor de programare: Simula, Pascal, Smalltalk, CLU și Ada;
dezvoltarea metodelor de programare.
Orientarea pe obiecte a deschis o nouă eră în domeniul conceperii și realizării sistemelor informatice. Spre deosebire de metodele clasice, în care procedurile active sunt aplicate asupra datelor pasive, metoda orientării pe obiecte încapsulează datele și procedurile în obiecte, asupra cărora sunt aplicate mesaje ce influențează comportamentul sistemului. Programarea orientată pe obiecte a preluat cele mai bune tehnici din programarea structurată la care a adăugat concepte noi ca obiecte, clase, subclase etc.
Conform [Salomie95], abordarea obiectuală a evoluat în doua etape (Figura 1.3):
în prima etapa s-a realizat o clasificare a obiectelor în clase. Clasele definesc structura și comportamentul unei întregi familii de obiecte și sunt privite ca șabloane generatoare de obiecte.
în a doua etapa s-au dezvoltat tehnicile specifice programării orientate pe obiecte: moștenire, polimorfism etc.
Etapa II
Etapa I
Figura 1.3 Etape în evoluția abordării obiectuale
Mecanismele de bază ale orientării pe obiecte sunt: obiectele, clasele, mesajele și metodele, moștenirea, încapsularea, abstractizarea, polimorfismul, persistența și relațiile între obiecte și clase.
Obiectul
Obiectul este abstractizarea unei entități din lumea reală. Orice entitate din lumea reală este un obste utilizat efectiv. Exploatarea reprezintă cea mai lunga etapă a ciclului de viață a unui sistem informatic.
Figura 1.2 Structura ciclului de viață al sistemului informatic
Un sistem informatic poate fi achiziționat de la o societate comercială specializată în dezvoltarea de software sau poate fi realizat în cadrul compartimentului IT al firmei. În ambele variante, etapa de dezvoltare a sistemului informatic presupune mai multe faze:
Definirea cerințelor utilizator presupune definirea, de către utilizator, a obiectivelor pe care trebuie să le îndeplinească noul sistem informatic;
Analiza constă în culegerea de informații referitoare la funcționarea sistemului informațional existent, în vederea cunoașterii cât mai detaliate a cerințelor la care trebuie să răspundă noul sistem;
Proiectarea presupune elaborarea unui set de specificații și modele detaliate referitoare la programe, structuri de date, persoane și mod de lucru etc;
Implementarea constă în realizarea structurilor de date și a procedurilor automate într-un anumit sistem de gestiune a bazelor de date (s.g.b.d) sau/și limbaj de programare;
Testarea este ultima fază a etapei de dezvoltare, în care se verifică dacă noul sistem informatic respectă atât cerințele definite de către utilizator, cât și cele identificate în faza de analiză.
Dezvoltarea metodelor de analiză și proiectare orientate obiect a dus la apariția unor instrumente CASE (Computer Aided Software Engineering), care au permis automatizarea procesului de modelare obiectuală și implementare a sistemelor informatice.
Concepte de bază în abordarea obiectuală
Conceptele paradigmei orientate obiect au apărut odată cu dezvoltarea limbajului Simula67 în anii ’60, dar s-au impus în practică abia în anii ‘90. Limbajul Simula67 a introdus pentru prima dată conceptele de clase, corutine și subclase.
Elementele care au influențat dezvoltarea orientării pe obiecte sunt:
realizările din domeniul calculatoarelor;
realizările din domeniul limbajelor de programare: Simula, Pascal, Smalltalk, CLU și Ada;
dezvoltarea metodelor de programare.
Orientarea pe obiecte a deschis o nouă eră în domeniul conceperii și realizării sistemelor informatice. Spre deosebire de metodele clasice, în care procedurile active sunt aplicate asupra datelor pasive, metoda orientării pe obiecte încapsulează datele și procedurile în obiecte, asupra cărora sunt aplicate mesaje ce influențează comportamentul sistemului. Programarea orientată pe obiecte a preluat cele mai bune tehnici din programarea structurată la care a adăugat concepte noi ca obiecte, clase, subclase etc.
Conform [Salomie95], abordarea obiectuală a evoluat în doua etape (Figura 1.3):
în prima etapa s-a realizat o clasificare a obiectelor în clase. Clasele definesc structura și comportamentul unei întregi familii de obiecte și sunt privite ca șabloane generatoare de obiecte.
în a doua etapa s-au dezvoltat tehnicile specifice programării orientate pe obiecte: moștenire, polimorfism etc.
Etapa II
Etapa I
Figura 1.3 Etape în evoluția abordării obiectuale
Mecanismele de bază ale orientării pe obiecte sunt: obiectele, clasele, mesajele și metodele, moștenirea, încapsularea, abstractizarea, polimorfismul, persistența și relațiile între obiecte și clase.
Obiectul
Obiectul este abstractizarea unei entități din lumea reală. Orice entitate din lumea reală este un obiect și reciproc orice obiect reprezintă o entitate din realitate. Din punct de vedere structural, obiectele încapsulează date și acțiuni (Figura 1.4).
Figura 1.4 Conceptul de obiect
Un obiect se caracterizează prin: stare, atribute, comportament și identitate. Starea unui obiect este definită de atributele lui, care au nume și valori asociate. Valorile asociate atributelor pot fi instanțe ale unor tipuri fundamentale (numeric, alfanumeric etc.) sau pot referi alte obiecte din cadrul sistemului informatic.
Atributul reprezintă o caracteristică, o proprietate a unei clase. Sintaxa folosită pentru definirea unui atribut este următoarea:
vizibilitate nume : expresie_tip=valoare_inițială
unde:
vizibilitatea poate fi: publică (+), privată (-) sau protejată (#)
nume reprezintă denumirea atributului
expresie_tip semnifică tipul atributului
valoare_inițială reprezintă valoarea implicită a atributului pentru un obiect nou creat.
De exemplu, obiectul Cont401 se prezintă astfel:
SimbolCont=”401”
DenumireCont=”Furnizori”
TipCont=”P”
SoldInitialDebitor=0
SoldInitialCreditor=1500
Comportamentul unui obiect semnifică modalitatea de acțiune și reacțiune a obiectului și este definit de setul de operații aplicabile obiectului respectiv [Salomie95]. Un obiect se comportă în modul său specific ca urmare a recepționării unui mesaj din partea altui obiect. Prin implementare, operațiile devin metode, concretizate în proceduri sau funcții, care acționează asupra atributelor obiectului respectiv.
De exemplu, clasa Cont poate avea următoarele metode:
ReturneazaRulajeDebitoare(): Double,
ReturneazaRulajeCreditoare():Double, etc.
Identitatea reprezintă proprietatea unui obiect care îl distinge de alte obiecte și este, de regulă, o adresă logică invariantă (pointer) ce se păstrează chiar dacă obiectul a fost supus unor transformări.
Clasele
Clasa este o implementare care poate fi instanțiată în vederea creării de multiple obiecte având același comportament. O clasă descrie un ansamblu de obiecte care au aceeași structură și același comportament. Într-un sistem orientat obiect, orice obiect este o instanță a unei clase. Clasele sunt entități statice, spre deosebire de obiecte care sunt entități dinamice ce se creează și se distrug în cadrul unei aplicații. O clasă poate fi accesată doar prin intermediul interfeței sale (Figura 1.5).
O clasă poate însuma elementele comune unui set de subclase. Subclasele mai sunt numite și clase derivate, iar clasele plasate cel mai sus în ierarhie sunt numite superclase. Clasele pot fi reprezentate grafic minimal (Figura 1.6) sau maximal (Figura 1.7).
Figura 1.5 Componentele unei clase
Figura 1.6 Reprezentarea minimală a claselor
Figura 1.7 Reprezentarea maximală a claselor
Figura 1.8 Exemple de obiecte ale clasei Factură
Metode și mesaje
Mesajul este numele unei metode ce aparține unui obiect și care poate fi invocată din exteriorul acestuia. Obiectele comunică prin mesaje. Setul tuturor mesajelor pe care un obiect le „înțelege” formează interfața obiectului. Un mesaj are un obiect destinatar și unul expeditor care va apela o operație. Invocarea unei operații este prefixată de identificatorul obiectului destinatar, delimitat de obicei, prin punct.
De exemplu, invocarea operației ReturneazaRulajeDebitoare din obiectul cont401 se reprezintă astfel:
Cont401.ReturneazaRulajeDebitoare
Metoda este o operație implementată în cadrul unei clase, care rezidă în instanțele acesteia și determină modul în care obiectele acționează atunci când primesc mesaje. Metodele pot trimite mesaje altor obiecte.
Există două tipuri de metode:
metode de clasă – sunt metodele folosite pentru crearea sau distrugerea instanțelor, pentru manipularea atributelor globale sau pentru definirea comportamentului aferent clasei;
metode instanță – sunt metodele care operează asupra instanțelor clasei.
Metodele unei clase pot fi grupate în următoarele categorii:
Constructori – sunt metode de creare și inițializare a obiectelor;
Destructori – sunt metode pentru distrugerea obiectelor;
Modificatori – sunt metode prin care se modifică starea internă a obiectelor (operații de scriere);
Selectori – sunt metode de redare a stării obiectelor (operații de citire);
Sintaxa folosită pentru definirea unei metode este următoarea:
vizibilitate nume (lista_ parametri): tip_returnat
unde:
vizibilitatea poate fi publică (+), privată (-) sau protejată (#)
nume reprezintă denumirea metodei
listă_parametri sunt parametrii transmiși metodei
tip_returnat reprezintă tipul de dată returnat
De exemplu, metoda ValoareMaterialFacturat() poate fi definită, în Visual Basic, astfel:
Public Function ValoareMaterialFacturat(Cant As Integer, Pret As Double) As Double ValoareMaterialFacturat= Cant*Pret
End Function
Încapsularea
Încapsularea sau ascunderea informației constă în proprietatea obiectului de a conține la un loc date și prelucrări, iar accesul la date se poate face numai prin intermediul metodelor. Prin faptul că datele nu sunt vizibile din exteriorul obiectului se asigură securitatea acestora.
În vederea asigurării unei flexibilități a protecției datelor și operațiilor unei clase se pot folosi următorii calificatori:
– (+) public – atributele/metodele sunt accesibile din afara clasei;
– (-) private – atributele/metodele nu sunt accesibile din exterior;
– (#) protected – atributele/metodele sunt accesibile numai claselor derivate.
De exemplu, pentru clasa Cont, protecția datelor și a operațiilor se poate realiza astfel:
După ce un cont a fost creat prin metoda AdaugaCont, informațiile despre acel cont pot fi citite doar cu ajutorul metodelor de tip Vizualizeaza. Prin declararea privată a atributelor clasei se permite implementarea restricțiilor, validarea și accesul controlat la realizările acestora. Astfel, se exclude posibilitatea modificării necontrolate a valorilor atributelor clasei.
Figura 1.9 Protecția datelor și a operațiilor în clasa Cont
Abstractizarea
Abstractizarea reprezintă modalitatea prin care se poate recurge la tipuri abstracte de date ce separă interfața de detaliile de implementare. Interfața asigură utilizatorului o vedere abstractă asupra tipului, în timp ce structura internă a clasei este văzută doar de către cel care efectuează implementarea.
Clasele sunt abstractizări ale unor mulțimi de obiecte. În timp ce obiectele descriu anumite entități din lumea reală, clasele descriu abstract aceste entități. Obiectele devin, așadar, instanțe ale claselor.
De exemplu, clasa Articol este o abstractizare a claselor Marfă și Material.
Figura 1.10 Exemplu pentru abstractizare
Moștenirea
Moștenirea claselor se face atât la nivel de implementare (structură și cod), cât și la nivelul comportamentului (metodelor interfeței) [Salomie95]. În terminologia orientării obiect, clasa de la care se moștenește este numită clasă de bază sau superclasă, iar cea care moștenește poartă numele de clasă derivată sau subclasă. Cu ajutorul moștenirii se pot exprima relații între clase, cum ar fi: clasificarea, specializarea, generalizarea, aproximația și evoluția.
Exemplu: Fie clasele Marfă și MarfăAlimentară. Clasa MarfăAlimentară va moșteni din clasa Marfă atributele Cod, Denumire și Um, fără a mai fi necesară redefinirea acestora. Clasa MarfăAlimentară va conține numai proprietățile specifice acesteia, cum ar fi TermenDeValabilitate etc.
Moștenirea este tranzitivă pe un număr oricât de mare de niveluri și poate fi de două tipuri:
simplă: fiecare clasă derivată are o singură clasă de bază;
multiplă: există clase derivate care au mai multe clase de bază.
În literatura de specialitate, există următoarele posibilități de moștenire (simplă) a atributelor:
Moștenirea directă: clasa derivată moștenește toate atributele clasei de bază pe care le poate adresa în mod direct;
Moștenire cu redefinire arbitrară: în clasa derivată se pot redefini unele atribute din clasa de bază;
Moștenire cu redefinire constrânsă: acest tip de moștenire implică restricții asupra tipului unui atribut din clasa derivată, în sensul că acesta trebuie să fie un subtip al tipului atributului redefinit sau o subclasă a tipului respectiv.
Referitor la metode, posibilitățile de moștenire (simplă) a acestora sunt următoarele:
Moștenire directă: clasa derivată moștenește metodele din clasa de bază;
Redefinire cu constrângeri: o clasă derivată poate să redefinească o metodă din clasa de bază, impunând anumite restricții parametrilor;
Moștenire cu excluderea unor metode: acest tip de moștenire se poate realiza prin redefinirea unei metode, care se dorește a fi eliminată, printr-o altă metodă care să „nu facă nimic” sau prin introducerea unor construcții speciale care să precizeze metodele ce sunt moștenite și să le menționeze pe cele care se exclud (sistemul Trellis/Owl) [Salomie95].
Polimorfismul
Polimorfismul constă în proprietatea unor obiecte (instanțe ale aceleiași clase), ca la primirea aceluiași mesaj să manifeste comportamente diferite (sunt executate operații/metode diferite). Polimorfismul poate fi asigurat prin două căi:
prin moștenire: o metodă a clasei de bază poate opera diferit pentru oricare din clasele derivate;
prin supraîncărcare: permite folosirea unei metode (procedură/funcție) cu același nume, dar cu parametri diferiți.
Exemplu: Fie clasa de bază Marfă și clasa derivată MarfăAlimentara. Clasa MarfăAlimentară moștenește atributele clasei Marfă, iar operația AdaugaMarfa este redefinită cu parametrii diferiți. Operația polimorfă AdaugaMarfa este implementată în cele două clase prin metode diferite.
Polimorfismul permite ca o operație să fie implementată prin mai multe metode, având aceeași semnătură în toate clasele care le implementează.
Persistența
Persistența descrie durata de viață a unui obiect. Scopul persistenței este de a salva atât starea, cât și comportamentul unui obiect de la o execuție la alta a aplicației care la generat. Datorită faptului că sistemele informatice de gestiune folosesc un volum mare de date, care necesită salvarea datelor (obiectelor) pe disc, problema persistenței este rezolvată fie prin utilizarea bazelor de date orientate obiect (în cazuri rare), fie prin utilizarea bazelor de date relaționale (în cazurile cele mai frecvente).
Relații între obiecte și clase
Relațiile dintre obiecte și clase sunt legături logice ce se stabilesc între acestea și se împart în:
Relații obiect-obiect: aceste relații se stabilesc între obiectele care schimbă între ele mesaje. Într-un sistem informatic pot exista următoarele tipuri de obiecte:
obiecte tip agent – sunt obiectele care pot fi operate de către alte obiecte din sistem, dar care pot să și acționeze asupra altor obiecte prin intermediul metodelor;
obiecte de tip server – sunt obiectele asupra cărora numai se operează;
obiecte de tip actor – sunt obiectele care doar operează asupra altor obiecte.
Relații obiect-clasă: fiecare obiect este instanța unei clase.
Figura 1.11 Relația obiect-clasă
Relații clasă-clasă: între clasele unui model orientat obiect se pot realiza mai multe tipuri de relații. Aceste relații sunt:
Asocierea – este o conexiune logică între două sau mai multe clase de obiecte. Asocierile pot fi unare (sunt generate de o singură clasă), binare (între două clase) sau N-are (mai mult de două clase).
Agregarea – este o formă particulară de asociere, de tip parte-întreg. În cazul în care, un obiect parte aparține cel mult unui întreg (la un moment dat), agregarea se numește compoziție.
Generalizarea – este o relație între o clasă și versiunile ei rafinate, numite specializări.
Dependența – descrie o legătură de tip server-client. Clasa client depinde de serviciile oferite de clasa server.
Metodologii de proiectare orientate obiect
În decursul timpului s-au elaborat mai multe metodologii de proiectare orientate obiect, dintre care cele mai importante sunt: Booch, OOA – Object Oriented Analys (Coad și Yordoun), OMT – Object Modeling Technique (Rumbaugh și colectivul), Fusion (Coleman și colectivul), Objectory – Object Factory for Software Development (Jacobson) etc.
2.1. Metodologia OMT (Object Modeling Technique)
Metodologia OMT, elaborată la începutul anilor ’90 de către James Rumbaugh, s-a impus cu ușurință în proiectarea obiectuală a sistemelor informatice datorită faptului că a fost foarte clar definită. Multe dintre conceptele utilizate în cadrul metodologiei OMT au fost preluate și în UML.
Formalismul OMT
Ca filozofie generală, OMT operează pe trei dimensiuni fundamentale: statică, dinamică și funcțională. Astfel, fiecărei dimensiuni i se asociază câte un model:
Modelul static se referă la structura statică a datelor, în acest sens elaborându-se diagrama claselor și diagrama obiectelor. Modelul static este o extensie a modelului Entitate-Asociere.
Modelul dinamic se referă la comportamentul claselor, la evenimentele/stările, precum și la reacția sistemului la acestea. Acest model presupune elaborarea diagramei de evenimente și a diagramei de stare.
Modelul funcțional descrie fluxul de informații din cadrul sistemului și presupune elaborarea diagramei de flux al datelor.
Modelul static
Modelul static se referă la clasele/obiectele, precum și la legăturile dintre acestea. În OMT, o clasă se reprezintă sub forma unui dreptunghi împărțit în trei compartimente (Figura 2.1): primul compartiment se referă la denumirea clasei, al doilea e destinat atributelor clasei, iar al treilea compartiment se referă la operațiile clasei.
Figura 2.1 Reprezentarea clasei Comandă în metodologia OMT
Metodologia OMT prevede următoarele tipuri de relații între clase:
Asocierea reprezintă o legătură logică între clase și are o serie de proprietăți care au fost preluate și în UML: numele asocierii, multiplicitatea, rolul și ordonarea. Aceste proprietăți sunt explicate pe larg în capitolul referitor la limbajul UML. Multiplicitatea este singura proprietate care diferă din punct de vedere al reprezentării grafice în UML. În OMT, se folosesc următoarele notații pentru multiplicități:
Exemplu: Un client poate efectua zero sau mai multe comenzi. Rolul clasei client este emitent, iar clasa comandă are rolul emisă. Numele asocierii este întocmește. Deoarece, pentru un client, clasa comandă poate avea mai multe instanțe, acestea pot fi ordonate.
Figura 2.2 Reprezentarea unei asocieri în OMT
Să luăm un alt exemplu, referitor la facturi și materiale. Având în vedere că o factură conține mai multe materiale, iar un material poate figura în mai multe facturi, apare necesară utilizarea clasei asociere MaterialFacturat. Conținutul acesteia este prezentat în Figura 2.3.
Figura 2.3 Reprezentarea clasei asociere în OMT
Agregarea este o legătură de tip parte-întreg. Agregarea se reprezintă grafic printr-un romb gol, la fel ca și în UML.
Exemplu: Într-o operație contabilă, se debiteză cel puțin un cont.
Figura 2.4 Reprezentarea agregării în OMT
Generalizarea/specializarea este o relație de moștenire între o clasă și versiunile ei evoluate (specializări). Generalizarea se reprezintă grafic printr-un triunghi.
Exemplu: Clasa Persoană se poate specializa în clasele Persoana Fizică și Persoană Juridică. Privită de sus în jos, relația este o specializare, iar de jos în sus, generalizare.
Figura 2.5 Reprezentarea generalizării/specializării în OMT
Modelul dinamic
Modelul dinamic presupune elaborarea diagramei de evenimente și a diagramei de stare. Modelul dinamic prezintă evoluția sistemului în timp, ca reacție a acestuia la stimulii externi și la interacțiunea dintre obiecte.
Starea unui obiect se modifică în timp datorită acțiunii unor evenimente (stimuli externi). Această modificare a stării unui obiect se reprezintă prin diagrama de stare a clasei respective.
Tranziția permite trecerea de la o stare la alta a unui obiect, iar acțiunea este o operație instantanee care este atașată unui eveniment. Diagrama de stare (Figura 2.6) se reprezintă sub forma unui graf, nodurile fiind stările obiectului, iar arcele reprezintă tranzițiile dintre stări. În cadrul stărilor se pot executa diferite activități permanente. Acestea vor fi prefixate de cuvântul cheie Do.
Figura 2.6 Diagrama de stări/tranziții în OMT
Exemplu: Din momentul primirii de la furnizor și până în momentul recepției produselor facturate, factura se poate afla în stările Factură sosită și Factură recepționată.
Figura 2.7 Diagrama de stare pentru clasa Factură
Pentru fiecare clasă, cu comportament dinamic important, se va întocmi câte o diagramă de stare.
Scenariul reprezintă o secvență de evenimente între obiecte, care interacționează în vederea îndeplinirii unei funcționalități a sistemului. Scenariile sunt reprezentate schematic prin intermediul diagramei de secvențe.
Exemplu: Pentru activitatea de aprovizionare cu materiale de la furnizor există următorul scenariu:
Furnizorul emite factura;
Factura este primită de către gestionar;
Furnizorul livrează materialele;
Se efectuează recepția materialelor;
Figura 2.8 Diagrama de evenimente pentru aprovizionarea cu materiale
Modelul funcțional
Modelul funcțional reflectă prelucrările și fluxurile de date din cadrul sistemului. Conform OMT, modelarea funcțională presupune întocmirea diagramei de flux al datelor (DFD). Această diagramă utilizează următoarele concepte:
Procesele care prelucrează date. Procesele sunt reprezentate grafic prin elipse (Figura 2.9).
Figura 2.9 Reprezentarea procesului în DFD
Fluxuri de date care asigură transportul datelor. Valorile datelor nu pot fi modificate în fluxul de date. Fluxurile de date sunt reprezentate grafic prin săgeți (Figura 2.10).
Figura 2.10 Reprezentarea fluxului de date în DFD
Actorii sunt obiecte active care dirijează fluxul de date în producerea sau consumul de valori. Actorii se reprezintă grafic prin dreptunghiuri (Figura 2.11).
Figura 2.11 Reprezentarea actorilor în DFD
Rezervorul de date este un obiect pasiv, din interiorul diagramei de flux de date, ce stochează date pentru o accesare ulterioară. Se reprezintă grafic prin două linii paralele (Figura 2.12).
Figura 2.12 Reprezentarea rezervorului de date în DFD
Fluxul de control este un canal prin care se verifică informația ce participă la formarea unui flux de date. Un flux de control este o valoare booleană ce se stabilește de regulă atunci când se verifică un proces. Se reprezintă grafic printr-o linie punctată (Figura 2.13).
Figura 2.13 Reprezentarea unui flux de control în DFD
Exemplu: după primirea facturilor de la furnizori, gestionarul trebuie să le înregistreze în baza de date a sistemului informatic. Pentru această activitate se poate elabora următoarea diagramă a fluxurilor de date:
Figura 2.14 Diagrama de flux al datelor pentru înregistrarea facturilor
Dezvoltarea sistemelor informatice conform metodologiei OMT
Ciclul de dezvoltare în OMT este format din următoarele faze: analiza, proiectarea și implementarea.
Faza de analiză presupune elaborarea modelului obiectelor, a modelului dinamic și a modelului funcțional.
Proiectarea sistemului se realizează în două etape. În prima etapă se urmărește proiectarea sistemului, iar în cea de-a doua etapă se dorește proiectarea obiectelor.
Implementarea presupune scrierea programelor necesare elaborării proiectului.
Figura 2.15 Ciclul de dezvoltare în OMT
Analiza
Faza de analiză presupune elaborarea celor trei modele conceptuale (static, dinamic și funcțional) prin parcurgerea următoarelor etape:
Realizarea unei descrieri inițiale a problemei
Elaborarea modelului static care presupune:
Identificarea claselor de obiecte și a atributelor acestora;
Crearea unui dicționar de date, conținând descrierile claselor, artributelor și relațiilor dintre clase;
Identificarea relațiilor dintre clase sub formă textuală;
Identificarea relațiilor de generalizare;
Verificarea căilor de acces la date;
Stabilirea iterațiilor în vederea rafinării modelului;
Gruparea claselor în module. Modulele au rol de „recipienți” în care sunt declarate clasele și obiectele concepției logice.
Conform OMT, modelul obiect = diagrama modelului obiect + dicționarul de date
Elaborarea modelului dinamic presupune parcurgerea următoarelor etape:
Elaborarea scenariilor;
Identificarea evenimentelor dintre obiecte și elaborarea diagramelor de evenimente pentru fiecare scenariu;
Elaborarea diagramei de flux de evenimente pentru sistem;
Dezvoltarea diagramelor de stare pentru fiecare clasă care are un comportament dinamic important.
În OMT, modelul dinamic = diagramele de stări + diagrama globală a fluxurilor de evenimente
Construirea modelului funcțional presupune:
Identificarea datelor de intrare și a datelor de ieșire;
Construirea diagramei fluxurilor de date;
Descrierea fiecărei funcții;
Identificarea constrângerilor;
Specificarea criteriilor de optimizare.
Conform OMT, modelul funcțional = diagramele de fluxuri de date + restricții
Verificarea și rafinarea celor trei modele:
Adăugarea în modelul static a operațiilor descoperite în modelul funcțional;
Verificarea claselor, atributelor, operațiilor și relațiilor dacă sunt coerente și complete, pentru fiecare nivel de abstracție. Compararea celor trei modele cu enunțul problemei și testarea modelelor cu ajutorul scenariilor;
Dezvoltarea de scenarii foarte elaborate.
Proiectarea sistemului
Proiectarea sistemului este faza în care se va determina arhitectura sistemului atât din punct de vedere hardware, cât și software. Conform metodologiei OMT, proiectarea sistemului presupune:
organizarea sistemului în subsisteme;
identificarea elementelor de conflict;
alegerea strategiei de stocare și de acces la date.
Există mai multe tipuri de structuri arhitecturale în care se încadrează aproape toate sistemele. Principalele tipuri de sisteme/subsisteme sunt:
sisteme cu prelucrare pe loturi: se caracterizează prin faptul că operatiile de prelucrare afecteaza loturi complete de date;
Exemplu: sisteme pentru încasări-plăți.
sisteme cu prelucrare continua: sunt acele sisteme care operează asupra datelor aflate în continuă actualizare;
sisteme interactive: sunt sistemele care tratează interactiuni cu agenti externi – utilizatori, periferice, alte sisteme;
Exemplu: sistemele informatice pentru bancomat.
sisteme dinamice: sunt acele sisteme care simulează evoluția în timp a lumii reale;
Exemplu: sistemele care utilizează modele economice, simulatoare, jocuri de întreprindere.
sisteme în timp real: sunt sistemele dominate de constrângeri temporale;
Exemplu: sistemele pentru controlul proceselor, sisteme pentru comunicatii etc.
sisteme de tranzacții: sunt sistemele cu baze de date care au rolul de stocare și accesare a informațiilor.
Exemplu: sisteme financiare, sisteme pentru evidența stocurilor etc.
Datorită faptului că majoritatea problemelor generează foarte multe clase, se impune împărțirea sistemului în subsisteme. OMT folosește o abordare clasică în acest sens: rezultatele fazei de analiză, clasele, sunt grupate în subsisteme. În OMT, sunt dificil de identificat componentele și subsistemele reutilizabile, datorită faptului că acestea nu au fost descoperite într-un stadiu incipient al dezvoltării sistemului. O altă problemă a organizării sistemelor în subsisteme, în faza de proiectare, o reprezintă faptul că eventualele modificări generate de aceste grupări ale claselor se transmit destul de greu diagramelor obiectelor.
Criteriile generale pe care trebuie să le îndeplinească un subsistem sunt următoarele:
Cererile sistemului să fie clar definite, înaintea începerii proiectării sistemului;
Sistemele ar trebui divizate în subsisteme folosind ascunderea informației, înainte de scrierea codului sursă;
Fiecare subsistem ar trebui să aibă o specificație precisă.
Legătura dintre subsisteme se realizează prin intermediul interfețelor. Toate subsistemele trebuie să beneficieze de interfețe viabile, care să facă față eventualelor modificări aduse cerințelor utilizatorilor. Comunicarea subsistemelor prin interfețe se poate realiza prin utilizarea fișierelor, a bazelor de date relaționale sau a bazelor de date orientate obiect. Deși bazele de date orientate obiect respectă principiile fundamentale ale tehnologiei orientate obiect (încapsulare, moștenire, polimorfism etc.), acestea sunt rar utilizate, datorită inexistenței unor sisteme puternice de gestiune a bazelor de date orientate obiect. Din acest motiv, stocarea informațiilor este asigurată, de obicei, de către bazele de date relaționale.
În ceea ce privește identificarea elementelelor de conflict, acestea pot apărea fie datorită defectării echipamentelor hardware, fie introducerii unor date incorecte de către utilizatori. În cazul erorilor umane, subsistemele trebuie concepute astfel încât să poată recunoaște și trata erorile apărute.
După elaborarea subsistemelor, trebuie ca fiecărui subsistem să i se aloce o unitate funcțională (hardware, software sau de uz general).
Proiectarea obiectelor
Proiectarea obiectelor este faza în care are loc definirea completă a claselor și asocierilor. În această fază sunt luate hotărâri cu privire la implementarea operațiilor, la transferul atributelor în tipuri de date, la rafinarea ierarhiilor de clase, precum și la identificarea de noi clase care nu sunt prezente în modelul static.
Conform OMT, proiectarea obiectelor presupune parcurgerea următoarelor etape:
Identificarea de noi operații în modelul static din modelul dinamic și funcțional.
În modelul dinamic, operațiile se regăsesc sub forma acțiunilor atașate evenimentelor sau a activităților executate în cadrul stărilor. În diagrama de evenimente, un eveniment (trimis de un obiect altui obiect) presupune existența unei operații în clasa destinatară evenimentului.
În modelul funcțional, pentru fiecare activitate și acțiune din modelul dinamic, se poate elabora câte o diagramă de flux al datelor. Fiecare proces va fi transformat într-o operație, iar fluxurile de date vor constitui datele de intrare (parametri) pentru operații (procese).
Proiectarea obiectelor presupune, pentru această etapă, verificarea corespondenței operațiilor existente în modelul static cu acțiunile, activitățile și procesele definite în modelul dinamic și în modelul funcțional, precum și adăugarea de altele noi, dacă operațiile respective nu se regăsesc în cele două modele.
2. Conceperea algoritmilor pentru implementarea operațiilor. În implementarea operațiilor trebuie să se țină cont de algoritmii care le descriu. În acest sens, se urmărește alegerea structurilor de date potrivite și a algoritmilor minimali pentru implementarea operațiilor.
3. Definirea claselor și a operațiilor interne. Clasele și operațiile interne nu au fost descoperite în faza de analiză. Există clase interne care sunt dependente de aplicație (exemplu clasa DescarcăGestiune) și clase interne care pot fi folosite în mai multe aplicații (biblioteci de clase etc.). Clasele interne (denumite de către Jacobson clase de control) au rolul de a face legătura între sistem și obiectele externe.
4. Proiectarea asocierilor. Asocierile identificate în faza de analiză pot fi binare sau n-are. În faza de proiectare se urmărește descompunerea asocierilor n-are în asocieri binare cu calificatori sau atribute de legătură.
Un alt aspect în proiectarea asocierilor îl reprezintă navigabilitatea. În faza de analiză, în cele mai multe cazuri, asocierile sunt bidirecționale. Implementarea poate fi simplificată prin identificarea asocierilor unidirecționale.
În cazul problemelor complexe este posibil ca în faza de proiectare să se adauge modelului static asocieri redundante. Scopul acestora este de a permite accesări eficiente ale informațiilor.
5. Rafinarea ierarhiilor de clase. Deoarece în faza de proiectare este posibil să apară noi clase, se impune și o rafinare a ierarhiilor de clase. În acest sens, se au în vedere următoarele aspecte:
Evitarea ierarhiilor bogate. Astfel, se elimină riscul producerii claselor greu de întreținut;
Evitarea ierarhiilor „plate”. Sunt de preferat ierarhiile care comunică între ele;
Construirea de ierarhii de clase în care fiecare din ele au un rol bine definit;
Identificarea și plasarea claselor abstracte în vârful ierarhiei.
Implementarea
În faza de implementare are loc scriere codului sursă necesar realizării sistemului. OMT oferă soluții pentru:
implementarea într-un limbaj neorientat spre obiecte;
implementarea într-un limbaj orientat spre obiecte;
implementarea în baze de date relaționale.
Metodologia Booch
La începutul anilor ’80, Grady Booch a dezvoltat metodologia OOD (Object Oriented Design), ulterior fiind dezvoltată în versiuni succesive. Metodologia OOD a fost elaborată inițial pentru dezvoltarea de aplicații în ADA și apoi în C++.
Formalismul Booch
Booch descrie sistemul informatic în două viziuni:
Nivelul logic în care se elaborează diagrama claselor, diagrama de obiecte, diagrama de stare și diagrama de interacțiune
Nivelul fizic se bazează pe arhitectura modulelor și a proceselor, în acest sens elaborându-se diagrama de module și diagrama de procese.
Figura 2.16 Niveluri și modele
Modelarea statică a nivelului logic
Modelarea statică în nivelul logic se realizează prin diagramele de clase și diagramele de obiecte. Pe lângă conceptele de bază (obiect, clasă etc.), în metodologia Booch se mai utilizează și alte concepte, cum ar fi:
Obiectul client – este un obiect care utilizează resursele altui obiect.
Concurență între obiecte – un obiect poate avea un comportament secvențial sau concurent. Un obiect secvențial nu face decât un serviciu o dată, în timp ce un obiect concurent poate face mai multe servicii simultan.
Protocoale client – se referă la o listă de operații ale unui obiect care pot acționa asupra altui obiect.
Diagrama claselor:
O clasă este reprezentată grafic sub forma unui nor având conturul realizat cu linie întreruptă. Un obiect este reprezentat grafic tot sub forma unui nor, dar conturul acestuia se realizează cu linie continuă.
Figura 2.17 Reprezentarea claselor și obiectelor în metodologia Booch
Atributele unei clase se pot reprezenta astfel:
NumeAtribut:Clasa=ValoareImplicită
Sintaxa utilizată pentru descrierea operațiilor unei clase este următoarea:
ValoareReturnată NumeOperație(parametri)
Pentru atribute, operații și relații se pot stabili diferite grade de vizibilitate. Prin urmare, există următoarele patru grade de vizibilitate: public, privat, protejat și implementare. Vizibilitatea publică nu are o notație specială, în schimb celelalte niveluri se reprezintă astfel :
| privat
|| protejat
||| implementare.
Între clase se pot stabili următoarele tipuri de relații: asociere, agregare, utilizare, generalizare, instanțiere și metaclasă. Reprezentarea grafică a acestor tipuri de relații este prezentată în Figura 2.18.
Figura 2.18 Reprezentarea relațiilor în metodologia Booch
Asocierea se caracterizează prin rol, cheie și restricții. Rolul precizează modul în care se identifică obiectele între ele, cheia este un atribut care permite identificarea unui obiect corespondent, iar restricția se referă la condiții ce vor fi îndeplinite.
Multiplicitățile relațiilor se reprezintă astfel:
1 un obiect
0..N zero sau mai multe obiecte
1..N unu sau mai multe obiecte
1..4,6 pentru specificarea unui interval.
Exemplu: Diagrama claselor pentru evidența comenzilor primite de la clienți (interni sau externi), conform metodologiei Booch, s-ar prezenta astfel:
Figura 2.19 Exemplu de diagramă a claselor
Booch introduce notații și pentru tipurile speciale de clase:
clase parametrizate: definesc mulțimi de clase în care fiecare clasă este specificată prin stabilirea parametrilor cu valori efective. Parametrii pot fi clase, obiecte și operații.
Figura 2.20 Reprezentarea claselor/obiectelor parametrizate
clase de utilitare se referă la colecții de funcții independente grupate după anumite criterii în clase. Grafic, clasele de utilitare se reprezintă astfel:
Figura 2.21 Reprezentarea claselor de utilitare
categorii de clase. Gruparea claselor în categorii de clase este utilă în cazul sistemelor complexe. Booch introduce chiar și notații pentru aceste grupuri de clase:
Figura 2.22 Reprezentarea categoriilor de clase în OOD
Modelarea dinamică a nivelului logic
Modelarea dinamică în nivelul logic se realizează prin diagramele de obiecte (asemănătoare celei de colaborări din UML), de stare și de interacțiune. În diagrama de obiecte, Booch introduce o serie de concepte prin care se îmbină aspectele statice cu cele dinamice. Diagrama de obiecte este folosită pentru a verifica diferite scenarii. Legăturile dintre obiecte sunt stabilite pe baza relațiilor dintre clase descrise în diagrama claselor. Modul de reprezentare al unei relații dintre obiecte este prezentat în Figura 2.23.
Figura 2.23 Reprezentarea relației dintre obiecte
Mesajele dintre obiecte pot fi simple, de tip sincron, asincron și de tip „Balking”. Reprezentarea lor grafică este puțin diferită față de cea din UML:
În diagrama de obiecte este posibil să se reprezinte și vizibilitatea obiectelor. Aceasta poate fi:
Exemplu: Obiectul interfață (FormularClient) solicită crearea unui nou obiect client.
Figura 2.24 Exemplu de diagramă a obiectelor în metodologia Booch
În cadrul digramelor de interacțiune sunt descrise mesajele dintre obiecte, pe durata de viață a acestora, ordonate cronologic. Această diagramă a fost preluată și în UML folosind, în mare parte, aceleași concepte și notații.
Figura 2.25 Reprezentarea diagramelor de interacțiune
Diagramele de stări sunt asemănătoare celor din metodologia OMT. Conceptele folosite sunt cele deja cunoscute: stare inițială, stare finală, starea-acțiune. De asemenea, există și posibilitatea de imbricare a stărilor. O superstare poate memora și un istoric al execuției tranzițiilor din cadrul ei, prin palsarea literei H într-un cerc.
Figura 2.26 Reprezentarea unei diagrame de stări
Nivelul fizic
În acest nivel se dezvoltă diagrama modulelor și diagrama proceselor. Prin diagrama modulelor se descrie arhitectura sistemului. Diagrama modulelor a fost gândită în special pentru limbajele care nu suportă conceptul de clasă, ci de modul (limbajele ADA, Modula2) și conține atât modulele, cât și relațiile dintre ele. Booch a introdus notații speciale pentru fiecare tip de modul: program principal, subprogram sau pachet generic, pachet sau sarcină, corp de subprogram.
Exemplu: dependența dintre modulele unui program scris în Visual Basic:
Figura 2.27 Diagrama de module pentru un program simplu în VB
Pentru a descrie arhitectura unui sistem complex, modulele legate între ele pot fi grupate în subsisteme (Figura 2.28).
Figura 2.28 Dependența dintre subsistemele A și B
În diagrama proceselor sunt descrise procesoarele și dispozitivele care formează platforma de execuție a sistemului, precum și modul în care procesele sunt alocate procesoarelor.
Figura 2.29 Reprezentarea diagramei proceselor
Diagrama modulelor și cea a proceselor sunt preluate, cu câteva modificări, de limbajul UML, ca diagramă a componentelor și diagramă de amplasare.
Dezvoltarea sistemelor informatice conform metodologiei Booch
Metodologia Booch suportă o dezvoltare iterativă și incrementală a sistemelor informatice. Această metodologie se bazează pe rafinarea succesivă a specificațiilor preconizate în fiecare etapă. Spre deosebire de metodologia OMT, metodologia Booch nu este la fel de bine elaborată. Metodologia OOD propune următoarele faze pentru ciclul de dezvoltare a sistemelor:
Faza de analiză nu este prea bine dezvoltată în cadrul metodologiei, Booch propunând utilizarea analizei clasice din SADT (Structured Analysis and Design Tehnique).
Faza de proiectare se prezintă la nivel logic și se concentrează asupra diagramelor descrise (identificarea claselor/obiectelor, identificarea relațiilor dintre clase/obiecte).
Figura 2.30 Ciclul de dezvoltare în OOD
Faza de evoluție se referă la scrierea codului, la testare și integrare;
Faza de modificare vizează schimbările apărute în evoluția sistemului, care presupun modificări în diagramele elaborate.
Metodologia Booch se bazează în dezvoltarea sistemelor informatice pe două tipuri de procese: macro-procese și micro-procese.
Procesele de tip macro sunt descrise prin:
stabilirea cerințelor de bază (conceptualizare);
dezvoltarea unui model al comportamentului (analiză);
crearea arhitecturii (proiectarea);
evaluarea implementării (evoluție);
managementul evoluției ulterioare livrării (întreținere).
Procesele de tip micro presupun următoarele activități specifice:
identificarea claselor și obiectelor la un nivel de abstracție;
identificarea semanticii claselor și obiectelor;
identificarea relațiilor dintre clase și obiecte;
specificarea interfeței și apoi, a implementării acestor clase și obiecte.
Metodologia OOSE (Object-Oriented Software Engineering)
Metodologia OOSE, cunoscută inițial sub denumirea de Objectory (Object Factory for Software Development), a fost elaborată de un grup de suedezi condus de Ivar Jacobson. Această metodologie a introdus tehnica definirii cerințelor prin cazuri de utilizare.
Formalismul OOSE
Modelele propuse de OOSE pentru descrierea sistemelor informatice sunt: modelul cerințelor, modelul de analiză, modelul de proiectare, modelul de implementare și modelul de test care verifică coerența sistemului. Legăturile dintre aceste modele sunt prezentate în Figura 2.31.
Figura 2.31 Legătura dintre modelele definite în OOSE
Modelul cerințelor
Modelul cerințelor definește limitele și funcționalitatea sistemului. Acest model se concentrează asupra diagramei obiectelor din domeniul problemei și asupra diagramei cazurilor de utilizare. Diagrama obiectelor din domeniul problemei (Figura 2.32) furnizează o vedere logică a sistemului, care este caracteristică în special cazurilor de utilizare.
Diagrama cazurilor de utilizare descrie interacțiunea dintre sistem și utilizatorii acestuia. Conceptele utilizate în cadrul acestei diagrame sunt actorul (se reprezintă sub forma unui omuleț stilizat) și cazul de utilizare (se reprezintă sub forma unei elipse și este similar scenariului din metodologia OMT). Relațiile dintre cazurile de utilizare sunt reprezentate prin săgeți cu linii punctate, însoțite de eticheta uses.
Figura 2.32 Reprezentarea diagramei de obiecte din domeniul problemei, conform OOSE
Figura 2.33 Reprezentarea diagramei cazurilor de utilizare, conform OOSE
Modelul de analiză
Modelul de analiză nu face o descriere în ansamblul sistemului, ca în majoritatea metodelor, ci o descriere coerentă a cazurilor de utilizare care compun sistemul. Sistemul informatic este descris printr-un ansamblu de cazuri de utilizare împreună cu relațiile dintre acestea. Un model poate fi descris prin cazuri de utilizare concrete (sunt cele care descriu activitatea fiecărui grup de actori) și abstracte (sunt cele care descriu legăturile dintre cazurile de utilizare concrete).
Figura 2.34 Cazuri de utilizare concrete și abstracte în OOSE
Modelele de analiză pot fi descrise prin obiecte entitate, obiecte de control și obiecte de interfață (Figura 2.35) :
Obiectele entitate reflectă conceptele (elementele) care aparțin domeniului problemei și care descriu aspectul static al sistemului. Obiectele entitate conțin atribute și operații.
Exemplu: Furnizori, Clienti, Marfuri fac parte din categoria obiectelor entitate.
Obiecte control sunt acele obiecte care asigură coordonarea obiectelor entitate și de interfață din cadrul aplicației.
Exemplu: DescarcăGestiune poate fi considerat un obiect de control.
Obiecte interfață sunt acele obiecte care asigură comunicarea sistemului cu utilizatorii.
Exemplu: Formularele, butoanele de comandă, casetele text etc. fac parte din categoria obiectelor de interfață
Figura 2.35 Categorii de obiect în OOSE
Obiectele sunt descrise prin stare, comportament și interfața cu utilizatorul. Între obiectele din aceeași categorie se pot stabili relații (Figura 2.36) de asociere, agregare (consists-of) și generalizare (inherits). Se pot realiza și asocieri între obiecte din categorii diferite, însă semantica lor nu este stabilită foarte clar.
De exemplu, pentru activitatea de aprovizionare și recepție a materialelor primite de la furnizorii interni și externi se poate elabora următorul model de analiză:
Figura 2.36 Exemplu de model de analiză, conform OOSE
Modelul de proiectare și de implementare
Conform OOSE, modelul de proiectare este o variantă de implementare a modelului de analiză, în funcție de caracteristicile mediului de dezvoltare ales. Categoriile de obiecte din modelul de analiză sunt reprezentate prin conceptul de bloc care descrie modul de reprezentare a relațiilor dintre obiecte, într-un limbaj de programare orientat obiect sau într-o bază de date relațională. Un bloc poate conține unul sau mai multe obiecte descrise în modelul de analiză. Fiecare bloc are:
o interfață;
o secțiune privată care încapsulează obiectele conținute;
o secțiune publică care permite accesul la anumite obiecte.
Între obiectele din modelul de analiză și blocurile contruite în modelul de proiectare nu există o corespondență directă. Acest lucru duce la apariția unor erori în procesul de trecere de la analiză la proiectare.
Dimensiunea dinamică a sistemului se reprezintă prin diagrama de tranziție a stărilor și prin diagrama de interacțiune. De regulă, fiecărui bloc i se asociază câte o diagramă de tranziție a stărilor și câte o diagramă de interacțiune.
Modelul de implementare constă în scrierea codului sursă.
Dezvoltarea sistemelor informatice conform metodologiei OOSE
Metodologia OOSE se bazează pe o dublă abordare:
sistemică, care permite descompunerea recursivă a sistemului în subsisteme, până se ajunge la nivelul obiect;
structurată, care inițializează ciclul de dezvoltare prin identificarea și analiza principalelor funcții ale sistemului.
În OOSE, ciclul de dezvoltare al sistemelor informatice este împărțit în trei procese (Figura 2.37):
procesul de analiză, care are ca rezultat un model al cerințelor și un model de analiză. Modelul cerințelor conține diagrama obiectelor din domeniul problemei și diagrama cazurilor de utilizare;
procesul de construcție este format din modelul de proiectare (în cadrul căruia sunt elaborate și diagramele de tranziție a stărilor și de interacțiune) și din modelul de implementare;
procesul de testare care se efectuează la nivel unitar, la nivel de integrare și de sistem.
Figura 2.37 Ciclul de dezvoltare în metodologia OOSE
Concluzii
Metodologia OMT permite definirea arhitecturii sistemului și oferă soluții de implementare atât în limbaje de programare orientate obiect, cât și în baze de date relaționale. OMT prezintă un model obiectual bogat (poate cel mai bine dezvoltat comparativ cu celelalte metodologii) în concepte și simboluri, precum și un proces de dezvoltare al sistemelor informatice foarte bine conceput (procesul unificat de dezvoltare al sistemelor informatice a preluat foarte multe idei din metodologia OMT).
Metodologia Booch se remarcă prin bogăția de notații (protocoale de comunicații etc.) și prin posibilitățile oferite pentru dezvoltarea sistemelor complexe (subsisteme, categorii etc.). Pe lângă aceste facilități însă, metodologia Booch prezintă anumite dificultăți în reprezentarea grafică a diagramelor claselor și obiectelor. În metodologia Booch este dezvoltată atât latura dinamică (diagrama obiectelor, diagramele de interacțiune și de stări), cât și cea arhitecturală (diagrama de module și diagrama proceselor).
În metodologia OOSE, utilizarea celor trei tipuri de obiecte (entitate, control, interfață) în conceperea unui sistem informatic acoperă o abordare de modelare cunoscută de mult timp în Smalltalk. Dezvoltarea sistemelor prin cazuri de utilizare este originală și integrează mai bine aspectul modular și incremental al sistemului de informare. Metodologia OOSE prezintă și anumite nereguli cu privire la construcția blocurilor și la semantica asocierilor dintre obiecte care aparțin unor categorii diferite.
Aceste trei metodologii au stat la baza elaborării UML. În Figura 2.38 sunt prezentate contribuțiile metodologiilor OMT, Booch și OOSE la elaborarea limbajului unificat de modelare (UML).
Figura 2.38 Contribuția metodologiilor în elaborarea UML
Limbajul Unificat de Modelare (UML)
Limbajul unificat de modelare (UML) este noul nume dat limbajului rezultat prin unificarea metodologiilor OOD, OMT și OOSE. UML s-a inspirat și din alte metode de proiectare și analiză, cum ar fi: CRC, Fusion, Shlaer și Mellor, Coad și Yourdon etc.
UML este un limbaj vizual de modelare, el nu este un limbaj vizual de programare pentru că nu dispune de întregul arsenal semantic și vizual specific limbajelor de programare.
UML a apărut într-o primă versiune (0.9) în iunie 1996, pentru ca în iulie 1997, odată cu versiunea 1.0, să fie trimis spre standardizare către OMG (Object Management Group). În noiembrie 1997, OMG a anunțat adoptarea specificației UML ca limbaj standard de modelare.
Arhitectura UML
UML se încadrează în structura pe patru niveluri a ierarhiei metamodelării:
Meta-metamodelul
Formează baza pentru arhitectura de metamodelare. Definirea limbajului pentru specificarea metamodelului reprezintă responsabilitatea principală a acestui nivel de arhitectură. Meta-metamodelul definește modelul la un nivel de abstractizare mai înalt decât metamodelul și este mai compact decât acesta. Meta-Object Facility (MOF) reprezintă un exemplu de meta-metamodel. MOF reutilizeaza simbolurile de modelare structurată din UML 2, fără a defini altele suplimentare.
Metamodelul
Metamodelul este o instanță a meta-metamodelului (Figura 3.1). Responsabilitatea principală a acestui nivel este de a defini un limbaj pentru modele specifice. UML și OMG Common Warehouse Metamodel (CWM) sunt exemple de metamodele.
Figura 3.1 Metamodelul este o instanță a meta-metamodelului
Infrastructura UML îndeplinește următoarele cerințe de proiectare:
definește un metalimbaj nucleu care poate fi reutilizat pentru a defini o varietate de metamodele, inclusiv UML, MOF și CWM;
aliniază arhitectural UML, MOF și XML Metadata Interchange (XMI), astfel încât interschimbarea modelului să fie complet acceptată;
permite personalizarea UML prin Profile și crearea de noi limbaje (familii de limbaje) bazate pe același metalimbaj nucleu ca UML.
Infrastructura UML este reprezentată prin pachetele Biblioteca Infrastructură și Tipuri Primitive.
Figura 3.2 Pachetele Bibliotecii Infrastructură
Biblioteca Infrastructură cuprinde următoarele pachete:
pachetul Nucleu conține concepte de bază utilizate în metamodelare;
pachetul Profile definește mecanisme ce sunt utilizate pentru a personaliza metamodelele.
Conform UML 2.4, pachetul Tipuri Primitive cuprinde câteva tipuri primitive predefinite care sunt frecvent utilizate în metamodelare și este special proiectat având în vedere cerințele UML și MOF.
Superstructura UML se referă la pachetul UML, care este împărțit într-un număr de pachete, ce se ocupă cu modelare structurală și comportamentală.
Figura 3.3 Superstructura UML 2
Modelul
Un modelul este o instanță a metamodelului. Responsabilitatea principală a acestui nivel o reprezintă definirea limbajului necesar pentru descrierea unui domeniu de informație. Un model utilizator este o instanță a unui metamodel UML și conține elementele modelului, cât și instantaneele (snapshots) aferente instanțelor elementelor modelului(Figura 3.4).
Figura 3.4 Modelul este o instanță a metamodelului
Obiecte reale
Obiectele reale (run-time instances) sunt instanțe create în momentul execuției unui model. Instantaneele care sunt descrise în nivelul model sunt versiuni simplificate ale instanțelor din timpul executiei modelului.
Figura 3.5 Obiectul real este o instanță a modelului
Modelarea cazurilor de utilizare
Tehnica descrierii cerințelor noului sistem informatic prin cazuri de utilizare a fost introdusă de Ivar Jacobson în metodologia OOSE.
Diagrama cazurilor de utilizare descrie într-o formă accesibilă și concisă funcționalitatea sistemului. Funcționalitățile pe care trebuie să le îndeplinească noul sistem informatic sunt reprezentate în cadrul acestor diagrame. Modelul descris de diagramele cazurilor de utilizare împreună cu documentele care descriu fiecare caz de utilizare determinat se numește modelul cerințelor.
Principalele scopuri la care răspund cazurile de utilizare sunt:
descrierea cerințelor funcționale ale sistemului în termeni comuni utilizatorilor și echipei de dezvoltare;
constituirea cadrului de referință comun pe parcursul întregului proces de dezvoltare, trecând prin analiză, proiectare și implementare;
asigurarea abilității de a trasa și urmări permanent legătura dintre fiecare cerință formulată de utilizatori și maniera de realizare a acesteia prin clase, relații și operații;
formarea bazei pentru testarea și verificarea sistemului produs.
În diagrama cazurilor de utilizare sunt descrise relațiile dintre actori și cazurile de utilizare.
Un actor definește un set de roluri pe care utilizatorul unei entitati îl poate juca atunci când interacționează cu aceasta. Actorul poate fi reprezentat grafic sub forma unui omuleț stilizat (vezi Figura 3.6-a), sub forma unei clase având stereotipul «Actor» (vezi Figura 3.6-b) sau sub forma unei interfețe (vezi Figura 3.6-c).
Exemplu: Client, Funcționar, subsistemul pentru evidența mijloacelor fixe, etc.
Figura 3.6 Reprezentarea grafică a actorilor în UML
Între actori pot exista următoarele relații:
Generalizarea descrie o relație de moștenire dintre un actor și o versiune mai rafinată a acestuia.
Figura 3.7 Relația de generalizare între actori
Dependența este utilizată atunci când un actor (client) depinde de un alt actor (server).
Figura 3.8 Relația de dependență între actori
Cazul de utilizare reprezintă o unitate funcțională furnizată de un actor, ca răspuns la apariția unei eveniment. Cazurile de utilizare sunt descrise, de regulă, prin verbe și se reprezintă grafic prin elipse. Un actor se poate afla în asociere (se reprezintă grafic printr-o linie continuă) cu mai multe cazuri de utilizare.
Exemplu: Emitere factură, Încheiere contract etc.
Figura 3.9 Relația dintre actorul Furnizor și cazurile de utilizare Emitere factura și Încheiere contract
În afara de relația de asociere care se poate defini între un actor și un caz de utilizare, între cazurile de utilizare mai pot fi declarate următoarele tipuri de relații:
Generalizarea descrie o relație de moștenire dintre un caz de utilizare și o versiune mai rafinată a sa (Figura 3.10);
Figura 3.10 Exemplu de generalizare între cazuri de utilizare
Extensia descrie o relație dintre un caz de utilizare și un comportament opțional al său definit într-un alt caz de utilizare care este executat în anumite situații. Din punct de vedere grafic, extensia se reprezintă printr-o săgeată punctată având stereotipul «extend» și poate avea atașată condiția de executare a respectivului caz de utilizare (Figura 3.11);
Figura 3.11 Cazul de utilizare Primire factura poate fi extins la cazul de utilizare Înregistrare furnizor nou
Incluziunea reprezintă relația prin care un caz de utilizare implică existența altui caz de utilizare. Din punct de vedere grafic, incluziunea se reprezintă printr-o săgeată punctată având stereotipul «include» (Figura 3.12).
Figura 3.12 Cazul de utilizare Livrare marfuri include cazul de utilizare Verificare stoc
Mulți autori recomandă descrieri suplimentare pentru cazurile de utilizare. O astfel de descriere poate conține: denumirea cazului de utilizare, scopul, actorii, punctul inițial, punctul final, descriere derulare ș.a.
De exemplu, în Figura 3.13 este prezentată diagrama cazurilor de utilizare pentru evidența comenzilor primite de la clienți, în baza contractelor încheiate cu aceștia.
Figura 3.13 Diagrama cazurilor de utilizare pentru evidența comenzilor clienților
Modelarea statică
În vederea modelării structurale, UML dispune de următoarele diagrame:
diagrama claselor;
diagrama de compoziție a structurii;
diagrama obiectelor.
Diagrama claselor
Diagrama claselor asigură descrierea claselor, a atributelor, a operațiilor, precum și a relațiilor dintre clase. Conceptele de bază folosite în descrierea diagramei claselor sunt clasa, obiectul, atributul și operația.
Clasa
O clasă este un descriptor pentru un set de elemente cu structură, comportament și relații similare. Clasele sunt declarate în diagramele de clase, iar elemente ale acestora sunt utilizate în majoritatea diagramelor UML. Din punct de vedere grafic, o clasă conține trei compartimente:
Un compartiment pentru denumirea clasei. Acest compartiment, pe lângă numele clasei, mai poate conține și alte elemente suplimentare:
stereotipul clasei- este un cuvânt cheie opțional situat deasupra numelui clasei, încadrat de caracterele «»;
o listă de proprietăți care poate conține mai multe proprietăți sau valori etichetate delimitate prin acolade.
O clasă abstractă se poate indica fie prin notarea numelui cu caractere italice, fie prin specificarea proprietății {abstract}. Stereotipul și lista de proprietăți sunt opționale.
Figura 3.14 Compartimentul Nume pentru o clasă
Un compartiment pentru definirea proprietăților clasei;
Un compartiment pentru declararea operațiilor clasei.
Figura 3.15 Reprezentarea minimala (a) și maximală (b) a unei clase
O clasă poate avea ca stereotip:
clasa tip – este utilizată pentru a specifica domeniul de obiecte împreună cu operațiile aplicabile obiectelor, fără a defini implementarea fizică a acestora. O clasă tip poate să nu includă nici o metodă, dar poate să ofere specificații comportamentale pentru operațiile sale. Poate, de asemenea, să conțină atribute sau să participe la realizarea unor asocieri; acestea sunt definite doar în scopul de a specifica comportamentul operației tip-ului și nu reprezintă o implementare efectivă a datelor.
clasa de implementare – reprezintă varianta realizată (implementată) a clasei tip, într-un limbaj de programare. O clasă de implementare stabilește structura fizică a datelor (pentru atribute și asocieri) și metodele unui obiect. Atributele fizice și asocierile clasei de implementare nu trebuie să fie aceleași cu cele ale clasei tip.
Un obiect poate avea cel mult o clasă de implementare și se poate conforma mai multor clase tip.
În UML mai există și alte stereotipuri pentru clase, cum ar fi cele preluate din Objectory:
clase entități sau clase domeniu – descriu nucleul unui sistem și oferă informații despre entitățile persistente (furnizori, mărfuri etc. );
Figura 3.16 Exemplu de clasă entitate
clase de interfață – sunt acele clase care asigură interfața cu utilizatorul (formulare, casete de dialog etc.).
Figura 3.17 Exemplu de clasă de interfață
clase de control – coordonează comportamentul obiectelor în cadrul unei aplicații (exemplu: „Închidere cont”).
Figura 3.18 Exemplu de clasă control
Clasele care nu se pot instanția (care nu au obiecte, realizări) se numesc clase abstracte. Clasele abstracte se pot instanția numai prin intermediul claselor derivate.
De exemplu, clasele CHITANȚĂ, CEC, MARFĂ și MATERIALE sunt clase instanțiabile. Clasele DOCUMENTE și PRODUSE sunt clase abstracte.
Figura 3.19 Clase abstracte (b) și clase instanțiabile (a)
Atributul
Atributul este o caracteristică, o proprietate a unei clase. Descrierea unui atribut poate fi precedată de stereotipul acestuia (încadrat între «»).
Atributele unei clase pot fi:
simple – sunt atributele elementare (atomice).
Exemplu: NumărFactură, CodBancă.
compuse – sunt atributele formate din mai multe atribute elementare.
Exemplu: DataNasterii, Adresa.
derivate – sunt atributele care se obțin prin calcul.
Exemplu:ValoareFactură, StocFinal, SoldFinal.
Un atribut poate descrie întreaga clasă (astfel de atribute sunt numite atribute de clasă sau statice) sau fiecare instanță în parte (aceste atribute sunt numite atribute de instanță).
În raport cu o instanță (obiect), un atribut poate avea una sau mai multe valori. În primul caz, atributul este de tip monovaloare, iar în cel de-al doilea caz avem de-a face cu un atribut multivaloare. În UML, atributele multivaloare sunt colecții de următoarele tipuri:
Bag – colecție de elemente neordonate care admite valori duplicate;
Sequence – colecție ordonată cu elemente duplicate;
Set – colecție neordonată cu valori unice;
OrderedSet – colecție ordonată cu valori unice.
Sintaxa UML pentru descrierea unui atribut este următoarea:
[<vizibilitate>] [‘/’] <nume> [‘:’ <expresie_tip>] [‘[‘ <multiplicitate> ‘]’] [‘=’ <valoare_inițială>][‘{‘ <modificator > [‘,’ <modificator >]* ’}’]
unde:
<vizibilitate>- descrie gradul de vizibilitate al atributului. Această vizibilitate poate fi publică (+), privată (-), protejată (#) sau pachet (~). Implicit, vizibilitatea este considerată publică.
‘/’ – indică faptul că atributul este derivat (calculat)
<nume> – reprezintă denumirea atributului
<expresie_tip>- semnifică tipul atributului
<multiplicitate>- conține numărul de valori posibile, sub forma [min..max], pe care le poate avea atributul pentru o instanță a clasei. Multiplicitatea implicită este 1.
<valoare_inițială>- reprezintă valoarea implicită a atributului pentru un obiect nou creat.
<modificator > [‘,’ <modificator >]* – sunt proprietăți suplimentare ale atributului, separate prin virgulă. UML 2 propune următoarele proprietăți aplicabile atributelor:
read only – atributul poate fi doar citit;
union – atributul este o reuniune a subseturilor sale;
subsets <nume_atribut> – atributul este un subset al atributului precizat prin <nume_atribut>;
redefines <nume_atribut> – atributul redefinește un atribut moștenit (de la superclasă), identificat prin <nume_atribut>;
ordered – valorile atributului sunt ordonate;
unique – nu sunt admise valori duplicate (este aplicabilă atributelor multivaloare);
id – se referă la faptul că atributul este parte a identificatorului clasei
<restricție>- expresie prin care se definește o restricție de integritate.
Atributele statice sunt subliniate cu o linie continuă. De asemenea, un atribut poate fi precedat de stereotipul acestuia.
De exemplu, în Figura 3.20. sunt descrise clasele Client și Comandă, ambele având atribute private. Clasa Client este descrisă prin:
atributele nenule Cod și Denumire
atributul Comenzi care va conține, pentru fiecare obiect Client, o colecție ordonată de obiecte unice de tip Comandă.
Clasa Comandă este descrisă prin următoarele atribute:
Număr are valoare implicită 100 și acceptă doar valori mai mari ca zero
Data trebuie să respecte următoarea restricție: comenzile vor fi întocmite după data de 01/01/2009
ValoareComandă este un atribut derivat.
Figura 3.20 Reprezentarea atributelor în clase
Operația
Operațiile sunt proceduri care rezidă în obiect și determină modul în care acesta acționează atunci când primește un mesaj. Operațiile unei clase reflectă comportamentul acesteia. Ca și în cazul atributelor, operațiile pot fi statice (acționează doar la nivelul clasei) sau de instanță (acționează la nivelul fiecărui obiect). Operațiile statice vor fi subliniate cu o linie continuă.
Conform UML, sintaxa unei operații este următoarea:
[<vizibilitate>] <nume> ‘(‘ [<lista_parametrii>] ‘)’ [‘:’ [<tip_returnat>] [‘[‘ < multiplicitate> ‘]’][‘{‘ <proprietate-operație> [‘,’ <proprietate-operație>]* ‘}’]]
unde:
<vizibilitate>- poate fi publică (+), privată (-), protejată (#) sau pachet (~). Ca și în cazul atributelor, vizibilitatea implicită este publică.
<nume>- reprezintă denumirea operației.
<lista_parametrii> – conține parametrii transmiși operației, separți prin virgulă. Aceștia pot fi descriși în formatul:
[<direcție >] <nume parametru> ‘:’ <expresie_tip>
[‘[‘<multiplicitate>’]’] [‘=’ <valoare_inițială>] [‘{‘ <proprietate-parametru> [‘,’ < proprietate-parametru>]* ‘}’]
unde,
<direcție > – poate lua una dintre valorile:
in – indică faptul că valorile parametrilor se transmit în cadrul operației de către apelant (parametru de intrare);
out – indică faptul că valorile parametrilor sunt transmise către apelant (parametru de ieșire) ;
inout – indică faptul că valorile parametrilor se transmit în cadrul operației de apelant și apoi sunt transmise înapoi apelantului (parametru de intrare-ieșire);
<proprietate-parametru>[‘,’<proprietate-parametru>]* – indică proprietăți suplimentare pentru parametru
<tip_returnat> – reprezintă tipul de dată returnat de operație.
<proprietate-operație>[‘,’<proprietate-operație>]* – precizează alte proprietăți adiționale operației, dintre care cele mai utilizate sunt următoarele:
redefines <nume_operație> – indică o redefinire a operației moștenite având denumirea <nume_operație>;
query – semnifică o operație de consultare (selector), care nu modifică starea sistemului;
ordered – setul de valori returnat de operație este ordonat;
unique – operația returnează o colecție cu valori unice;
<restricție> – indică o restricție de integritate aplicabilă operației.
Pentru asigurarea unei securități a datelor este necesar ca atributele unei clase să fie declarate private, iar accesarea lor să se realizeze doar prin intermediul operațiilor (modificatori și selectori).
Exemplu: clasa Comandă are operații pentru salvare, pentru citirea numărului comenzii, pentru citirea datei comenzii, precum și pentru calculul valorii unei comenzi. De asemenea, clasa Comandă are și operația statică TotalValoareComenzi (returnează valoarea tuturor comenzilor emise/primite).
Figura 3.21 Reprezentarea operațiilor în cadrul unei clase
După cum am mai precizat, operațiile unei clase pot fi grupate în patru categorii:
constructori sunt operații care asigură instanțierea clasei (creează obiecte ale acesteia);
destructori sunt operații destinate distrugerii (eliminării) instanțelor;
modificatori sunt operații care permit modificarea valorilor deținute de atribute;
selectori sunt operații care returnează starea unui obiect.
Prin implementare, operațiile devin metode. O metodă este definită prin semnătură (denumirea operației, parametrii și tipul returnat) și corpul său (setul de instrucțiuni necesare execuției metodei). Operațiile care nu se pot implementa, se numesc operații abstracte. O operație abstractă va aparține fie unei clase abstracte, fie unei interfețe și este scrisă cu litere italice sau conține proprietatea {Abstract}.
Figura 3.22 Exemplu de clasă abstractă care conține o operație abstractă
Relații între clase
Definirea relațiilor între clase asigură colaborarea dintre obiectele unui sistem informatic. În UML, se pot defini următoarele tipuri de relații: asocierea, agregarea, generalizarea și dependența.
Asocierea reprezintă o legătură logică ce se stabilește între clase de obiecte. Din punct de vedere grafic, asocierea se reprezintă printr-o linie continuă între clasele asociate, poate avea un nume și, eventual, o săgeată care reprezintă sensul de citire al acesteia.
Exemplu: Clientul emite comanda.
Figura 3.23 Clase asociate
Extremitățile asocierii (AssociationEnd – vezi Figura 3.23) au rolul de a specifica proprietățile participării claselor respective la asociere. Aceste proprietăți sunt:
Multiplicitatea – descrie câte obiecte ale clasei atașate capătului de asociere se pot asocia unui obiect al clasei corespondente.
Multiplicitatea unei clase se reprezintă grafic în formatul:
Valoare minimă ..Valoare maximă
Exemple de multiplicități:
0..1 zero sau un obiect
1..1 minim un obiect, maxim un obiect
1 echivalentă cu 1..1
0..* zero sau mai multe obiecte
* echivalentă cu 0..*
1..* unul sau mai multe obiecte
2..10 între două și zece obiecte
4 echivalentă cu 4..4
Dacă nu se specifică explicit multiplicitatea este considerată 1..1.
Numele de rol – este opțional și semnifică funcția clasei la care este atașat capătul asocierii.
Figura 3.24 Multiplicități și roluri în cadrul unei asocieri
În exemplul prezentat în Figura 3.24, multiplicitățile au următoarele semnificații:
pentru capătul de asociere Client: câte obiecte client pot emite un obiect comanda (minim unul, maxim unul – 1..1)
pentru capătul de asociere Comandă: câte obiecte comandă sunt emise de către un obiect client (minim zero, maxim N – 0..*)
Navigabilitatea – precizează modul în care se poate „migra” între clasele asociate.
În exemplul prezentat în Figura 3.24, prin intermediul navigabilității se pot afla următoarele informații:
navigabilitatea capătului de asociere Client permite identificarea clientului care a emis o comandă;
navigabilitatea capătului de asociere Comandă asigură obținerea comenzilor emise de către un client.
Navigabilitatea poate fi:
Bidirecțională (implicit): parcurgerea unei asocieri se poate realiza din ambele sensuri. De regulă, se evită navigabilitatea bidirecțională deoarece conduce la implementarea unor informații derivate (redundante).
Unidirecțională: parcurgerea unei asocieri este permisă numai într-un sens, deci numai către o clasă.
Un capăt de asociere care permite navigabilitatea are atașată o săgeată, iar în caz contrar va conține simbolul X.
Exemple:
Figura 3.25 Reprezentarea navigabilitații într-o asociere
Analizând navigabilitățile din Figura 3.25 se pot trage următoarele concluzii:
Navigabilitatea este bidirecțională și nu este reprezentată explicit
Navigabilitatea este reprezentată explicit și este permisă numai dinspre Factură (unidirecțională)
Navigabilitatea este bidirecțională și este reprezentată explicit
Navigabilitatea nu este permisă în niciun sens
Navigabilitatea este considerată unidirecțională deoarece nu este reprezentată explicit cea a capătului de asociere Factură
Calificatorul – reprezintă un atribut sau un grup de atribute care servește la partajarea setului de obiecte ale asocierii de instanța calificată. Calificatorii sunt atribute ale asocierii și sunt folosiți pentru reducerea multiplicității capetelor de asociere.
Exemplul 1: Unei banci îi corespund mai multe persoane, dar prin utilizarea calificatorului se poate regăsi o singură persoană (vezi Figura 3.26).
Exemplul 2: Utilizarea calificatorului ID conduce la reducerea multiplicității capătului de asociere atașat clasei Persoană (vezi Figura 3.27).
Figura 3.26 Reprezentarea calificatorului într-o asociere
Figura 3.27 Reducerea multiplicității unei clase prin utilizarea calificatorului
Vizibilitatea – atunci când capătul de asociere permite navigarea, numele de rol poate fi prefixat cu domeniul de vizibilitate (Figura 3.28). Acest aspect este important, în special, în etapa de implementare pentru determinarea vizibilității atributului de legătură.
Figura 3.28 Reprezentarea vizibilității capătului de asociere
Proprietăți – capătul de asociere poate conține și alte proprietăți, încadrate între acolade, cum ar fi:
{Ordered} – dacă multiplicitatea unui capăt de asociere este mai mare decât 1, atunci instanțele clasei atașate pot fi ordonate în cadrul unei asocieri.
De exemplu, instanțele clasei Factură pot fi ordonate deoarece capătul de asociere atașat are multiplicitatea mai mare decât 1.
Figura 3.29 Reprezentarea proprietății Ordered
{Bag} – capătul de asociere este o colecție neordonată în care o instanță poate fi prezentă de mai multe ori.
De exemplu, în cazul în care un produs figurează într-o comandă la prețuri diferite, capătul de asociere aferent clasei Produse poate avea propietatea Bag.
Figura 3.30 Reprezentarea proprietății Bag
{Sequence} sau {Seq} – capătul de asociere este o colecție ordonată în care o instanță poate fi prezentă de mai multe ori.
De exemplu, dacă se dorește ordonarea produselor din Figura 3.30, capătul de asociere aferent clasei Produse are proprietatea Sequence.
Figura 3.31 Reprezentarea proprietății Sequence
{Subsets <numeAtribut>} – capătul de asociere este un subset al atributului specificat prin numeAtribut.
De exemplu, numele de rol ProduseAlimentareComandate și ProduseNealimentareComandate sunt subseturi ale numelui de rol ProduseComandate (vezi Figura 3.32).
{Union} – capătul de asociere este o reuniune a subseturilor sale.
În Figura 3.32, rolul ProduseComandate reprezintă o reuniune a subseturilor ProduseAlimentareComandate și ProduseNealimentareComandate.
Figura 3.32 Reprezentarea proprietății Subsets și Union
{Redefines <CapătAsociere>} – capătul de asociere este o redefinire a altuia, precizat prin <CapătAsociere>. Proprietatea este utilizată mai ales în cazul asocierilor în care sunt implicate clase derivate.
De exemplu, rolul ParticipăLaCurs trebuie redefinit în funcție de calitatea persoanei participante la curs: profesor sau student (Figura 3.33).
Figura 3.33 Reprezentarea proprietății Redefines
Orice altă proprietate aplicabilă atributelor, dacă extremitatea asocierii permite navigarea.
În funcție de numărul de clase participante, asocierile pot fi:
asocieri unare/reflexive – la realizarea acestor asocieri participă o singură clasă.
Figura 3.34 Reprezentarea asocierii unare/reflexive
asocieri binare – la realizarea acestor asocieri participă două clase corespondente.
Figura 3.35 Reprezentarea asocierii binare
asocieri n-are – la realizarea acestor asocieri participă mai mult de două clase. În cadrul acestor asocieri, liniile de legătură sunt conectate printr-un romb, iar multiplicitatea fiecărui capăt al asocierii descrie numărul posibil de instanțe atașate acestuia, când sunt cunoscute instanțele celorlalte extremități. În cazul acestor asocieri, multiplicitățile minime sunt de obicei 0.
De exemplu, multiplicitățile din Figura 3.36 sunt stabilite astfel:
Câte obiecte Factură corespund unei perechi de obiecte Marfă-Gestiune
Câte obiecte Marfă corespund unei perechi de obiecte Factură-Gestiune
Câte obiecte Gestiune corespund unei perechi de obiecte Factură-Marfă
Figura 3.36 Reprezentarea asocierii n-are
Clasa asociere descrie o asociere care are proprietățile unei clase. O clasă asociere poate avea relații proprii și apare atunci când asocierea poate fi descrisă prin atribute sau operații proprii. Clasa asociere este legată de asociere printr-o linie punctată și apare, de regulă, pentru asocierile de tip m÷n (asocieri cu multiplicități maxime egale cu n) . Numele asocierii, dacă este definit, trebuie să fie același cu cel al clasei asociere.
De exemplu, asocierea dintre clasele Factură și Marfă poate fi descrisă prin atributele Cantitate, Preț unitar și operația ValoareMarfă.
Figura 3.37 Reprezentarea clasei asociere
Agregarea reprezintă un caz particular al asocierii, de tip parte-întreg (ansamblu-subansamblu). Agregarea este simbolizată printr-un romb gol care este plasat la capătul de asociere corespunzător clasei întreg. Obiectele de tip parte pot aparține, la un moment dat, mai multor obiecte de tip întreg. Ca urmare, capătul de asociere atașat clasei întreg poate avea multiplicitatea *.
Agregarea poate fi:
Fixă – numărul și tipul componentelor sunt predefinite;
Variabilă – numărul de componente poate varia.
În funcție de numărul claselor participante, agregarea poate fi:
Recursivă – o componentă face referire la ea însăși.
De exemplu, o piesă poate fi folosită la construirea altei piese.
Figura 3.38 Reprezentarea agregării reflexive
Binară – când sunt prezente două clase, una reprezentând întregul, cealaltă reprezentând partea.
De exemplu, un automobil este construit din mai multe piese.
Figura 3.39 Agregare binară
Compoziția este un caz special al agregării. Compoziția apare atunci când obiectele clasei parte aparțin obiectelor clasei întreg, iar durata lor de viață coincide. Multiplicitatea capătului de asociere atașat clasei întreg nu poate fi mai mare decât unu, deoarece un obiect parte aparține cel mult unui obiect întreg la un moment dat. Clasa parte nu poate participa la alte agregări.
Din punct de vedere grafic, compoziția se reprezintă printr-un romb plin plasat la clasa întreg. Compoziția trebuie să îndeplinească următoarele reguli:
clasa parte nu poate exista independent de clasa întreg;
operațiile efectuate asupra clasei întreg au efect și asupra părților;
crearea unei instanțe a clasei întreg nu presupune și instanțierea părților;
instanțele părților vor avea durata de viață egală cu cea a obiectului întreg.
Ca și agregarea, compoziția poate fi recursivă sau binară.
Exemple:
1. Un apartament este compus din 1-3 camere. O cameră nu poate exista independent de un anumit apartament.
Figura 3.40 Reprezentarea compoziției
2. O comandă e compusă din mai multe produse comandate. Produsele comandate pot exista numai în raport cu o anumită comandă.
Figura 3.41 Reprezentarea compoziției
Generalizarea
Generalizarea este o relație de moștenire între o clasă și versiunile ei evoluate (specializări). Clasele generalizate se numesc clase de bază, superclase sau clase părinte, iar clasele specializate sunt numite subclase, clase derivate sau clase copil.
Generalizarea este asimetrică (dacă A este derivata lui B, atunci B nu poate fi derivata lui A) și nerecursivă (A nu poate fi derivata lui A). În UML, relația de generalizare este simbolizată printr-o linie continuă cu un triunghi gol îndreptat spre clasa de bază. Uneori, linia care leagă subclasa de superclasă poate fi însoțită și de o etichetă.
Figura 3.42 Reprezentarea generalizării
De exemplu, un furnizor poate fi intern sau extern (Figura 3.42), iar o persoană poate fi persoană fizică sau persoană juridică (Figura 3.43)
Figura 3.43 O altă reprezentare a generalizării
Generalizarea poate fi:
parțială (moștenire multiplă) – o subclasă este derivată din mai multe clase de bază;
separată (moștenire simplă) – subclasa provine dintr-o singură clasă de bază
;
completă – toate subclasele unei clase de bază sunt specificate explicit;
incompletă – nu sunt specificate (cunoscute) toate subclasele.
În UML sunt definite următoarele restricții referitoare la generalizare:
overlapping – un obiect al clasei de bază poate aparține mai multor clase derivate.
De exemplu, un partener poate fi atât debitor cât și creditor
Figura 3.44 Exemplu de generalizare cu restricția overlapping
disjoint – o instanță a clasei de bază aparține unei singure clase derivate
De exemplu, o persoana este fie persoană fizică, fie persoană juridică.
Figura 3.45 Exemplu de generalizare cu restricțiile disjoint și complete
complete – în relația de generalizare sunt specificate toate subclasele aferente clasei de bază (vezi Figura 3.45).
incomplete – relația de generalizare nu precizeză toate subclasele aferente clasei de bază.
De exemplu, o marfă se poate specializa în mărfuri alimentare, electrice etc.
Figura 3.46 Exemplu de generalizare cu restricția incomplete
Dependența este utilizată atunci când o clasă (client) depinde de o altă clasă (server). Dependența este un tip special de relație care presupune că modificarea unei clase (server) poate avea impact asupra comportamentului/stării altei clase (client). Relația de dependență se reprezintă printr-o săgeată punctată îndreptată dinspre client spre server, pe care se înscrie tipul dependenței.
În UML 2, există următoarele stereotipuri pentru dependențe:
call – o operație din client apelează o operație a furnizorului;
create – clientul creează instanțe ale furnizorului;
derive – descrie relația prin care clientul este derivat (poate fi obținut) din furnizor;
instantiate – una sau mai multe operații din client creează instanțe ale furnizorului;
rafine – reprezintă o legătură dintre o entitate și o versiune rafinată (derivată) a acesteia, aflată pe un nivel mai înalt de detaliere;
substitute – sursa (clientul) poate substitui, în cursul execuției aplicației, furnizorul; substituția nu implică o moștenire a structurii, ci numai o interfață comună a celor două elemente;
trace – se referă la o relație între două elemente cu același înțeles, dar aflate în modele diferite;
use – implementarea clientului este condiționată de existența furnizorului;
realize – clientul constituie o implementare a furnizorului.
Spre deosebire de asocieri care sunt întotdeauna instanțiabile, dependențele nu presupun întotdeauna instanțe.
Exemple:
Figura 3.47 Clasa Cursuri depinde de clasa Cursanti
Figura 3.48 Formularul Materiale depinde de sursa de date (tabelul Materiale)
Figura 3.49 Clasele B, C și D, din faza de proiectare depind de clasa A descrisă în faza de analiză
Interfețe
Interfața desemnează totalitatea operațiilor vizibile ale unei clase, componentă sau pachet. O interfață descrie doar partea vizibilă din structura unei clase. Interfața este o clasă abstractă pură, care are scopul de a grupa un set de metode ce sunt comune unor clase între care nu exista neaparat o relație de “rudenie” (moștenire). Deci, putem spune că interfața este specifică claselor între care există o legătură directă, dar și anumitor clase între care nu există o astfel de legătură. O interfață este o clasă fără atribute și cu toate operațiile definite numai prin semnătură, fără a conține corpul operațiilor. Este evidentă asemănarea dintre interfețe și clasele abstracte: ambele sunt neimplementabile. Operațiile unei interfețe sunt implementate diferit de către clasele care oferă acea interfață, numite și clase care implementează/realizează interfața respectivă.
De exemplu, clasele Contract și MarfaAlimentara conțin operația Valabilitate(). Această operație va returna, pentru ambele clase, numărul de ani în care este valabil contractul/marfa. Deci, ambele clase pot utiliza interfața Valabilitate.
Figura 3.50 Clase care folosesc aceeași interfață Valabilitate
În UML, interfața se poate reprezenta grafic în două variante:
extinsă – presupune utilizarea unei clase cu stereotipul «Interface», în care compartimentul pentru atribute rămâne vid;
restrânsă/sintetică- presupune utilizarea unui mic cerc etichetat cu numele interfeței. Cercul va fi legat, printr-o linie continuă, de clasa care va implementa interfața respectivă.
De exemplu, interfața Valabilitate este reprezentată grafic în ambele variante, în Figura 3.51.
Figura 3.51 Reprezentări ale interfeței Valabilitate
Interfețele pot face obiectul următoarelor tipuri de relații mai speciale:
generalizarea presupune că o interfață moștenește operațiile altei interfețe;
De exemplu, interfața unui formular MDI va moșteni de la interfața unui formular clasic toate operațiile acesteia.
Figura 3.52 Reprezentarea generalizării interfețelor
realizarea este o relație (de dependență) ce se stabilește între interfață și clasa care realizează interfața respectivă. În funcție de varianta de reprezentare grafică a interfeței, relația de realizare se reprezintă astfel:
în varianta extinsă, realizarea se reprezintă grafic printr-o linie punctată cu un triunghi atașat interfeței;
în varianta sintetică/restrânsă, realizarea este descrisă printr-o linie continuă ce leagă cercul interfeței de clasa care o realizează.
De exemplu, clasele Contract și MarfăAlimentară realizează interfața Valabilitate (Figura 3.53 și Figura 3.54)
Figura 3.53 Reprezentarea relației de realizare în varianta extinsă
Figura 3.54 Relația de realizare în varianta restrânsă
dependența dintre interfață și clasa care folosește sau solicită interfața respectivă. În funcție de varianta de reprezentare grafică a interfeței, relația de dependență se reprezintă astfel:
în varianta extinsă, este reprezentată ca o relație de dependență obișnuită, în care clasa ce utilizează sau solicită interfața depinde de aceasta
în varianta sintetică/restrânsă, dependența este reprezentată printr-o linie continuă, ce leagă clasa de interfața. În acest caz, interfața este descrisă printr-un semicerc.
De exemplu, să presupunem clasa DocumentPlată prin care se achită contravaloarea contractului. Clasa DocumentPlată depinde de interfața Valabilitate deoarece nu se pot efectua plăți pentru un contract expirat.
Figura 3.55 Reprezentarea relației de dependență în varianta extinsă
Figura 3.56 Reprezentarea relației de dependență în varianta restrânsă
Relații derivate
Se numesc relații derivate acele legături logice care pot fi deduse din alte relații. Chiar dacă nu adaugă informații semantice, ele pot fi prezente din motive de claritate sau de design. Denumirea unei relații derivate este prefixată de caracterul „/”.
Exemple:
1. Asocierea ClientContract este derivată deoarece clientul care a incheiat contractul poate fi aflat, indirect, prin asocierile genereaza și întocmește.
Figura 3.57 Reprezentarea grafică a unei relații derivate
2. Asocierea ClientProduse este derivată, deoarece ea poate fi aflată prin asocierile Conține și Întocmește.
Figura 3.58 O altă relație derivată
Restricții de integritate
Restricțiile de integritate sunt condiții care trebuie respectate de elementele unui model (atribute, operații, roluri, relații). Restricțiile de integritate pot fi exprimate în pseudocod sau OCL (Object Constraint Language), într-un limbaj de programare (C++, VB etc.) sau în limbajul natural. În UML, restricțiile de integritate sunt încadrate între acolade.
Exemple:
Toate contractele trebuie să fie încheiate după 1 ianuarie 2014. În plus, data expirării trebuie să fie mai mare decât data încheierii contractului, iar valoarea contractului trebuie să fie, evident, mai mare ca zero.
Figura 3.59 Restricții de integritate
O persoană este fie persoană fizică, fie persoană juridică :
Figura 3.60. Restricție de excluziune de roluri
Un cont poate avea fie rolul de sintetic, fie de analitic:
Figura 3.61 Reprezentarea unei restricții de excluziune în cadrul unei asocieri unare
Diagrama de obiecte
Diagrama de obiecte prezintă instanțele claselor, descrise in diagrama claselor, precum si relațiile dintre acestea. Diagrama de obiecte este mai puțin utilizată în proiectarea sistemelor informatice, deoarece ea reprezintă de fapt o instanță a diagramei claselor. O diagramă de clase poate conține și obiecte, dar dacă aceasta nu conține nicio clasă ea este de fapt o diagramă a obiectelor.
Așa cum s-a vazut și în subcapitolul 1.3.1, obiectele sunt instanțe ale claselor. Un obiect este descris asemănător clasei a cărei instanță o reprezintă, fiind omise însă operațiile acesteia. Obiectele se reprezintă grafic prin casete dreptunghilare cu două compartimente:
Un compartiment pentru numele obiectului. Notația obiectului derivă din notația clasei:
Nume_obiect : nume_clasă
Un compartiment pentru atribute. Acestea sunt definite conform sintaxei: numeAtribut:tip=valoare, unde tipul este opțional.
Obiectele, la fel ca și clasele, se pot reprezenta minimal sau maximal (vezi Figura 3.62).
Figura 3.62 Reprezentarea minimală (a) și maximală (b) a obiectelor
În exemplul din Figura 3.63 sunt prezentate obiecte ale claselor Factură, Marfă și MărfuriFacturate, precum și legăturile existente între acestea.
Figura 3.63 Reprezentarea obiectelor și a legăturilor dintre acestea (diagrama obiectelor)
Diagrama de structuri compozite
Această diagramă descrie structura internă a unui clasificator (clasă, componentă sau caz de utilizare), precum și interacțiunile acestuia cu alte părți ale sistemului. Diagrama de structuri compozite este asemănătoare diagramei claselor, cu precizarea că ea descrie părți individuale în loc de clase întregi. Diagrama de structuri compozite utilizează următoarele concepte:
Parte (part) – descrie un element format din una sau mai multe instanțe cuprinse într-un clasificator. Partea descrie rolul unei instanțe într-un clasificator.
Figura 3.64 Reprezentarea grafică a conceptului Parte
Port (port) – definește punctul de interacțiune dintre un clasificator și mediul cu care interacționează sau între comportamentul clasificatorului și părțile lui interne.
Figura 3.65 Reprezentarea grafică a conceptului Port
Colaborare (collaboration) – o colaborare este un tip de clasificator structurat în care rolurile și atributele cooperează pentru a defini structura internă a unui clasificator. Se va utiliza o colaborare atunci când se identifică rolurile și conexiunile care sunt necesare pentru a realiza un anumit obiectiv de colaborare.
Figura 3.66 Reprezentarea grafică a concepului Colaborare
UtilizareColaborare (CollaborationUse) – reprezintă o utilizare particulară a colaborării, prin care sunt descrise relațiile dintre proprietățile clasificatorului. Aceste relații pot fi legături de dependență și sunt folosite cu următoarele stereotipuri:
«represents» – când colaborarea este folosită într-un clasificator;
«occurrence» – când colaborarea reprezintă un clasificator.
Figura 3.67 Reprezentarea grafică a conceptului UtilizareColaborare
Conector (Connector) – este utilizat pentru a indica o legătură ce face posibilă comunicarea între două sau mai multe instanțe parte/port. Din punct de vedere grafic, conectorul se reprezintă printr-o linie continuă. Spre deosebire de asociere, care indică o legătură între orice instanță a clasificatorilor ce intră în relație, conectorul indică o legătură doar între instanțele care joacă rolul părților conectate.
Rol (Role binding) – fiecare element are rolul definit în colaborare. Din punct de vedere grafic, rolul se reprezintă printr-o linie punctată.
În exemplul de mai jos, sunt definite două colaborări: Tranzacție (Figura 3.68) și Tranzacție-Mărfuri (Figura 3.69). Tranzacție este folosită de două ori în definirea colaborării Tranzacție-Mărfuri și e o colaborare între două roluri: Vânzător și Cumpărător.
Figura 3.68 Colaborarea Tranzacție
Tranzacție-Mărfuri este o colaborare între trei roluri: Furnizor, Gestionar și Client. Specificația Tranzacție-Mărfuri este alcătuită din două colaborări Tranzacție, indicate prin elipsele punctate. Specificația Cumpărare indică o tranzacție în care vânzătorul este Furnizorul, iar cumpărătorul este Gestionarul. Specificația Vânzare indică o tranzacție în care vânzătorul este Gestionarul, iar cumpărătorul este Clientul.
Figura 3.69 Colaborarea Tranzacție-Mărfuri
Într-un alt exemplu, pornind de la diagrama claselor descrisă în Figura 3.70 se poate realiza diagrama de structuri compozite prezentată în Figura 3.71. O proprietate care se referă la o instanță ce nu e deținută de obiectul compozit se reprezintă printr-un dreptunghi cu linie întreruptă (vezi instanța Persoana din Figura 3.71).
Figura 3.70 Diagrama a claselor
Figura 3.71 Diagrama de compoziție a structurii
Modelarea dinamică
În cadrul diagramelor dinamice sunt reprezentate tipurile de evenimente/stări, actorii, obiectele participante și mesajele dintre actori care pot apărea în timpul funcționării sistemului. Modelul dinamic descrie comportamentul obiectelor ca răspuns la apariția unor evenimente.
Scenariile reprezintă instanțe ale cazurilor de utilizare și sunt folosite pentru:
înțelegerea cazurilor de utilizare;
determinarea claselor, a obiectelor;
determinarea legăturilor dintre obiecte;
înțelegerea modului în care responsabilitățile unui caz de utilizare sunt distribuite claselor, respectiv obiectelor.
Conform UML, modelarea dinamică a sistemelor informatice se poate realiza prin intermediul următoarelor diagrame:
diagrame de interacțiuni
(Interactions Diagrams);
diagrama de stare (State machine Diagram);
diagrama de activități (Activities Diagram).
Din categoria diagramelor de interacțiune fac parte :
diagrama de secvențe (Sequence Diagram);
diagrama de comunicare (Communication Diagram);
diagrama de sincronizare (Timing Diagram);
diagrama de ansamblu a interacțiunii (Interaction Overview Diagram).
De regulă,
aceste diagrame se vor întocmi pe baza cazurilor de utilizare și a scenariilor (vezi Figura 3.69):
Figura 3.72 Legăturile dintre cazurile de utilizare și diagramele dinamice
Diagrame de interacțiuni
Interacțiunile reprezintă un mecanism folosit în descrierea funcționalității sistemului infomatic. O interacțiune poate fi exprimată prin următoarele diagrame: diagrama de secvențe, diagrama de comunicare, diagrama de timp și diagrama de ansamblu a interacțiunii. În proiectarea unui sistem informatic unele diagrame pot fi opționale, cum ar fi, de exemplu, diagrama de timp (Timing Diagram).
Diagrama de secvențe
În cadrul digramelor de secvențe sunt descrise mesajele dintre obiecte, ordonate cronologic, pe durata de viață a acestora. Diagrama de secvențe prezintă două dimensiuni:
pe orizontală sunt prezentate obiectele participante la interacțiune
pe verticală se reprezintă durata de viață a obiectelor participante. Din punct de vedere grafic, durata de viață a obiectelor participante se reprezintă prin linii punctate.
Conform UML 2.5, diagramele de secvențe utilizează următoarele concepte:
Linia de viață – reprezintă un participant individual la interacțiune. Din punct de vedere grafic, linia de viață se reprezintă printr-un dreptunghi, care conține de obicei numele obiectului/clasei, urmat de o linie punctată ce semnifică durata de viață a participantului.
Figura 3.73 Obiecte participante cu durata lor de viață
Cadru – este un dreptunghi definit în jurul diagramei având numele interacțiunii scris în compartimentul plasat în colțul din stânga sus.
Figura 3.74 Reprezentarea grafică a conceptului cadru
Utilizare interacțiune – referă o interacțiune care este definită într-o altă diagramă de interacțiune. Din punct de vedere grafic, utilizare interacțiune se reprezintă ca un fragment combinat având operatorul ref.
Figura 3.75 Reprezentarea grafică a conceptului utilizare interacțiune
Fragmentul combinat – este o specializare a unui fragment de interacțiune și definește o expresie din cadrul acestuia. Un fragment de interactiune este o noțiune abstractă și reprezintă o parte a unei interactiuni generale. Conform UML, cele mai utilizate fragmente combinate sunt:
Fragmentul alternativ – descrie un fragment combinat ce reprezintă o alegere de comportament, în care cel mult un operand va fi ales. Operandul ales trebuie să conțină cel puțin o expresie logică ce va fi evaluată ca fiind adevărată în acest punct al interacțiunii. Fragmentul combinat alternativ folosește operatorul interacțiune alt.
Figura 3.76 Reprezentarea grafică a unui fragment combinat alternativ
Fragmentul opțiune – se referă la un fragment combinat ce reprezintă o alegere de comportament, conform căreia secvența de comportament se declașeaza doar dacă e îndeplinită condiția specificată. Un fragment opțiune este, din punct de vedere semantic, echivalent cu un fragment combinat alternativ care conține un operand ce are un conținut nevid, iar cel de-al doilea operand este vid. Fragmentul combinat opțiune folosește operatorul interacțiune opt.
Fragmentul repetitiv – descrie un fragment combinat destinat repetării anumitor secvențe de comportament. Fragmentul combinat repetitiv folosește operatorul interacțiune loop.
Fragmentul pauză – indică un fragmentul combinat ce reprezintă un scenariu de întrerupere, în sensul că operandul este un scenariu care este pus în aplicare în locul părții rămase din fragmentul de interacțiune. Fragmentul combinat pauză folosește operatorul interacțiune break.
Fragmentul paralel – se referă la un fragment combinat ce conține o fuziune paralelă între comportamentele operanzilor. Fragmentul combinat paralel folosește operatorul interacțiune par.
Stare invariantă – este o constrângere aplicată participanților la interacțiune. Se poate utiliza o varietate de constrângeri, ca de exemplu, valori ale atributelor sau variabilelor, stări interne sau externe etc. Din punct de vedere grafic, o stare invariantă este plasată pe durata de viață a participantului și se poate reprezenta în două moduri:
ca o restricție scrisă între acolade
cu ajutorul unui simbol de stare ce conține o restricție care verifică starea obiectului.
De exemplu, în Figura 3.77(a) atributul tipStare al obiectului factură trebuie să fie egal cu 0, iar în Figura 3.77(b) obiectul factură trebuie sa fie în starea Închisă.
Figura 3.77 Reprezentarea grafică a conceptului stare invariantă
Continuarea – este o modalitate de a defini continuări ale diferitelor ramuri ale unui fragment combinat alternativ. Din punct de vedere grafic, continuarea se reprezintă cu același simbol ca și stările, dar poate cuprinde mai multe linii de viață (vezi exemplele din Figura 3.84 și Figura 3.85).
Figura 3.78 Reprezentarea grafică a conceptului continuare
Poartă – reprezintă punctul de conectare al unui mesaj ce provine din afara fragmentului de interacțiune ce transmite un mesaj in interiorul interacțiunii. Porțile sunt conectate prin mesaje. În cadrul unei diagrame de secvențe se pot defini trei tipuri de porți, și anume:
porți formale pentru interacțiuni în general,
porți actuale pentru utilizările de interacțiune,
porți de expresie pentru fragmente combinate.
Figura 3.79 Reprezentarea grafică a conceptului poartă
Distrugerea instanței specificate – permite distrugerea instanței descrisă de linia de viață. Din punct de vedere grafic, distrugerea unui obiect participant se realizează folosind simbolul X.
Figura 3.80 Reprezentarea grafică a conceptului utilizat pentru distrugerea instanței specificate
Activare – presupune preluarea controlului de către un obiect participant, care coincide de cele mai multe ori cu începutul de execuție a unei acțiuni și durează până în momentul cedării controlului altui obiect. Din punct de vedere grafic, activarea se reprezintă cu ajutorul unui dreptunghi plasat pe durata de viață a obiectului participant la interacțiune. Un obiect activ se poate reactiva. Acest proces se numește activare recursivă (vezi Figura 3.83).
Constrângeri de durată – se referă la restricții ce pot fi aplicate asupra intervalului de timp care există între execuțiile elementelor unei diagrame de interacțiuni. Sintaxa folosită pentru definirea unei constrângeri de durată este următoarea:
{d min .. d max}
De exemplu, perioada de timp dintre momentul trimiterii mesajului SolicităMarfă și momentul primirii mesajului de răspuns ReturnMarfă, de către client, este de 1-2 secunde.
Figura 3.81 Reprezentare grafică a conceptului Constrângeri de durată
Mesaje/stimuli – reprezintă operații prin care obiectele comunică între ele. Un mesaj presupune existența unui obiect expeditor și a unui obiect receptor. Un mesaj se reprezintă prin săgeți, cărora le pot fi atașate următoarele elemente:
numele mesajului
un număr de secvență (1,2,…. ; a,b,…..)
Cele mai importante tipuri de comunicații ce pot fi utilizate in cadrul diagramei de secvențe sunt descrise în Figura 3.82.
Figura 3.82 Tipuri de mesaje între obiecte în UML 2
În Figura 3.83 este prezentată o variantă generală a diagramei de secvențe, iar interacțiunile conținute de aceasta sunt explicate mai jos:
Obiectul User invocă operația ob1.Op1() a obiectului ob1.
Mai departe este descris un fragment combinat alternativ ce are următoarea structură: dacă este îndeplinită condiția1 se creează obiectul ob3; dacă este îndeplinită condiția2 se apelează operația ob2.Op1() a obiectului ob2, iar din cadrul acestuia se invocă operația ob3.op1() aferentă obiectului ob3. După aproximativ 1-2 secunde, se solicită din cadrul obiectului ob2 distrugerea obiectului ob3.
În continuare este prezentată o structura repetitivă, descrisă cu ajutorul unui fragment combinat repetitiv. Structura acestui fragment de interacțiune este următoarea: se apeleaza operația ob2.op2() atâta timp cât este indeplinită contiția3; după fiecare invocare a acestei operații se așteaptă un răspuns.
Invocarea operației ob1.op2() conduce la o activare recursivă a obiectului ob1. După această secvență de interacțiune, obiectul ob1 solicită distrugerea obiectului ob2, iar obiectul user solicită operația ob1.Op3(), la care primește un răspuns.
Figura 3.83 Reprezentarea generală a unei diagrame de secvențe în UML 2
De exemplu, în Figura 3.84 este prezentată diagrama de secvențe pentru conectarea la un sistem informatic. În cadrul acestei diagrame sunt definite următoarele variabile :
– user și parola pentru accesul la sistemul informatic,
– accesSistem care va conține răspunsul sistemului la validitatea datele de conectare (true sau false).
Datele de acces sunt introduse în cadrul formularului FrmAcces. După ce utilizatorul alege opțiunea Login, sistemul face o verificare a datelor de conectare folosind funcția Verifică. În final, i se comunică utilizatorului dacă are sau nu acces la sistem.
Figura 3.84 Diagrama de secvențe pentru accesul la sistemul informatic
În Figura 3.85 este prezentată diagrama de secvențe pentru adăugarea unui furnizor. Pentru verificarea accesului la sistem se utilizează interacțiunea UserAcces descrisă în Figura 3.84. Dacă se are acces la sistem, utilizatorul introduce datele furnizorului nou în cadrul formularului FrmFurnizori și confirmă aceste date. Se creează un obiect Furnizor, după care datele introduse în formularul FrmFurnizori sunt atribuite proprietăților obiectului nou creat cu ajutorul operației IncarcaDate. Dacă obiectul Furnizor nou creat nu există în cadrul colecției de furnizori (verificarea se realizează cu ajutorul funcției Exista), atunci acesta este adaugat în ColFurnizori. După aceea, i se comunică utilizatorului că procesul de confirmare a datelor s-a incheiat cu succes. Dacă obiectul Furnizor nou creat există în cadrul colecției de furnizori, atunci acesta este inițializat și i se comunică utilizatorului că procesul de confirmare a datelor nu s-a desfașurat cu succes. În final, utilizatorul închide formularul FrmFurnizori și, cu această ocazie, se distruge și obiectul Furnizor. În cazul în care nu se are acces la sistem, nu se declanșează nicio interacțiune.
Figura 3.85 Diagrama de secvențe pentru adăugarea unui furnizor
Diagrama de comunicare
Diagrama de comunicare (denumită diagrama de colaborări în UML 1.x) descrie obiectele participante la interacțiune și mesajele dintre acestea. O interacțiune dintre două obiecte participante (lifeline) este reprezentată grafic cu o linie având atașată o expresie de secvență și o săgeată. Săgeata indică direcția de comunicare.
Figura 3.86 Reprezentarea generală a unei diagrame de comunicare
O expresie de secvență are următorul format:
secvență '.' . . . ':' nume_mesaj
Secvență indică ordinea de apariție a mesajelor în cadrul interacțiunii si are următoarea sintaxă:
[ integer [ nume ] ] [ recurență ]
unde,
Integer – indică ordinea secvențială a mesajului.
Exemplu: 1.1, 1.2, 2, 2.1, 2.2
Nume – definește un fir de execuție concurent. Mesajele al căror nume diferă sunt concurente la acel nivel de imbricare.
Exemplu: mesajele 1.1a și 1.1b sunt concurente în secvența 1.1
Recurență – definește o execuție condiționată sau iterativă a mesajelor în funcție de o expresie logică. În acest sens, UML oferă următoarele opțiuni:
[condiție] – indică o clauză condițională
*[clauză iterativă] – se referă la o clauză iterativă cu o execuție secvențială a mesajelor
*||[clauză iterativă] – presupune o clauză iterativă cu o execuție concurentă a mesajelor
Nume_mesaj indică numele mesajului transmis de către obiectul expeditor obiectului destinatar.
Exemple:
1 [Year(DataFactura)=2015]: AdaugaFactura() – operația AdaugaFactura() se execută numai dacă anul emiterii facturii este 2015.
1.1a *[i:=1..10]: Caută(ColFacturi.Item(i)) – Caută() va fi executată in mod secvențial de 10 ori
1.2a *||[i=1.. 10]: Caută(ColFacturi.Item(i)) – 10 mesaje Caută() vor fi trimise simultan
1.3 *: Afișează() – mesajul Afișează() va fi repetat de un număr nespecificat de ori
Pentru a prezenta efectul mesajelor asupra obiectelor se pot folosi următoarele cuvinte cheie:
{new} pentru obiecte sau legături create în timpul execuției
{destroyed} pentru obiecte sau legături distruse în timpul execuției
{transient} pentru obiecte sau legături create și apoi distruse în timpul execuției.
În Figura 3.87 este prezentată diagrama de comunicare pentru adăugarea unei facturi.
Figura 3.87 Diagrama de comunicare pentru adăugarea unei facturi
Dialogul dintre actor (gestionar) și sistem are loc prin intermediul interfeței FormFacturi. Gestionarul introduce datele facturii în formular (1), iar în urma confirmării (2), dacă factura este emisă după anul 2015, se creează obiectul factură (3). Acesta este adăugat în colecția facturi (4), doar dacă nu există deja (VerificaFactura()=False).
Diagrama de ansamblu a interacțiunilor
Aceste diagrame definesc interacțiunile prin alte variante ale diagramelor de activități/secvențe, asigurând astfel o imagine de ansamblu asupra structurii de control. Structura de control se referă la ordinea în care fiecare instrucțiune/procedură a unui program este executată sau evaluată. Diagramele de ansamblu a interacțiunilor se axează pe imaginea de ansamblu a structurilor de control în cadrul cărora nodurile sunt interacțiuni (Interactions) sau utilizări interacțiune (IntractionUses). În cadrul acestor diagrame nu sunt prezentate detalii cu privire la liniile de viață sau mesajele dintre obiecte.
Diagramele de ansamblu a interacțiunilor sunt specializări ale diagramelor de activtăți/secvențe și se caracterizează prin următoarele aspecte:
Utilizează notațiile diagramei de activități, unde nodurile obiect sunt interacțiuni sau utilizări interacțiune.
Reprezintă o modalitate de a descrie interacțiunile făcând abstracție de mesaje și linii de viață.
În forma de bază, toate activitățile sunt utilizări interacțiune.
Fragmentele combinate alternative sunt reprezentate cu noduri de decizie și noduri joncțiune corespunzătoare.
Fragmentele combinate paralele sunt reprezentate cu noduri bifurcație și noduri joncțiune corespunzătoare.
Figura 3.88 Diagramă de ansamblu a interacțiunilor pentru adăugarea facturilor
De exemplu, dacă în cadrul iteracțiunii Login, datele de conectare introduse sunt corecte, atunci utilizatorul poate adăuga noi facturi prin intermediul utilizării interacțiunii Adaugă factură. Diagrama de secvențe Adaugă factură este prezentată în Figura 3.89. Diagrama de secvențe Login este realizată utilizând concepte de timp.
Figura 3.89 Diagrama de secvențe pentru adăugarea unei facturi
Diagrama de sincronizare
Diagramele de sincronizare sunt utilizate pentru a descrie interacțiunile în raport cu constrângerile temporale. Aceste diagrame prezintă comportamentul obiectelor participante la interacțiune într-o anumită perioadă de timp.
Conform UML 2.5, conceptele principale utilizate în cadrul diagramelor de sincronizare sunt următoarele:
Linia de viață reprezintă un participant individual la interacțiune. Din punct de vedere grafic, linia de viață se reprezintă sub forma unui dreptunghi care conține, de regulă, numele clasificatorului sau al instanței care îl reprezintă.
Figura 3.90 Linia de viață pentru diagrama de sincronizare
Mesajul. În cadrul diagramei de sincronizare se pot folosi mesaje variate, în funcție de tipul lor (vezi Figura 3.82).
Eticheta mesajului. Etichetele sunt doar notații stenografice utilizate pentru a preveni apariția confuziei în cadrul diagramelor, datorată mesajelor care intersectează liniile de viață. O etichetă semnifică întreruperea unui mesaj și continuarea lui de la o altă etichetă cu aceeași denumire.
Figura 3.91 Reprezentarea grafică a etichetelor
Starea sau condiția liniei de timp reprezintă starea clasificatorului/atributului participant sau o serie de condiții testabile, cum ar fi o valoare distinctă sau enumerabilă. O stare poate fi continuă sau nu, în funcție de schimbările prin care trece clasificatorul/atributul participant.
Figura 3.92 Starea sau condiția liniei de timp
Schimbarea unei stări este cauzată de cele mai multe ori de primirea unui mesaj, dar pot apărea situații când ea este provocată de o constrângere de durată (vezi Figura 3.93) sau o restricție de timp (vezi Figura 3.94).
De exemplu, obiectul Form se află în starea Activ între 1 și 5 minute.
Figura 3.93 Contrângere de durată
În Figura 3.94, datorită restricției de timp, obiectul Form intră în starea Activ între orele 7:00am și 7:15am.
Figura 3.94 Restricție de timp
Valoarea generală a liniei de viață arată valoarea elementelor conectabile ca funcție de timp. Valoarea este descrisă sub formă de text, iar intersectarea reflectă evenimentul care determină schimbarea valorii.
Figura 3.95 Valoarea generală a liniei de viață
Distrugerea instanței specificate permite distrugerea instanței descrisă de linia de viață.
Figura 3.96 Distrugerea instanței specificate
În Figura 3.97 este prezentată diagrama de sincronizare pentru accesul unui utilizator la sistemul informatic. Această diagramă se bazează pe diagrama de secvențe Login descrisă în Figura 3.88.
Figura 3.97 Diagramă de sincronizare cu mai multe linii de viață si cu mesaje
Linia de viață Utilizator este descrisă în diagramele de sincronizare prezentate în Figura 3.98 și în Figura 3.99.
Figura 3.98 Linia de viață compactă cu stări
Figura 3.99 Linia de viață pentru un obiect distinct
Diagrama de stare
În UML 2.4 sunt definite două tipuri de diagrame de stări:
Diagrama de stare de comportament: descrie comportamentul unei părți din sistem
Diagrama de stare de protocol: este o specializare a diagramei de comportament și este folosită pentru a exprima protocolul utilizat sau ciclul de viață al unui clasificator.
Diagrama de stare este folosită pentru reprezentarea stărilor prin care trece o entitate (clasă, caz de utilizare, actor etc), datorită evenimentelor care pot apărea în cursul funcționării sistemului. Diagrama de stare se realizează, de regulă, pentru clasele definite în diagrama claselor.
Diagramele complexe pot fi descompuse în subdiagrame (stări compuse).
O diagrama de stare utilizează următoarele concepte:
Starea inițială (constructorul): indică punctul inițial de start, pentru o mașină de stare sau substare;
Figura 3.101 Stare inițială
Starea finală (destructorul): indică executarea completă a unei mașini de stări;
Figura 3.102 Stare finală
Punctul de intrare este plasat, de regulă, pe marginea unei stări, a unei diagrame de stări sau a unei stări compuse și reprezintă zona de intrare în cadrul acestora;
Figura 3.103 Punct de intrare
Punctul de ieșire este plasat, de regulă, pe marginea unei stări, a unei diagrame de stări sau a unei stări compuse și reprezintă zona de ieșire din cadrul acestora;
Figura 3.104 Reprezentare grafică Punct ieșire (aborted)
Acțiune semnal trimis (Send signal action) creează o instanță semnal, ce poate genera o tranziție sau o acțiune;
Figura 3.105 Reprezentare grafică SendSignalAction
Acțiune semnal recepționat (Receive signal action) semnifică primirea unui semnal acțiune;
Figura 3.106 Reprezentare grafică ReciveSignalAction
Decizia permite alegerea unei stări, în funcție de o condiție;
Figura 3.107 Reprezentare grafică Decizie
Acțiunea transformă un set de intrări într-un set de rezultate. Simbolul actiune trebuie să urmeze simbolului recepție semnal, dacă exista unul în acea tranziție.
Figura 3.108 Reprezentare grafică Acțiune
Evenimentul este un fapt ce se produce la un moment dat și transportă o informație către un obiect sau de la un obiect la altul. Evenimentul nu trebuie confundat cu operația care la generat!
Sintaxă: NumeEveniment(ListăParametrii)
Clasificarea evenimentelor:
1. După natura lor, evenimentele se împart în:
Evenimente timp – se referă la trecerea unui anumit interval de timp;
Exemplu: After(data) , When(data)
Evenimente mesaj- pot fi de două tipuri:
evenimente cerere- presupun invocarea unei operații de către un obiect sau chiar de către același obiect;
Exemplu: OnInsert(), etc.
evenimente semnal – constau în primirea unui semnal de la un alt obiect;
Exemplu: MouseClick(), KeyPress()
2. După locul apariției, evenimentele se împart în:
evenimente interne: sunt acele evenimente care apar în interiorul sistemului;
evenimente externe: sunt cele care acționează din afara sistemului;
Starea: este o abstractizare a valorilor atributelor și a legăturilor unui obiect. Starea reprezintă un răspuns al obiectului la un eveniment extern.
O stare se reprezintă grafic sub forma unui dreptunghi cu colțurile rotunjite (Figura 3.96) și conține următoarele compartimente:
un compartiment care va indica numele stării
un compartiment pentru activitățile interne: acest compartiment conține o listă internă de acțiuni sau operații în formatul nume_acțiune / expresie_acțiune
. În UML, se pot utiliza următoarele activități interne:
Entry: indică acțiunea care se va executa la intrarea în stare;
Do: precizează acțiunea care va fi executată în cadrul stării;
Exit: indică acțiunea executată la ieșirea din stare;
Include: identifică o substare invocată.
un compartiment pentru tranzițiile interne: acest compartiment conține o listă de tranziții interne, unde fiecare tranziție internă este descrisă în formatul unui trigger. Un trigger se referă la un eveniment, ce poate cauza execuția unui comportament asociat.
Figura 3.109 Reprezentarea general a unei stări
Figura 3.110 Reprezentarea stării Închidere cont
De exemplu, în Figura 3.97 este prezentată starea unui cont. La sfârșitul unui exercițiu financiar, un obiect Cont ajunge în starea Închidere cont. După efectuarea actualizărilor generate de activitățiile interne (Entry, Do, Exit), soldul final al contului devine, în exercițiul financiar următor, sold inițial (cont.ReinitializeazăSoldInițial).
Tranziția de stare
O tranziție de stare schimbă starea unui obiect datorită unui eveniment. Tranziția se poate declanșa odată cu încheierea acțiunilor (prelucrări generate de evenimente) sau activităților (anumite prelucrări interne) stării. Tranziția este reprezentată printr-o săgeată (de la starea sursă către starea destinație), căreia îi este atașată o etichetă de forma:
eveniment [conditie] / actiune
unde:
eveniment – reprezintă semnătura evenimentului care a generat tranziția
[condiție] – descrie expresia logică de apariție a evenimentului
acțiune – reprezintă operația care va fi executată la apariția evenimentului
Tranzițiile de stare pot fi:
Simple – sunt tranziții între două stări diferite.
De exemplu, când un client debitor își achită datoriile, pe data de 20 a fiecărei luni, devine client normal.
Figura 3.111 Exemplu de tranzitie simplă între două stări
Recursive – implică o singură stare.
De exemplu, dacă recepția este parțială, starea obiectului „NIR în curs” rămâne neschimbată până la terminarea activității de recepție a materialelor.
Figura 3.112 Exemplu de tranziție recursivă
Pentru stări concurente – o tranzițe concurentă poate avea multiple stări sursă și multiple stări țintă.
Exemplu: Din starea „Cont închis”, în urma evenimentului de redeschidere a contului, un obiect al clasei cont intră atât în starea „cont inițializat” cât și în starea „cont deschis”.
Figura 3.113 Exemplu de stari concurente
Pentru stări compuse – o starea compusă se poate descompune în mai multe substări concurente sau substări secvențiale.
Exemplu: În Figura 3.114 este prezentată starea compusă Stare Control care se descompune în substările secvențiale Deselectat și Selectat.
Figura 3.114 Exemplu de stare compusă din stări secvențiale
Pentru a concluziona, să presupunem diagrama de stare (Figura 3.102) pentru clasa Client. Un client poate să-și achite facturile primite prin intermediul documentelor de plată. Trebuie remarcată starea compusă Client debitor, în care rămâne un client, până când își achită toate facturile. O altă reprezentare a stării compuse Client debitor este descrisă în Figura 3.103.
Figura 3.115 Diagrama de stare pentru clasa Client
Figura 3.116 O altă reprezentare a stării compuse Client debitor
Diagrama de activități
Diagramele de activități sunt folosite pentru descrierea claselor de obiecte, a cazurilor de utilizare, a pachetelor sau a operațiilor, privite în raport cu dinamica sistemului. Conceptele de bază folosite în cadrul acestei diagrame sunt următoarele:
Acțiunea – reprezintă o etapă în execuția unui algoritm sau a unei proceduri. În UML, acțiunile mai sunt numite și stări-acțiuni (action state), pentru că acestea reprezintă operații ale stărilor. O acțiune este o etapă din cadrul unei activități. Acțiunile pot conține activități/tranziții interne. O acțiune poate fi descrisă:
într-un limbaj formal (OCL, pseudocod etc.)
într-un limbaj de programare (VB, C++ etc.)
în limbajul natural.
Figura 3.117 Reprezentarea acțiunii în diagrama de activități
În cadrul unei acțiuni se pot defini pre- și post-condiții locale (Figura 3.105).
Figura 3.118 Reprezentarea pre- și post-condițiilor locale în cadrul unei acțiuni
Tranziția (flux de control) de la o acțiune la alta se reprezintă printr-o săgeată și poate conține numele evenimentului și condiția de declanșare a acestuia. Un flux de control este o extremitate ce declanșează un nod activitate, după ce s-a încheiat un nod activitate precedent.
Figura 3.119 Reprezentarea tranziției
Nodurile de control- coordonează fluxul într-o activitate. În cadrul diagramelor de activități, descrise conform UML, se utilizează următoarele noduri de control:
Rezervor de date (DataStore) face referire la datele persistente. Reprezentarea grafică a rezervorului de date este prezentată în Figura 3.107.
Figura 3.120 Reprezentarea grafică a rezervorului de date
De exemplu, înscrierea unui student la o facultate presupune actualizarea bazei de date “Student”. Odată pe semestru, studenții înregistrați în baza de date intră în sesiune de examene.
Figura 3.121 Exemplu de utilizare a rezervorului de date
Acceptă acțiune eveniment (AcceptEventAction) este o acțiune care așteaptă apariția unui eveniment ce satisface o condiție specificată.
Figura 3.122 Reprezentarea grafică pentru acceptarea unei acțiuni eveniment (a) și pentru acceptarea unei acțiuni eveniment de timp (b)
De exemplu, cererea de anulare a ordonării va conduce la executarea acțiunii "Anulează Ordonare ".
Figura 3.123 Exemplu pentu acceptarea unei acțiuni eveniment
În contabilitate, la sfârșitul fiecărei luni, se întocmește balanța de verificare.
Figura 3.124 Exemplu pentu acceptarea unei acțiuni eveniment de timp
Acțiune semnal trimis (SendSignalAction) creează o instanță semnal, ce poate genera o tranziție sau o acțiune.
De exemplu, acțiunea "Creează comandă" generează instanța semnal "Întocmire comandă". Această instanță semnal poate genera acțiunea "Creează factură".
Figura 3.125 Acțiunea-semnal ÎntocmireComandă
Obiecte și fluxuri obiect. Un nod obiect este un nod de activitate, care indică o instanță a unui clasificator particular, posibil într-o stare particulară, ce poate fi disponibil într-un punct particular din cadrul activității. Nodurile obiect conțin valori în momentul execuției, care sunt conforme cu tipul specificat. Dacă tipul nodului obiect nu e specificat, atunci valorile pot fi de orice tip.
Figura 3.126 Notații pentru noduri obiect: obiect (a), nod obiect pentru transmisie conținând seturi (b), nod obiect pentru transmisie cu semnal tip (c)
Un flux obiect reprezintă o cale prin care obiectele sau informațiile pot naviga între componentele sistemului.
Figura 3.127 Exemplu de flux obiect
Un nod obiect mai poate fi descris în cadrul unei diagrame și prin intermediul unor pini atașați acțiunilor din cadrul fluxului.
Figura 3.128 O altă prezentare a exemplului descris în Figura 3.114
Întreruperea unei regiuni de activități se referă la un grup de activități ce pot fi întrerupte din execuție.
De exemplu, acțiunea "Deschidere factură" se execută până la închiderea ei, când controlul va fi preluat de acțiunea "Închidere factură". Dacă se anulează deschiderea facturii ("Cancel factură"), se întrerupe acțiunea "Deschidere factură", iar controlul va fi preluat de către acțiunea "Anulează factură".
Figura 3.129 Întreruperea unei regiuni de activități
De cele mai multe ori diagramele de activități conțin un punct de start care marchează inițierea și unul sau mai multe puncte finale care marchează încheierea secvenței de acțiuni. Pentru a se evita repetarea anumitor secvențe comune mai multor diagrame diferite, se pot defini subactivități (vezi Figura 3.117). Acestea simplifică elaborarea unei diagrame și reprezintă o secvență de acțiuni bine definită.
Figura 3.130 Reprezentarea grafica a subactivităților
Acțiunile pot fi grupate pe centre de responsbilități (swimlane) cărora le corespund clase, obiecte, unități organizaționale (compartimente ale unei societăți sau terțe persoane fizice/juridice). O acțiune va aparține unui anumit centru de responsabilitate, dar o tranziție poate trece dintr-un centru în altul.
Un astfel de exemplu este prezentat în Figura 3.118. Centrele de responsabilități sunt Furnizor, Aprovizionare și Depozit. Se observă gruparea activităților pe centre de responsabilități, precum și trecerea tranzițiilor dintr-un centru în altul.
Figura 3.131 Acțiuni repartizate pe centre de responsabilitate
Grafic, centrele de responsabilități mai pot fi reprezentate și prin includerea lor între paranteze rotunde în cadrul acțiunilor (Figura 3.119). În acest caz, acțiunile pot avea stereotipul «external».
Figura 3.132 Includerea centrelor de responsabilități în cadrul acțiunilor
În elaborarea diagramelor de activități se poate ține cont și de detaliile de implementare necesare realizării/implementării acestora [CozgareaG]. În acest sens, se au în vedere variabilele, operațiile/metodele etc. necesare pentru implementarea acestor diagrame.
De exemplu, pentru cazul de utilizare AdaugaFurnizor se poate elabora diagrama de activități utilizând detaliile de implementare. În cadrul diagramei sunt declarate următoarele variabile (acțiunea “Declarare variabile”):
pFurnizor este o variabila de tip Furnizor. Furnizor este o clasă implementată în cadrul sistemului și are metodele Salvează, AdaugaInColectie ș.a.
ConfirmareDate este o variabilă de tip Boolean
Dacă datele completate (acțiunea “Introducere date furnizor”) sunt confirmate (ConfirmareDate=True), atunci se verifică în cadrul colecției furnizorilor dacă există un furnizor care are codul identic cu cel introdus de către utilizator (ExistaFurnizor(Cod)). Dacă nu există un astfel de furnizor (ExistaFurnizor(Cod)=False), atunci se creează un obiect nou de tip furnizor (pFurnizor=NEW FURNIZOR). Se realizează salvarea datelor introduse de către utilizator în cadrul obiectului nou creat (pFurnizor.Salveaza(Cod, Denumire,Adresa)), iar apoi acesta este adăugat în cadrul colecție furnizorilor (pFurnizor.AdaugaInColectie). Acest lucru se întâmplă dacă nu se anulează operația de adăugare a furnizorului. În caz contrar (este acceptată acțiunea eveniment Cancel), obiectul furnizor nou creat nu mai este adăugat în cadrul colecției furnizorilor, iar variabilele sunt resetate.
Figura 3.133 Diagrama de activități orientată spre implementare pentru cazul de utilizare AdaugăFurnizor
Gestionarea modelelor
Gestionarea modelelor se referă la gruparea elementelor de modelare în pachete, subsisteme și modele.
În cazul sistemelor complexe, pentru o mai bună organizare a modelelor, se impune gruparea elementelor de modelare în pachete și subsisteme.
Structurarea în pachete
Pachetul este o grupare de elemente de modelare căreia i se atribuie un nume. Pachetele trebuie să aibe nume unice și pot conține diagrame de clase (pachetele de clase reflectă viziunea logică a sistemului), pentru a putea urmării arhitectura sistemului. Criteriul de grupare al elementelor de modelare în pachete rămâne la latitudinea utilizatorului.
Grafic, un pachet se reprezintă sub forma unui dreptunghi, care are atașat o etichetă în care se precizează numele și eventual stereotipul acestuia.
Figura 3.134 Reprezentarea pachetelor
Între pachete pot exista relații de dependență, cu următoarele stereotipuri:
«import» – elementele pachetului importat devin vizibile pentru pachetul importator (vezi Figura 3.122);
«access» – permite utilizarea elementelor dintr-un alt pachet prin precizarea căii de acces (vezi Figura 3.122);
«merge» – este folosit atunci când conținutul unui pachet poate fi extins cu conținutul altui pachet. Stereotipul «merge» indică o relație directă între două pachete și conduce la combinarea elementelor acestora.
Figura 3.135 Reprezentarea grafică a dependențelor «import» și «access»
De exemplu, pachetul Z se află în relații de dependență (Figura 3.123), având stereotip «merge», cu pachetele X și Y. În baza acestor relații, conținutul pachetului Z va fi o combinare a elementelor pachetelor X și Y (Figura 3.124)
Figura 3.136 Reprezentarea grafică a dependenței cu stereotip «merge»
Figura 3.137 Conținutul pachetului Z obținut pe baza relațiilor de tip «merge» cu pachetele X și Y
Figura 3.138 Structurarea în pachete, a activității de aprovizionare cu mărfuri
De exemplu, în Figura 3.125 este prezentat pachetul Aprovizionare care include pachetele Facturare, Mărfuri și Recepție. Între acestea din urmă, există relații de dependență cu stereotip «access».
Structurarea în subsisteme
Subsistemul este un grup de elemente de modelare, care reflectă o unitate de comportament în sistemul fizic [Zaharie02]. Un subsistem este format din trei compartimente:
unul în care sunt precizate operațiile (nu este etichetat)
unul pentru definirea elementelor de specificare (Specification Elements). Acestea sunt formate din operații ce acționează asupra subsistemului, cazuri de utilizare, diagrame de stări etc.
unul pentru definirea elementelor de realizare (Realization Elements). Acestea sunt formate din elemente de specificare reprezentate cu ajutorul relației de realizare (o linie punctată cu un triunghi gol).
Figura 3.139 Reprezentarea minimală (a) și maximală (b) a subsistemelor
Subsistemele comunică între ele numai prin intermediul interfețelor.
De exemplu, un sistem informatic de contabilitate generală poate fi format din următoarele subsisteme:
– subsistem pentru gestiunea stocurilor;
– subsistem pentru evidența mijloacelor fixe;
– subsistem pentru evidența salariilor;
– subsistem pentru contabilitatea financiară;
Figura 3.140 Împărțirea sistemului de contabilitate generală pe subsisteme
Structurarea în modele
Modelele conțin elemente de modelare specifice unui sistem fizic privit dintr-un anumit punct de vedere. Modelele se pot reprezenta împreună cu pachetele și subsistemele. Modelele se reprezintă grafic asemănător pachetelor.
Figura 3.141 Reprezentarea modelelor
Legăturile dintre modele sunt reprezentate prin relații de dependență, în general, având stereotip rafinare sau import.
De exemplu, modelul Client depinde de modelul Business (Figura 3.129).
Figura 3.142 Două modele reprezentând părți ale sistemului
Diagrame de implementare
Diagramele de implementare prezintă aspecte referitoare la structurile de program, la arhitectura sistemului. UML propune, în acest sens, două diagrame:
diagrama de componente
diagrama de amplasare
Diagrama de componente
Diagrama de componente descrie aspecte referitoare la structura programelor, la dependențele dintre modulele unui sistem informatic. Diagrama de componente este asemănătoare diagramei de pachete. Diferența dintre ele constă în bogăția semantică oferită de diagrama de componente. În diagramele de componente, elementele modelului sunt private, în timp ce diagrama de pachete descrie doar elementele publice. O diagramă de componente are un nivel mai ridicat de abstractizare decât diagrama claselor.
Componenta se referă la un modul al unui sistem informatic și se reprezintă grafic sub forma unui dreptunghi, având stereotipul «component» sau având doar simbolul specific. O componentă se poate implementa prin una sau mai multe clase.
Figura 3.143 Reprezentarea grafică a unei componente
Obținerea informațiilor necesare unei componente, dintr-o altă componentă, se poate realiza cu ajutorul interfețelor.
Componentele au interfețe pe care le suportă (provided) și interfețe pe care le cer (required) de la alte componente. Componentele nu depind direct de alte componente, ci depind de interfețele pe care acestea le suportă. Astfel, o componentă poate fi substituită cu o altă componentă care suportă interfețele potrivite.
De exemplu, componenta Facturare solicită interfața Plată și realizează interfețele IntrareFactură și FacturareElemente.
Figura 3.144 Componenta Facturare
O componentă are două vederi:
vederea externă (black-box) este realizată cu ajutorul proprietăților și operațiilor vizibile la nivel public. Pentru a defini legătura între participanții dintr-o colaborare (de exemplu, cazuri de utilizare, activități sau specificații de interacțiune), comportamentele acestora pot fi asociate cu interfețe sau conectori. Cuplarea componentelor într-un sistem poate fi definită prin utilizarea dependențelor între interfețele acestora.
vederea internă (white-box) este descrisă cu ajutorul proprietăților private și cu realizarea de clasificatori. Această vedere arată cum un comportament extern este realizat la nivel intern. Legatura dintre vederea internă si cea externă se poate realiza cu ajutorul dependențelor sau utilizând conectorii delegati la parțile interne.
De exemplu, în Figura 3.132 este prezentată vederea externă (black-box), iar în Figura 3.133 este descrisă vederea internă (white-box) a componentei Facturare. În cadrul vederii externe sunt descrise doar interfețele cerute (Plată) și furnizate (IntrareFactura și FacturareElemente). În cadrul vederii interne, pe langă interfețele cerute și furnizate, sunt descrise și clasele care realizează componenta Facturare (Factură, LinieFactură), precum și artefactele (clasele implementate în VisualBasic.Net, Factura.vb și LinieFactura.vb) specifice acesteia.
Figura 3.145 Vederea externă (black-box) a componentei Facturare
Figura 3.146 Vederea internă (white-box) a componentei Facturare
În Figura 3.134 este reprezentată componenta Facturare împreună cu interfețele IntrareFactură, FacturareElemente și Plată, descrise în detaliu.
Clasificatorii interni care realizează comportamentul unei componente pot fi reprezentați în cadrul acesteia (Figura 3.135).
Figura 3.147 Reprezentarea extinsă a interfețelor realizate și cerute
Un conector delegat este un conector care leagă contactul extern al unei componente (specificat de porturile sale) de realizarea internă a comportamentului (Figura 3.136). Un conector de asamblare este un conector între două componente, în care o componentă furnizează serviciile cerute de o altă componentă.
Figura 3.148 O reprezentare alternativă a componentei
În Figura 3.136 este descrisă structura internă a componentei FacturareMarfă. Aceasta este formată din alte componente (Facturare, Document și Marfă), legate între ele prin conectori de asamblare. De asemenea, sunt reprezentați și conectorii delegați prin care se realizează contactul extern al componentei cu componentele interne.
Figura 3.149 Vederea internă (white-box) a structurii componentei FacturareMarfă
Verifica in documentatie! S-ar putea sa fie gresit exemplul!
Între componentele identificate în cadrul unui sistem informatic se pot stabili relații de dependență. Aceste dependențe se pot reprezenta cu ajutorul interfețelor (o componentă cu o interfața solicitată depinde de componenta care furnizează acea interfață – vezi Figura 3.137) sau direct între componente (vezi Figura 3.138).
Figura 3.150 Reprezentarea dependențelor dintre componente prin intermediul interfețelor
Figura 3.151 Reprezentarea dependențelor generale între componente
Componentele pot utiliza următoarele stereotipuri standard:
«subsystem» în modelul de componente la scară largă
«specification» și «realization» în modelul de componente cu specificații distincte și definiții de realizare, unde o specificație are multiple realizări.
Diagrama de amplasare (Deployment diagram)
Diagrama de amplasare descrie configurația echipamentelor în cadrul sistemului, precum și repartizarea componentelor și a proceselor pe acestea. Diagrama de amplasare se reprezintă printr-un graf, ale cărui noduri reprezintă resurse de procesare a datelor implicate [Zaharie02]. Conceptele de bază utilizate în cadrul acestei diagrame sunt:
Artefactul reprezintă specificația unui element fizic de informație, care este folosit sau produs în procesul de dezvoltare de software sau în funcționarea unui sistem informatic.
Exemple: fișiere sursă, scripturi sau fișiere executabile, tabele din cadrul unui sistem de baze de date etc. (Vezi Figura 3.140)
Figura 3.152 Reprezentarea grafică a unui artefact
De exemplu, componenta Factură se implementează, în VB.NET, sub forma unei clase.
Figura 3.153 Reprezentarea dependenței dintre artefact și componentă.
Nodul este o resursã I.T. pe care artefactele pot fi desfãsurate pentru executare.
Figura 3.154 Reprezentarea grafică a nodului
Prin relația de dependență, având stereotipul «deploy», dintre nod și artefacte se indică posibilitatea unui nod de a suporta tipuri de componente (vezi Figura 3.142). Acest aspect mai poate fi descris și prin includerea componentelor în cadrul nodurilor. De asemenea, artefactele pot fi desfășurate și pe instanțe de noduri (vezi Figura 3.143). Nodurile pot fi conectate între ele prin asociere.
Figura 3.155 Reprezentarea asocierilor dintre noduri
Figura 3.156 Desfășurarea artefactelor în cadrul unei instanțe a unui nod
Specificația de desfășurare reprezintă un set de proprietăți care determină execuția parametrilor unei componente artefact, desfășurate într-un nod.
Exemple de stereotipuri ce se pot adăuga la specificațiile de desfășurare:
«concurrencyMode» care poate avea valorile {thread, process, none};
«transactionMode» care poate avea valorile {transaction, nestedTransaction, none}.
Figura 3.157 Specificație de desfășurare (a) și instanța acesteia (b)
Dispozitivul (Device) este o resursă fizică I.T. cu capacități de prelucrare, pe care un artefact este desfășurat pentru executare.
Figura 3.158 Reprezentarea grafică a dispozitivelor
Mediul de execuție este un nod cu stereotipul «Execution Environment», ce oferă configurația necesară tipurilor specifice de componente care sunt desfășurate pe el, sub forma artefactelor executabile (vezi Figura 3.146).
De exemplu, în diagrama de amplasare pentru aprovizionarea cu mărfuri de la furnizor (vezi Figura 3.146) se poate realiza, pe lângă serverul de bază de date, un server de aplicații ce conține toate clasele identificate. Aplicația client conține interfața cu utilizatorul.
Figura 3.159 Exemplu de diagramă de amplasare
Realizarea persistenței
Persistența se referă la posibilitatea „supraviețuirii” obiectelor de la o execuție la alta a sistemului informatic. Datorita faptului că sistemele informatice de gestiune utilizează un volum mare de informații, în literatura de specialitate există trei abordări în vederea realizării persistenței:
operațiile legate de persistență sunt incluse în obiectele de gestiune
realizarea persistenței prin clase dedicate
gestionarea globală și unitară a persistenței asumată de un nivel arhitectural distinct.
De exemplu, clasa Factură pe lângă operațiile specifice (ValoareFactură și ValoareTVA), poate avea și operații pentru asigurarea persistenței. Acestea sunt Salvează, Încarcă și Șterge.
Figura 3.160 Clasa Factură cu operații de persistență
Implementarea claselor se va realiza diferit, în funcție de mediul de dezvoltare, precum și de preferințele programatorului. Față de clasele care conțin și operații care să asigure persistența, utilizarea claselor dedicate în acest sens, reprezintă o soluție superioară, deoarece eventualele modificări ale modului de memorare vor afecta numai clasele de persistență. Clasele dedicate vor conține ca operații numai cele specifice persistenței.
Figura 3.161 Clasa Factură și clasa pereche de persistență FacturaPersistentă
O altă variantă de asigurare a persistenței este utilizarea unui gestionar de persistență, care să asigure operațiile minime pentru persistență (încarcă, salvează, ștergere) precum și serviciul de generare și atribuire al realizărilor cheilor primare folosite în tabele.
Modelarea afacerilor (BPMN)
Cadrul general
BPMN (Business Process Modeling Notation) reprezintă standardul grafic pentru descrierea și înțelegerea activităților specifice unei afaceri.
Principalul scop al BPMN este „să ofere o notație accesibilă pentru toți utilizatorii de afaceri, de la analiștii de afaceri, care creează proiectul inițial al proceselor, până la dezvoltatorii tehnici responsabili pentru implementarea acestora și, în final, pentru oamenii de afaceri care vor gestiona și monitoriza aceste procese. Astfel, BPMN creează o punte de legătură standardizată pentru decalajul dintre proiectarea procesului de afaceri și implementarea acestuia.”. În acest sens, BPMN furnizează diagrama proceselor de afaceri (Business Process Diagram) care este realizată pentru a fi folosită atât de proiectanți, cât și de managerii proceselor de afaceri.
BPMN definește o mapare a notațiilor sale vizuale pentru execuția semantică a proceselor de afaceri prin limbaje de execuție, cum ar fi Business Process Modeling Language (BPML), Business Process Execution Language for Web Services (BPEL4WS) și Web Services Business Process Execution Language (WS-BPEL).
În 2004, Business Process Management Initiative (BPMI – acum parte a OMG) a lansat public versiunea 1.0, iar în 2006, OMG a adoptat specificația BPMN 1.0 ca standard.
Diagrama proceselor de afaceri (BPD)
În cadrul diagramei proceselor de afaceri (BPD) sunt utilizate următoarele concepte:
Obiecte de flux (flow objects)
Obiecte conectoare (connecting objects)
Centre de responsabilități (swimlane objects)
Artefacte (artifact objects)
Obiectele de flux sunt de trei tipuri:
Evenimentele sunt „ceva” ce se întâmplă în cadrul proceselor de afaceri. Evenimentele pot avea o cauză și un efect, și pot fi:
evenimente de start – indică unde (sau ce) va începe un proces. Evenimentele de start pot fi de mai multe tipuri, pentru a arăta condițiile în care se inițiază procesul.
Figura 4.1 Eveniment start
evenimente intermediare – sunt acele evenimente care pot apărea după ce un proces a fost inițiat, dar înainte de a se termina. Un eveniment intermediar poate să apară în decursul unui flux normal al unui proces.
Figura 4.2 Eveniment intermediar
evenimente finale – indică unde se termină un proces și modul de finalizare al acestuia.
Figura 4.3 Evenimente finale
Un eveniment poate fi utilizat pentru a „prinde” (catch) sau a „arunca” (throw) un trigger eveniment. „Prinderea” (catching) unui eveniment de start creează o nouă instanță a procesului, iar „prinderea” unui eveniment intermediar conduce la continuarea procesului numai dacă evenimentul a fost însușit (de exemplu, primirea unui mesaj). „Aruncarea” (throwing) unui eveniment final are loc atunci când procesul s-a încheiat, iar „aruncarea” unui eveniment intermediar conduce la lansarea unui eveniment (de exemplu, trimiterea unui mesaj). Sintagma catch-throw este specifică limbajelor de programare.
Figura 4.4 Un eveniment „throw” transferă semnalul (token-ul) unui eveniment „catch”
Există mai multe tipuri de evenimente ce se pot manifesta în cadrul unei diagrame a proceselor de afaceri. Aceste evenimente sunt descrise în tabelul de mai jos:
Activitățile corespund unor etape ori stări concrete pe care le suportă participanții, pentru a executa fluxul de lucru. Activitățile pot fi atomice și compuse. Activitățile atomice sunt acele activități care nu se mai pot diviza în alte subactivități. Activitățile compuse se pot diviza într-un set de subactivități. Conform BPMN, activitățile descrise în cadrul diagramei proceslor de afaceri pot fi:
Task-uri – un task reprezintă o activitate atomică.
Figura 4.5 Reprezentarea grafică a unei activități
Subprocese – subprocesul este o activitate compusă care este inclusă într-un proces. Se reprezintă grafic printr-un dreptunghi cu colțurile rotunjite, care are în partea de jos un “plus” încadrat într-un dreptunghi mic.
Figura 4.6 Reprezentarea grafică a unui subproces
Un subproces poate conține activități ce se vor executa în mod repetitiv (Figura 4.7).
Figura 4.7 Subproces repetitiv
Procese – un proces este format dintr-un set de task-uri și subprocese și se reprezintă grafic sub forma unui graf de obiecte de flux.
Punctele de decizie sunt elemente de modelare care controlează modul în care fluxurile de secvență interacționează atunci când ele converg sau diverg în cadrul unui proces. Un punct de decizie se reprezintă grafic sub forma unui romb.
Punctele de decizie pot fi de mai multe tipuri:
Bazate exclusiv pe date. Sunt cele mai folosite puncte de decizii. Acestea sunt bazate pe expresii logice conținând atributul <expresie condiție> specific ieșirii fluxului secvențial din punctul de decizie. Punctele de decizie bazate exclusiv pe date se pot reprezenta grafic printr-un romb gol (Figura 4.9 – a) sau prin marcarea unui X în cadrul rombului (Figura 4.9 – b).
Figura 4.8 Reprezentarea grafică a punctului de decizie bazat exclusiv pe date
Figura 4.9 Reprezentarea grafică a punctului de decize cu indicator intern (X)
Marcarea unei alternative cu caracterul „\” (backslash) indică o variantă implicită.
Bazate exclusiv pe evenimente. O decizie de acest tip reprezintă un punct de ramificație în cadrul procesului, unde alternativele sunt bazate pe evenimente ce apar într-un punct din proces (Figura 4.11).
Figura 4.10 Punctul de decizie bazat exclusiv pe evenimente
Figura 4.11 Exemplu pentru utilizarea punctului de decizie bazat pe evenimente, utilizând evenimentele mesaj și timp
Inclusive. O decizie inclusivă reprezintă un punct de ramificație unde alternativele sunt bazate pe expresii condiționale, conținute în cadrul fluxului secvențial de ieșire. Evaluarea unei expresii condiționale nu exclude evaluarea altei expresii condiționale.
Figura 4.12 Reprezentare grafică a punctului de decizie inclusiv
Există două moduri de modelare a tipului de decizie inclusiv:
Utilizând un set de secvențe de flux condiționale marcate cu mini-romburi (Figura 4.13)
Utilizând punctul de decizie inclusiv (Figura 4.14)
Figura 4.13 Decizie inclusivă reprezentată prin fluxuri secvențiale condiționale
Figura 4.14 Decizie inclusivă reprezentată prin punct de decizie
Complexe. BPMN include punctul de decizie complex, pentru situațiile în care este dificil să se reprezinte în întregime celelalte tipuri de puncte de decizii. Punctul de decizie complex poate fi utilizat pentru a combina decizii simple, în diferite situații complexe.
Figura 4.15 Reprezentarea grafică a punctului de decizie complex
Un punct de decizie complex poate fi utilizat pentru fuzionarea sau scindarea fluxurilor secvențiale din cadrul unui proces de afaceri.
Figura 4.16 Punct de decizie complex pentru scindarea unui flux
Figura 4.17 Punct de decizie complex pentru fuziunea fluxurilor secvențiale
Paralele. Punctul de decizie paralel furnizează un mecanism ce sincronizează fluxuri paralele și creează fluxuri paralele. Acest punct de decizie permite o abordare echilibrată a modelării și este folosit atât pentru bifurcația unui flux în fluxuri secvențiale paralele, cât și pentru compunerea unor fluxuri paralele.
Figura 4.18 Reprezentarea grafică a punctului de decizie paralel
Figura 4.19 Punct de decizie paralel utilizat pentru bifurcația unui flux în fluxuri secvențiale paralele
Figura 4.20 Punct de decizie paralel utilizat pentru compunerea unor fluxuri paralele
Obiectele conectoare
În BPMN există două tipuri de obiecte conectoare:
flux (secvențial sau mesaj);
asociere.
Un flux secvențial este folosit pentru a arăta ordinea în care activitățile se desfășoară într-un proces.
Figura 4.21 Un flux secvențial
Expresiile condiționale existente în cadrul unui proces vor fi evaluate înainte ca tokenul (semnalul) să fie generat și trimis de obiectul sursă prin intermediul unui flux. Dacă sursa unui flux secvențial este o activitate, în locul punctului de decizie se poate utiliza un mini-romb, care trebuie plasat la începutul fluxului secvențial (Figura 4.22).
Figura 4.22 Flux secvențial condițional
Un flux secvențial, care este generat în urma evaluării unei expresii condiționale, poate fi definit ca o alternativă implicită, prin marcarea acestuia cu „backslash” (Figura 4.23).
Figura 4.23 Flux secvențial implicit
Un flux mesaj este folosit pentru a descrie mesajele care se transmit și se recepționează între două entități.
Figura 4.24 Flux mesaj
Asocierea este utilizată pentru a corela informații și artefacte cu obiectele de flux. Asocierea se reprezintă grafic prin linie punctată.
Figura 4.25 Asocierea
O asociere dirijată (vezi Figura 4.26) este adesea folosită cu obiecte de date (Data Object). Aceasta precizează care dintre obiectele de date sunt de intrare și care sunt de ieșire dintr-o activitate.
Figura 4.26 Asociere dirijată
Obiectele conectoare pot avea marcaje adiționale (etichete), plasate deasupra sau sub săgeată.
Centre de responsabilități
BPMN utilizează centrele de responsabilități („swimlanes”) pentru separarea unor zone din cadrul procesului. Centrele de responsabilități folosite în cadrul diagramelor proceselor de afaceri pot fi:
Participanții (Pool) din cadrul procesului. Participantul la un proces poate fi un rol aferent procesului de business (vânzătorul, cumpărătorul etc.) sau o entitate de business (o companie). Interacțiunea dintre participanți se realizează cu ajutorul fluxurilor mesaj. Fluxurile secvențiale nu pot depăși granițele unui participant.
De exemplu, interacțiunea dintre participanții Bancă și Companie (Figura 4.27) se realizează cu ajutorul fluxurilor mesaj Solicită informații cont și Primește informații cont.
Figura 4.27 Interacțiunea dintre participanți (pool-uri)
Partiții (Lane) ale participantului. O partiție poate fi orice rol intern (manager, asociat etc), un sistem sau subsistem informatic (sistemul financiar-contabil etc), un departament intern (Financiar, Aprovizionare etc) etc. Fluxurile secvențiale pot depăși granițele unei partiții.
De exemplu, o societate (participant) poate avea următoarele compartimente (partiții): Aprovizionare, Producție și Desfacere.
Figura 4.28 Reprezentarea grafică pentru partiții (lane-uri)
Artefacte
Artefactele au rolul de a aduce informații suplimentare unei diagrame. BPMN utilizează trei artefacte standard:
Obiectul-data – precizează datele necesare unei activități, precum și cele produse de către acestea. Un obiect-data are atributele Nume și Stare. Numele se referă la denumirea obiectului-data, iar starea indică impactul pe care îl are procesul asupra sa.
Figura 4.29 Reprezentarea grafică a unui obiect data
De exemplu, obiectul data Comandă se află inițial în starea Completată, iar după execuția activității Aprobare Comandă va intra în starea Aprobată (Figura 4.30).
Figura 4.30 Exemplu de stare pentru obiectul data Comanda
Un obiect data poate fi atașat unui flux secvențial sau unui flux mesaj (vezi Figura 4.31).
Figura 4.31 Obiect data atașat unui flux secvențial
Adnotarea – reprezintă un mecanism pus la dispoziția proiectanților, pentru a adăuga informații textuale (comentarii) diagramelor.
Figura 4.32 Reprezentare grafică pentru artefactul Adnotare
Grupul furnizează un mecanism vizual de grupare a elementelor din cadrul unei diagrame.
Figura 4.33 Reprezentare grafică pentru artefactul Grup
BPMN este proiectat pentru a acoperi mai multe tipuri de modelare și permite crearea proceselor „end-to-end”. Elementele structurale ale BPMN permit unui observator oarecare să diferențieze secțiunile dintr-un model de business. Conform versiunii 1.2, un model BPMN end-to-end poate să conțină trei tipuri fundamentale de submodele:
Procese private (interne) – sunt acele procese interne unei organizații cunoscute și sub denumirea de workflow. Procesele private sunt conținute într-un singur participant (pool). O diagramă de procese de afaceri poate să conțină mai multe procese private.
Procese abstracte (publice) – acest tip de procese reprezintă interacțiuni dintre procesele de afaceri private și alte procese sau alți participanți.
Procese de colaborare (globale) – aceste procese descriu interacțiuni dintre două sau mai multe entități de business. Aceste interacțiuni sunt definite ca secvențe de activități și reprezintă șabloane pentru schimburile de mesaje între entitățile implicate.
De exemplu, în Figura 4.34 este descrisă diagrama procesului de afaceri pentru onorarea comenzilor către clienți. Fluxul din cadrul acestui proces este următorul:
Comanda, întocmită de client, este primită de societate
Se verifică stocul existent și dacă este insuficient, atunci comanda este refuzată. Comanda va trece succesiv prin stările Deschisă, Refuzată, iar apoi Închisă (se utilizează evenimentul intermediar link)
Dacă stocul existent este suficient, atunci comanda este acceptată și va avea loc emiterea facturii și livrarea mărfurilor către client.
În final factura va fi plătită și comanda va fi închisă.
Figura 4.34 Diagrama procesului de afaceri pentru onorarea comenzilor
Modelarea arhitecturii sistemelor informatice
Cadrul general
Arhitectura software reprezintă, conform ANSI/IEEE Std 1471-2000, “organizarea fundamentală a unui sistem, încorporată în componentele și relațiile dintre acestea și în principiile care ghidează conceperea și evoluția sa”.
Dezvoltarea fără precedent a tehnologiei informației a condus la elaborarea de noi tehnici de realizare a sistemelor informatice. În decursul timpului, au fost elaborate diferite modele de arhitecturi pentru sistemele informatice, atât la nivel logic cât și fizic:
Arhitectura logică vizează modul în care este structurat și organizat sistemul la nivel conceptual pentru a asigura funcționalitățile cerute;
Arhitectura fizică descrie structura programelor și distribuirea lor în cadrul echipamentelor electronice.
Există diferite abordari pentru tehnologiile arhitecturale, care pot fi clasificate astfel:
Abordările conceptuale sunt folosite pentru definirea cerințelor de business specifice aplicației. Acestea sunt elaborate conform viziunii utilizatorilor finali, în scopul elaborării unui model de afaceri. Descrierea activităților de business specifice domeniului de aplicabilitate se realizează prin intermediul diagramelor UML sau cu ajutorul modelelor de business (BPMN). Evident, aceste modele nu conțin detalii de implementare.
Abordările logice. Pe baza modelelor de business sunt dezvoltate, de către proiectanți, modele de aplicații, prin care se precizează modul în care acestea vor îndeplini cerințele de business.
Abordările fizice. Modelele de aplicații vor fi implementate, în funcție de tehnologia existentă în cadrul organizației, sub formă de cod sursă. O mare parte din activitațiile de implementare pot fi preluate de către framwork-uri, prin generarea de cod sursă și printr-un management al datelor la un nivel ridicat de abstractizare.
Modele de arhitectură logică
În dezvoltarea sistemelor informatice se pot utiliza următoarele tipuri de arhitecturi logice:
Arhitectura pe un nivel (one tier architecture) apare când server-ul și clientul sunt una și aceeași aplicație. Baza de date, regulile de business și interfața cu utilizatorul sunt descrise toate în același loc, în cadrul aceleiași aplicații.
Arhitectura pe două nivele (two tier architecture) descrie perfect aplicațiile client-server. Aceste arhitecturi se bazează pe dialogul dintre două categorii de entități:
Clientul este entitatea care asigură interfața cu utilizatorul, lansează cereri de executare a unor operații către server și se ocupă de punerea într-o anumită formă a informațiilor primite de la server.
Serverul este entitatea care recepționează, interpretează și execută operațiile solicitate de către clienți. Datele sunt stocate într-un server de baze de date (de exemplu, SQL Server sau Oracle).
Figura 5.1 Arhitectura Client-Server
De cele mai multe ori, regulile de business sunt implementate în totalitate pe server.
Arhitectura pe trei nivele (three tier architecture) se caracterizează prin implementarea într-un mediu propriu a regulilor de business. Aplicațiile client pot folosi aceste reguli de business independent una de alta și independent de datele existente.
Modelele de arhitectură logică cel mai des utilizate sunt cele pe trei (Figura 5.2 – a) sau patru nivele (Figura 5.2 – b). Arhitecturile pe patru nivele (ca si cele N-tier) pot fi obținute, de regulă, printr-o extindere a nivelului de logică a problemei (business).
Nivelurile prezente în cadrul unei arhitecturi pe trei sau patru nivele pot fi:
Interface se refera la interfața aplicației, care permite dialogul sistemului cu utilizatorul;
Business services reprezintă cel mai dinamic nivel al aplicației și se referă la prelucrările specifice domeniului de activitate al sistemului informatic;
Business process permite implementarea claselor de control și a celor care asigură dirijarea aplicatiei;
Business entity permite implementarea obiectelor și regulilor de gestiune specifice domeniului sistemului informatic;
Data representation utilizează accesorii de date care stochează date. Acest nivel este responsabil cu asigurarea persistenței obiectelor.
Pe baza acestor arhitecturi logice sunt dezvoltate majoritatea sistemelor informatice. În Figura 5.3 este descrisă diagrama de amplasare pentru o arhitectură pe patru nivele. Serverul de aplicații va conține clasele de control, meniul, regulile de business precum și clasele care asigură persistența obiectelor, în timp ce aplicația client va conține doar interfața cu utilizatorul.
Între aceste componente există următoarele comunicații:
Între aplicația server și serverul de baze de date
Între aplicația server și aplicația client. Aplicația client nu comunică niciodată direct cu serverul de baze de date
În Figura 5.3 serverul de aplicații, serverul de baze de date și aplicația client sunt executate pe calculatoare diferite. Se pot dezvolta însă aplicații ce se vor executa pe un singur calculator, indiferent de tipul de arhitectură folosit.
Figura 5.2 Arhitectura pe trei nivele (a) și arhitectura pe patru nivele (b)
Figura 5.3 Diagrama de amplasare pentru o arhitectură pe patru nivele
În continuare, este prezentat un model de arhitectură n-tier, original, bazat pe utilizarea unui framework performant, care asigură un nivel ridicat de abstractizare (Figura 5.4). Acest model garantează o creștere considerabilă a flexibilității la modificările ulterioare ale fluxurilor informaționale.
Figura 5.4 Arhitectura n-tier utilizand framework si repository
Framework este un mediu de dezvoltare, utilizat pentru generarea modelului relațional, a claselor care asigură implementarea proceselor de business și, în special, a acelor clase care asigură persistența obiectelor sau chiar a interfeței cu utilizatorul. Prin acest framework, proiectanții pot concepe modelele de business ale unei aplicații la un nivel foarte ridicat de abstractizare. Pe baza modelelor obținute se poate genera automat o clasă de mapare generală, un repository pentru baza de date, un repository pentru interfețele cu utilizatorul și baza de date a aplicației (vezi Figura 5.4). De exemplu, un instrument CASE care asigură implementarea cvasi-completă a modelelor de business, poate avea rolul unui framework în cadrul unei aplicații informatice.
General class mapping este o clasa parametrizată, generată de către framework, care se poate mapa pe orice tip de clasă de gestiune și care va asigura operațiile de persistență. Se poate instanția pentru orice tip de obiect de gestiune, după o citire, în prealabil, a meta-datelor salvate in Database Repository.
Repository este generat de către framework și conține meta-datele specifice domeniului problemei, în cadrul unei baze de date sau a unor fișiere XML. Se poate construi atât un repository pentru baza de date, cât și unul pentru interfețele cu utilizatorul final.
Modele de proiectare propuse pentru Repository
Un Database Repository conține structura modelului relațional necesar aplicației: numele tabelelor, denumirile atributelor, tipurile de dată asociate atributelor, atributele care sunt chei primare, atributele prin care se realizeaza legatura dintre tabele, relațiile dintre tabele.
Un Interface Repository conține tipurile de controale care există în cadrul unui formular, precum și legatura acestora cu Repository-ul pentru baza de date (sursele de date).
In continuare, sunt prezentate modele de proiectare pentru elaborarea unui Repository: în Figura 5.5 este prezentată diagrama claselor pentru un Database Repository, iar în Figura 5.6 este prezentată diagrama claselor simplificată pentru Interface Repository.
Figura 5.5 Diagrama claselor pentru Database Repository
Figura 5.6 Diagrama claselor pentru Interface Repository
În concluzie, încorporarea unui Framework în cadrul unui sistem informatic împreună cu utilizarea unui Repository (în special pentru baza de date) conduce la o abstractizare ridicată a procesului de dezvoltare, precum și la o creștere considerabilă a flexibilității sistemului la modificările ce pot apărea în cadrul fluxurilor informaționale din interiorul organizației.
Implementarea diagramei claselor
Implementarea presupune transformarea modelelor în structuri de date, în proceduri sau funcții scrise în limbaje de programare. Dintre toate diagramele UML, diagrama claselor este singura care poate fi direct implementată.
Implementarea diagramei claselor în modelul relațional
Implementarea diagramei claselor în model relațional presupune implementarea claselor, a atributelor și a operațiilor, precum și a relațiilor dintre clase.
Clasele
În general, o clasă din diagrama claselor (cele cu stereotip «tabel») se transformă în cel puțin o tabelă în modelul relațional. Conform modelului relațional orice tabel trebuie să conțină o cheie primară. Problema apare deci, în stabilirea cheilor primare aferente relațiilor modelului relațional. Există două soluții:
Precizarea, în cadrul clasei, a unui atribut (grup de atribute) cu stereotip «PrimaryKey». Acest atribut (grup de atribute) va deveni, în cadrul tabelei din modelul relațional, cheie primară;
De exemplu, în clasa Factură pentru atributul Număr s-a definit stereotipul «PK». Acest atribut va deveni, în tabela Factură din modelul relațional, cheie primară.
Figura 6.1 Implementarea în modelul relațional, a unei clase ce conține un atribut cu stereotip «PK»
În cadrul fiecărui tabel din modelul relațional, să se definească câte o cheie primară surogat, care să permită identificarea înregistrărilor acelui tabel.
De exemplu, clasa Factura se va tansforma în tabela Factura și va avea pe post de cheie primară un câmp ID.
Figura 6.2 Implementarea generală, în modelul relațional, a unei clase
Atributele
În general, atributele unei clase devin câmpuri în cadrul tabelei. Se pot întâlni situații când nu toate atributele unei clase devin câmpuri într-un tabel sau când un atribut al unei clase se poate reprezenta prin mai multe câmpuri. În primul caz este vorba în special de atributele derivate (de exemplu valoarematerial, etc), iar în al doilea caz este vorba despre atributele compuse, (de exemplu adresa) care vor fi descompuse doar dacă prezintă interes pentru aplicație. Prin transformarea claselor în tabele, toate câmpurile tabelelor devin publice.
În cazul atributelor cu multiplicități mai mari decât unu este necesară crearea de noi tabele, care vor prelua pe post de cheie externă, cheia primară din tabelul inițial (Figura 6.3).
Figura 6.3 Implementarea atributelor cu multiplicități mai mari decât unu
Operațiile
Modelul relațional nu respectă principiul încapsulării, prin urmare, operațiile unei clase nu se pot implementa în cadrul unui model relațional. Operațiile unei clase se pot implementa însă independent de modelul relațional, ca interogări, proceduri sau funcții (în funcție de s.g.b.d.-ul ales).
Relațiile dintre clase
Asocierea
Regulile de implementare a asocierilor sunt puțin diferite față de cele folosite la transformarea modelelor conceptuale entitate-asociere în model relațional.
Asocierile de tip 11 (ambele multiplicități maxime sunt egale cu 1):
Soluția generală: oricare dintre tabelele asociate claselor poate conține drept cheie externă, cheia primară a tabelului asociat.
Soluții particulare:
Asocieri de tipul 0..1-1..1 (cele mai uzuale): tabela derivată din clasa atașată capătului de asociere cu multiplicitate minimă 0 va prelua, cu rol de cheie externă, cheia primară a tabelei derivate din clasa atașată capătului de asociere cu multiplicitate minimă 1.
De exemplu, tabela derivată din clasa Contract va prelua cu rol de cheie externă, cheia primară a tabelei derivate din clasa Cerere.
Cerere (IdCerere, NrCerere, Data)
Contract (IdContract, NrContract, Data, IdCerere)
Figura 6.4 Exemplu de implementare a asocierii de tip 0,1-1,1
Asocierile de tipul (1..1-1..1) sau (0..1-0..1): unul din cele două tabele derivate va prelua cheia primară a celuilalt tabel derivat. În cazul asocierilor de tip (1..1-1..1), se mai poate alege și soluția în care se formează un tabel ce va conține toate atributele claselor participante la asociere.
În exemplul prezentat în Figura 6.5, sunt prezentate variantele de obținere a modelului relațional.
Angajat (IdAngajat, Marcă, Nume)
CarteMuncă(IdCarte, Număr, DataEmitere, IdAngajat)
Sau
Angajat (IdAngajat, Marcă, Nume, IdCarte)
CarteMuncă(IdCarte, Număr, DataEmitere)
Sau
Angajat-CarteMuncă (IdAngajat, Marcă, Nume, Număr, DataEmitere)
Figura 6.5 Exemple de implementare a asocierii de tip 1,1-1,1
Asocieri de tip 1n (o multiplicitate maximă este 1, iar cealaltă mai mare decât 1): tabela derivată din clasa atașată capătului de asociere cu multiplicitate maximă n va prelua, cu rol de cheie externă, cheia primară a tabelei derivate din clasa atașată capătului de asociere cu multiplicitate maximă 1.
De exemplu, tabela din modelul relațional asociată clasei Comandă va primi pe post de cheie externă, cheia primară a tabelei derivate din clasa Client.
Client (IDClient, Cod, Denumire, Adresa)
Comanda (IDComanda, Numar, Data, Explicații, IDClient)
Figura 6.6 Exemplu de implementare a asocierii de tip 1-N
Asocieri mn (toate cardinalitățile maxime sunt mai mari decât 1): asocierea devine tabel și va conține cheile primare ale tabelelor derivate din clasele participante (acestea vor avea rol de chei externe). Cheia primară a tabelei nou formate va fi alcătuită din cheile externe sau poate fi o cheie artificială (surogat).
Clasa asociere devine tabel și va conține atributele proprii (dacă există) și cheile primare ale tabelelor derivate din clasele participante (vor avea rol de chei externe). Cheia primară a tabelei nou formate poate fi alcătuită din cheile externe sau poate fi o cheie artificială (surogat).
De exemplu, dacă se are în vedere faptul că pe o comandă poate figura o piesă de mai multe ori, având prețuri diferite, modelul relațional obținut în baza diagramei claselor este cel prezentat în Figura 6.7. Cheia primară a tabelei LinieComandă este IdLinieComandă, iar IdComandă și IdPiesă sunt chei externe.
Comandă (IdComandă, Număr, Data)
Piesă (IdPiesă, Cod, Denumire)
LinieComandă (IdLinieComandă, IdComandă, IdPiesă, Cantitate, PrețUnitar)
Figura 6.7 Exemplu de implementare a clasei asociere
Agregarea/Compoziția
Pentru relațiile de agregare/compoziție se vor aplica aceleași reguli de implementare ca și pentru asocieri.
Factură (IdFactură, Serie, Număr, Data, Explicații)
Facturare(IdFacturare, Cantitate, Preț, IdFactură)
Figura 6.8 Exemplu de implementare a relației de compoziție
Dependența
De obicei, în procesul de conversie a claselor în modelul relațional, relațiile de dependență sunt tratate ca și asocierile (se vor aplica regulile de transformare prezentate mai sus).
Generalizarea
Reprezentarea generalizării în modelul relațional se rezumă la variantele de reprezentare a atributelor moștenite în relațiile modelului relațional. Există trei variante de implementare a moștenirii în modelul relațional:
favorizând generalizarea: se va crea o singură tabelă care va conține atât atributele din clasa de bază, cât și cele din clasele derivate;
favorizând specializarea: se vor crea tabele pentru fiecare din clasele derivate. Aceste tabele vor conține și atributele specifice clasei de bază;
crearea de tabele pentru fiecare clasă: se vor crea tabele atât pentru clasa de bază, cât și pentru clasele derivate. Tabelele asociate claselor derivate vor avea pe post de cheie primară (acestea vor avea și rol de chei externe), cheia primară din tabela asociată clasei de bază.
De exemplu, un Client poate fi Persoană fizică sau Persoana juridică. Implementarea acestei relații de generalizare/specializare în modelul relațional este descrisă în
Figura 6.9.
Favorizând generalizarea:
Client(IDClient, Cod, Denumire, CNP, Codfiscal)
Favorizând specializarea:
PersoanăFizică(IDClient, Cod, Denumire, CNP)
PersoanăJuridică(IDClient, Cod, Denumire, Codfiscal)
Crearea de tabele pentru fiecare clasă:
Client(IDClient, Cod, Denumire)
PersoanăFizică(IDClient, CNP) – IDClient este cheie primară și cheie externă
PersoanăJuridică(IDClient, CodFiscal) – IDClient este cheie primară și cheie
externă
Figura 6.9 Implementarea generalizării/specializării în modelul relațional
Implementarea diagramei claselor în limbaje de programare orientate spre obiecte
Implementarea diagramei claselor în limbaje de programare orientate spre obiecte presupune conversia elementelor diagramei (clase, atribute, operații, relații) în cod sursă. Toate tehnicile de implementare utilizate în continuare sunt descrise pentru limbajul VB.NET.
Clasele
O clasă din diagrama claselor se implementează în VB.NET, conform sintaxei descrisă în Figura 6.10.
Figura 6.10 Sintaxa generală de implementare a unei clase în VB.NET
VB.NET suportă atât implementarea claselelor abstracte cât și a interfețelor. Sintaxa acestora este descrisă în Figura 6.11.
Figura 6.11 Clase abstracte (a) și interfețe (b) in VB.NET
Atributele
Atributele se vor implementa ca atribute/proprietăți membru ale clasei (cu respectarea vizibilității). În funcție de multiplicitatea lor, atributele unei clase se pot implementa ca:
variabile elementare pentru atributele care au multiplicitatea egală cu unu;
De exemplu, atributul CodFurnizor al clasei Furnizor se poate declara astfel:
Private CodFurnizor As String
variabile de tip matrice (tablou) pentru atributele care au multiplicitatea mai mare ca unu;
De exemplu, atributul CotaTVA are multiplicitatea 3, aferentă valorilor 0%, 9% și 19%:
Private cotaTVA(2) As Decimal
variabile de tip colecție pentru atributele care au multiplicitate infinită;
De exemplu, atributul PretFacturare (un produs poate fi facturat la prețuri diferite) poate fi definit ca mai jos:
Private PretFacturare As New Collection
În funcție de vizibilitatea atributelor unei clase, acestea se pot implementa utilizând clauzele: Private, Public, Protected. VB.NET nu suportă tipul de vizibilitate Pachet (acesta fiind preluat, în UML, din limbajul Java).
Într-o clasă se pot declara proprietăți ajutătoare (Property) care pot fi configurate de către utilizator, pentru a se putea implementa și respecta principiul încapsularii. Astfel, se asigură:
accesul neautorizat la date
implementarea restricțiilor de integritate
definirea unor atribute derivate
definirea unor atribute doar pentru citire (Property Get) sau doar pentru scriere (Property Set)
De exemplu, pentru implementarea clasei Factură, având structura descrisă în Figura 6.12, se poate recurge la declararea pentru fiecare atribut al clasei, a unor variabile locale accesibile din exterior, numai prin intermediul proprietăților Set/Get.
Figura 6.12 Clasa Factură
Implementarea, în VB.NET, a clasei Factură este prezentată mai jos:
Public Class Factura
Private pNumar As Integer 'variabilă locală pentru Număr
Private pSerie As String 'variabilă locală pentru Serie
Private pData As String 'variabilă locală pentru Data
Private pExplicatii As String 'variabilă locală pentru Explicații
Public Property Numar() As Integer
Get 'citire Numar
Return pNumar
End Get
Set(ByVal value As Integer) 'atribuire Numar
pNumar = value
End Set
End Property
Public Property Serie() As String
Get 'citire Serie
Return pSerie
End Get
Set(ByVal value As String) 'atribuire Serie
pSerie = value
End Set
End Property
Public Property Data() As Date
Get 'citire Data
Return pData
End Get
Set(ByVal value As Date)
If value >= #1/1/2000# Then 'implementare restricție
pData = value ' atribuire Data
Else
MsgBox("eroare")
End If
End Set
End Property
Public Property Explicatii() As String
Get ' citire Explicații
Return pExplicatii
End Get
Set(ByVal value As String) ' atribuire Explicații
pExplicatii = value
End Set
End Property
Operațiile
Prin implementare, operațiile unei clase devin metode. Operațiile unei clase se pot implementa ca proceduri sau funcții.
De exemplu, operația ValoareMaterial se poate implementa, în VB.NET, ca funcție:
Public Function ValoareMaterial(Cantitate As Double, Pret As Double) As Double
ValoareMaterial = Cantitate * Pret
End Function
Un rol special în cadrul metodelor unei clase, îl au constructorul și destructorul. În VB.NET constructorul se poate defini utilizând sintaxa:
Public Sub New ([<lista parametri>])
Utilizarea destructorului este opțională, dar dacă totuși se dorește acest lucru se poate utiliza metoda Finalize().
De exemplu, pentru clasa Furnizor se poate defini un constructor care va crea obiecte Furnizor cu valorile specificate prin parametrii cod și DenFz:
Public Class Furnizor
Private CodFurnizor As String
Private Denumire As String
Sub New(ByVal cod As String, ByVal DenFz As String)
CodFurnizor = cod
Denumire = DenFz
End Sub
End Class
Relațiile dintre clase
Asocieri:
Asocierile se vor implementa prin atribute de legătură, numai în clasele care asigură navigarea. Astfel, dacă multiplicitatea capătului de asociere care asigură navigarea este:
Egală cu 1, atunci clasa opusă va conține o variabilă membru de tipul clasei atașate capătului de asociere respectiv
De exemplu, în urma implementării, clasa Comandă va conține o proprietate de tip Client.
Implementarea în VB.NET:
Mai mare decât 1 și finită, atunci clasa opusă va conține un vector de tipul clasei atașate capătului de asociere respectiv
De exemplu, clasa Comandă va conține un vector care va păstra instanțele clasei Mijloc Fix.
Implementarea în VB.NET:
Infinită (*), atunci clasa opusă va conține o colecție de instanțe ale clasei atașate capătului de asociere respectiv
De exemplu, clasa Client va conține o proprietate de tip Collection, care va păstra instanțele clasei Document
Implementarea în VB.NET:
Clasa asociere va conține câte o proprietate de tipul fiecărei clase asociate, iar fiecare clasă asociată va conține câte o colecție de tipul clasei asociere.
De exemplu, clasele Factură și Materiale vor avea câte o proprietate de tip Collection în care se vor salva instanțele clasei MaterialeFacturate. Clasa MaterialeFacturate va avea o proprietate de tip Factura și o proprietate de tip Materiale.
Implementarea în VB.NET:
Agregare/Compoziție
Relațiile de tip agregare/compoziție sunt tratate asemănător cu asocierile.
Dependența
În general, dependențele între clase pot fi asimilate relațiilor de tip asociere. De cele mai multe ori, relațiile de dependență sunt implementate prin definirea în clasa client, a unei proprietăți de tipul clasei server.
Generalizarea
Moștenirea este tratată diferit de limbajele de programare orientate-obiect. Dacă în versiunile precedente ale limbajului Visual Basic (ex. 6.0) era admisă numai moștenirea de interfață (folosind instrucțiunea Implements), iar cea de implementare putea fi doar simulată prin introducerea în clasa derivată a unui atribut de tipul clasei de bază, în VB.NET moștenirea se poate implementa prin clauza Inherits, conform sintaxei de mai jos:
Public Class ClasaDerivata : Inherits SuperClasa
…..
End Class
De exemplu, relația de generalizare dintre clasa de bază (Persoana) și clasele derivate (PersoanaFizica, PersoanaJuridica) se poate implementa direct în VB.NET.
Implementare în VB.NET:
Rational Unified Process (RUP)
Cadrul general
În decursul timpului au fost propuse și utilizate numeroase metode de proiectare a sistemelor informatice. Datorită faptului că UML rămâne un limbaj de modelare și nu o metodă, a apărut necesară elaborarea unui proces unificat de aplicare a UML în dezvoltarea sistemelor informatice.
Rational Unified Process (RUP) este un proces general pentru dezvoltarea de sisteme informatice elaborat de către firma Rational Software. RUP poate fi considerat un ghid în utilizarea practică a Limbajului Unificat de Modelare (UML) pentru dezvoltarea de sisteme informatice [Jacobson99].
Principalele caracteristici ale procesului unificat sunt:
Este un proces iterativ și incremental. Conform RUP, dezvoltarea unui sistem informatic se realizează prin mai multe iterații successive, fiecare din ele aducând noi funcționalități sistemului (aspectul incremental). În fiecare iterație se abordează un set de cazuri de utilizare. Principalele avantaje ale utilizării procesului iterativ sunt :
reducerea costurilor de neconcordanță cu cerințele inițiale
reducerea riscului de a lansa/finaliza produsul cu întârziere prin identificarea din timp a riscurilor majore
accelerarea în ansamblu a ritmului de dezvoltare al proiectului
mai buna implicare a beneficiarului, precum și rafinarea iterativă a cerințelor acestuia
Este un proces orientat pe cazuri de utilizare. În cazurile de utilizare sunt decrise funcționalitățile noului sistem. Cazurile de utilizare vor reprezenta punctul central al dezvoltării unui sistem informatic, deoarece pe baza lor se definesc cerințele noului sistem, se vor proiecta modelele, iar implementarea și testarea trebuie să corespundă cerințelor cazurilor de utilizare. Cazul de utilizare este astfel, elementul de legătură al procesului unificat de dezvoltare [Lungu03].
Este un proces centrat pe arhitectură. Această caracteristică se referă atât la împărțirea sistemului în subsisteme, cât și la aspecte cum ar fi: rețeaua de calculatoare utilizată, sistemul de operare, software-ul în care se va dezvolta sistemul, legislația în vigoare etc. Împărțire sistemului în subsisteme permite lucrul în echipe și desfășurarea iterativă a procesului de dezvoltare.
În funcție de activitățile care se desfășoară în cadrul RUP, acesta poate fi structurat în (Figura 7.1):
fazele ciclului de dezvoltare (studiul preliminar, elaborare, construcție și tranziție)
activități primare (modelarea afacerii, cerințele, analiza și proiectarea, implementarea, testarea și amplasarea)
activități suport (managementul configurarației și al modificărilor, managementul proiectului și mediul de dezvoltare).
Din Figura 7.1 se observă că pe măsura dezvoltării iterative a proiectului, activitățiile de analiză și proiectare, implementare și testare primesc un rol tot mai important în dezvoltarea proiectului. În ceea ce privește activitățile suport, managementul proiectului este prezent într-o proporție constantă pe întreaga durată a ciclului de dezvoltare, în timp ce managementul configurației și modificărilor își intensifică prezența în faza de construcție, când necesitatea unei modificări trebuie atent analizată pentru a nu influența succesul proiectului.
Figura 7.1 Fazele și procesele RUP
Fazele RUP
Ciclul de viață al proiectului este compus din patru faze, fiecare dintre ele producând un rezultat final care reprezintă element de intrare pentru următoarea fază. La sfârșitul fiecărei faze se efectuează o analiză pentru a se verifica dacă obiectivele au fost îndeplinite. Trecerea la faza următoare se realizează numai dacă obiectivele fazei curente au fost îndeplinite. Fazele ciclului de viață al sistemului informatic descrise în RUP sunt (Figura 7.2): studiul preliminar, elaborarea, construcția și tranziția.
Figura 7.2 Fazele ciclului de dezvoltare
În afara cazului în care viața produsului încetează, un sistem informatic aflat în curs de exploatare va trece (dacă se solicită modificări) într-o nouă generație (Figura 7.3) repetând aceeași secvență a fazelor. În RUP acest fenomen este numit evoluție.
Figura 7.3 Evoluția sistemului prin mai multe cicluri de dezvoltare
Studiul preliminar are rolul de a prezenta o imagine generală a proiectului, stabilirea obiectivelor și eventualele riscuri care vor apărea în dezvoltarea lui. Rezultatul fazei îl reprezintă viziunea sistemului care conține o descriere sintetică a sistemului și a funcționalității acestuia (cine îl va utiliza, facilitățile oferite etc.). În afara viziunii sistemului, alte documente create în această fază sunt lista riscurilor proiectului, planul inițial de realizare și planul pentru faza de elaborare. Lucrările de bază ale acestei faze cuprind:
Definirea scopului proiectului
Un model inițial al cazurilor de utilizare(10%-20%)
Prezentarea unui plan inițial de afacere
Identificarea costurilor previzibile
Prezentarea eventualelor riscuri, precum și alegerea unei strategii de atenuare a acestora
Un plan al proiectului în care vor fi descrise fazele și iterațiile
Unul sau mai multe prototipuri
Pregătirea mediului de realizare a proiectului
Elaborarea are ca scop definirea arhitecturii viitorului produs, care va reprezenta punctul de reper pentru proiectare și implementare. Arhitectura este rezultatul analizei domeniului problemei (va lua în considerare cele mai semnificative cazuri de utilizare) și a riscurilor asociate. Abordarea arhitecturii într-o fază incipientă a dezvoltării produsului permite supravegherea eventualelor erori de proiectare, a riscurilor implicate de modificarea în timp a scopului sistemului. Principalele rezultatele ale acestei faze sunt:
Descrierea arhitecturii produsului software
Un prototip executabil al arhitecturii
Un model al cazurilor de utilizare (80% complet)
Lista revizuită a riscurilor
Un manual de utilizare preliminar
Definirea și planificarea iterațiilor din faza de construcție etc.
Construcția în cadrul acestei faze are loc dezvoltarea efectivă a sistemului (proiectarea detaliată a sistemului, dezvoltarea programelor și testarea accestora). Fiecare iterație a fazei de construcție conține următoarele lucrări de bază:
Managementul resurselor și controlul procesului
Dezvoltarea și testarea componentelor de program
Evaluarea rezultatelor iterației
Principalele documente rezultate sunt: componentele cu documentația aferentă, materialele de instruire, planul de instalare și planul pentru faza de tranzitie.
Tranziția are ca scop efectuarea testărilor finale în condițiile existente la utilizatori, efectuarea eventualelor modificări cerute de utilizatori, configurarea și instalarea produsului la utilizatorii finali, precum și asigurarea documentație necesare sistemului informatic.
Activitățile RUP
În literature de specialitate, deseori conceptul de activitate este similar celui de proces [Lungu03]. O activitate se realizează prin parcurgerea mai multor etape. Etapele se materializează în documente, diagrame sau programe etc. Legăturile dintre activitățile primare sunt prezentate în Figura 7.4.
Figura 7.4 Fiecărei activități îi este asociat un set de modele
Activitățile primare sunt: modelarea afacerii, definirea cerințelor, analiza și proiectarea, implementarea, testarea și amplasarea.
Modelarea afacerii
Modelarea afacerii are rolul de a preciza ce trebuie să asigure noul sistem. Modelarea afacerii are ca rezultat un model al cazurilor de utilizare în afaceri (business use-case), pe baza căruia se obține un model obiectul în afaceri (business object model). Acestă activitate poate fi opțională [Ericsson].
Definirea cerințelor
Definirea cerințelor presupune identificarea cerințelor funcționale și nefuncționale ale sistemului. Cerințele sunt formulate cu ajutorul utilizatorilor și sunt concretizate într-un set de cazuri de utilizare. Cazurile de utilizare pot fi dezvoltate și pe baza modelului obiectual în afaceri (business object model), în cazul în care acesta este realizat (Figura 7.4). Pentru elaborarea modelului cazurilor de utilizare trebuie să se identifice actorii, cazurile de utilizare, relațiile existente între cele două concepte, precum și să se asigure (opțional) o descriere a cazurilor de utilizare.
Actorii reprezintă, așa cum am mai precizat în capitolul referitor la limbajul UML, utilizatorii sau alte subsisteme care interacționează cu noul sistem. Un actor definește un set de roluri pe care utilizatorul unei entitati îl poate juca atunci când interacționează cu aceasta. Identificarea actorilor se va realiza din descrierea problemei ori din discuțiile cu utilizatorii. Actorii sunt descriși de regulă prin substantive.
Cazurile de utilizare reprezintă o unitate funcțională furnizată de un actor ca răspuns la apariția unei eveniment. Cazurile de utilizare sunt descrise de regulă prin verbe.
Relațiile dintre actori și cazurile de utilizare se stabilesc după regula că fiecare actor are cel puțin un caz de utilizare. Fiecare caz de utilizare identificat presupune cât mai multe detalii precizate într-o descriere a acestora.
Cunoscându-se cerințele utilizatorilor cu privire la noul sistem se poate elabora prototipuri ale interfeței.
Analiza
Principalul scop al analizei este acela de a defini ce trebuie dezvoltat. În această activitate sunt vizate abstractizările, conceptele și relațiile domeniului problemei evitându-se detaliile de implementare. Analiza trebuie să furnizeze în final, un model al domeniului problemei, concretizat în diagrama claselor, la care se adaugă diagramele dinamice.
Pentru elaborarea diagramei claselor trebuie să se cunoască obiectele, clasele cu atributele și operații specifice, relațiile dintre clase (asocieri, agregări, generalizări și dependențe).
Diagrama cazurilor de utilizare oferă informații pentru identificarea claselor. Astfel, actorii se pot reprezenta în general prin clase. Pentru identificarea altor clase (este vorba, în principiu, despre clasele entitate), o soluție ar fi analizarea substantivelor folosite în descrierea cazurilor de utilizare. Fiecare caz de utilizare trebuie să aibă în diagrama claselor cel puțin o clasă de prezentare și cel puțin o clasă de control pentru fiecare din actorii cu care interacționează. Relațiile dintre actori (dependență, generalizare) se regăsesc ca relații între clase (dependență, generalizare) în diagrama claselor.
Atributele clasei pot fi identificate din descrierile cazurilor de utilizare, din fluxurile de evenimente sau din enunțul problemei. În general, este bine să se evite declararea unor atribute specifice implementării. La definirea atributelor se va evita precizarea vizibilității și a tipului de dată, aceste informații fiind lăsate pentru faza de proiectare.
Operațiile clasei, la fel ca și unele atribute, se pot identifica din enunțul problemei, din descrierile cazurilor de utilizare sau a fluxurilor de evenimente.
De regulă, un mesaj existent în diagramele de interacțiuni va figura ca o operație în clasa căreia îi este destinat mesajul.
Acțiunile din cadrul diagramei de activități vor figura, în general, ca operații în cadrul clasei. Acțiunile precizate în cadrul tranzițiilor de stare sau în tranzițiile interne (din cadrul diagramei de stare) sunt în general operații în cadrul clasei. În privința relațiilor dintre clase există posibilitatea ca unele dintre ele să fie identificate din diagrama cazurilor de utilizare.
Pentru relațiile de asociere și agregare, nu există reguli precise privind identificarea lor, însă ele pot fi deduse din informațiile existente.
Proiectarea
Activitatea de proiectare se bazează pe dezvoltarea elementelor obținute în activitatea de analiză cu elemente specifice implementării. Activitatea de proiectare presupune [Zaharie02]:
adăugarea de noi clase, necesare pentru asigurarea persistenței, pentru realizarea interfeței;
revederea și definitivarea claselor, atributelor, operațiilor definite în cursul activității de analiză;
extinderea și completarea laturii logice a arhitecturii, împreună cu crearea și dezvoltarea aspectelor de implementare, distribuire și exploatare.
În cadrul activității de proiectare trebuie să se parcurgă următoarele etape:
definirea claselor, atributelor, operațiilor identificate în faza de analiză cu precizarea detaliilor tehnice necesare implementării (sunt specifice fiecărui limbaj orientat-obiect în parte);
identificarea de noi clase, atribute, operații, relații între clase;
revizuirea diagramei de compoziție a structurii și a diagramelor dinamice;
modelarea arhitecturii sistemului.
În cadrul activității de proiectare se mai pot identifica și alte clase, care nu au fost identificate în faza de analiză. Unii autori definesc clasele utilizate în activitatea de analiză ca fiind clase de analiza, iar cele definite în activitatea de proiectare, clase de proiectare. Pentru identificarea claselor în faza de proiectare se pot avea în vedere următoarele aspecte [Hunt00]:
fiecărei clase de prezentare din analiză îi va corespunde o clasă de interfață;
claselor entitate le vor corespunde clase de domeniu, clase de persistență și clase asociere;
sarcinile claselor de control vor fi distribuite anumitor clase, în funcție de conținutul diagramelor de interacțiuni.
În definirea atributelor se va ține cont de vizibilitatea lor, de numele, tipul și lungimea acestora. Pe lângă atributele definite în activitatea de analiză este posibil ca în activitatea de proiectare să se identifice noi atribute, ca urmare a definirii de noi clase.
În definirea operațiilor se va ține cont de vizibilitatea lor, de parametri și de tipul de dată rezultat.
Este utilă, în activitatea de proiectare, efectuarea modificărilor necesare și în diagrama cazurilor de utilizare, datorită modificărilor realizate asupra claselor, atributelor și relațiilor identificate în activitatea de analiză. Acest aspect, conduce și la revizuirea diagramei de compoziție a structurii și a diagramelor dinamice.
Modelarea arhitecturii sistemului presupune elaborarea diagramei componentelor, care descrie aspecte referitore la structura programelor, la dependențele dintre componentele software (cod sursă, fișiere, etc.) și a diagramei de amplasare care se referă la configurația echipamentelor în cadrul sistemului, precum și la repartizarea componentelor și a proceselor pe acestea.
Implementarea
Implementarea presupunse translatarea diagramelor și a specificațiilor elaborate în activitatea de proiectare, într-un limbaj de programare. Scrierea programelor este dependentă de programator, de specificațiile și de tehnicile de programare folosite.
Testarea
Activitatea de testare presupune verificarea funcționalității sistemului conform cerințelor utilizatorilor. Testarea se realizează prin compararea rezultatelor obținute prin noul sistem cu cele dorite a se obține. În momentul testării sistemului este posibil să apară erori, provenite din implementarea incorectă a modelelor obținute în activitatea de proiectare sau din cauza logicii folosite în programare. Aceste erori sunt consemnate într-un raport de testare, după care vor fi eliminate în viitoarea versiune a sistemului. Testarea se încheie în momentul în care cele două categorii de rezultate sunt egale. Este definit chiar un ciclu de viață al testării, care conține [Zaharie02]: planificarea, proiectarea, implementarea, execuția și evaluarea.
Amplasarea
Amplasarea se referă la definitivarea sistemului și la livrarea acestuia utilizatorilor. Activitatea de amplasare mai cuprinde instalarea, asigurarea documentației și formarea utilizatorilor.
Activitățile suport sunt: managementul configurației și al modificărilor, managementul proiectului și mediul de dezvoltare.
Managementul configurației și al modificărilor
Managementul configurației și al modificărilor are drept scop gestiunea versiunilor viitoare ale sistemului în condițiile dezvoltării iterative, precum și gestiunea erorilor.
Managementul proiectului
Această activitate se referă la planificarea, conducerea și execuția proiectului, precum și la gestiunea riscurilor.
Mediul de dezvoltare
Mediul de dezvoltare vizează organizarea procesului de dezvoltare a sistemului informatic, în funcție de echipamentele hard și soft de care dispun membrii echipei.
Studiu de caz – proiectarea unui sistem informatic privind acordarea creditelor pentru persoane fizice
În vederea realizării unui sistem informatic privind acordarea creditelor se au în vedere următoarele reguli de afaceri (business rules):
Clientul întocmește o cerere pentru acordarea creditului. Pentru analiza bonității, banca îi solicită clientului o adeverință de venit pe ultimele șase luni.
Dacă îndeplinește condițiile cerute, clientul încheie contractul de credit. Contractul poate avea dobândă fixă sau variabilă. Un client poate încheia mai multe contracte, iar un contract e încheiat de un singur client.
Rambursare contractelor de credit se poate realiza prin documente de plată; un document de plată se referă la un singur contract de credit, iar pentru un contract se pot întocmi mai multe documente de plată.
Modelarea proceselor de afaceri
Modelarea proceselor de afaceri are rolul de a preciza ce trebuie să asigure noul sistem și se concretizează în elaborarea diagramelor proceselor de afaceri.
În Figura 8.1 este reprezentată diagrama proceselor de afaceri pentru acordarea unui credit, în baza regulilor de business enunțate. Fluxul din cadrul procesului este următorul:
Banca primește cererea și adeverința de venit (activitatea Întocmire dosar din care rezultă obiectul-data Dosar aflat în starea Întocmit), iar în baza acestora se analizează bonitatea clientului (subprocesul Analiză bonitate);
Dacă nu sunt îndeplinite condițiile necesare, banca respinge dosarul de credit (activitatea Dosar respins produce starea Respins a obiectului-data Dosar)
În situația în care clientul îndeplinește condițiile de bonitate, banca aprobă cererea de credit (activitatea Dosar aprobat creează starea Aprobat a obiectului-data Dosar), iar apoi se încheie contractul (activitatea Încheiere contract generează obiectul-data Contract aflat în starea Deschis).
La termenul prevăzut în contract, banca trimite banii în contul clientului, iar acesta îi poate retrage.
După această activitate, începe subprocesul repetitiv de Rambursare a contractului (la sfârșitul acestei activități, obiectul-data Contract va intra în starea Închis).
Figura 8.1 Diagrama procesului de afaceri pentru acordarea creditelor
Figura 8.2 Diagrama subprocesului Rambursare
În Figura 8.2 este prezentat subprocesul de rambursare. Fluxul descris în cadrul acestuia este următorul:
Subprocesul se declanșează lunar, la termenul stabilit;
Dacă soldul este mai mare ca zero, atunci clientul efectuează plata în baza graficului de rambursare.
Notă: Pentru simplificare, am considerat că toți clienții respectă clauzele contractuale și rambursează creditele la termen. Am evitat, în acest fel, problemele legate de rescadențări, penalizări sau, mai grav, de executare silită.
Definirea cerințelor
Definirea cerințelor presupune identificarea cerințelor funcționale și nefuncționale ale noului sistem. În acest sens, am conceput diagrama cazurilor de utilizare descrisă în Figura 8.3. Există doi actori identificați: clientul și funcționarul bancar. Cazurile de utilizare au fost identificate în funcție de regulile de business.
Figura 8.3 Diagrama cazurilor de utilizare
Analiza/proiectarea
În proiectarea unui sistem informatic unele diagrame pot fi opționale, cum ar fi, de exemplu, diagrama de compoziție a structurii, diagrama de sincronizare, diagrama de comunicare sau cea de ansamblu al interacțiunii.
Cele mai multe clase descrise în diagrama claselor au fost identificate în diagrama proceselor de afaceri și în diagrama cazurilor de utilizare (clasele Client, Cerere, AdeverințăVenit, Contract și DocumentPlată).
Multiplicitățile claselor participante sunt stabilite în funcție de regulile de business. Celelalte restricții sunt stabilite în raport cu tipul și funcția atributului: CNP este nenul și unic, Nume este nenul, Cerere.Numar este unic și mai mare ca zero etc.
Toate clasele conțin operații destinate asigurării persistenței: Încarcă(), Salvează() și Șterge(). Operația Încarcă are rolul de a prelua starea unui obiect direct din baza de date; Salvează servește la înregistrarea stării unui obiect în baza de date, iar Șterge elimină, din baza de date, înregistrarea aferentă unui obiect.
Pentru clasa Contract au fost prevăzute mai multe operații cu rolul de a furniza anumite valori calculate pe baza datelor aferente unui contract: DobândaLunară (returnează valoarea dobânzii lunare), Comision (returnează valoarea comisionului perceput de bancă), ValoareTotalaDeRambursat (furnizează suma totală ce urmează a fi rambursată de client) etc.
Se știe că dobânda poate fi fixă sau variabilă. Această problemă s-a rezolvat prin adăugarea clasei Dobanda, care are ca atribute ProcentDobândă și DataProcentDobândă (data de la care este valabil procentul de dobândă respectiv).
Figura 8.4 Diagrama claselor
Diagramele de activități și de secvențe, prezentate în continuare, sunt orientate spre implementare, în limbajul VB.NET.
În Figura 8.5 este descrisă diagrama de activități pentru operația ValoareTotalaRambursata(pData). Operația returnează totalul plăților efectuate de client în contul unui contract de credit. Totalul rambursat pentru un contract se obține prin însumarea tuturor plăților efectuate, pentru acel contract, până la data cerută prin parametrul pData. În cadrul diagramei sunt folosite variabilele Plata (va conține totalul rambursat), pDocPlata (servește la referirea fiecărui document de plată corespunzător unui contract) și i (contorizează obiectele existente în cadrul colecției DocumentePlata – vezi implementarea clasei Contract).
Figura 8.5 Diagrama de activități pentru operația ValoareTotalaRambursata(pData)
În Figura 8.6 este descrisă diagrama de secvențe pentru operația ValoareTotalaRambursata. În cadrul diagramei au fost utilizate atât fragmentul repetitiv (Loop), cât și cel alternativ (Alt). Variabilele folosite în cadrul acestei diagramei au fost explicate la diagrama de activități prezentată anterior. Conținutul variabilei Plata este returnat, în final, metodei ValoareTotalaRambursata.
Figura 8.6 Diagrama de secvențe pentru operația
ValoareTotalaRambursata(pData)
Operația DobandaLunara din clasa Contract are rolul de a furniza valoarea dobânzii aferentă unei luni. În Figura 8.7 și în Figura 8.8 sunt descrise diagramele de activități și de secvențe aferente operației DobandaLunara(pData).
Figura 8.7 Diagrama de activități pentru operația DobandaLunara(pData)
Figura 8.8 Diagrama de secvențe pentru operația DobandaLunara(pData)
În mod asemănător, se pot elabora diagramele de activități și de secvențe, pentru celelalte operații ale claselor sau pentru diferite cazuri de utilizare.
Din diagrama proceselor de afaceri se pot identifica diferite stări pentru unele obiecte. Astfel, pentru obiectul Cerere se identifică stările: Întocmită, Aprobată sau Respinsă (Figura 8.9). De asemenea, obiectul Contract se poate afla în stările Deschis și Închis.
Figura 8.9 Diagrama de stare pentru clasa Cerere
În Figura 8.10 este prezentată diagrama componentelor, iar în Figura 8.11 este descrisă diagrama de amplasare.
Figura 8.10 Diagrama componentelor
Figura 8.11 Diagrama de amplasare într-o arhitectură pe trei nivele
Implementarea
În baza diagramei claselor se obține următorul model relațional:
Client (IdClient, CNP, Nume, Prenume Adresă, Telefon)
Cerere(IdCerere, Numar, Data, IdClient, IdAdeverinta)
Contract(IdContract, Numar, Data, DataSfarsit, ProcentComision, Valoare, IdCerere, IdCategorie)
AdeverințăVenit (IdAdeverinta, Numar, Data)
Venit(IdVenit, An, Luna, VenitLunar, IdAdeverinta )
DocumentPlata(IdDocument, Numar, TipDocument, Data, Suma, IdContract)
Dobanda(IdDobanda, ProcDob, DataProcDob)
Categorie (IdCategorie, Cod, Denumire)
DobandaCategorie(IdCategorie, IdDobanda)
Implementarea diagramei claselor în VB.NET este realizată mai jos:
Public Class Client
Private pCNP As String
Private pNume As String
Private pPrenume As String
Private pAdresa As String
Private pTelefon As String
Public Property CNP() As String
Get
CNP = pCNP
End Get
Set(ByVal value As String)
If value Is Nothing Then
MsgBox("CNP eronat !")
Else
pCNP = value
End If
End Set
End Property
Public Property Nume() As String
Get
Nume = pNume
End Get
Set(ByVal value As String)
If value Is Nothing Then
MsgBox("Nume eronat !")
Else
pNume = value
End If
End Set
End Property
Public Property Prenume() As String
Get
Prenume = pPrenume
End Get
Set(ByVal value As String)
pPrenume = value
End Set
End Property
Public Property Adresa() As String
Get
Adresa = pAdresa
End Get
Set(ByVal value As String)
pAdresa = value
End Set
End Property
Public Property Telefon() As String
Get
Telefon = pTelefon
End Get
Set(ByVal value As String)
pTelefon = value
End Set
End Property
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Public Class Cerere
Private pNumar As Integer
Private pData As Date
' atribute de legatura:
Private pClient As Client
Private pAdevVenit As AdeverintaVenit
Public Property Numar() As Integer
Get
Numar = pNumar
End Get
Set(ByVal value As Integer)
If value > 0 Then
pNumar = value
Else
MsgBox("Numar eronat !")
End If
End Set
End Property
Public Property Data() As Date
Get
Data = pData
End Get
Set(ByVal value As Date)
pData = value
End Set
End Property
Public Property Client() As Client
Get
Client = pClient
End Get
Set(ByVal value As Client)
pClient = value
End Set
End Property
Public Property AdevVenit() As AdeverintaVenit
Get
Return pAdevVenit
End Get
Set(ByVal value As AdeverintaVenit)
pAdevVenit = value
End Set
End Property
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Public Class AdeverintaVenit
Private pNumar As Integer
Private pData As Date
' atribut de legatura:
Private pVenituri(5) As Venit
Public Property Numar() As Integer
Get
Numar = pNumar
End Get
Set(ByVal value As Integer)
If value > 0 Then
pNumar = value
Else
MsgBox("Numar eronat !")
End If
End Set
End Property
Public Property Data() As Date
Get
Data = pData
End Get
Set(ByVal value As Date)
If value >= Now().AddYears(-1) Then
pData = value
Else
MsgBox("Data nu este permisa!")
End If
End Set
End Property
Public Property Venituri(ByVal index As Integer) As Venit
Get
Venituri = pVenituri(index)
End Get
Set(ByVal value As Venit)
pVenituri(index) = value
End Set
End Property
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Public Class Venit
Private pAn As Integer
Private pLuna As Integer
Private pVenitLunar As Double
Public Property An() As Integer
Get
An = pAn
End Get
Set(ByVal value As Integer)
If value >= Now.Year – 1 Then
pAn = value
Else
MsgBox("Anul nu este permis !")
End If
End Set
End Property
Public Property Luna() As Integer
Get
Luna = pLuna
End Get
Set(ByVal value As Integer)
If value >= 1 And value <= 12 Then
pLuna = value
Else
MsgBox("Luna eronata !")
End If
End Set
End Property
Public Property VenitLunar() As Double
Get
VenitLunar = pVenitLunar
End Get
Set(ByVal value As Double)
pVenitLunar = value
End Set
End Property
Public Function VenitMediu() As Double
End Function
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Public Class Contract
Private pNumar As Integer
Private pData As Date
Private pDataSfarsit As Date
Private pProcentComision As Single
Private pValoare As Double
'atribute de legatura:
Private pCerere As Cerere
Private pCategorieCredit As CategorieCredit
Private pDocumentePlata As New Collection
Public Property Numar() As Integer
Get
Numar = pNumar
End Get
Set(ByVal value As Integer)
If value > 0 Then
pNumar = value
Else
MsgBox("Numar eronat !")
End If
End Set
End Property
Public Property Data() As Date
Get
Data = pData
End Get
Set(ByVal value As Date)
If value >= pCerere.Data Then
pData = value
Else
MsgBox("Data eronata (anterioara cererii)!")
End If
End Set
End Property
Public Property DataSfarsit() As Date
Get
DataSfarsit = pDataSfarsit
End Get
Set(ByVal value As Date)
If value >= pData Then
pDataSfarsit = value
Else
MsgBox("Data sfarsit eronata !")
End If
End Set
End Property
Public Property ProcentComision() As Single
Get
ProcentComision = pProcentComision
End Get
Set(ByVal value As Single)
If value > 0 Then
pProcentComision = value
Else
MsgBox("Procent comision eronat !")
End If
End Set
End Property
Public Property Valoare() As Double
Get
Valoare = pValoare
End Get
Set(ByVal value As Double)
If value > 0 Then
pValoare = value
Else
MsgBox("Valoare eronata !")
End If
End Set
End Property
Public Property Cerere() As Cerere
Get
Cerere = pCerere
End Get
Set(ByVal value As Cerere)
pCerere = value
End Set
End Property
Public Property CategCredit() As CategorieCredit
Get
CategCredit = pCategorieCredit
End Get
Set(ByVal value As CategorieCredit)
pCategorieCredit = value
End Set
End Property
Public Property DocumentePlata() As Collection
Get
DocumentePlata = pDocumentePlata
End Get
Set(ByVal value As Collection)
pDocumentePlata = value
End Set
End Property
Public Function DobandaLunara(pData As Date) As Double
End Function
Public Function DobandaTotala() As Double
End Function
Public Function Comision() As Double
End Function
Public Function ValoareTotalaDeRambursat(pData As Date) As Double
End Function
Public Function ValoareTotalaRambursata(pData As Date) As Double
End Function
Public Function SoldCredit(pData As Date) As Double
End Function
Public Function RataLunara(pData As Date) As Double
End Function
Public Function AnuitateLunara(pData As Date) As Double
End Function
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Public Class DocumentPlata
Private pNumar As Integer
Private pTipDocument As String
Private pData As Date
Private pSuma As Double
'atribut de legatura:
Private pContract As Contract
Public Property Numar() As Integer
Get
Numar = pNumar
End Get
Set(ByVal value As Integer)
If value > 0 Then
pNumar = value
Else
MsgBox("Numar eronat !")
End If
End Set
End Property
Public Property TipDocument() As String
Get
TipDocument = pTipDocument
End Get
Set(ByVal value As String)
pTipDocument = value
End Set
End Property
Public Property Data() As Date
Get
data = pData
End Get
Set(ByVal value As Date)
If value >= pContract.Data Then
pData = value
Else
MsgBox("Data eronata(anterioara contractului!")
End If
End Set
End Property
Public Property Suma() As Double
Get
Suma = pSuma
End Get
Set(ByVal value As Double)
If value > 0 Then
pSuma = value
Else
MsgBox("Suma eronata !")
End If
End Set
End Property
Public Property Contract() As Contract
Get
Return pContract
End Get
Set(ByVal value As Contract)
pContract = value
End Set
End Property
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Public Class CategorieCredit
Private pCod As String
Private pDenumire As String
'atribut de legatura:
Private pDobanzi As New Collection
Public Property Cod() As String
Get
Cod = pCod
End Get
Set(ByVal value As String)
If Not value Is Nothing Then
pCod = value
Else
MsgBox("Cod eronat !")
End If
End Set
End Property
Public Property Denumire() As String
Get
Denumire = pDenumire
End Get
Set(ByVal value As String)
pDenumire = value
End Set
End Property
Public Property Dobanzi() As Collection
Get
Dobanzi = pDobanzi
End Get
Set(ByVal value As Collection)
pDobanzi = value
End Set
End Property
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Public Class Dobanda
Private pProcDob As Single
Private pDataProcDob As Date
Public Property ProcDob() As Single
Get
ProcDob = pProcDob
End Get
Set(ByVal value As Single)
If value > 0 Then
pProcDob = value
Else
MsgBox("Procent eronat!")
End If
End Set
End Property
Public Property DataProcDob() As Date
Get
DataProcDob = pDataProcDob
End Get
Set(ByVal value As Date)
pDataProcDob = value
End Set
End Property
Public Sub Incarca()
End Sub
Public Sub Salveaza()
End Sub
Public Sub Sterge()
End Sub
End Class
Bibliografie
Bibliografie
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Metodologii Orientate PE Obiecte Utilizate In Proiectarea Sistemelor Informatice (ID: 128545)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.