Diagrame UML construite pentru obtinerea unui model al activitatilor desfasurate intr-o organizatie

STUDIU DE CAZ

Utilizarea limbajului UML depinde de complexitatea sistemului real ce urmeaza a fi modelat, de metoda de management si realizare a proiectelor, de tipul sistemului informatic ce se doreste realizat, precum si de nivelul de detaliere dorit in faza de proiectare.

Diagramele UML :

. pot conduce la obtinerea unui model al activitatilor desfasurate in sistemul real;

. pot contribui la obtinerea unei scheme concise ce raspunde problemelor cheie ale aplicatiei;

. pot furniza specificatii detaliate pentru sincronizarea modelului cu codul sursa;

. pot evidentia erori in solutiile sistemelor deja construite .

Fiecare diagrama se construieste intr-un anumit moment al dezvoltarii sistemului si are o anumita utilitate in proiect. Deciziile sunt luate de echipa de realizare a proiectului, tinand cont de cerintele functionale ale sistemului si de resursele disponibile.

1- Diagrame UML construite pentru obtinerea unui model al activitatilor desfasurate intr-o organizatie

In acest studiu de caz ne propunem sa evidentiem utilizarea diagramelor UML pentru obtinerea unui model al activitatii desfasurate intr-o organizatie. In locul descrierii explicite a activitatii desfasurate, am preferat sa evidentiem procesele identificate.

Pentru fiecare etapa vom prezenta exemple si vom propune teme ce pot fi dezvoltate luand in calcul activitatea desfasurata in organizatie. Diagramele UML construite conduc in final la o diagrama a claselor completa, implemetabila intr-un limbaj orientat obiect. In paralel, pornind de la aceeasi diagrama, se poate construi un model al claselor persistente, ce conduce la baza de date relationala care asigura persistenta datelor.

Ne vom opri dupa etapa de proiectare, considerand ca solutia de implementare si persistenta datelor fac obiectul altor discipline din programa de invatamant.

Teoretic, intregul ciclu de viata al sistemului informatic poate fi impartit in mai multe etape. Acestea sunt:

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

B          analiza (Analysis);

C          proiectarea (Design);

D          implementarea. (Implementation).

. importanta si amploarea etapelor se stabileste in functie de dimensiunea si scopul sistemului;

. aceste etape se parcurg formal sau nu, constient sau nu, dar se parcurg;

. fiecare etapa are nevoie de intrari provenite din cea anterioara si produce iesire pentru urmatoarea;

. etapele se desfasoara succesiv; daca insa lucreaza echipe specializate pe faze de dezvoltare, se pot desfasura si in paralel, pentru ca dezvoltarea orientata obiect urmeaza un model in spirala.

A          Construirea unui model al sistemului real este etapa in care se identifica procesele desfasurate si modul in care ele interactioneaza.

Activitatile din cadrul proceselor se detaliaza cu ajutorul diagramelor de activitati, in 3 etape:

..A1.. se identifica procesele si se includ, pe mai multe nivele, intr-o diagrama generala a activitatilor desfasurate. Diagrama este mai degraba cuprinzatoare decat precisa, ascunzand structura organizationala si descriind doar functionalitatea organizatiei.

Exemplu:

Activitatile desfasurate conduc la identificarea mai multor procese, ce pot fi grupate pe 3 nivele:

Nivel 1:

.1- Planificare = dezvolta si monitorizeaza planul tactic si strategic al organizatiei: investitii, resurse, evaluare performante, monitorizare riscuri si oportuinitati.

.2- Aprovizionare = cuprinde toate activitatile legate de aprovizionare, inclusiv achitarea facturilor primite de la furnizor; include contractarea precum si asigurarea calitatii articolelor aprovizionate.

.3- Vanzare = inregistreaza intreaga activitate de vanzare, incluzand marketingul, comenzile de la clienti, facturarea, distributia.

.4- Productie = include productia si depozitarea, transportul intre sectia de productie si depozite.

.5- Dezvoltare = se refera la constructii pentru fabrici, sectii de productie, birouri, depozite.

.6- Finante = vizeaza circuitul banilor si controlul activitatilor financiare: investitii, gestiune a conturilor bancare, raportari legale.

.7- Cercetare = urmareste cercetarile intreprinse pentru dezvoltarea si optimizarea activitatii desfasurate.

Nivel 2:

De exemplu, procesul .3- Vanzare se poate detalia astfel:

.3.1 negociere contract;

. 3.2 preluare comenzi;

. 3.3 livrare articole;

.3.4 acceptare refuzuri;

. 3.5 facturare;

. 3.6 incasare facturi.

Nivel 3:

De exemplu,

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

.3.2.1 se confirma alegerea clientului

.3.2.2 se preia comanda de la client

3.2.3 se negociaza data livrarii

3.2.4 se stabileste data livrarii

3.2.5 se confirma detaliile din comanda

▪ procesul .3.5 facturare se poate detalia astfel:

. 3.5.1 identificare a bunurilor livrate si acceptate;

. 3.5.2 stabilire a pretului de vanzare;

. 3.5.3 aplicare a reducerilor;

. 3.5.4 completare a fcaturilor;

. 3.5.5 editare si trimitere a facturilor ce insotesc produsele.

Schematic, procesele pot fi prezentate in urmatoarea structura ierarhica:

1 2 3Vanzare4 ..

3.1

.

3.5 Facturare

3.5.2 Stabilirea pretului de vanzare

..

Tema:

Definiti procese suplimentare pentru activitatea desfasurata in organizatie.

Detaliati cateva procese evidentiate pe nivelele descrise.

Descrieti activitatea desfasurata astfel incat sa evidentiati intr-o maniera personala procesele cuprinse in descriere.

..A2.. se construiesc diagrame de activitati pentru procesele analizate.

Pentru o mai buna intelegere a structurii si dinamicii organizatiei se includ obiecte. Plasand obiecte in diagrama de activitati, putem vedea unde sunt create si manipulate obiectele in desfasurarea procesului, unde se schimba starea lor. La acest nivel, obiectele sunt privite doar ca avand o stare ce poate fi schimbata prin actiuni asupra obiectului.

Exemplu:

Diagrama de activitati pentru procesul .3.2. - preluare comenzi este (fig. 1):

fig. 1

Tema:

Contruiti diagrame de activitati pentru alte procese

B          Analiza, in sens larg, acopera investigarea activitatii desfasurate si definirea unui sistem informatic.

. incepe dezvoltarea sistemului de la definirea proceselor, de la identificarea cazurilor de utilizare care descriu aceste procese si merge pana la momentul in care dezvoltatorii de sistem au un model comprehensiv al comportamentului sistemului, pot prezenta utilizatorilor viitorul sistem, impreuna cu tipurile de informatii memorate si regasite de el.

. se disting doua faze: analiza cerintelor si analiza de sistem.

B1        Analiza cerintelor, clasificate in cerinte functionale, care evidentiaza ce face sistemul si cerinte nefunctionale, ce vizeaza performantele sistemului ( fiabilitate, calitate a interfetei).

. se centreaza in jurul diagramei cazurilor de utilizare, cea care exprima interactiunea cu mediul exterior;

. conduce la definirea comportamentul extern al sistemului si la includerea sistemul in contextul activitatii desfasurate (business environment);

Schematic, intrarile si iesirile acestei etape pot fi reprezentate ca in figura 2, unde:

. diagrama cazurilor de utilizare prezinta actorii si actiunile declansate de ei.

descrierea unui caz de utilizare consta in prezentarea scenariilor. Se iau in calcul urmatoarele recomandari :

. se clarifica toate problemele cu persoanele implicate (stakeholders);

. se identifica setul de scenarii ce acopera toate alternativele si exceptiile;

. pentru fiecare scenariu se construieste o diagrama de secvente;

. in cazul scenariilor cu alternative si exceptii se recomanda construirea diagramelor de activitati pentru evidentierea detaliilor.

prototipurile pentru interfata cu utilizatorul ajuta la vizualizarea modului in care sistemul lucreaza.

	Participanti
			Scop

 

Procesele existente

 

Analiza cerintelor

fig. 2

Participantii la dezvoltarea viitorului sistem stabilesc in aceasta etapa sarcini pe grupuri de persoane implicate, iau decizii privind oportunitatea definirii unui nou sistem informatic.

Exemplu:

Scop: Dezvoltarea unui sistem informatic pentru activitatile ce vizeaza aprovizionarea cu componente, conform comenzilor primite de la clienti pentru asamblarea unor sisteme de calcul (produse finite).

Procese existente:

. gestiunea comenzilor primite de la clienti

. contractarea marfurilor de la furnizor

. aprovizionarea cu marfa

. gestiunea marfurilor aprovizionate

. achitarea furnizorilor

Participanti:

. utilizatori

. beneficiari

. analisti

Sarcini:

. documentarea viziunii proiectului

. construirea cazurile de utilizare

. descrierea cazurilor de utilizare

. definirea arhitecturii preliminare a sistemului

. analiza riscului

Decizii:

. ce isi propune sistemul pentru fiecare din utilizatori?

. tehnic si organizational este posibil?

. ce riscuri pot afecta fezabilitatea?

. beneficiile justifica costurile?

Diagrama cazurilor de utilizare pentru procesele ce vizeaza aprovizionarea conform contractelor incheiate cu furnizorii este (fig. 3):

fig. 3

Descrierea cazurilor de utilizare.

Prezentam in continuare cateva scenarii ce descriu cazuri de utilizare reprezentative, cu eventuale alternative sau exceptii.

= scenariul 1

Denumire: Incheierea contractului pentru aprovizionarea cu componente

Descrierea derularii

.. stabilirea necesarului de aprovizionat;

.. analiza ofertelor de la furnizori;

.. alegerea furnizorului;

.. stabilirea conditiilor contactuale;

.. semnarea contractului de ambele parti.

= scenariul 2

Denumire: Gestiunea componentelor aprovizionate

Descrierea derularii

.. se inregistreaza factura cu care au sosit componentele;

.. gestionarul verifica componentele; in functie de calitatea si cantitatea existenta,

.. gestionarul inscrie componentele corespunzatoare pe NIR; pentru o factura se completeaza un NIR/mai multe NIR-uri;

.. NIR-urile se pastreaza in arhiva gestiunilor.

SAU

.. intocmeste proces verbal pentru componentele necorespunzatoare calitativ sau lipsa cantitativ;

.. furnizeaza informatii pentru stornarea facturilor la compartimentul aprovizionare.

= scenariul 3

Denumire: Gestionarea cererii de la aprovizionare/vanzare

Descrierea derularii

.. gestionarul primeste o comanda de la departamentul aprovizionare/vanzare;

.. gestionarul verifica cantitatea si calitatea ceruta;

.. gestionarul calculeaza pretul mediu pentru analiza ofertei in cazul aprovizionarii/pretul de vanzare pentru livrare;

.. in cazul vanzarii, descarca gestiunea dupa scoaterea din gestiune a marfii.

= scenariul 4

Denumire: validarea unui client cand acesta suna pentru o comanda

Descrierea derularii

. clientul furnizeaza un numar de identificare pe care operatorul il tasteaza in fereastra de interfata;

. sistemul raspunde cu numele si adresa clientului si o parola de acces;

. operatorul cere confirmarea pentru nume, adresa si parola si inchide fereastra daca raspunsurile date sunt conforme cu datele de pe ecran.

Alternative:

1. clientul nu are un numar de identificare pentru a fi gestionat; operatorul trebuie sa ceara clientului sa aiba un numar de identificare inaintea intrarii in sistem.

2. sistemul nu poate gasi inregistrarea cu numarul de identificare dat al clientului si se afiseaza un mesaj de eroare. Operatorul cere un nou numar de identificare si reia operatia de validare de la pasul 1.

3. clientul nu poate furniza numele, adresa sau parola; operatorul inchide aplicatia. Sistemul trebuie sa inregistreze incercarea nereusita pentru a permite cercetarea fraudei.

Exceptii:

. daca sistemul nu e disponibil, operatorul preia numele si numarul de telefon al clientului si-l suna imediat ce sistemul e disponibil.

scenariul 5

Denumire: preluarea detaliilor unei comenzi pentru un client

Descrierea derularii

. clientul furnizeaza codul produsului si cantitatea; operatorul tasteaza aceste informatii pe ecran;

. clientul cere o data anume pentru livrare, operatorul o tasteaza pe ecran. Sistemul confirma ca aceata e acceptabila/acceptata

. operatorul citeste comanda si comunicata data livrarii clientului, care accepta

. operatorul inchide ecranul de interfata si sistemul raspunde ca aceasta comanda a fost acceptata. Operatorul multumeste clientului si intreaba daca exista alta comanda

Alternative:

1. clientul nu are un cod al produsului, dar stie numele produsului. Sistemul poate permite acceptarea numelui si regaseste codul.

2. sistemul nu poate accepta data livrarii si ofera o data apropiata pe care o negociaza cu clientul.

3. se constata nereguli in detaliile unei comenzi:

. clientul a facut o greseala in furnizarea datelor si operatorul trebuie sa faca modificari in detalii;

. comanda excede limita de creditare a clientului sau cere un produs neinclus in oferta; dupa discutii cu clientul se fac modificari.

se renunta la comanda din diferite motive.

Observatii:

. in situatia in care preluarea comenzii se face prin telefon, este indicat sa se construiasca o diagrama de activitati care sa ia in calcul si alternativele prezentate in scenariu (fig. 4).

. iesirile evidentiate in diagrama reprezinta intrari in alte procese (procesul de vanzare dupa transferul apelului)

fig.4

B2        Analiza de sistem, faza din care incepem sa vorbim de un proces de "elaborare a cazurilor de utilizare".

. exprima comportamentul sistemului si interactiunea cu mediul afacerii in termeni din domeniul computerelor, intr-un limbaj al dezvoltatorilor.

. evidentiaza interactiunile dintre obiecte pornind de la scenariile descrise anterior; se defineste o prima forma a structurii viitorului sistem.

. conduce la construirea unui model obiect, imagine a modului in care sistemul se prezinta utilizatorilor, a tipurilor de informatii memorate si regasite de sistem.

Schematic, aceasta etapa poate fi reprezentata ca in figura 5 , unde:

Diagrama cazurilor de utilizare construita in etapa de analiza a cerintelor se completeaza cu noile cazuri de utilizare rezultate din prezentarea scenariilor, in special a exceptiilor si a alternativelor.

Modelul obiect cuprinde:

.. diagrama claselor, ce evidentiaza structura statica a sistemului;

.. diagramele de secventa, de colaborare si de stare, ce evidentiaza dinamica sistemului.

Analiza de sistem

fig.5

Pentru definirea diagramei claselor (numita si modelul domeniului in aceasta etapa) tinem cont ca:

▪ o clasa este o abstractie pentru :

.. persoane (clienti, furnizori, studenti .)

.. lucruri (catalog de produse, container, factura ..)

.. idei-concepte abstracte (specificatii ale produselor, zborile aeriene, conturi bancare)

▪ in diagrama claselor nu se definesc interactiunile dintre clase ci doar caile de-a lungul carora acestea se formeaza.

▪ includerea unei clase in diagrama se poate face in 2 moduri:

1. clasele se aleg dintre substantivele prezente in textul ce descrie activitatea desfasurata. Problema este ca nu toate substantivele sunt nume de clasa(denumirea clientului este un atribut, facturare este descriere a unei de activitati)

2. se apeleaza la una din urmatoarele categorii de clase utilizate in activitatea de modelare:

Criterii pentru includerea claselor in diagrama claselor

1. se defineste o clasa doar daca sistemul are nevoie sa memoreze date despre ea, pentru a raspunde unor cereri viitoare;

2. se defineste o clasa corespunzatoare unui actor doar daca sistemul are nevoie sa-si aminteasca atributele actorului;

3. se exclud clasele care reprezinta iesiri din sistem, daca sistemul poate calcula informatiile cand are nevoie de ele in viitor; raspunsurile sistemului la evenimente (iesirile din sistem) se pot defini ca atribute, atribute calculate, mesaje.

Criterii pentru includerea atributelor in diagrama claselor

1. se defineste un atribut doar daca sistemul are nevoie de valoriile lui pentru a raspunde unor cereri viitoare;

2. nu se folosesc atribute pentru a inregistra o conexiune intre clase; se folosesc asocieri;

3. un atribut se include intr-o singura clasa;

nu se includ atribute calculate.

Teme:

Completati diagrama cazurilor de utilizare cu noi cazurile de utilizare.

Adaugati cazurilor de utilizare exceptiile si alternativele rezultate din prezentarea scenariilor.

Construiti diagrama claselor pentru cazutile de utilizare descrise.

Pentru definirea diagramelor de secventa, de colaborare si de stare, notiunea de obiect este esentiala in aceasta etapa; obiectele sunt prezentate ca apartinand unui stereotip, vazut ca cel mai important dintre mecanismele de extensie. Stereotipul permite ca elemente cu aceeasi strucutra sa poata primi semnificatie sau utilizare particulara.

Obiectele definite pentru descrierea unui caz de utilizare pot fi:

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

= corespund obiectelor din sistemul real; reflecta concepte si elemente ce apartin domeniului de activitate, afacerii reprezentate; sunt persistente in timp si sunt translatate in tabele ale bazelor de date relationale.

Exemple: facturi, marfiri, clienti.

▪ obiecte de control - stereotip << control>>

= organizeaza comportamentul complex al sistemului. Se definesc in situatii care implica mai multe obiecte de interfata sau obiecte de gestiune.

Exemple: un obiect ce compara continutul unei facturi de aprovizionare cu datele din NIR, un obiect care identifica diferentele rezultate din comparatia anterioara, un obiect care trateaza situatii posibile mentionate la exceptii.

▪ obiecte de interfata (boundary) - stereotip << boundary>>

= controleaza interactiunea cu mediul exterior (outside world). Rolul lor este sa translateze informatiile furnizate de actori in evenimente interne la care raspund obiecte de control sau obiecte de gestiune si sa prezinte raspunsul acestor obiecte astfel incat sa poata fi intelese de actor.

Exemple: fereastra de ecran, formular, caseta de text, butoane, liste derulante.

▪ obiecte de implementare (factory)

= grupeaza elemente legate de structura interna a sistemului. Ele preiau responsabilitatea pentru crearea obiectelor cand sunt definite pentru prima data si pentru transferul lor in/din baza de date pe timpul duratei lor de viata. Cel mai des sunt utilizate ca obiecte legate de persistenta, asigurand comunicarea intre obiecte si baza de date.

Exemplu: Pentru a apela un obiect client dintr-o baza de date relationala, acesta este preluat via un obiect de control intr-un obiect de implementare. Atributul cod client este utilizat pentru a regasi in baza de date o inregistrare cu al carui continut se populeaza atributele obiectului client. Dupa ce obiectul a fost creat in memorie, alte obiecte il pot referii. Trebuie apoi returnat in baza de date; obiectul de implementare poate fi chemat sa transfere atributele modificate in baza de date si sa distruga obiectul de gestiune.

Exemple:

Prezentam in continuare diagrame de secventa construite pentru cateva din scenariile definite anterior.

▪ in diagrama de secvente pentru scenariul 4 (fig. 6) se include doua obiecte: un obiect de interfata utilizat pentru interactiunea cu operatorul si un obiect de gestiune client.

1. prin intermediul obiectului de interfata operatorul tasteaza numarul clientului si-l trimite sistemului;

2. sistemul raspunde cu numele, adresa si numarul clientului; aceasta implica definirea unui obiect de gestiune (al clasei client) care sa memoreze nume, adresa, numar client.

fig. 6

Clasa Client poate fi reprezentata astfel:

3. daca datele afisate pe ecran corespund cu cele furnizate de client, operatorul confirma clientul. Faptul ca datele unui client trebuie validate impune definirea unui obiect de control (Validare) care preia sarcinile confirmarii:

Diagrama de secvente este cea din figura 7:

fig. 7

In acest moment poate fi construita diagrama claselor din figura 8.

fig. 8

Teme:

.Construiti diagrame de colaborare pentru clasele: interfata preluare comanda, clienti, comanda, control comanda, livrare.

.Completati diagrama claselor din figura 9, cu informatii obtinute din diagramele de colaborare.

. Construiti diagrama de stare pentru clasa client.

. Construiti diagrama de stare pentru produse livrate.

C          Proiectarea se ocupa de cum va opera sistemul si-l descompune in componente ce pot fi dezvoltate individual, oferind totodata o vedere de ansamblu asupra sistemului.

proiectarea sistemului implica impartirea sa in subsisteme, si alocarea resurselor hardware si software.

. proiectarea obiectelor continua strategia aleasa in etapa de proiectare a sistemului si rafineaza detaliile.

Schematic, intrarile si iesirile acestei etape pot fi reprezentate astfel:

Proiectare

			Model obiect

Cazurile de utilizare interactioneaza si interfereaza unele cu altele, prin intermediul unor obiecte de baza (comanda este folosita de cazul de utilizare ce reflecta preluarea comenzii si de de cazul de utilizare ce reflecta livrarea unei comenzi).

Diagrama de secvente

. evidentiaza noi interactiuni intre obiecte (pentru actori sau obiecte ale claselor noi introduse dupa faza de analiza);

. poate evidentia crearea unui nou obiect, distrugerea unui obiect sau apelarea unui obiect printr-o operatie proprie;

. verifica daca obiectele definite in faza de analiza sunt viabile pentru implementare sau trebuie restructurate; se adauga informatile schimbate;

. interactiunile din diagrama (mesajele dintre obiecte) trebuie sa se regaseasca printre operatiile clasei obiectului destinatar.

Diagrama de colaborare

.evidentiaza functionalitatile rezultate din interactiunile cazurilor de utilizare;

. inlocuieste mesajele specificate in faza de analiza cu operatii adaugate claselor de obiecte destinatar;

Diagrama de activitati

. detaliaza interactiunile dintre cazurile de utilizare;

. descrie algoritmi ai unor operatii complexe.

Teme:

. Evidentiati in diagrame cazuri de utilizare care interactioneaza si interfereaza unele cu altele.

. Construiti diagrame de colaborare pentru evidentierea functionalitatilor rezultate din interactiunile cazurilor de utilizare.

. Construiti diagrame de activitati ce detaliaza interactiunile dintre cazurile de utilizare (editarea unei facturi);

Diagrama claselor evidentiaza acum un set de obiecte legate unele de altele si organizate astfel incat permit implementarea scenariilor ce descriu cazurile de utilizare; cuprinde detalii necesare implementarii:

. atributelor le sunt adaugate gradele de vizibilitate, eventual valori implicite sau valori initiale;

. pot exista alte obiecte ca atribute (stare,ClsMatAprov);

. operatiile pot manipula atributele obiectelor din clasa, pot apela operatii ale altor obiecte sau pot manipula atribute ale altor obiecte, daca acestea apartin interfetei;

. interactiunile dintre obiecte specificate in faza de analiza sunt reprezentate acum prin operatii; se specifica semnatura operatiilor si nu ce face operatia;

. se fac precizari suplimentare privind asocierile dintre obiecte; ele sunt implementate prin atribute memorate intr-una ori in ambele clase care se asociaza, sau prin evidentierea legaturile dintre tabele in cazul bazelor de date relationale .

Pornind de la aceste consideratii, prezentam in final (fig.9) o diagrama a claselor construita pentru activitatea de contractare si aprovizionare a componentelor necesare asamblarii prouselor comandate de clienti.

fig.9

Teme:

. Construiti diagrama claselor pentru activitatile ce vizeaza preluarea comenzilor si livrarea produselor.

. Construiti diagrame ale claselor pentru procesele descrise in etapa de analiza.