De cele mai multe ori, în viata de zi cu zi, avem de-a face cu modele. Astfel, atunci când vorbim despre avioane sau automobile, avem în minte anumite caracteristici sau aspecte ale acestor obiecte, de pilda viteza sau forma lor aerodinamica. Aceasta înseamna ca am redus întregul obiect, în cazul de fata destul de complicat, la un model simplu, care se deplaseaza repede si are o forma alungita cu muchii rotunjite, pentru a sustine o teorie sau a demonstra ceva. Celelalte caracteristici, ca de exemplu consumul de carburanti, pretul sau costul întretinerii, au fost neglijate cu buna stiinta pentru ca nu erau relevante pentru teoria noastra. La fel, atunci când ne referim la cunostinte, prieteni sau, dimpotriva dusmani, neglijam, de cele mai multe ori, aspectul lor fizic si ne referim la modelul lor psihologic sau comportamental verificat în relatiile cu propria noastra persoana.
În general, spunem ca nu putem trece la a realiza ceva, fara a avea în minte, la început vag dar mai apoi din ce în ce mai detaliat, un model al obiectului pe care dorim sa-l construim.
Daca ne referim la sistemele informatice, acestea reprezinta ele însele modele informationale ale activitatilor noastre în cele mai diverse domenii - productie, servicii, comert, politica, administratie. Proiectul unui sistem informatic reprezinta planul de realizare al unui asemenea sistem si pleaca, evident, tot de la un model, care reduce sistemul final la elementele lui esentiale permitând abordarea sa sistematica si controlul pe parcursul executiei. Aceasta permite coordonarea echipelor de realizare a proiectului prin verificarea stadiului la care s-a ajuns fata de ceea ce era planificat, precum si elaborarea documentatiei de proiectare.
Definitie
Modelul este, prin urmare, o reprezentare abstracta a unui sistem, care permite planificarea, studiul, analiza, conceptia si verificarea performantelor sistemului înainte de realizarea sa propriu zisa, precum si crearea documentatiei de proiectare, facilitând totodata comunicarea între echipele de proiectare.
Modelul se dovedeste deosebit de util în trei faze diferite ale proiectarii: în specificarea cerintelor noului sistem, în activitatea de analiza a sistemului proiectat, în activitatea de formulare a solutiei informatice pentru sistemul proiectat si realizare a acestuia.
Sistemul proiectat este considerat ca subsistem (cutie neagra), care functioneaza în cadrul unui sist 919c21j em mai larg (de exemplu, întreprinderea sau segmentul de piata al acesteia). Se dezvolta un model de nivel context care precizeaza limitele functionale ale sistemului proiectat.
Modelul reprezinta sistemul proiectat, vazut din interior. Acesta se compune din obiecte care reprezinta o abstractizare a conceptelor manipulate de utilizator precum si relatiile dintre acestea. Se au în vedere: structura statica si comportamentul dinamic al sistemului.
Modelul corespunde mijloacelor de realizare efectiva a sistemului proiectat si evidentiaza conceptele informatice utilizate ca instrumente, limbaje sau platforme de dezvoltare. Modelul serveste la studierea, si anticiparea unei solutii.
Observatii
Este de preferat sa se descopere o eventuala eroare de conceptie pe un model, decât în faza de exploatare sau de testare a sistemului deja realizat.
Un obiect poate fi abstractizarea unei entitati specifice utilizate în analiza sau componenta unei solutii de program în faza de realizare. Corespondenta între acestea este înca mai evidenta daca limbajul utilizat este el însusi orientat obiect (ex.C++ sau Java)
Realizarea "clasica" a sistemelor, sub forma "caderii de apa în cascada" (waterfall) - vezi Introduction to object-oriented systems development, B329 Unit 1, External Course Assessor, Dr.Lucas Chi-kwong Hui, University of Hong Kong, pag.4-22 - a fost conceputa înca din 1970 si consta în 4 mari faze care se executau succesiv si integral: analiza, proiectarea, constructia si testarea. Au fost realizate si instrumente de management pentru planificarea, executia si controlul punerii în practica a unei asemenea metodologii, cum ar fi SDLC (systems development life cycle) care consta în spargerea proceselor complexe în faze si activitati. Principalele instrumente utilizate erau diagramele de relatii între entitati (relation diagrams) si diagramele de fluxuri de date (flowcharts).
Principalul inconvenient al SDLC este ca nu putem fi siguri ca avansam în construirea adevaratului sistem pâna când nu îl realizam si îl testam. Ori, este aproape sigur ca pe parcursul proiectarii si chiar dupa terminarea sa, procesul va suferi numeroase schimbari. În acest caz, riscurile reluarii proiectarii, aproape de la zero, sunt enorme.
O ameliorare a acestei metode, SDLC iterativ, a aparut mai târziu, dupa 1980 si consta în realizarea unui nucleu al sistemului în jurul caruia acesta se dezvolta pas cu pas si se completeaza pe masura necesitatilor aparute.
Spre deosebire de SDLC, proiectarea orientata obiect, descrisa ca un proces unificat (Unified Process), se bazeaza pe o abordare obiect înca de la începutul analizei. Aceasta înseamna, în primul rând, definirea actorilor umani si a functiilor sistem ca obiecte care interactioneaza pentru a produce un anume rezultat distinct si important pentru proiect - cazul de utilizare. Apoi cazurile de utilizare se detaliaza în clase de obiecte de acelasi fel, care contin date caracteristice si modurile lor de utilizare. În sfârsit, comportamentul sistemului este descris prin diagrame de secvente si de colaborare între aceste clase, care se finalizeaza prin realizarea tuturor functiilor sistemului proiectat.
Asadar, în cadrul unei categorii de obiecte de acelasi fel (clasa) se definesc, alaturi de tipurile de date (atribute), toate actiunile de care obiectele apartinând aceleiasi clase sunt responsabile (operatii). Acesta este primul principiu, acela al încapsularii datelor si metodelor.
Un al doilea principiu, este mostenirea, cu alte cuvinte transmiterea proprietatilor unei clase (numita si superclasa), catre o asa zisa clasa derivata, care pe lânga caracteristicile mostenite poate avea si alte proprietati.
În sfârsit, al treilea principiu al abordarii obiect este polimorfismul, adica pastrarea aceleiasi denumiri pentru operatii asemanatoare dar cu functiuni diferite, identificarea facându-se dupa formatul de apel (forma si numarul parametrilor) dar si dupa clasa careia îi apartine. Aceasta permite simplificarea întelegerii logicii procedurilor si actiunilor, respectiv a programelor care le pun în aplicare.
Marele avantaj al abordarii obiect este acela ca, daca se alege ca mediu de programare tot un limbaj orientet obiect (de ex.C++ sau Java), obiectele se pastraza si evolueaza în aceeasi structura si interrelationare, de la analiza pâna la realizare.
Astazi, standardul industrial de modelare obiect este UML (Unified Modeling Language), dezvoltat sub directa responsabilitate a OMG (Object Management Group) - un grup industrial interesat în unificarea metodologiei de proiectare si standardizarea tehnologiilor obiect, pentru a putea garanta interoperabilitatea sistemelor importante. OMG cuprinde actualmente peste 800 membri, printre care Sun, IBM, Microsoft etc., dar si mari întreprinderi utilizatoare din toate sectoarele de activitate.
În figura 1_1 este schematizat istoricul nasterii si dezvoltarii UML. Parintii acestui limbaj sunt considerati a fi Grady Booch, James Rumbaugh si Ivar Jacobson datorita unor prime lucrari în acest domeniu - Object Management Technology (OMT) si Object Oriented System Engineering (OOSE) - înca din 1994. În 1995 se consemneaza o prima tentativa de unificare a conceptelor încercata de Booch si Rumbaugh, la care se alatura si Jacobson în 1996. Lucrarea comuna este înaintata OMG în ianuarie 1997 când apare si prima versiune UML 1.0. adoptata la sfârsitul acestui an, dupa anumite completari, sub numele UML 1.1. Eforturi sustinute de standardizare din parte a OMG duc la aparitia unor versiuni din ce în ce mai complete, aplicabile în industrie: 1.3 în 1999 si UML 1.4 în septembrie 2001. Astazi se aplica pe scara larga versiunea 2.0 si, de curând, si-a facut aparitia versiunea 3.0 care este aplicata experimental.
Conform UML, un concept derivat din cerintele utilizatorului în conformitate cu cazurile lui de utilizare este proiectat mai departe în realizarea modelului si în programare. Invers, plecând de la program, putem descoperi carei necesitati îi corespunde acesta si, în consecinta, care este ideea care a stat la baza proiectului (reverse engineering).
UML este un limbaj esentialmente grafic, ce se defineste în jurul mai multor categorii de diagrame, fiecare dintre acestea fiind dedicata reprezentarii unor concepte particulare ale unui sistem informatic: prima categorie descrie serviciile functionale, a doua priveste structura statica a sistemului iar cea de-a treia se refera la dinamica functionarii sistemului.
Diagramele functionale se bazeaza exclusiv pe cazurile de utilizare (use case diagram) pentru specificarea cerintelor sistemului. Paradigma de reprezentare este ilustrata în figura 1_2 a si are urmatoarea semnificatie: Actorul participa la Cazul de utilizare reprezentat în diagrama. Atât actorii cât si cazurile de utilizare trebuie sa poarte denumiri unice, între cazurile de utilizare existând si anumite relatii de care ne vom ocupa ulterior. Cazurile de utilizare arata ce anume trebuie proiectat, fara a da vreo indicatie cum sa se faca acest lucru.
Diagramele statice, numite si diagrame structurale, arata legaturile între diferitele elemente de structura ale modelului si se refera la:
Diagramele de clase (class diagram), a caror paradigma de reprezentare se vede în figura 1_2 b, constituie punctul central al dezvoltarii obiect. În figura mentionata, clasa B - caracterizata prin atributele atribut2 si atribut3 si operatiile operatie2 si operatie3 - este asociata clasei A - caracterizata prin atribut1 si operatie1 - printr-o relatie de agregare. Cu alte cuvinte, un numar neprecizat de instante ale clasei B (notat cu 0..*) intra în compunerea unei instante apartinând clasei A. Pe de alta parte, clasa A este legata printr-o relatie de generalizare /particularizare de sub-clasa A1 care îi mosteneste proprietatile (atribut1 si operatie1) având în plus operatie4.
Pentru analiza, diagrama de clase este utila deoarece descrie structura entitatilor manipulate de utilizator.
În realizarea modelului, cu o diagrama de clase se reprezinta de obicei structura programelor orientate obiect sau, mai precis, modulele limbajului de dezvoltare.
Diagramele de componenta (component diagram)[1], a caror paradigma de reprezentare este data în figura 1_2 c, constituie concepte de configurare a programelor în pachete de programe, în fisiere sursa sau în biblioteci. Aceste concepte arata cum se leaga între ele fisierele sursa, pachetele de programe si bibliotecile, în cadrul sistemului informatic proiectat. Astfel, în figura mentionata sunt reprezentate pachetul de programe de tip <<Applet>>, care cuprinde toate programele de interfata om-masina (IOM) si care comunica cu pachetul de programe de tip <<Baza de date>> numit Clienti. Cele doua pachete de programe pot fi amplasate pe masini diferite sau în biblioteci diferite în cadrul sistemului informatic.
Diagramele de desfasurare sau de aranjare în teren (deployment diagram) , a caror paradigma de reprezentare se vede în figura 1_2 d, corespund structurii de retea informatica ce preia sistemul de programe si modului în care sunt instalate componentele de retea. Astfel, din figura 1_2 d rezulta ca sistemul local este constituit din serverul central, la care sunt legate un server de înlantuire si un server Web.
Diagramele dinamice, numite si diagrame comportamentale, arata cum interactioneaza între ele diferitele elemente ale modelului si sunt alcatuite din:
Diagramele de activitati (activities diagram), a caror paradigma de reprezentare este ilustrata în figura 1_2 e. Ele reprezinta regulile de înlantuire ale activitatilor în cadrul sistemului, de exemplu, navigarea într-un site Web. Activitatile sunt reprezentate prin dreptunghiuri ovalizate iar trecerea de la o activitate la alta prin sageti, care se întâlnesc în noduri de stare marcate prin linii verticale. Ansamblul activitatilor are un punct de intrare si un punct de iesire, marcate ca în figura.
Diagramele de stare (states diagram), a caror paradigma de reprezentare este data în figura 1_2 f. Ele reprezinta ciclul de viata comun obiectelor unei aceleiasi clase si permit completarea cunostintelor claselor, atât în cadrul analizei cât si în cazul conceptiei. Conventia de reprezentare este inversa ca la diagramele de activitati, cu alte cuvinte starile sunt marcate prin dreptunghiuri cu colturi rotunjite iar drumul de la o stare la alta prin sageti reprezentând actiuni specifice. Ca si la diagramele de activitati, exista mai multe cai prin care se poate ajunge de la o stare la alta. Alegerea unei cai sau a alteia depinde de conditiile în care se afla sistemul la momentul respectiv. În diagrama din figura 1_2 f nu sunt mentionate punctele si conditiile de alegere.
Diagramele de secventa (sequence diagram), a caror paradigma de reprezentare este ilustrata în figura 1_2 g. Diagramele de secventa servesc, în primul rând, dezvoltarii de scenarii în cadrul analizei utilizarii sistemului. În diagramele de secventa mesajele sunt reprezentate orizontal, pe o axa a timpului de sus în jos, de atâtea ori de câte ori apar.
Diagramele de colaborare (cooperation diagram), a caror paradigma de reprezentare este data în figura 1_2 h. În diagramele de colaborare exista o singura cale, care uneste doua elemente (clase, actori), mesajele care circula pe aceasta cale împreuna cu sensul lor fiind marcate pe margine cu sageti. De obicei, diagramele de colaborare se construiesc pe baza diagramelor de secventa si figureaza schimburile de mesaje între obiecte în cazul anumitor functionari particulare ale sistemului. Atât diagramele de secventa cât si diagramele de colaborare sunt, ambele, diagrame de interactiune UML.
Actor
Comertul electronic (e-commerce) se refera, în general, la utilizarea tehnologiilor informatiei si comunicatiilor (TIC) în:
Cercetarea pietei;
Încheierea contractelor sau a diferitelor tranzactii de afaceri;
Achizitionarea de materiale, distribuirea produselor si derularea vânzarilor, inclusiv prin intermediul magazinelor electronice.
Daca primele doua domenii sunt strâns legate de relatia client-furnizor si asigurarea confidentialitatii schimbului de informatii de afaceri[2], cel de-al treilea domeniu mentionat mai sus pune accentul pe integrarea pe suport informatic a tuturor proceselor care asigura profitabilitatea întreprinderii. Acestea se refera atât la activitatile interne cât si la legaturile informationale cu mediul (e-business).
Magazinul electronic reproduce într-un spatiu virtual functiunile magazinului clasic, cu urmatoarele avantaje: spatiu mult mai redus pentru depozitarea marfurilor, disparitia costurilor pentru locatie, personal spacializat în vânzari, energie s.a., reclama aproape gratuita, internationalizarea clientelei, dar si dezavantajul unei clientele mult mai fluctuante în functie de noutatea si competitivitatea produselor oferite.
În cele ce urmeaza ne vom referi la o asemenea aplicatie de gestionare a unui magazin electronic, care ofera spre vânzare carti.
Se urmareste construirea unei "librarii on-line" pe un site Web si, cu acest prilej, trecerea în revista a tuturor instrumentelor metodologice de proiectare orientate obiect.
Societatea comerciala "Libraria X" a decis sa intre în rândul marilor librarii on-line, deja functionale pe site-uri Web precum www.amazon.fr, www.fnac.com, www.eyrolles.com s.a.
Obiectivul fundamental al viitorului site www.librariaX.com este de a permite navigatorilor pe Web de a cauta opere pe teme, autori, cuvinte-cheie etc., de a-si constitui un cos virtual propriu si apoi de a-l putea comanda si plati direct pe Web.
Scopul proiectului este de a ocupa o pozitie în fata concurentilor generalisti, introducând rapid elemente de noutate. În acest scop, site-ul va trebui sa fie evolutiv si performant.
Site-ul www.librariaX.com va trebui sa regrupeze toate functionalitatile necesare cautarii, descoperirii detaliate de lucrari, selectiei acestora si lansarii de comenzi on-line.
Prima etapa, pentru persoana care navigheaza, consta în a gasi, cât mai rapid posibil, lucrarea pe care o cauta, în catalog. Referintele lucrarii fiind mai mult sau mai putin precise, este preferabil sa se furnizeze mai multe criterii de cautare. Persoana care navigheaza trebuie sa poata alege un criteriu: titlu, autor, ISBN etc, sau mai multe criterii simultan (vezi exemplul de formular de interfata om-masina IOM pentru cautare rapida din figura 1_3). Ar fi de dorit ca rezultatele cautarii sa fie disponibile pe o pagina si sa poata fi usor parcurse si reclasate.
Fig.1_3 Formular de interfata
om-masina IOM pentru cautarea rapida
Daca persoana în cauza nu are o idee precisa despre ceea ce cauta, trebuie sa i se ofere un mijloc de a se plimba - asa cum ar face-o daca s-ar afla într-o adevarata librarie - si a avea acces la o clasificare tematica, la noutati, la o lista cu cele mai bune vânzari etc (vezi, de exemplu, ecranul IOM de cautare generala din figura 1_4. Acesta este de fapt o fereastra care se afla în permanenta în partea superioara a paginilor de cautare).
Informatica întreprinderi management stiinta tehnica practica
Introducere Cercetare avansata Teme Noutati Subiectul lunii Cele mai bune vânzari
Cautare rapida Tema
|
Fig.1_4 Ecranul IOM de cautare generala |
Fiecare carte vânduta în cadrul site-ului trebuie sa fie prezentata în detaliu, punându-se în evidenta urmatoarele elemente:
o imagine (pentru majoritatea lucrarilor) care sa poata fi, eventual, marita;
pretul si disponibilitatea;
comentarii ale clientilor;
tabla de materii detaliata, extrase, etc. (a se vedea, de exemplu, schita IOM a paginii de prezentare a fisei detaliate a lucrarii din figura 1_5).
Fig.1_5 IOM - Fisa detaliata a
lucrarii
Într-un veritabil magazin, clientul îsi alege articolele, unele dupa altele, le depune în cosul sau, apoi merge la cassa pentru a plati. Site-ul Web încearca sa reproduca aceasta obisnuinta de cumparare. Astfel, navigatorul îsi poate înregistra cumparaturile într-un cos virtual (vezi exemplul de cos virtual) având apoi posibilitatea de a adauga, a sterge sau a modifica cifra care exprima cantitatea, înainte de a plati.
În orice moment, clientul poate accesa formularul bonului de comanda, în care îsi trece coordonatele si informatiile necesare pentru plata si livrare (vezi exemplul de bon de comanda). Pentru a garanta securitatea si confidentialitatea, se impune ca trimiterea datelor sa fie criptata. În cazul în care se doreste, sistemul trebuie sa fie capabil sa emita un deviz, care sa poata fi imprimat de client pentru a comanda prin fax sau curier.
Clientul trebuie sa-si poata apoi urmari comenzile, sa le poata modifica înainte de a fi expediate, într-o maniera securizata.
Exigentele nefunctionale se refera la calitate si la performanta.
Sa cumperi o carte pe Web nu trebuie sa-ti ia mult timp si nici sa ai cunostinte speciale. În acest scop, trebuie:
- sa existe o prezentare clara si intuitiva;
- formularul de comanda sa fie simplu;
- help-ul on-line sa fie puternic. Clientul trebuie sa poata consulta help-ul contextual în orice moment si sa navigheze pe paginile de help. Ar fi de dorit ca noilor vizitatori sa li se propuna o vizita ghidata.
Libraria X trebuie sa poata gestiona conturi de peste 10.000 de clienti;
site-ul Web trebuie sa suporte peste 1.000 conexiuni simultan;
catalogul trebuie sa poata cuprinde peste 1.000.000 de titluri;
cautarea nici unei carti nu trebuie sa consume mai mult de 30 secunde.
Informatiile referitoare la lucrarile prezentate pe site provin, de regula, din doua surse complementare:
prima serveste la alimentarea bazei de date cu toate lucrarile noi;
cea de-a doua serveste la actualizarea datelor referitoare la pret si starea stocului de carti din catalog.
Sursele mentionate vor fi încarcate automat, periodic, în baza de date.
Orice alte informatii vor fi culese manual, cu ajutorul unei mici aplicatii intranet dedicate îmbogatirii datelor referitoare la lucrari.
Datele culese din site-ul Web si înregistrate în baza de date descriu coordonatele clientilor si caracteristicile comenzilor acestora.
Coordonatele clientilor sunt memorate. În prima faza, ele permit trimiterea pachetului corespunzator comenzii. În faza a doua, acestea economisesc o noua colectare a datelor cu prilejul unei noi comenzi.
Toate datele personale sunt protejate iar confidentialitatea lor este garantata.
Comenzile sunt înregistrate, apoi tratate ulterior de serviciul clienti. Clientii pot consulta istoricul tuturor comenzilor lor.
Cosul navigatorului nu va fi salvat în baza de date. Durata sa de viata nu va depasi pe aceea a vizitei utilizatorului.
Culegerea numarului cartelei de credit a clientului trebuie sa se efectueze securizat, criptând transferul HTTP prin intermediul protocolului SSL. Comanda si numarul cartelei de credit sunt stocate în baza de date pâna la prelucrarea comenzii. Banca în cauza va valida tranzactia dupa care, numarul cartelei de credit va fi suprimat din baza de date.
Pentrul site-ul www.librariaX.com avem urmatorii actori umani:
navigatorul: persoana care viziteaza site-ul;
Web-master-ul: rolul angajatilor care au în sarcina buna functionare si întretinerea site-ului Web;
serviciul clienti: rolul angajatilor care se ocupa cu urmarirea comenzilor-client;
librarul: rolul angajatilor responsabili de continutul redactional al site-ului.
De asemenea, avem în vedere:
sistemul informatic "Noutati" conectat la site-ul Web, care alimenteaza baza de date cu toate noile lucrari;
"Gestiunea stocurilor", care serveste la actualizarea datelor privind pretul si stocul de carti din catalog.
Aceste doua surse sunt încarcate în baza de date în mod automat si periodic.
Ansamblul actorilor este reprezentat în figura 1_6.
Observatii
Un actor reprezinta un rol jucat de o entitate externa (utilizator uman, dispozitiv material sau alt sistem) care interactioneaza direct cu sistemul studiat. Un actor poate consulta sau modifica direct starea sistemului, emitând sau primind mesaje purtatoare de informatii.
Actor este acela care beneficiaza de utilizarea sistemului. Eliminati, pe cât posibil, actorii "fizici" în favoarea celor "logici". Aceasta ne permite sa depasim tehnologiile de interfata care risca sa evolueze si sa identificam "actorii logici", susceptibili de a fi reutilizati. De exemplu, chiar daca aceeasi persoana fizica poate juca succesiv rolurile de librar si Webmaster fata de site-ul Web, este vorba de doi actori diferiti, doua profiluri distincte.
Definitie
Un caz de utilizare reprezinta un ansamblu de secvente de actiuni realizate de sistem, care produc un rezultat observabil interesant pentru un anume actor.
Un caz de utilizare modeleaza un serviciu adus de sistem. El exprima interactiunile actori - sistem si aduce o valoare adaugata notabila respectivului actor.
O eroare frecventa este aceea de a dori sa se mearga prea în detaliu. Un caz de utilizare reprezinta secvente de actiuni realizate de sistem, care reprezinta în mod precis un obiectiv specific al actorului. Cazul de utilizare nu trebuie deci sa se reduca la o singura secventa si nici la o singura actiune.
Pentru fiecare actor identificat anterior, sa cercetam deci diferitele intentii specifice în care utilizeaza sistemul.
Exprimarea exigentelor functionale a pus în evidenta principalele cazuri de utilizare ale navigatorului: cautarea lucrarilor, gestionarea cosului si efectuarea comenzii. Sa reprezentam acest lucru printr-o diagrama de cazuri de utilizare (vezi figura 1_7).
Serviciul Clienti
Fig.1_7 Cazuri de utilizare pentru navigator
Observatii
Fiecare caz de utilizare trebuie sa aiba un obiectiv în sine si sa poata fi realizat independent de altele. De exemplu, un navigator poate vizita site-ul cu unicul scop de a cauta lucrari, fara intentia de a cumpara. El poate sa gestioneze un cos virtual numai pentru a face o simulare sau pentru a obtine un deviz. Toate aceste obiective sunt independente si auto-suficiente, reprezentând adevarate cazuri de utilizare.
Utilizarea sagetii în asocierea cu Serviciul Clienti semnaleaza un sens unic de transmitere a informatiei.
Definitie
Asociere este o relatie între elemenetele UML (clase,cazuri de utilizare etc) care descrie un ansamblu de legaturi.
În relatiile reprezentate în figura 1_7, o legatura înseamna: "Actorul x participa la cazul de utilizare y".
Angajatii întreprinderii "Libraria X", librarul si webmaster-ul, au urmatoarele sarcini:
sa întretina catalogul, ceea ce face sa intervina cele doua sisteme: "Noutati" si "Gestiunea stocurilor";
sa întretina informatiile editoriale;
sa întretina site-ul.
Aceste cazuri de utilizare sunt reprezentate în figura 1_8.
Întretinerea site-ului Webmasterul Fig.1_8 Cazuri de utilizare pentru angajati
Observatie
Remarcati sagetile de navigabilitate catre cazurile de utilizare: actorii ne-umani nu fac decât sa trimita mesaje sistemului, fara sa primeasca vreunul.
Pentru a detalia diagrama cazurilor de utilizare, UML defineste trei tipuri de relatii standard între cazurile de utilizare:
relatia de incluziune, formalizata prin cuvântul-cheie <<include>>, în care cazul de utilizare de baza încorporeaza explicit un altul, într-o maniera obligatorie;
relatia de extensie, formalizata prin cuvântul-cheie <<extinde>>, în care cazul de utilizare de baza încorporeaza implicit un altul, de maniera optionala;
relatia de generalizare /specializare, reprezentata printr-o sageata cu vârful alb catre elementul generalizant, în care cazurile de utilizare descendente mostenesc descrierea generalizantului. Fiecare dintre acestea pot cuprinde interactiuni specifice suplimentare.
Primele doua relatii se reprezinta printr-o linie întrerupta, în timp ce cea de-a treia se reprezinta printr-o linie continua. În primele doua relatii, sageata de la capatul liniei întrerupte marcheaza "ce" include, respectiv "cine se extinde", cazul de utilizare aflat la capatul fara sageata marcând "cine" include, respectiv "cu ce se extinde".
Observatii
Cele trei cazuri principale ale navigatorului sunt legate în mod natural prin relatii de extensie (vezi figura 1_7): cautarea se poate finaliza cu punerea unei lucrari în cos iar gestiunea cosului poate da nastere la o comanda.
Diferitele posibilitati de cautare a lucrarilor pot fi modelate cu precizie printr-o relatie de generalizare /specializare, asa cum se arata în figura 1_9.
Fig.1_9 Relatii de specializare ale cazului
de utilizare Cautarea
lucrarilor
Cautarea lucrarilor este, în figura 1_9, un caz virtual (nu se realizeaza decât prin specializarile sale).
Cazurile de utilizare ale angajatilor nu pun în evidenta nici o relatie între ele.
Pe lânga cele de mai sus, navigatorul mai are urmatoarele cazuri de utilizare:
consultarea comenzilor în curs;
consultarea help-ului on-line
Consultarea comenzilor în curs apare în momentul în care navigatorul doreste sa intre pe site-ul www.librariaX.com pentru a trece în revista propriile comenzi si, eventual, a face unele completari. Evident, în acest caz el trebuie sa se identifice cu un nume utilizator (user name) si parola (password) date de sistem, fara a mai fi obligat sa furnizeze toate datele sale personale. Accesul este limitat numai la comenzile proprii.
Help-ul on-line apare în toate aplicatiile Web si este disponibil utilizatorului în orice faza a derularii acestora, cu alte cuvinte pentru toate celelalte cazuri de utilizare descrise mai sus.
În figura 1_10 este reprezentata diagrama completa a cazurilor de utilizare ale navigatorului si relatiile dintre acestea.
Observatii
Consultarea help-ului on-line nu trebuie neglijata, dar nu este un caz de utilizare major.
Consultarea help-ului on-line poate extinde toate celelalte cazuri de utilizare. În orice moment, fie la cautarea lucrarilor, fie la gestiunea cosului etc, navigatorul poate sa întrerupa activitatea pentru a consulta help-ul on-line si apoi sa continue activitatea întrerupta.
Sa încercam sa simplificam vederea de ansamblu asupra cazurilor de utilizare analizate, utilizând în acest scop un alt tip de diagrama UML si anume aceea în care are loc o grupare (pachetare) a cazurilor pe anumite criterii. Din cele de mai sus rezulta ca am putea grupa cazurile de utilizare ale navigatorului, cazurile de utilizare ale angajatilor si cazul de utilizare secundar de consultare a help-ului on-line în pachete separate (vezi figura 1_11). Asa cum se vede în figura, actorii - atât cei externi cât si cei interni - sunt grupati la rândul lor într-un singur pachet denumit Actori.
Fig.1_11 Pachetarea cazurilor de utilizare
Putem ierarhiza realizarea cazurilor de utilizare, tinând cont de:
prioritatea functionala determinata de serviciul Marketing al întreprinderii;
riscul tehnic estimat de seful de proiect.
Un exemplu de ordine de abordare rezultata din evaluarea cazurilor de utilizare tinând cont de criteriile de mai sus este dat în tabelul 1_1.
Tabelul 1_1 Clasamentul cazurilor de utilizare
|
Caz de utilizare |
Prioritate |
Risc |
Ordine de abordare |
|
Cautarea lucrarilor |
înalta |
mediu | |
|
Gestionarea cosului |
înalta |
scazut | |
|
Efectuarea comenzii |
medie |
înalt | |
|
Consultarea comenzilor în curs |
scazuta |
mediu | |
|
Consultarea help-ului on-line |
scazuta |
scazut | |
|
Întretinerea catalogului |
înalta |
înalt | |
|
Întretinerea informatiilor editoriale |
medie |
scazut | |
|
Întretinerea site-ului |
medie |
scazut |
Conform clasificarii de mai sus se poate elabora o planificare a proiectului care urmeaza ordinea de abordare mentionata în ultima coloana a tabelului 1_1.
Aceasta ordine de abordare este deosebit de importanta, atât pentru seful de proiect care trebuie sa-si organizeze echipele cu care sa atace proiectul si sa planifice întreaga actiune, cât si pentru conducerea întreprinderii care trebuie sa-si planifice resursele pe care sa le puna la dispozitia proiectului în asa fel încât sa nu întârzie desfasurarea acestuia.
Observatii
Efectuarea comenzii este de prioritate medie, deoarece navigatorul poate scoate la imprimanta devizul si apoi poate comanda prin fax sau curier trimitând plata prin posta.
Accentul este pus pe "Întretinerea catalogului" si "Cautarea lucrarilor", care sunt indispensabile în prima instanta.
La nivelul riscurilor tehnice, seful de proiect a considerat "Întretinerea catalogului" ca având cel mai înalt nivel de risc, din cauza problemelor legate de integritatea informatiilor (actualizate semi-automat în baza de date) si necesitatii de a dispune de un catalog valid si la zi.
"Efectuarea comenzii" este considerata, de asemenea, ca având un nivel înalt de risc, datorita problemelor de confidentialitate si de criptare ce trebuiesc rezolvate.
Unul din principiile Procesului Unificat rezultat din dezvoltarea orientata obiect bazata pe UML este acela de a identifica si înlatura mai întâi riscurile majore.
Daca prioritatea este înalta si riscul de asemenea, cazul trebuie abordat în prima instanta. De aceea, "Întretinerea catalogului" a fost situata pe primul loc în tabelul 1_1.
Daca prioritatea este scazuta si riscul de asemenea, se poate lasa cazul printre ultimile de rezolvat (vezi "Consultarea help-ului on-line" în tabelul 1_1).
Atunci când cele doua criterii sunt antagoniste, seful de proiect trebuie sa decida cântarind argumentele pro si contra si tratând, eventual, cu clientul pentru a stabili ordinea de abordare a cazului de utilizare respectiv.
Întrebari
Ce este un model si unde se utilizeaza? Câte feluri de modele cunoasteti si care sunt acestea?
Ce este UML si cum a aparut?
Câte feluri de diagrame UML cunoasteti (functionale, statice, dinamice)?
Enuntati studiul de caz "e_commerce". Care este scopul acestuia?
Ce exigente functionale exista în studiul de caz "e_commerce" (cautarea, descoperirea, selectia, comanda)?
Ce exigente nefunctionale puteti enumera în studiul de caz "e_commerce" (de calitate, de conceptie)?
Ce restrictii de conceptie exista în cadrul studiului de caz "e_commerce" (referitoare la actualizarea datelor de referinta, la actualizarea datelor din formularele site-ului, la cos sau la plata securizata)?
Ce tipuri de actori puteti identifica pentru site-ul www.librariaX.com ?
Reprezentati diagramele cazurilor de utilizare pentru: a) navigator; b) angajati.
Explicati relatiile dintre cazurile de utilizare ale navigatorului.
Ce sunt pachetele de cazuri de utilizare si la ce sevesc ele? Ce diagrama de pachete apare evidenta pentru cazurile de utilizare în cadrul studiului de caz "e_commerce"?
Cum pot fi ierarhizate cazurile de utilizare ale site-ului www.librariaX.com si care va fi ordinea lor de abordare?
Aplicatii practice
Alegeti o alta aplicatie (de exemplu, gestionarea productie din cadrul unei întreprinderi). Ce exigente functionale exista? Ce restrictii de conceptie puteti enumera în aces caz? Care sunt actorii principali?
Reprezentati diagramele cazurilor de utilizare pentru: a) seful sectiei care alcatuieste programul de fabricatie periodic b) lansatorul productiei; c) maistrul care distribuie sarcinile în atelier; d) gestionarul magaziei de materiale, piese, subansambluri; e) agentul de aprovizionare. Exista relatii între acestea? Reprezentati-le.
În 1998 OECD (Organizatia pentru Cooperare si Dezvoltare Economica) a definit comertul electronic ca pe o suma de afaceri derulate pe retele care utilizeaza protocoale non-proprietar stabilite pe baza unor standarde deschise, ca de exemplu Internet. Numai ca, folosirea Internetului în tranzactiile comerciale ridica serioase probleme de confidentialitate. Acestea sunt în mare parte rezolvate astazi prin folosirea semnaturii electronice - codificare electronica a documentului si semnatarului al carui secret este asigurat printr-un sistem de chei electronice si printr-o ierarhie de institutii de garantare a utilizarii acestora.
|
