adriana gheorghies‚, ovidiu gheorghies‚ogh/files/ip/curs-03.pdf · diagrama cazurilor de...

1 / 31

Ingineria programarii

Adriana Gheorghies, Ovidiu Gheorghies

23 octombrie 2005

Etapele dezvoltarii programelor

• Etapele dezvoltariiprogramelor

UML - Unified ModelingLanguage

Diagrama cazurilor deutilizare(Use Case Diagram)

2 / 31

• Analiza cerintelor• Proiectarea• Scrierea codului• Testare• Intretinere

Toate etapele dezvoltarii programelor depind de analiza cerintelor.


UML - Unified ModelingLanguage• UML - Istoric (1)• UML - Istoric (2)• UML - Istoric (3)• UML - Istoric (4)• Ce este UML? (1)• Ce este UML? (2)• Tipuri de diagrameUML


3 / 31


UML - Istoric (1)




4 / 31

• 1975-1989 apar primele limbaje de modelare OO• 1989-1994 numarul limbajelor de modelare creste de la 10 la 50• Limbajele de modelare de success din aceasta perioada:

◦ Booch (Grady Booch)◦ OOSE - Object-Oriented Software Engineering (Ivar

Jacobson)◦ OMT - Object Modeling Technique (James Rumbaugh)

UML - Istoric (2)




5 / 31

• La mijlocul anilor 1990 a ınceput un proces de omogenizare, prinıncorporarea ın fiecare limbaj a caracteristicilor gasite ın celelaltelimbaje

• Cauze:

◦ Booch, Rumbaugh si Jacobson, au ajuns la concluzia ca ar fimai bine sa conduca evolutia limbajelor lor pe un acelasidrum, pentru a elimina diferentele gratuite ce nu faceau decatsa ıncurce utilizatorii

◦ industria software avea nevoie de stabilitate pe piatalimbajelor de modelare

◦ convingerea ca prin unirea fortelor se pot aduce ımbunatatiritehnicilor existente

UML - Istoric (3)




6 / 31

• Octombrie 1994 - a ınceput ın mod oficial dezvoltarea UML prinunificarea limbajelor Booch si OMT (Rational Software)

• Octombrie 1995 - apare versiunea preliminara 0.8 a UnifiedMethod

• Iunie 1996 - publicata versiunea 0.9 a UML (include si OOSE)• Pe parcursul anului 1996 multe companii vad ın UML o optiune

strategica pentru dezvoltarea produselor lor• Companii care au contribuit la crearea UML 1.0: DEC,

Hewlet-Packard, I-Logix, Intellicorp, IBM, MCI Systemhouse,Microsoft, Oracle, Rational, Texas Instruments etc.

UML - Istoric (4)




7 / 31

• Ianuarie 1997 - UML 1.0 a fost propus spre standardizare ıncadrul OMG

• Noiembrie 1997 - Versiunea UML 1.1 a fost adoptata ca standardde catre OMG

• Actualmente UML este dezvoltat de catre OMG Revision TaskForce, condus de Cris Kobryn(http://www.omg.org/)

• Versiunea precedenta “definitiva” este UML 1.5• Ultima versiune este UML 2.0 (se mai lucraza la aspecte

“sintactice”)• Resurse oficiale UML: http://www.uml.org

Ce este UML? (1)




8 / 31

• Este un limbaj de modelare bazat pe notatii grafice• Este folosit pentru a

◦ specifica◦ vizualiza◦ construi◦ documenta

componentele unui program (sistem software)

Ce este UML? (2)




9 / 31

• Este un limbaj cu ajutorul caruia se pot construi (descrie)modele.

• Un model surprinde un anumit aspect al unui program• Fiecare model poate fi descris la diferite nivele de abstractizare• Fiecarui model ıi corespunde o diagrama

Tipuri de diagrame UML




10 / 31

• Analiza

◦ Diagrama cazurilor de utilizare (Use Case Diagram)◦ Diagrama de activitati (Activity Diagram)

• Proiectare

◦ Structura: Diagrama de clase (Class Diagram)◦ Comportamentul:

• Diagrama de stari (Statechart Diagram)• Diagrame de interactiuni (Interactions Diagrams)

◦ Diagrama de secventa (Sequence Diagram)◦ Diagrama de colaborare (Collaboration Diagram)

• Implementare

◦ Diagrama de componente (Component Diagram)◦ Diagrama de plasare (Deployment Diagram)



Diagrama cazurilor deutilizare(Use Case Diagram)• Diagrama cazurilor deutilizare (1)• Diagrama cazurilor deutilizare (2)• UseCase (1)• UseCase (2)• UseCase (3)• Actor (1)• Actor (2)• Actor (3)• Relatii (1)• Asociere• Asociere - Exemplu• Asociere - Exemplu• Generalizare• Generalizare -Exemplu• Generalizare -Exemplu• Dependenta• Dependenta -Exemplu• Dependenta -Exemplu• Extension Point• Diagrama UC -exemplu

11 / 31

Diagrama cazurilor de utilizare(Use Case Diagram)

Diagrama cazurilor de utilizare (1)




12 / 31

• Folosita pentru a capta cerintele sistemului• Delimiteaza granitele sistemului• Punctul de plecare ıl constituie scenariile de folosire a sistemului• Poate prezenta:

◦ specificarea cerintelor (externe) din punctul de vedere alutilizatorului

◦ specificarea functionalitatii sistemului din punctul de vedere alsistemului

Diagrama cazurilor de utilizare (2)




13 / 31

Poate contine:

• UseCase-uri = functionalitati ale sistemului• Actori = entitati externe cu care sistemul interactioneaza• Relatii

UseCase (1)




14 / 31

• Este o descriere a unei multimi de secvente de actiuni (incluzandvariante) pe care un program le executa atunci candinteractioneaza cu entitatile din afara lui (actori) si care conduc laobtinerea unui rezultat observabil.

• Pote fi un sistem, un subsistem, o clasa, o metoda

UseCase (2)




15 / 31

• Reprezinta o functionalitate a programului• Precizeaza ce face un program sau subprogram• Nu precizeaza cum se implementeaza o functionalitate• Identificarea use case-urilor se face pornind de la cerinte ale

clientului si analizand descrierea problemei.

UseCase (3)




16 / 31

• Notatie• Atribute

◦ Nume = fraza verbala ce denumeste o operatie saucomportament din domeniul problemei.

• Restrictii

◦ Numele este unic

Actor (1)




17 / 31

• Reprezinta un rol pe care utilizatorii unui use case ıl joaca atuncicand interactioneaza cu acesta

• Este o entitate exterioara sistemului.• Interactioneaza cu sistemul:

◦ Initiaza executia unor cazuri de utilizare◦ Ofera functionalitate pentru realizarea unor cazuri de utilizare

Actor (2)




18 / 31

Poate fi:

• utilizator (uman)• sistem software• sistem hardware

Actor (3)




19 / 31

• Notatie• Atribute

◦ Nume = indica rolul pe care actorul ıl joaca ın interactiunea cuun UseCase

• Restrictii

◦ Numele este unic

Relatii (1)




20 / 31

Se stabilesc ıntre doua elemente:

• Actor - UseCase: asociere• Actor - Actor: generalizare• UseCase - UseCase: asociere, generalizare, dependenta

(<<include>>, <<extend>>)

Asociere




21 / 31

• Modeleaza o comunicare ıntre elementele pe care le conecteaza.

• Poate sa apara ıntre

◦ un actor si un UseCase (actorul initiaza excutia cazului deutilizare sau ofera functionalitate pentru realizarea acestuia).

◦ doua UseCase-uri (transfer de date, trimitere demesaje/semnale)

• Notatie

Asociere - Exemplu




22 / 31

Asociere - Exemplu




23 / 31

Generalizare




24 / 31

• Se realizeaza ıntre elemente de acelasi tip ⇒ ierarhii.• Modeleaza situatii ın care un element este un caz particular al

altui element.• Elementul particular mosteneste relatiile ın care este implicat

elementul general.

• Notatie

Generalizare - Exemplu




25 / 31

Generalizare - Exemplu




26 / 31

Dependenta




27 / 31

• Apare ıntre doua UseCase-uri.• Modeleaza situatiile ın care

◦ Un UseCase foloseste comportamentul definit ın alt UseCase(<<include>>)

◦ Comportamentul unui UseCase poate fi extins de catre un altUseCase (<<extend>>)

• Notatie

Dependenta - Exemplu




28 / 31

Dependenta - Exemplu




29 / 31

Extension Point




30 / 31

• Identifica un punct ın comportamentul unui UseCase ın carecomportamenentul acestuia poate fi extins de catre un altUseCase

• Trebuie sa aiba un nume• Poate avea atasata o conditie

Diagrama UC - exemplu




31 / 31

adriana gheorghies‚, ovidiu gheorghies‚ogh/files/ip/curs-03.pdf · diagrama cazurilor de...

Documents