Proiectarea Sistemelor Informatice

CURS 5

31 octombrie 2007

13:41

UML - standard de notatii, fiind constituit dintr-un set de simboluri diagrame si modele utilizate pe parcursul dezvaltarii sistemelor informatice.

A fost adoptat ca standard in noiembrie 1997.necesitatea adoptarii notatiilor este o consecinta directa a numarului si diversitatii metodologiilor existente. Nu este o metodologie!

Cei care au elaborat UML-ul au dezvoltat si un ghid pentru realizarea SI, care s.n. Rational Unified Process:acesta poate fi considerat o metodologie de analiza si proiectare a SI.

MODELE UML

UML-ul abordeaza sistemul informatic din mai multe perspective corespunzatoare cerintelor diverse (ale utilizatorilor, ale analistilor sau proiectantilor sau cerinte legate de implementare). Ca urmare, UML propune mai multe tipuri de modele:

1. Modelarea proceselor de afaceri (Diagrama Cazurilor de Utilizare)

2. Modelarea structurii sistemului (modelul static). Sunt dezvoltate Diagrama Atlaselor si Diagrama de Obiecte.

3. Modelarea comportamentului sistemului (modelul dinamic). Sunt dezvoltate 4 tipuri de diagrame: Diagrama de Secvente, Diagrama de Colaborare, Diagrama de Activitati si Diagrama de Stari.

4. Modelarea implementarii sistemului (Diagrama de Pakete, Diagrama de Implementare si Diagrama de Desfasurare).

OBS: Din cele 10 tipuri de diagrame, cel mai frecvent utilizate sunt urmatoarele: Diagrama Cazurilor de Utilizare, D. de Clase, D. de Secvente si cea de Activitati. Asadar, nu este obligatoriue dezvoltarea tuturor diagramelor.

Toate diagramele UML interactioneaza intre ele si de obicei cunosc o dezvoltare iterativa prin adunari succesive.

DIAGRAMA CAZURILOR DE UTILIZARE

. Se mai numeste si modelul cerintelor deoarece surprinde cerintele utilizatorilor din partea sistemului proiectat.

. Reprezinta o viziune din exterior asupra sistemului, independenta de modul de implementare.

. Aceasta diagrama este f utila, in identificarea initiala a cerintelor, pe baza discutiilor cu beneficiarii sistemului si de asemenea,pe ntru identificarea granitelor sistemului informatic, adica ce functionalitati vor fi incluse in sistem si care nu.

. Aceasta diagrama cunoaste o evolutie iterativa prin mai multe etape de rafinare.

. Din cauza ca defineste functionalitatea sistemului, se mai numeste si model functional.

ELEMENTE COMPONENTE:

1)CAZUL DE UTILIZARE = serviciu, utilitate furnizata de sistem sau de o componenta a sistemului unui utilizator oarecare. Accentul cade pe CE trebuie realizat,nu pe CUM trebuie realizat. Denumirile sunt simple pentru a putea fi intelese de utilizatorii nespecialisti. ("inscriere admitere", "plata taxa master", "calcul cost productie")

Cazurile de utilizare trebuie sa fie initializate de un actor sau rezultatele lor sa fie vazute de un actor.

Ex: actor=functionar, serviciul oferit=comanda produs (sageata de la omushor la oval).

2)ACTORUL= o entitate exterioara SI care beneficiaza de serviciile furnizate de acesta. Apare sub forma unui rol jucat de o persoana, de un grup de persoane, de un alt sistem sau de un dispozitiv fizic care interactioneaza cu sistemul.

Exemple: student, secretara, departamentul de aprovizionare, contabil, senzor de temperatura, sistem informatic contabil extern, etc.

Pentru a identifica actorii, se va raspunde la urmat intrebari:

. CINE e interesat de info din sistem?

. CINE modifica date din sistem?

. CINE interactioneaza cu sistemul?

Ex: actor1=client, actor2=functionar banca (ambii exteriori sistemului);in sistem: retragere numerar, alimentare bancomat cu numerar (reprezentate prin oval)

Cateodata, pentru a putea grupa cazurile de utilizare care apartin de aceeasi entitate sau subsistem, acestea sunt incadrate intr-un kenar.

Ex: actor=functionar, cazuri de utilizare: comanda produs, preia produsul, refuza produsul.

Un actor poate participa la mai multe cazuri de utilizare, de ex in desenul de mai sus, functionarul realizeaza comandarea produselor si in functie de situatie poate sa preia sau sa refuze produsul comandat. (de ex, dc nu corespunde calitativ)

Un rol poate fi jucat de mai multe persoane (de ex, un functionar poate fi reprezentat de Ionescu, Popescu etc.) Dar putem avea si situatia inversa cand o persoana joaca roluri diferite (de ex, Nicolaescu poate fi simplu programator intr-un proiect, dar este manager de proiect in cadrul altui proiect).