Model de aplicatie privind urmarirea comenzilor primite de la clienti

Model de aplicatie privind urmarirea comenzilor primite de la clienti

Cei mai multi afirma ca punctul de pornire in modelarea UML il reprezinta diagrama cazurilor de utilizare (DCU), motiv pentru care se mai spune ca este o modelare orientata pe cazurile de utilizare. O alta abordare, presupune inceperea modelarii cu descrierea proceselor economice care fac obiectul sistemului informational analizat, caz in care se va utiliza diagrama de activitati (DA). In aceasta situatie, identificarea si formularea cazurilor de utilizare se vor face pe baza DA-lor.

Asadar vom incepe cu DA in scopul modelarii proceselor economice (business processes) din firma.

I. Diagrama de activitati (DA)

1. Elemente teoretice

DA arata, intr-o forma simplificata, ce se intampla in timpul unei operatiuni (a unui obiect) sau a unui proces economic, adica pasii (activitatile), punctele de decizie si ramurile de executie. Este asemanatoare cu schema fluxurilor de informatii (flowchart), insa diferenta esentiala consta in faptul ca permite si controlul concurent al activitatilor si nu doar controlul secvential.

Poate fi considerata ca o extensie a diagramei starilor, insa accentul este mutat pe activitati si nu pe stari. Datorita acestei legaturi stranse, activitatile in DA mai sunt numite si "activity states".

Principalele elemente ale DA sunt activitatile si tranzitiile de la o activitate la alta. Exista un punct de intrare si unul de iesire.

Reprezentarea unui punct de decizie se poate face in doua moduri: folosirea simbolului romb sau specificarea conditiilor (guard) direct pe fiecare flux de control.

Reprezentarea activitatilor concurente (executate in acelasi timp) se face cu ajutorul conectorilor de bifurcare (FORK) sau jonctiune (JOIN). Conectorul de bifurcare arata crearea mai multor fire de executie, iar cel de jonctiune arata ca un fir de executie asteapta pe celelalte sa isi termine actiunile pentru a putea continua prelucrarea.

DA poate fi extinsa prin adaugarea partitiilor (swimlanes) pentru a arata si rolurile (utilizatorii) implicate in executia fiecarei activitati.

O DA poate fi definita pt un CU (descrierea unui proces economic in context organizational) sau pt descrierea unei operatiuni a unui obiect.

2. Exemplu

Figura 1 Diagrama de activitati pentru procesul Inregistrare comanda noua

3. Comentarii

In exemplul de mai sus este prezentata DA pentru inregistrarea unei comenzi noi. Evenimentul declansator este reprezentat de primirea unei comenzi (semnal) din partea clientului. Se verifica existenta clientului in baza de date, iar daca nu exista se solicita persoanei responsabile adaugarea noului client. In cazul in care clientul exista, se continua cu preluarea datelor de pe comanda si calculul valorii comenzii, necesar mai ales pentru verificarea limitei de creditare. Daca limita de creditare este depasita (sold + vaaloare comanda > limita de creditare), atunci se va solicita responsabilului financiar marirea limitei. Daca nu este aprobata marirea, atunci se va transmite clientului o notificare privind respingerea comenzii sale. Daca limita nu este depasita sau este aprobata marirea ei, atunci comanda va trece in starea aprobata si se va continua cu verificarea stocurilor. Daca pentru toate produsele comandate exista stoc suficient, atunci se trece la livrare lor, altfel se va instiinta sistemul de productie in vederea actualizarii planului de productie. Ca raspuns, productia va trimite o notificare privind data prognozata pentru finalizarea productiei, pe baza careia se va actualiza comanda si va fi instiintat clientul.

Activitatea Livrare nu face parte din procesul Inregistrare comanda noua, ea fiind inclusa doar pentru a evidentia continuitatea activitatilor din sistem. Aceasta activitate este complexa, iar descrierea ei va impune construirea unei alte DA.

Nota! Ar fi fost mai bine daca partitia Manager financiar ar fi fost plasata in stanga Desfacerii pentru evitarea intersectarii fluxurilor de control!!!!!

Observati! Legaturile dintre activitatile din diagrama si operatiile incluse in diagrama de clase.

II. Diagrama cazurilor de utilizare (DCU)

1. Elemente teoretice

DCU - realizeaza modelarea sistemului dpdv al utilizatorului. O colectie de CU descrie ceea ce vor utilizatorii de la sistem.

Un CU reprezinta o colectie de scenarii in legatura cu utilizarea sistemului. Fiecare scenariu descrie o secventa de evenimente. Fiecare CU este initiat de un actor (persoana, alt sistem sau trecerea timpului), iar rezultatul reprezinta ceva utilizabil de actorul care a initiat-o sau un altul.

Relatii intre CU (sau cum poate fi pusa in practica reutilizarea CU):

Incluziunea CU - presupune identificarea unor pasi comuni mai multor CU si gruparea lor intr-un CU separat. Trebuie retinut ca un astfel de CU nu are o existenta de sine-statatoare, ci el exista doar ca parte a unuia sau mai multor CU care-l includ.

Extensia presupune crearea unui CU nou prin care se adauga anumiti pasi la un CU existent. Extensia unui CU de baza are loc intr-un anumit punct din acesta, bine stabilit, numit punct de extensie, care trebuie evidentiat in DCU. Ambele relatii (includerea si extensia) se reprezinta printr-o linie de dependenta careia i se ataseaza stereotipul corespunzator.

Generalizarea - un CU mosteneste comportamentul unui alt CU, la care adaga propriul comportament.

Grupare - atunci cand sunt prea multe CU. Se vor utiliza pachetele.

Cum se identifica CU? Se poate porni de la analiza diagramelor de activitati care descriu procesele economice desfasurate in cadrul sistemului. O alta varianta - intervievarea utilizatorilor si analiza atenta a rezultatelor interviurilor (sau a unei sesiuni JAD).

Descrierea pasilor pentru un scenariu al unui CU se poate realiza in doua moduri: forma narativa (se vor specifica, in ordine, urmatoarele elemente: actorul care initiaza scenariul, preconditiile, pasii, postconditiile si actorul care beneficiaza de rezultatele CU) sau construirea unei diagrame de activitati.

DCU este utila mai ales la proiectarea interfetelor utilizator si la testarea sistemului.

2. Exemplu

Figura 2 Diagrama cazurilor de utilizare pentru Sistemul de urmarire a comenzilor

3. Comentarii

DCU din figura de mai sus a fost construita pornind de la DA de la punctul I.2. Se observa ca actiunea Verificare limita credit a fost retinuta ca un CU distinct pe considerentul reutilizarii lui in mai multe CU, respectiv Inregistrare comanda noua, Modificare date comanda si pachetul Livrare. De asemenea, activitatea Aprobare marire limita de credit a fost considerat ca un CU distinct care extinde cele doua cazuri de baza, Inregistrare comanda si Modificare date comanda. Aceasta a fost alegerea analistului, el gandind aceasta situatie ca una de exceptie pe care a dorit sa o evidentieze in DCU, mai ales ca intervine un alt rol (Managerul financiar). Aceeasi discutie pentru Adaugare client nou.

Activitatea Livrare, inclusa in DA, a fost considerata una prea complexa pentru a fi reprezentata ca un singur caz de utilizare. Modelarea ei implica un set de DCU, reunite intrun pachet.

In afara CU rezultate direct din DA, au mai fost adaugate urmatoarele: Modificare date comanda, initiat de client ca urmare a solicitarii acestuia privind modificarea datei de livrare sau a cantitatilor livrate; Anulare comanda, tot ca urmare a solicitarii clientului, dar numai in cazul in care executia comenzii nu este prea avansata.

Relatia dintre Verificare stare comanda si CU de baza Anulare comanda a fost considerata ca extensie si nu ca o incluziune deoarece Verificare stare comanda poate exista si de sine-statator, atunci cand se raspunde solicitarii de informatii din partea clientului cu privire la situatia comenzii sale.

Scenariile posibile pentru CU Inregistrare comanda noua sunt:

Inregistrare comanda client nou,

Inregistrare comanda client existent fara depasirea limitei de creditare,

Inregistrare comanda client existent cu marirea limitei de creditare,

Inregistrare comanda client existent cu neaprobarea maririi limitei de creditare,

Inregistrare comanda cu livrare imediata,

Inregistrare comanda cu livrare ulterioara.

III. Diagrama claselor de obiecte (DCO)

1. Elemente teoretice

DCO sunt utilizate pentru a descrie clasele de obiecte dintr-un sistem si relatiile dintre acestea.

Ce este obiectul?

este vazut drept corespondentul unui concept din lumea reala in SI-le. (obiectul abstractizeaza ceva din lumea reala - angajat, tranzactie, produs)

este caracterizat de o stare (atribute), un comportament (operatii - metode) si o identitate (UID - intern)

este o entitate activa care raspunde la mesaje in vederea realizarii functiilor sistemului din care face parte. Mesaj = apelarea unei operatii a unui obiect de catre altul. Structura mesajului - receptor+selectorul+argumentele

- Ce este clasa?

reuneste obiectele cu stare si comportament similar

un obiect = instanta a unei clase, de la care preia starea si comportamentul.

Tipuri aparte de clase sunt utilizatorii si sistemele externe - considerate actori.

Clasele abstracte - nu sunt folosite pentru a crea obiecte, ci pentru introducerea relatiilor de mostenire. Ele sunt scrise cu caractere "italice".

Atributele class scope global (CSG) - au o singura valoare, comuna pentru toate obiectele din clasa (ex: numarul facturilor din clasa FACTURA)

Pentru atribute se pot specifica: numele (substantiv sau subiect), tip, valori initiale, valori posibile, vizibilitatea. Variabilele CSG sunt subliniate.

Tipuri de metode:

de actualizare sau de citire

constructori si destructori. Creare obiect = alocare spatiu memorie si/sau initializare atribute. Daca exista mai multi constructori, vor avea semnatura diferita.

Abstracte - fara implementare, sunt incluse doar in clasele abstracte.

Pentru operatii se specifica: nume, vizibilitate, lista de parametri, tipul returnat

Operatiile pot fi si ele de tip class scope global (constructorii si destructorii) - adica nu se aplica unui anumit obiect.

Exista 3 categorii: asocieri, dependente si derivari.

ASOCIERI

relatie intre doua sau mai multe clase prin care se modeleaza interdependentele dintre obiectele instantiate din clasele respective.

Relatiile de asociere sunt descrise prin rol si cardinalitate.

Tipuri de asocieri - binara, n-ara si reflexiva

Asocierile alternative (XOR) arata ca un obiect den clasa 1 se va asocia fie cu un obiect din clasa 2, fie unul din clasa 3.

Agregarea - un tip aparte de asociere prin care se reprezinta relatiile de tip parte-intreg - o clasa poate fi modelata ca fiind parte a altei clase

Compozitia - caz particular de agregare, in care partile componente au aceeasi durata de viata cu a intregului. Este un tip de agregare mai puternica, in care fiecare clasa componenta poate apartine unui singur intreg. Putem vorbi de agregari partajate si agregari compuse.

Asocierile pot avea atasate nume (de regula, verbe), directia numelui (opusul poate fi specificat intre paranteze), roluri (optional) si multiplicitate, constraint-uri (XOR).

DERIVAREA

o relatie intre doua clase prin care se modeleaza similitudinile si diferentele dintre acestea - o clasa poate mosteni atributele si metodele unei alte clase.

Se utilizeaza termenii specializare, generalizare si mostenire.

Acest concept este utilizat pentru a organiza clasele in ierarhii. Ierarhie de clase - clase radacina si clase

DEPENDENTE

modificarile asupra elementului dependent se vor reflecta asupra elementului dependent

Arata ca o clasa utilizeaza o alta. Cel mai comun mod de utilizare - se arata ca semnatura unei operatii a unei clase utilizeaza o alta clasa.

Atunci cand se defineste o metoda abstracta, inseamna ca acea clasa forteaza subclasele sa implementeze acea metoda.

2. Exemplu

Figura 3 Diagrama de clase pentru Sistemul de urmarire a comenzilor

3. Comentarii

IV. Diagrama starilor de tranzitie (DST)

1. Elemente teoretice

Ca urmare a interactiunilor cu utilizatorii sau alte sisteme sau ca urmare a trecerii timpului, obiectele sistemului analizat sufera unele modificari (adica isi schimba starea).

O stare este reprezentata de valorile unor atribute.

DST reflecta starile unui obiect, precum si tranzitiile de la o stare la alta. In fapt, ea releva punctul de inceput, cel de sfarsit si schimbarile de stare ale obiectului. Ea arata modul in care un obiect isi schima starea ca urmare a interactiunii cu alte obiecte (adica efectele interactiunilor asupra starii obiectelor). Accentul pe interactiunea dintre obiecte va fi tratata ulterior (diagrama de colaborare si diagrama de secvente).

DST poate fi atasata unei clase, unui caz de utilizare, unui subsistem sau chiar intregului sistem.

In simbolul unei stari pot fi adaugate elementele: numele starii, variabilele de stare si activitatile (evenimente si actiuni de intrare, iesire sau derulate cat timp obiectul se afla intr-o anumita stare).

La liniile de tranzitie pot fi adaugate evenimentul declansator si actiunea, separate cu "slash", precum si conditii de tranzitie (guard condition). Nu este obligatoriu ca fiecare tranzitie sa aiba atasat un eveniment, desi, in cele mai multe situatii se intampla.

Exista 4 tipuri de evenimente care declanseaza o tranzitie:

invocarea unei operatiuni care are ca rezultat modificarea valorii atributelor. Exemplu: apelarea operatiunii verificareLimitaCredit - va determina trecerea in una din cele doua stari, aprobata sau neaprobata;

de timp - dupa un anumit timp se declanseaza trecerea obiectului intr-o alta stare - AFTER. Exemplu: dupa 30 de zile de la livrare, factura devine scadenta;

de schimbare - apar ca urmare a modificarii valorii unui atribut, ceea ce va determina o schimbare de stare - sunt exprimate prin WHEN. Exemplu: la actualizarea valorii platite, daca valoare factura=valoare platita, atunci factura ajunge in starea achitata;

semnal (signal). Exemplu: crearea facturii presupune ca obiectul LIVRARE sa transmita un mesaj-semnal obiectului COMANDA prin care atributul Stare va fi setat pe Onorata.

Structurile de control alternative pot fi utilizate pentru alegerea starii urmatoare in functie de o conditie.

Rolul DS - ajuta dezvoltatorii sa inteleaga comportamentul unui obiect.

Un obiect poate avea mai multe stari in acelasi timp (paralele). Ex. de stari paralele: STUDENT - bursier si caminist si integralist.

Actiunile atasate tranzitiilor reprezinta expresii procedurale care sunt executate daca are loc tranzitia (de exemplu, cand are loc trecerea facturii in starea "scadenta", se va initia notificarea clientului, adica dupa 30 de zile de la data facturii).

2. Exemplu

Figura 4 Diagrama de stari pentru clasa Comanda

3. Comentarii

Prima stare a comenzii este In curs de aprobare, ca urmare a executiei operatiunii creareComanda declansata de evenimentul-semnal Primire comanda. Trecerea comenzii in aceasta stare va declansa automat operatiunea verificareLimitaCredit, in functie de rezultatul careia comanda va trece in una din doua stari posibile: Aprobata, daca limita de creditare nu este depasita, si Neaprobata daca limita este depasita, caz in care se va continua imediat prin invocarea operatiunii marireLimitaCreditare. Daca marirea limitei este aprobata si inregistrata, atunci comanda va trece in starea Aprobata, iar daca nu in starea Respinsa, caz in care va fi declansata executia operatiunii notificareComandaRespinsa.

Trecerea comenzii in starea aprobata va declansa operatiunea verificareStoc, in urma careia se pot ivi doua situatii: stocul este suficient, caz in care se va continua cu livrarea produselor si trecerea comenzii in starea Onorata; stocul este insuficient, caz in care se va executa operatiunea notificareProductie, iar comanda va fi trecuta in starea Lansata in fabricatie.

O alta stare posibila este Anulata, evenimentul declansator fiind solicitarea de anulare din partea clientului. Insa, trecerea comenzii in aceasta stare este posibila numai daca ea nu a fost deja onorata deja. Astfel, am dorit sa evidentiem in mod express ca nu este posibila tranzitia din starea Onorata in starea Anulata.

Toate schimbarile de stare ale comenzii sunt realizate prin operatiunea actualizareStare.

Ar mai putea fi adaugata o stare, Fabricata, prin care sa se evidentieze faptul ca o comanda este gata de livrare. Evenimentul declansator ar fi unul de tip semnal, adica o notificare primita de la sistemul de productie.

V. Diagrama de secvente (DS)

1. Elemente teoretice

DS releva interactiunile dintre obiecte, luand in considerare factorul timp. Interactiunile dintre obiecte au loc intr-o anumita sceventa, prin schimbul de mesaje.

Principalele elemente ale DS sunt: obiectele, mesajele si timpul - reprezentat ca progresie verticala.

Obiectele - plasate in partea de sus. Fiec obiect are o linie a vietii (pe verticala) pe care vor fi reprezentate activarile - care semnifica executia unei operatiuni a obiectului respectiv.

Mesajele - unesc liniile de viata a doua obiecte, dar pot exista si mesaje transmise de un obiect catre el insusi. Exista 3 tipuri de mesaje: simple (transferul controlului executiei unui alt obiect), sincrone si asincrone. Mesajele pot fi insotite de conditii, care arata cand este transmis un mesaj si cand nu, si de parametri.

Timpul - este reprezentat ca progresie verticala, adica mesajele plasate in partea superioara apar mai devreme decat cele situate mai jos.

DS poate include si starile obiectelor, caz in care un obiect poate apare de mai multe ori pentru a reflecta fiecare stare a sa.

DS este intocmita pentru fiecare CU sau doar pentru un scenariu al unui CU.

Pot fi reprezentate si structurile de control - IF si WHILE (paranteze [] plus *)

Crearea unui obiect poate fi pusa in evidenta prin plasarea sa mai jos, pentru a reflecta momentul crearii.

Activarile unui obiect reprezinta punctele de legatura cu DST si DA, iar obiectele fac legatura cu DCO si DO. Oricum, fata de DST, viziunea este mai larga, nefiind limitata la comportamentul unui singur obiect (clasa).

2. Exemplu

Figura 5 Diagrama de secvente pentru cazul de utilizare Inregistrare comanda noua

3. Comentarii

Prima activare a clasei comanda corespunde operatiunii creareComanda. In cadrul acestei operatiuni se calculeaza valoarea comenzii, scop in care sunt necesare preturile produselor si se va transmite un mesaj clasei Produs pentru invocarea operatiunii furnizarePret (prima activare pe linia clasei Produs).

Dupa calculul valorii comenzii urmeaza verificarea limitei de creditare, scop in care se transmite un mesaj de invocare a operatiunii verificareLimitaCredit catre clasa Client. Daca limita nu este depasita este transmis un mesaj de raspuns, iar daca este depasita este invocata metoda marireLimitaCredit a aceleiasi clase Client. In functie de rezultatul acestei operatiuni este invocata metoda actualizareStare (clasa Comanda) si se poate continua in doua moduri: daca marirea a fost aprobata, se continua cu verificarea stocurilor, altfel se transmite un mesaj catre Client pentru invocarea notificComandaRespinsa in vederea instiintarii clientului in legatura cu respingerea comenzii sale.

Verificarea stocurilor este necesara pentru a determina daca poate fi onorata comanda imediat. A doua activare a clasei Produs corespunde duratei de executie a operatiunii verificareStoc invocata prin mesajul 4.2. Daca stocurile sunt insuficiente, atunci se transmite un mesaj de raspuns, care poate contine si data promisa pentru livrare, care va determina activarea operatiunilor actualizare DataOnorarePrognozata si notificareDataOnorarePrognozata, aceasta din urma fiind declansata automat odata cu modificarea valorii atributului DataOnorarePrognozata. Daca stocurile sunt suficiente se va declansa procesul de livrare, evidentiat in figura 5 prin mesajul transmis clasei Livrare pentru invocarea operatiunii creareFactura. Oricum, acest proces este mult mai complex, el fiind redat doar pentru a arata modul de continuare a cazului de utilizare analizat.

Nota! Pentru simplitatea diagramei, nu a mai fost prevazuta situatia verificarii existentei clientului si eventuala adaugare a lui. Includerea ei ar fi presupus doua mesaje schimbate intre clasele Comanda si Client, si plasate in partea superioara a diagramei.

Atentie! Fiecare mesaj schimbat intre clase, cu exceptia celor de raspuns, trebuie sa corespunda invocarii unei operatiuni dintr-o clasa. Aceasta operatiune trebuie adaugata mai intai in DCO si apoi mesajul in DS.

VI. Diagrama de colaborare (DC)

1. Elemente teoretice

DS si DC mai sunt numite si diagrame de interactiune. Ele sunt echivalente dpdv semantic, adica ele prezinta aceleasi informatii, respectiv modul in care interactioneaza obiectele. astfel, fiecare poate fi generata din cealalta.

Totusi, cateva diferente exista: DS accentueaza factorul timp, aratand cum au loc interactiunile in timp; DC accentueaza contextul si organizarea de ansamblu a obiectelor care interactioneaza. De asemenea, DS este aranjata in functie de factorul timp, iar DC in functie de spatiu.

Mesajele sunt reprezentate ca sageti atasate liniilor de asociere a obiectelor. Pentru fiecare mesaj se vor specifica un numar de sceventa, o eticheta si parametrii transmisi. Un mesaj inseamna invocarea unei metode a obiectului destinatie.

Schimbarea starii unui obiect poate fi reprezentata printr-un nou simbol de obiect in care este specificata starea si care va fi unita cu simbolul initial printro linie intrerupta cu sageata.

In DC pot fi adaugate si conditiile care trebuie indeplinite pentru a fi transmis un mesaj.

Structurile alternative si repetitive pot fi reprezentate (ca in DS)

Reprezentarea rezultatelor returnate se face pe mesajul care invoca operatiunea din obiectul destinatie care va efectua calculul.

2. Exemplu

Figura 6 Diagrama de colaborare pentru cazul de utilizare Inregistrare comanda noua

3. Comentarii

Se pot observa lesne similitudinile cu DS.