Diagrames UML

Introducció
● Què és UML?:

○ Unified Modeling Language

○ Llenguatge de Modelatge Unificat

○ És el llenguatge de modelatge de sistemes de programari/informació

més conegut i utilitzat en l'actualitat.

● Què permet?:

○ Permet modelar sistemes, dominis i processos (no necessàriament

programari)
Tipus de diagrames UML
Tipus de diagrames més importants
● Diagrames de casos d'ús

● Diagrames de classes

● Diagrames de seqüència o interacció

● Altres: Components, Desplegament, Màquines d’estado,

Activity, etc.
Diagrama de Casos d’Ús
● Representa la forma en com un actor i els elements del sistema en
desenvolupament interactuen entre si.

● Són molt generals i intuitius pel client

● Elements:

○ Actor: entitat externa al sistema (usuaris, dispositius de hardware, altres

sistemes, etc.) que interactua amb ell intercanviant senyals i dades. Són rols.

○ Casos d'ús: funcionalitat que s'ha de dur a terme amb el sistema que s'està
desenvolupant

○ Associacions d'ús: relacions entre actors i casos d’ús (no obligatòries) que
representan una interacció

○ Límits del sistema: és un requadre opcional per mostrar els límits del sistema
Diagrama de Casos d’Ús: Tipus d’associacions
● Normal

● Generalitza:

○ Generalitza actors

● <<extend>>:

○ Passa opcionalment

● <<include>>:

○ Sempre passa, per reutilitzar el Cas d’Ús

Diagrama de Casos d’Ús: Consells
● Els noms dels casos d'ús s'han de començar amb un verb.

● És més intuïtiu representar els casos d’ús i els actors

en ordre descendent, situant els més importants a la part
superior del diagrama.

● Anomenar els actors amb substantius relacionats amb les

regles de negoci, d'acord amb els rols que representen.

● Més info:
https://drive.google.com/open?id=0B5GfeijbwtkeSHYxU3NTbDd
wOFkm
Diagrama de Casos d’Ús: Pasos
1. Llegir una vegada tot el text

2. Llegir una segona vegada i identificar:

a. Sistema

b. Actors/rols:

i. Els principals a dalt a l’esquerra

ii. Si hi ha rols de “backend”, a la dreta

3. Identificar les accions/funcionalitats/casos d’ús:

a. Són verbs, accions

4. Connectar els casos d’ús amb els actors

Diagrama de Casos d’Ús: Exercici pràctic
● Es tracta d’una web multinacional de cava

● Un usuari pot:

○ Visitar el catàleg de caves

○ Comprar caves i rep un mail

● Un usuari registrat pot:

○ Fer el mateix que un usuari normal

○ També pot rebre descomptes per mail

● Un administrador pot:
 Diagrama de Casos d’Ús: Exercici pràctic
Visitar catàleg Actualitzar catàleg

Comprar cava Crear descomptes

Usuari <<include>>

Enviar email <<include>>

<<include>>
Rebre descomptes Administrador

Usuari registrat
Diagrama de Classes
● L’objectiu és representar les classes del sistema

○ Normalment de llenguatges orientat a objectes

● Nombre clase

●
Atributs
●

●
Mètodes

● Visibilitat
Diagrama de Classes - Normes importants
● Recordar: no existeix solució única:

○ Cal explicar la solució proposada SEMPRE

○ No us pagaran per fer un dibuix bonic, sinò per raonar

● Normes:

○ Classes: sustantiu, en singular, majúscula

○ Atributs: nomenclatura de Java, indicar tipus de dada i visibilitat

○ Mètodes: verb en infinitiu, nomenclatura de Java, indicant tipus de

dada d’entrada, return i visibilitat

○ Relacions: verb, sempre indicar-la, nomenclatura de Java, posar

Diagrama de Classes: Visibilitat
● Public (+): Indica que serà visible tant dins com fora de la
classe

● Private (-): Indica que només serà accessible des de dins de

la classe

● Protected (#): Indica que només serà accessible des del

package o les subclasses

● Per defecte, només visible pel package

Diagrama de Classes: Relacions
● Associació

● Dependència

● Herència

● S’ha de tenir
en compte la
multiplicitat:
Diagrama de Classes: Relacions - Associació

Relaciones involutivas
Diagrama de Classes: Relacions - Agregació i composició
● Agregació: una classe
forma part d’una altra
(però pot existir
sense ella)
works
● Composició: necessitem
l’existència d’una
classe per poder tenir
una altra (no té
sentit l’existència
builtUsing
d’una sense l’altra)
Diagrama de Classes: Relacions - Herència
● Una superclasse abstracta

● Una subclasse que hereda els

atributs i mètodes pùblics i
protected de su superclasse
Diagrames d’arquitectura / Deployment
● Mostra l’estructura general
del sistema

● Mostra els components i

parts principals del
sistema

● No estàndar
Diagrames de seqüència / Interacció
● Mostra la seqüència de interaccions entre classes

● Es posen:

○ Classes

○ Mètodes

○ Returns
Diagrames de màquines d’estats
● Molt semblant al diagrama de
flujo i d’activitats

● Mostra l’estat del sistema en

cada moment

● És com un arbre de decisió

● No té corresponència amb
classes ni components ni res.
Simplement mostra les fases
d’un procès