You are on page 1of 52

UML

ANÀLISI I DISSENY D’APLICACIONS


Departament d’Enginyeria Informàtica i Matemàtiques
Universitat Rovira i Virgili

ANÀLISI I DISSENY D’APLICACIONS 1

DEPARTAMENT D’ENGINYERIA INFORMÀTICA I MATEMÀTIQUES 1

UNIVERSITAT ROVIRA I VIRGILI 1

I. INTRODUCCIÓ 3
I. 1. Diagrames d’UML 3

II. CONCEPTES GENERALS 4


II. 1. Element 4
II. 2. Estereotip 4
II. 3. Visibilitat 4
II. 4. Comentari 5
II. 5. Classificador 5
II. 6. Instància 5
II. 6. 1. Col·lecció 6
II. 6. 1. 1. Cardinalitat i multiplicitat d’una col·lecció 6
II. 7. Dependència 6
II. 8. Format general dels diagrames d’UML 6

III. ELS DIAGRAMES D’ESTRUCTURA 8


III. 1. El diagrama de classes 8
III. 1. 1. Classes 8
III. 1. 1. 1. El concepte de classe en UML 8
III. 1. 1. 2. Notació general de la classe 8
III. 1. 1. 3. Notació de l’objecte 10
III. 1. 2. Altres classificadors 11
III. 1. 2. 1. Interfície 11
III. 1. 2. 2. Tipus de dades i literals 12
III. 1. 3. Associació i conceptes relacionats 13
III. 1. 3. 1. Notacions de l’associació i de l’enllaç 14
III. 1. 3. 2. Exemples d’associacions 15
III. 1. 3. 3. Agregació i composició 17
III. 1. 4. Generalització, especialització i herència en classes i altres classificadors 18
III. 1. 4. 1. Generalització especialització i herència en les classes 18
III. 1. 4. 2. Generalització, especialització i herència en alguns classificadors altres que les
classes 19
III. 1. 4. 3. Especialització d’associacions 19
IV. ELS DIAGRAMES DE COMPORTAMENT 21
IV. 1. Diagrama de casos d’ús 21
IV. 1. 1. Conceptes 21
IV. 1. 1. 1. Subjecte 21
IV. 1. 1. 2. Actor 21
IV. 1. 1. 3. Relacions entre actors 22
IV. 1. 1. 4. Cas d’ús 22
IV. 1. 1. 5. Relacions entre casos d’ús i actors 23
IV. 1. 1. 6. Relacions entre casos d’ús 23

ADA – UML bàsic pàg. 1


IV. 1. 2. Exemple general 25
IV. 2. Diagrama d’estats 26
IV. 2. 1. Conceptes previs 26
IV. 2. 1. 1. Senyal 26
IV. 2. 1. 2. Esdeveniment i disparador 26
IV. 2. 2. Màquina d’estats 27
IV. 2. 3. Estat 28
IV. 2. 3. 1. Comportaments associats a un estat 28
IV. 2. 3. 2. Notació de l’estat simple 29
IV. 2. 4. Vèrtexs altres que l’estat en màquines d’estats només amb estats simples 29
IV. 2. 4. 1. Pseudoestat inicial, estat final i pseudoestat terminal 29
IV. 2. 4. 2. Pseudoestats d’embrancament i de tria 30
IV. 2. 5. Transicions simples 30
IV. 2. 6. Exemples de diagrama d’estats amb estats simples 31
IV. 2. 7. Conceptes i notacions propis dels diagrames amb estats compostos i/o de submàquina 32
IV. 2. 7. 1. Notació de l’estat compost 32
IV. 2. 7. 2. Tipus de vèrtex addicionals 33
IV. 2. 7. 3. Transicions en el cas d’estats compostos 34
IV. 2. 7. 4. Exemples amb estats compostos 34
IV. 2. 7. 5. Notació de l’estat de submàquina 35
IV. 2. 7. 6. Exemple d’estat de submàquina 35
IV. 3. Diagrama d’activitats 37
IV. 3. 1. Classificació dels arcs i nodes d’activitat 37
IV. 3. 2. Signe d’objecte i signe de control 38
IV. 3. 3. Acció i activitat 38
IV. 3. 4. Node d’objectes 38
IV. 3. 4. 1. Paràmetre d’activitat 39
IV. 3. 4. 2. Pin 39
IV. 3. 4. 3. Altres nodes d’objectes 40
IV. 3. 5. Arc d’activitat 40
IV. 3. 5. 1. Arc d’objectes i arc de control 41
IV. 3. 6. Nodes de control 41
IV. 3. 7. Nodes executables altres que l’acció 42
IV. 3. 7. 1. Notació ampliada de l’activitat 42
IV. 3. 7. 2. Node d’activitat estructurada 42
IV. 3. 7. 3. Regió d’expansió 43
IV. 3. 8. Execució d’una acció i d’una activitat estructurada 44
IV. 3. 9. Partició d’activitats 45
IV. 3. 9. 1. Notació de la partició d’activitats 46
IV. 3. 10. Exemple de diagrama d’activitats 47
IV. 4. Diagrames d’interacció 48
IV. 4. 1. Interacció 48
IV. 4. 2. El diagrama de seqüències 48
IV. 4. 2. 1. Línia de vida 48
IV. 4. 2. 2. Fragment d’interacció 49
IV. 4. 2. 3. Missatge 50

ADA – UML bàsic pàg. 2


I. INTRODUCCIÓ
L’OMG (Object Management Group) és una organització internacional no lucrativa en què participen
universitats i empreses de programari, maquinari, usuàries i consultores que té com a finalitat
l’elaboració d’estàndards sobre eines relatives a la tecnologia d’objectes que són desenvolupades per
empreses.

L’UML (Unified Modeling Language) és un conjunt de conceptes i notacions utilitzables en el modelatge


gràfic de programari orientat a l’objecte durant el seu desenvolupament, i té l’origen una unificació dels
models utilitzats en 3 mètodes preexistents de desenvolupament de programari orientats a l’objecte
feta per llurs autors. UML ni és per si sol un mètode de desenvolupament de programari ni està lligat a
cap mètode en particular, i es pot fer servir dins de mètodes de desenvolupament de programari molt
diversos.

I. 1. DIAGRAMES D’UML

Hi ha dos grups de diagrames:

Diagrames d’estructura, que descriuen aspectes del sistema de programari considerat que són es-
tructurals (allò que el sistema té). N’hi ha els següents:
• diagrama de paquets,
• diagrama de perfil,
• diagrama de classes,
• diagrama d’objectes,
• diagrama d’estructures compostes,
• diagrama de components,
• diagrama de desplegament.
Diagrames de comportament, que representen l‘activitat del sistema (allò que el sistema pot fer) des
de diferents punts de vista. N’hi ha els següents:
• diagrama de casos d’ús,
• diagrama d’estats,
• diagrama d’activitats,
• diagrama d’interacció, que té aquestes variants:
o diagrama de seqüències,
o diagrama de comunicacions,
o diagrama de visió general de la interacció,
o diagrama temporal.

ADA – UML bàsic pàg. 3


II. CONCEPTES GENERALS
En aquest apartat veurem alguns conceptes bàsics d’UML que són generals en el sentit que o bé són
transversals en relació als diferents diagrames o bé són d’ús molt freqüent en diversos diagrames.

II. 1. ELEMENT

Els models dels diferents nivells consten d’elements; un element és un concepte que té representació
en els models mitjançant un símbol geomètric bidimensional, una línia o una sèrie alfanumèrica
(String).

Un element tipificat és un element que pot tenir diferents valors pertanyents a un cert conjunt; a
aquest conjunt se l’anomena tipus.

Un element derivat és un element redundant que s’obté mitjançant un algorisme a partir d’altres ele-
ments del model.

Notació

Quan es descriu la sintaxi dels elements textuals els fragments de text (mots clau, parèntesis etc.) es-
tàndard d’UML es representen en cursiva i entre cometes mentre que aquells noms i expressions que
són propis del model representat estan en lletra normal. La lletra cursiva també té altres usos en altres
contexts.

II. 2. ESTEREOTIP

És una variant d’un element - anomenat element base de l’estereotip – la qual té almenys la mateixa
estructura i relacions amb altres elements que l’element base però pot tenir aspectes addicionals i té un
ús més restringit que l’element base.

Notació de l’estereotip

Quan es fa ús d’un estereotip se’l representa pel mateix símbol (potser amb diferent color o textura)
que l’element base, més el nom de l’estereotip entre ‘«’ i ‘»’ (cometes llatines), o també per un símbol
específic de l’estereotip en qüestió.

II. 3. VISIBILITAT

La visibilitat és un atribut dels elements que delimita quins altres elements del model hi tenen accés;
és una enumeració (vegeu l’apartat III. 1. 2. 2. ) que té aquests valors:
• “+” o “public”, que vol dir que l’element és accessible per aquells elements que poden accedir a
l’espai de noms que el conté directament;
• “-” o “private”, que significa que l’element només és accessible pels elements de l’espai de noms
que el conté directament;
• “#” o “protected”, que vol dir que l’element només és visible per als elements del seu mateix espai
de noms A i per als elements d’espais de noms generalitzats per A;
• “~” o “package”, que només es pot aplicar a elements continguts directament en un espai de noms
que no és un paquet i aleshores vol dir que l’element només és visible per als elements continguts
directament o indirectament dins el paquet que conté el seu espai de noms.

ADA – UML bàsic pàg. 4


II. 4. COMENTARI

El comentari és una explicació en llenguatge natural destinada només a ser llegida i que, per tant, no
té cap efecte sobre el funcionament del sistema modelitzat ni ha de ser interpretada per l’eina de mo-
delatge.

Qualsevol element o grup d’elements d’un model pot tenir comentaris associats.

Notació

Va dins d’un símbol de nota, que representa un full de paper apaïsat amb un angle doblegat:

comentari

Si es refereix a tot un diagrama un comentari pot aparèixer aïllat a dintre seu; si no, es recomana que
estigui connectat amb cadascun dels elements als quals fa referència per línies discontínues, per tal que
no hi hagi dubte de quins són els elements al·ludits.

II. 5. CLASSIFICADOR

Un classificador és un tipus que té característiques (features) estructurals i de comportament. Un


classificador és un espai de noms per a les seves característiques.

El classificador té nombrosos estereotips estàndard (per exemple, la classe), alguns dels quals per la
seva banda també tenen estereotips estàndard.

Notació

Un classificador en general es representa per un rectangle, que pot estar dividit horitzontalment en di-
versos compartiments, dels quals l’únic obligatori és el superior, que conté el nom del classificador i al
damunt l’estereotip corresponent.

El nom dels classificadors comença per majúscula i es representa centrat.

«estereotip»
Nom classificador

Molts estereotips del classificador tenen un símbol específic, altre que el rectangle.

II. 6. INSTÀNCIA

Cada un dels valors d’un classificador n’és una instància (instance). Una instància pot pertànyer a di-
versos classificadors alhora.

Notació

Les instàncies es representen pel mateix símbol que els classificadors respectius. Allà on en el cas d’un
classificador hi ha el nom del classificador, en el cas d’una instància hi ha el nom de la instància (opta-
tiu) i tot seguit “:” i la llista dels classificadors a què pertany separats per comes; tots dos noms van
subratllats. El nom d’un classificador pot anar precedit del seu estereotip.

«estereotip»
inst:Cl1, Cl2

ADA – UML bàsic pàg. 5


II. 6. 1. Col·lecció
Una col·lecció és un conjunt de còpies d’instàncies del mateix classificador, que són els elements de la
col·lecció. Es pot especificar que una col·lecció pugui tenir o no elements duplicats (és a dir, múltiples
còpies de la mateixa instància) i que els elements estiguin ordenats d’alguna manera o no.

II. 6. 1. 1. Cardinalitat i multiplicitat d’una col·lecció

La cardinalitat d’una col·lecció és el nombre d’instàncies que té en un moment determinat.

La multiplicitat d’una col·lecció estableix quins valors pot tenir la seva cardinalitat. En el cas més ge-
neral és una sèrie d’especificacions d’intervals de la forma límit_inferior“..”límit_superior separades per
comes.

Els límits de cada interval poden ser valors enters no negatius o bé expressions parametritzades que
donin un resultat enter; a més el límit superior o tots dos poden ser substituïts per “*”, que indica que
qualsevol valor enter no negatiu és vàlid; quan els dos límits d’un interval coincideixen se’n pot posar
només un.

Per exemple la multiplicitat 0..1, 3, 5..* indica que el valor de la cardinalitat pot ser qualsevol enter no negatiu llevat de 2 i 4.
0..* equival a *..* i per tant a *. La multiplicitat 0..0 està permesa.

Quan una multiplicitat forma part d’una especificació textual més llarga està delimitada per “[“ i ”]”,
però no pas quan està sola acompanyant un element gràfic.

Si el límit superior és més gran que 1 la multiplicitat pot anar seguida de les propietats següents:
• “unique”, que vol dir que no s’admeten valors duplicats, o “nonunique”; per defecte és “unique”
• “ordered”, que vol dir que les instàncies estan ordenades per algun criteri, o “unordered”; per de-
fecte és “unordered”.

II. 7. DEPENDÈNCIA

Una dependència expressa que un o més elements d’un model (clients) depenen, per a la seva realit-
zació o especificació, d’un o més altres elements (subministradors, suppliers).

Hi ha molts estereotips estàndard de la dependència, que sovint només s’apliquen a alguns tipus
d’elements.

Notació

Una dependència es representa per una fletxa de punta oberta i línia discontínua del client cap al sub-
ministrador, amb l’estereotip al costat:
«estereotip»

II. 8. FORMAT GENERAL DELS DIAGRAMES D’UML

Cada diagrama d’UML es representa opcionalment dins d’un marc amb una capçalera, així:

capçalera

diagrama

La capçalera pot tenir aquestes parts:


ADA – UML bàsic pàg. 6
• tipus de diagrama, opcional
• nom del diagrama,
• valors dels paràmetres de l’element del model o espai de noms al qual correspon el diagrama (op-
cionals també).

ADA – UML bàsic pàg. 7


III. ELS DIAGRAMES D’ESTRUCTURA
Els diagrames d’estructura descriuen l’organització estàtica del model, prescindint per tant de la des-
cripció del comportament del model. En particular, veurem el de classes.

III. 1. EL DIAGRAMA DE CLASSES

És el diagrama d’estructura bàsic i més general; serveix per a definir classificadors de tota mena i rela-
cions de diferents tipus entre ells.

III. 1. 1. Classes

III. 1. 1. 1. El concepte de classe en UML

Una classe descriu un conjunt d’entitats que tenen les mateixes propietats, comportament, relacions i
semàntica. La classe és un estereotip del classificador i per tant en principi pot tenir instàncies, que
s’anomenen objectes.

Un aspecte característic dels objectes és que tenen identitat, cosa que significa que dos objectes poden
ser diferents encara que tinguin valors idèntics en tots els atributs. Les instàncies de classificadors
qualssevol no tenen identitat en general.
Les característiques estructurals de les classes s’anomenen propietats i poden ser de dues menes:
• Atributs, quan formen part de la classe. Per a cada objecte cada atribut pot tenir un valor o
més, que han de pertànyer a un tipus que s’especifica. Els valors dels diferents atributs constitu-
eixen l’estat de l’objecte, el qual reflecteix en cada moment l’efecte acumulat dels comporta-
ment que l’han afectat.
• Extrems d’associació (vegeu l’apartat III. 1. 3. ).
X Un atribut derivat és un atribut que és element derivat (vegeu l’apartat II. 1. ), i per tant se’n pot
obtenir el valor a partir d’altres elements per mitjà d’un algorisme que es pot descriure per mitjà d’una
restricció que ha de complir el valor de l’atribut derivat per a ser correcte.

Les característiques de comportament de les classes són les operacions, les quals descriuen el com-
portament de la classe. Cada operació té una signatura que en descriu els eventuals paràmetres i va-
lors de retorn. Les operacions en altres contexts s’anomenen mètodes o serveis; en UML un mètode és
una descripció de la implementació d’una operació.

Els atributs de classe no prenen valors per a cada objecte sinó per a tota la classe en conjunt; anàlo-
gament, les operacions de classe no es demanen en relació a un objecte concret sinó en relació a la
classe en general.

Quan es parla simplement d’atributs o operacions s’entén que són a nivell d’objecte; quan es volen dife-
renciar dels de nivell de classe se’ls anomena atributs d’objecte i operacions d’objecte.

III. 1. 1. 2. Notació general de la classe

Una classe, igual que els altres estereotips del classificador, es representa per mitjà d’un rectangle, que
pot ser compartimentat verticalment o no.
• El compartiment superior o únic porta el nom de la classe i, si s’escau, les seves propietats com a
element del model i l’estereotip (“class”, que és l’estereotip per defecte del classificador), tot cen-
trat. El nom de la classe és obligatori i no hi pot haver dues classes del mateix nom dins el mateix
paquet; es recomana que els noms de classe estiguin en negreta (i comencin per majúscula i
estiguin centrats, com es recomana per als noms de classificador en general).
• La resta de compartiments, quan existeixen, contenen una llista cadascun. Hi ha dues llistes estàn-
dard: la del segon compartiment, que descriu els atributs (d’objecte i de classe), i la del tercer, que

ADA – UML bàsic pàg. 8


descriu les operacions (també tant les d’objecte com les de classe). Les llistes poden portar un
nom, especialment si n’hi ha més o menys que les dues estàndard.
• Que una classe aparegui només amb el compartiment del nom no vol dir necessàriament que no
tingui atributs ni operacions, sinó que es tracta d’una representació simplificada.

Nom de la classe
Nom de la classe

llista d’atributs

llista d’operacions

La llista d’atributs

La descripció d’un atribut va alineada per l’esquerra i té el format següent:


“^” visibilitat “/” nom_atribut ”:” tipus ”[“multiplicitat”]” “=” valor_per_defecte “{“cade-
na_de_propietats”}”
només nom_atribut és obligatori. Pel que fa a la resta,
• “^” indica que l’atribut és heretat (molt sovint no es mostren pas, els atributs heretats).
• La visibilitat pot tenir els valors enumerats a l’apartat II. 3. A un atribut de visibilitat “private” no-
més s’hi pot accedir des de la mateixa classe, i a un atribut de visibilitat “protected” només s’hi pot
accedir des de la mateixa classe o una de les seves subclasses. Si no s’indica la visibilitat no se’n
suposa cap valor per defecte, sinó que es considera una propietat oculta.
• “/” indica que l’atribut és derivat.
• La multiplicitat (vegeu l’apartat II. 6. 1. 1. ) aquí fa referència al nombre de valors que pot tenir
l’atribut a cada objecte; es pot ometre quan és 1..1.
• El tipus ha de ser un classificador.
• Dins cadena de propietats hi pot haver les propietats següents:
o “readOnly” indica que el valor de l’atribut no es pot modificar; per defecte és “false”.
o “redefines” nom_atribut_1 vol dir que l’atribut en qüestió, d’una subclasse substitueix l’atribut
nom_atribut_1 de la superclasse.
o “ordered”, “unordered”, “unique” i “nonunique” es refereixen als valors de l’atribut són aplica-
bles en el cas que la cardinalitat màxima de la seva multiplicitat sigui més gran que 1; “unique”
vol dir que no hi pot haver duplicats entre els valors de l’atribut en un objecte i és propietat per
defecte, igual que “unordered”. “seq” o “sequence” es la combinació d’“ordered” i “nonunique”.
o “id” indica que l’atribut és part de l’identificador dels objectes de la classe.
Els atributs de classe es distingeixen perquè tenen subratllats el nom i l’expressió de tipus; altrament
són atributs d’objecte.

Es recomana que els noms dels atributs comencin per minúscula i que el conjunt de
l’especificació de cada atribut estigui alineada per l’esquerra.

La llista d’operacions

La descripció de cada operació va alineada per l’esquerra té el format següent:


“^” visibilitat signatura “{”cadena de propietats“}”
“^” denota una operació heretada.

La visibilitat pot tenir els valors de l’apartat II. 3. A una operació de visibilitat “private” només s’hi pot
accedir des de la mateixa classe, i a una operació de visibilitat “protected” només s’hi pot accedir des de
la mateixa classe o una de les seves subclasses. Si no s’indica la visibilitat no se’n suposa cap valor per
defecte, sinó que es considera una propietat oculta.

La signatura té el format següent:


nom_operació “(”llista_paràmetres “)” “:”tipus_del_retorn “[”multiplicitat“]”
Una operació pot no tenir paràmetres (és a dir, la llista de paràmetres pot ser nul·la), però el parèntesi
és obligatori. Pot no haver–hi valor de retorn, i aleshores tampoc hi ha “:”. Els paràmetres de la llista

ADA – UML bàsic pàg. 9


van separats per comes i cadascun és de la forma
direccio_de_paràmetre nom_paràmetre “:” tipus“[”multiplicitat“]” “=” valor_per_defecte
• direccio_de_paràmetre pot ser “in” (que és el valor per defecte), “out” o “inout”.
• El tipus dels paràmetres i del valor de retorn és com en el cas dels atributs.
• El valor de retorn també es pot expressar com un paràmetre de nom “return”.
“{cadena de propietats}” és opcional, i pot contenir aquestes propietats:
• “query”, que significa que l’operació no té afectes col·laterals, això és que no altera l’estat del sis-
tema;
• “ordered”/“unordered” i “unique”/“nonunique” es refereixen al valor de retorn i, igual que en el cas
dels atributs, són aplicables en el cas que la cardinalitat màxima de la seva multiplicitat sigui més
gran que 1.
• “redefines” nom_operació_1 vol dir que l’operació en qüestió, d’una subclasse substitueix l’operació
nom_operació_1 de la superclasse.
En una classe hi pot haver diverses operacions amb el mateix nom sempre que la signatura no sigui
idèntica (per exemple tingui paràmetres diferents o els mateixos paràmetres però el tipus d’algun sigui
diferent).

Les operacions de classe tenen la signatura subratllada.

Les operacions abstractes (vegeu l’apartat III. 1. 4. 1. ) tenen o bé la signatura en cursiva o bé la pro-
pietat “abstract”.

Es recomana que els noms de les operacions comencin per minúscula i que el conjunt de
l’especificació de cada operació estigui alineat per l’esquerra.

Exemples de classes:
estático
Punt subrayado método

:
-x: Real Lis constructor
-y: Real
+crear (in x: Real, in y: Real)
La classe Punt té dos atributs x i y de visibilitat privada i una operació de classe crear que té dos paràmetres d’entrada de ti-
pus real, x i y.

Rectangle

+extrems: Punt [2]


#gruixLinia: Integer = 1 area=abs((extrems[1].x-
+/area: Real extrems[2].x)*(extrems[1].y-
extrems[2].y))
+getGruixLinia (): Integer {query}
+setGruixLinia (nouGruix: Integer, out vellGruix: Integer)
-calculArea (): Real El uml nos sirve para expresar el desarrollo de un
«constructor» sw —> instrucciones visuales a un desarrollador
+nouRectangle (extrem1: Punt, extrem2: Punt): Rectangle

La classe Rectangle té els atributs: extrems, públic, que és una matriu de 2 elements que tenen com a tipus la classe Punt (de
l’exemple anterior); gruixLinia, protegit, de tipus Integer i valor inicial 1; i area, públic, derivat segons la fórmula de la restric-
ció annexa, de tipus Real. Les operacions són getGruixLinia, pública, sense paràmetres, amb un valor de retorn de tipus Inte-
ger; setGruixLinia, pública, amb un paràmetre d’entrada nouGruix i un de sortida vellGruix, tots dos de tipus Integer; calculA-
rea, privada, sense paràmetres i amb un valor de retorn de tipus Real; nouRectangle, pública i de classe, amb els paràmetres
d’entrada de tipus Punt extrem1 i extrem2 i com a valor de retorn un objecte de la mateixa classe Rectangle; aquesta opera-
ció té l’estereotip constructor, com totes les que hi hagués eventualment a sota d’ella mentre no aparegués un altre estereotip
(també es pot indicar l’estereotip a cadascuna, immediatament després de la visibilitat si n’hi ha).

III. 1. 1. 3. Notació de l’objecte

Hem vist que quan un classificador és una classe a les seves instàncies se’ls diu objectes. La notació de

ADA – UML bàsic pàg. 10


l’objecte és semblant a la de la classe; té el compartiment del nom i pot tenir el dels atributs (només
els d’objecte, òbviament), però normalment no tindrà el de les operacions.

Si l’objecte pertany a uns determinats estats d’una classe, després del nom de la classe ve, entre “[” i
“]”, la llista dels estats separats per comes.

De cada atribut es pot especificar el valor, de la manera indicada a la figura següent; el tipus dels atri-
buts es pot ometre, perquè ja s’ha especificat a la descripció de la classe. Si un atribut pren successi-
vament diversos valors durant la vida de l’objecte, es pot o bé indicar la llista corresponent o bé repre-
sentar l’objecte com a diversos objectes que difereixen en el valor de l’atribut en qüestió, que quan
aquests valors són successius en el temps poden estar relacionats dos a dos per dependències “beco-
mes”.

Exemple:

Objecte i classe

nom_objecte :Nom_classe Nom_classe

atribut_1.Tipus_1=valor_1 +atribut_1: Tipus_1


atribut_2=valor_2 -atribut_2: Tipus_2

El símbol de l’esquerra representa un objecte concret de la classe de la dreta. Dins l’objecte s’ha mostrat el tipus només d’un
dels atributs, però normalment es mostra per a tots o per a cap.

III. 1. 2. Altres classificadors


Aquest apartat tracta d’alguns dels classificadors altres que la classe que figuren més sovint en els dia-
grames de classes, per bé que s’hi poden representar classificadors de tota mena.

III. 1. 2. 1. Interfície

És un classificador que consisteix en una declaració de característiques (en el sentit de l’apartat II. 5. )
de visibilitat pública i eventualment restriccions i màquines d’estat de protocol (vegeu l’apartat IV. 2. 2.
) que componen el contracte de la interfície. Com que és només una declaració no se’n poden crear
instàncies directament; per tant és un classificador no instanciable i ha d’estar implementada per al-
menys un classificador instanciable que implementi com a mínim el contracte de la interfície.

Entre una interfície i un classificador que la implementa hi ha la mateixa relació – una dependència de realització (apartat II.
7. ) que entre un tipus i la seva classe d’implementació.

En particular, totes les operacions d’una interfície les ha de tenir també – amb la mateixa signatura
respectivament- tot classificador que la implementi, i els atributs que té han de ser implementats
d’alguna manera (no necessàriament a base de tenir declarats atributs idèntics, públics). Un classifica-
dor pot implementar diverses interfícies alhora; inversament, una interfície pot ser implementada per
instàncies de diversos classificadors en diferents moments.

Notacions relatives a la interfície

Com a classificador que és, una interfície es pot representar amb el símbol de classificador amb
l’estereotip “interface”, i aquesta és l’única notació quan es representa aïllada, però quan es representa
relacionada amb altres classificadors té dos símbols específics:
• La dependència d’implementació entre una interfície i un classificador que la implementa (interfí-
cie suportada pel classificador) es pot representar així:

Classificador

Interfície

• La dependència d’un classificador envers una interfície que fa servir (interfície requerida pel clas-

ADA – UML bàsic pàg. 11


sificador) es representa així:

Classificador

Interfície

Exemples:

Interfície suportada per una classe i requerida per una altra


«interface»
Comparable

+esIgual (o: Object): Boolean

Cadena
ClasseClient
.....
.....
+esIgual (o: String): Boolean .....
Comparable

La interfície Comparable pretén declarar totes les operacions que hauran de tenir aquelles classes que vulguin permetre que
dos dels seus objectes es puguin comparar segons algun criteri d’igualtat que només queda definit dins la implementació de
l’operació esIgual dins la classe Cadena, que és la que implementa Comparable. La classe ClasseClient utilitza la interfície
Comparable, en el sentit que la implementació d’alguna operació de ClasseClient crida alguna operació de Comparable.
Narmalmente clase implem intal

.
Amb la notació general de les dependències “use” i de realització:
Peneste caso
la clase incluye las

,
met de la interface para gecut
Cadena

.
ClasseClient

.
«interface»
..... «use»
Comparable .....
+esIgual (o: String): Boolean +esIgual (o: Object): Boolean .....
CASO GURIOSO
(La dependència de realització té una notació diferent de la de les altres dependències, com s’ha asse-
nyalat a l’apartat II. 7. ).

III. 1. 2. 2. Tipus de dades i literals

Els tipus de dades són classificadors que tenen les característiques següents:
• Les seves instàncies s’anomenen valors i no tenen identitat, a diferència dels objectes; per tant
dos valors iguals no es poden distingir, a diferència de dos objectes amb el mateixos valors a tots
el atributs que tanmateix poden ser objectes diferents;
• les seves operacions no tenen efectes col·laterals, cosa que vol dir que no canvien el valor de
cap atribut ni envien missatges.
Un aclariment sobre els efectes col·laterals: l'operació d'addició de nombres, per exemple, no altera el valor de cap atribut
perquè els nombres sumats no tenen identitat; una altra cosa seria prendre el valor d'un atribut d’un objecte, sumar-li quel-
com i substituir el valor anterior per aquesta suma, ja que aleshores canviaria l’estat de l’objecte.

Són tipus de dades les enumeracions i els tipus dits primitius, a més dels que es puguin definir.

Enumeració

Una enumeració és un tipus de dades, les instàncies del qual són literals que s’especifiquen un a un.

L’ordre de les instàncies és significatiu.

Tipus primitius

Són tipus de dades predefinits, les instàncies dels quals no tenen estructura (és a dir, són atòmiques).
Les seves operacions poden estar especificades altrament que en UML (amb les notacions de l’Àlgebra,
per exemple).

ADA – UML bàsic pàg. 12


Els tipus primitius d’UML són
• “Boolean” (enumeració formada pels valors “true” i “false”),
• “Integer” (nombres enters positius i negatius més el zero),
• “Real” (nombres reals),
O
• “UnlimitedNatural” (nombres naturals començant per l’1 més “*” que denota un valor il·limitat), i
• “String” (sèries de caràcters mono o multibyte).

Notacions dels tipus de dades

w
Els tipus de dades en general es representen pel símbol de classificador, amb l’estereotip “dataType”.
Poden tenir compartiments d’atributs i d’operacions, igual que la classe, i eventualment compartiments
addicionals per a d’altra informació. Els tipus primitius tenen l’estereotip “primitive”. L’enumeració es
representa per un classificador amb l’estereotip “enumeration” que després d’eventuals compartiments
per als atributs i per a les operacions pot tenir un compartiment especial amb la llista dels seus literals.

Exemple:
ante
Import agenpare
un
para
«enumeration» -

valores
GEI
Ensenyament
conjunto de

GET
GEE

L’enumeració Ensenyament té 3 valors possibles GEI, GET i GEE, en aquest ordre.

Literals

En UML hi ha els següents tipus de literals:


• Literals String: van entre ‘ ” ’
• Literals Boolean: true o false, per defecte “false”
• Literals Integer: un nombre enter, per defecte zero
• Literals UnlimitedNatural: o bé “*” o bé una sèrie de dígits
• Literals Real: tenen 2 notacions possibles:
o Notació decimal: signe + o – opcional, seguit d’una sèrie de zero o més dígits, seguida opcio-
nalment d’un punt i d’un o més dígits
o Notació científica: signe + o – opcional, seguit d’un nombre natural que pot estar seguit de E o e
i si ho està pot estar seguit d’un altre nombre natural precedit d’un signe + o – opcional
• Literals nuls: pot ser null o altres valors, depenent del seu ús

III. 1. 3. Associació i conceptes relacionats


Una associació és un classificador que descriu una relació entre diversos altres classificadors amb un
cert significat, la qual té un reflex a nivell de les instàncies respectives.

Una associació té diversos extrems d’associació (association end) a cadascun dels quals hi ha un
classificador que fa un cert paper (role) en l’associació. Un classificador pot fer múltiples papers en la
mateixa associació, els quals hauran de tenir noms diferents.

Una associació amb dos extrems es diu binària, amb tres ternària, etc.

L’existència d’una associació implica l’existència d’enllaços (links) d’ella que són tuples formades per
instàncies dels classificadors dels seus extrems, una per a cada extrem.

En altres paraules: un enllaç és a una associació com un objecte és a una classe.

Com a cas especial, una associació pot establir més d’un enllaç entre les mateixes instàncies dels classi-
ficadors; llavors aquests enllaços han de tenir un identificador que els distingeixi.

En una associació binària, quan es pot accedir de manera eficient en temps d’execució a la instància o
instàncies d’un dels extrems b a partir d’una instància de l’altre extrem a amb la qual tenen enllaços de
l’associació es diu que hi ha navegabilitat des d’a cap a b.
ADA – UML bàsic pàg. 13
Una associació derivada és una associació redundant que és conseqüència de restriccions o d’altres
associacions; per exemple la que resulta de combinar dues associacions amb un extrem comú.

Classe associativa és una associació que és alhora una classe; cal considerar que una associació és
una classe quan els seus enllaços (enllaços objectes) tenen atributs i/o operacions per ells mateixos,
això és, que no siguin de cap de les instàncies que enllacen.

Un qualificador és un atribut o llista d’atributs d’un extrem d’una associació binària o de l’associació
mateixa, si és classe associativa; aleshores la multiplicitat d’aquest extrem delimita el nombre
d’objectes enllaçats que tenen els mateixos valors en aquests atributs per a cada objecte de l’altre ex-
trem.

III. 1. 3. 1. Notacions de l’associació i de l’enllaç

Una associació binària es pot representar mitjançant una línia contínua que uneix els classificadors dels
dos extrems.

Una associació amb 3 extrems o més es representa mitjançant un rombe buit (més gros que el que in-
dica una agregació, vegeu l’apartat III. 1. 3. 3. ) unit per línies als classificadors. Aquest rombe també
es pot utilitzar, opcionalment, en el cas d’associacions binàries.

Els següents tipus d’elements poden acompanyar aquestes representacions:


• El nom de l’associació, que és opcional i comença amb minúscula (excepte en el cas d’una classe
associativa en què comença amb majúscula perquè aleshores el nom de l’associació ha de coincidir
amb el de la classe associativa).
• “/” davant del nom de l’associació, o en el seu lloc si no se li dóna nom, indica que l’associació és
derivada.
• Una línia discontínua que uneix les línies de dues associacions binàries amb un extrem comú acom-
panyada de la restricció “{xor}” vol dir que les dues associacions són alternatives, en el sentit que
cap instància de l’extrem comú no pot participar alhora en un enllaç de cada associació.
• En el cas de classe associativa, un símbol de classe, que indica que l’associació en qüestió és una
classe associativa; va unit a la línia o rombe d’associació per una línia discontínua; el nom de la
classe associativa i el de l’associació han de ser el mateix, i es pot posar als dos llocs o a un sol.
A més, els següents tipus d’elements poden acompanyar un extrem d’una associació:
• El nom del paper del classificador dins l’associació.
• Una multiplicitat, que indica quantes instàncies del seu classificador, i per tant quants enllaços de
l’associació, poden estar relacionats a una mateixa instància del classificador de l’altre extrem.
• Un indicador de navegabilitat d’una associació binària és una punta de fletxa oberta, posada en un
extrem de la línia que representa l’associació. Indica que, en temps d’execució, partint de cadascu-
na de les instàncies del classificador de l’altre extrem es pot accedir de manera eficient a les ins-
tàncies del classificador d’aquest extrem que té enllaçades. Pot figurar als dos extrems, a un o a
cap; si en un extrem no n’hi ha s’entén que no està definit si hi ha navegabilitat cap a ell o no
(tanmateix també s’accepta que l’absència d’indicador de navegabilitat als dos extrems s’interpreti
com que hi ha navegabilitat cap a tots dos), mentre que per a indicar explícitament que no s’hi pot
navegar cal posar “x” a prop de l’extrem en qüestió, damunt la línia de l’associació.
• Un qualificador es representa per un rectangle més petit que el de la classe i interposat entre
aquesta i l’associació.
• Una visibilitat: “+”, “#”o “-” a nivell de paper.
• Una cadena de propietats que pot contenir les especificacions de propietat estàndard següents:
o “redefines” seguida del nom d’un extrem d’una altra associació associació1 significa que
l’extrem considerat substitueix aquest darrer.
o “ordered” vol dir que les instàncies del classificador d’aquest extrem enllaçades a les mateixes
instàncies dels classificadors de la resta d’extrems estan ordenades segons algun criteri.
o “nonunique” vol dir que entre les instàncies del classificador d’aquest extrem enllaçades a les
mateixes instàncies dels classificadors de la resta d’extrems n’hi pot haver de repetides.
o “sequence” o “seq” és la combinació de “ordered” i “nonunique”.
La notació d’un enllaç és com la de l’associació, sense multiplicitat ni propietats, però òbviament entre
instàncies de classificador (vegeu-ne la notació a l’apartat II. 6. ) en comptes de classificadors.

ADA – UML bàsic pàg. 14


III. 1. 3. 2. Exemples d’associacions

gmiipicidad
ipcoleción

;
Associació binària amb nom, sentit, navegació, papers i multiplicitats
d
popicday
Empresa
Osertidode
lloc de treball
lectune

conenacadeno Persona
0..1
empleador t
{ordered} 1..*
empleat
Aquesta associació significa que cada persona, en el paper d’empleat, pot tenir un lloc de treball en una empresa, la qual fa el
paper d’empleador; tota empresa té almenys una persona en el paper d’empleat i els empleats de cada empresa estan orde-
nats segons algun criteri no especificat.
* Nombres solo en las asociaciones
Extrem d’associació binària considerat com a atribut
necesario
que sea

.
Empresa

empleat: Persona[1..*] {ordered}

Correspon a l’associació anterior, però només en part: no s’hi pot especificar de quantes empreses pot ser empleat una perso-
na.

o
Classe associativa binària amb sentit, navegació, papers i multiplicitats
-

Lloc de treball
Empresa Persona
0..2 {ordered} 1..*
empleador empleat

relac
Guarda into sobre la
.
Lloc de treball
entre das clases

salari: float

És com l’associació lloc de treball anterior, llevat que aquí l’associació té un atribut i per tant ha de ser una classe associativa i
-

en conseqüència el seu nom ha de començar per majúscula. Si la cardinalitat màxima del paper empleador fos 1 no caldria la
classe associativa: n’hi hauria prou d’afegir a la classe Persona l’atribut salari.

Associació derivada
assignatures del curs vatributo derivado
Curs Assignatura
{nonunique}

alumnes de l’assignatura

/alumnes del curs B relaciones con


Alumne
{nonunique} bidireccional
naveg
.
L’associació alumnes del curs és derivada i és conseqüència de les associacions que signifiquen que cada curs té assignatures i
que cada assignatura té alumnes, i significa doncs que els alumnes d’un curs són tots els alumnes d’almenys una assignatura
del curs. Entre un alumne i curs determinats hi podria haver més d’un enllaç (seria en el cas que l’alumne cursés més d’una
assignatura del curs); d’aquí la propietat “nonunique” dels extrems de l’associació. Es podria definir una associació entre
alumne i curs que no fos derivada de les altres dues (que, per exemple, permetés que un alumne fos d’un curs sense estar
enllaçat a cap de les assignatures d’aquest); llavors no hi duria “/”.

ADA – UML bàsic pàg. 15


Associació amb qualificador Associació ternària

Categoria
Departament
0..1
categoria

1..*
Categoria 2..5
Empleat

2..5

Empleat 0..1

categoria: Categoria[1..*] Departament

principal
Associacions binàries Classe associativa caract

-
Categoria EmpDept

"
1..* categoria: Categoria
1..*
2..5
2..5 1..*
Empleat Empleat Departament
EmpDept
2..5
1..*
1..* Enamerantionss

Categoria
Departament

Observeu les diferències entre aquests quatre exemples:

L’associació amb qualificador significa que a cada departament hi ha entre 2 i 5 empleats de cada categoria i que cada emple-
at pertany almenys a un departament. Com que la categoria és un atribut de l’empleat, és independent de l’associació, i per
tant un empleat que pertany a diversos departaments té les mateixes categories en tots ells.

L’associació ternària vol dir que a cada departament hi ha entre 2 i 5 empleats de cada categoria, per a cada empleat i cate-
goria hi ha un departament o cap (per exemple, perquè si un empleat no té una certa categoria no la té a cap departament), i
per a cada empleat i departament hi ha una categoria o cap (per exemple, perquè si un empleat no pertany a un departament
determinat no hi té cap categoria). Un empleat pot tenir diverses categories però cada una en un departament diferent, i pot
estar en diversos departaments però amb una categoria diferent en cadascun.

Les tres associacions binàries volen dir que per a cada departament hi ha entre 2 i 5 empleats, prescindint de la categoria, i
per a cada categoria hi ha entre 2 i 5 empleats, prescindint del departament; per a cada empleat hi ha almenys una categoria,
per una banda, i almenys un departament, per una altra. Cada departament té almenys una categoria i cada categoria està
almenys en un departament.

La classe associativa vol dir que a cada departament hi ha entre 2 i 5 empleats, cada empleat està almenys en un departa-
ment i hi té una categoria, que pot ser diferent segons el departament però no cal que ho sigui.

ADA – UML bàsic pàg. 16


Associacions binàries alternatives

1
Proveidor
1

{xor}
Compte

Client
1

Cada compte correspon o bé a un client o bé a un proveïdor; si les multiplicitats de Proveidor i Client fossin 0..1 hi podria ha-
ver comptes que no fossin ni d’un client ni d’un proveïdor.

III. 1. 3. 3. Agregació i composició

Una associació binària és una agregació si el seu significat és que un objecte en un extrem (objecte
component, pertanyent a la classe component) és part d’un objecte de l’altre extrem (objecte agregat
pertanyent a la classe agregada).

En una relació d’agregació l’objecte agregat “coneix” els seus objectes components (i pot demanar-los
operacions, per exemple) però no viceversa, en general.

Una agregació és una composició si compleix totes aquestes condicions alhora:


• els objectes components només es poden crear si existeix l’objecte agregat del qual han de formar
part;
• cada objecte component forma part d’un sol objecte agregat;
• un objecte component no pot passar d’un objecte agregat a un altre;
• quan l’objecte agregat és esborrat o copiat els passa això mateix a tots els seus objectes compo-
nents.
Una classe composta és una classe agregada resultant d’una composició. Als seus objectes en comptes
d’objectes agregats se’ls diu objectes compostos.

De vegades es diu que una composició és una agregació per conteniment, mentre que una agregació no
composició és una agregació per referència, tenint en compte que els objectes components en una
agregació existeixen independentment de l’objecte compost i per tant fora d’ell.

Notació de l’agregació i de la composició

Una classe agregada duu un indicador d’agregació, que és un rombe més petit que el que representa
les associacions no binàries - ple en el cas d’una composició i buit en cas contrari- posat al costat d’ella
damunt la línia que representa l’associació amb una classe component.

Exemples:

Agregació
0..1 {xor} porter 1

0..1 defensa 3
EquipDeFutbol Jugador
0..1 mig 2

0..1 davanter 5

Representa la composició clàssica d’un equip de futbol. Cada jugador o bé juga en un equip o en cap, i un jugador només pot
estar en una de les quatre posicions, o en cap si no juga en cap equip. Se suposa que els defenses, per exemple, són inter-

ADA – UML bàsic pàg. 17


canviables entre ells, altrament o bé l’extrem corresponent a Jugador hauria d’estar ordenat, i llavors l’ordre determinaria les
posicions, o bé hi hauria d’haver onze agregacions diferents. Observeu que si la restricció “{xor}” i la línia discontínua associ-
ada estiguessin més a la dreta (és a dir, a la banda de Jugador en comptes de la d’EquipDeFutbol) un equip no podria tenir al-
hora defenses i porter, per exemple, i en canvi un jugador podria ser defensa en un equip i mig en un altre, per exemple, però
no pas en el mateix equip.

Composició

Universitat 1 1..*
CentreUniversitari

Una universitat està formada per centres (facultats i escoles), cada centre fa part d’una sola universitat, es crea lligat a ella i
no pot passar d’una universitat a una altra, i si se suprimeix una universitat tots els seus centres se suprimeixen també.

III. 1. 4. Generalització, especialització i herència en classes i


altres classificadors

III. 1. 4. 1. Generalització especialització i herència en les classes

Quan la generalització/especialització té lloc entre classes, si la classe A és subconjunt d’una altra B es


diu que A és subclasse de B i B superclasse d’A.

Entre classes l’herència consisteix en què la subclasse té almenys tots els atributs, operacions, associa-
cions i dependències de la superclasse.

Una subclasse pot ser-ho de diverses superclasses alhora (herència múltiple) i, independentment, pot
ser superclasse d’altres classes (jerarquia d’herència).

Un conjunt de generalització pot tenir nom (imprescindible quan damunt el classificador hi ha definit
més d’un conjunt de generalització) i se li pot especificar una cadena de propietats de la forma {p1,
p2} en la qual p1 pot ser “complete” (que significa que tota instància del classificador pertany també a
algun dels subconjunts) o la seva contrària “incomplete”, que és opció per defecte; p2 pot ser o bé
“overlapping” que indica que hi pot haver instàncies del classificador que pertanyin a diversos dels seus
subconjunts, o bé la seva contrària “disjoint”, que és opció per defecte.

Classe abstracta

Quan un classificador abstracte és una classe (classe abstracta) pot tenir operacions abstractes,
que no estan implementades i per tant no tenen mètode (en el sentit de l’apartat III. 1. 1. 1. ), sinó
que simplement representen una generalització d’operacions de les seves subclasses, totes les quals
han de tenir implementada l’operació mitjançant un mètode (excepte en el cas d’una subclasse que si-
gui també classe abstracta amb operacions abstractes, cas en el qual la implementació de les operaci-
ons abstractes es pot diferir a les seves subclasses directes o indirectes.

Exemples

Alumne Alumne Alumne Professor

Ensenyament
{complete, disjoint}

AlumneDoctorat AlumneGET AlumneGEI AlumneMIA AlumneDoctorat

A la figura de l’esquerra el classificador AlumneDoctorat és subconjunt del classificador Alumne. Com que no és abstracte hi

ADA – UML bàsic pàg. 18


pot haver alumnes que no siguin de doctorat.

A la figura del mig les propietats del conjunt de generalització anomenat Ensenyament indiquen que tota instància d’Alumne
ha de pertànyer almenys a algun dels classificadors que l’especialitzen (cosa que és redundant amb el fet que Alumne és abs-
tracte) i que entre les seves instàncies no n’hi pot haver que siguin alhora de dos o més dels subconjunts d’Alumne, per
exemple d’AlumneGEI i d’AlumneGET.

A la figura de la dreta s’especifica que tot alumne de doctorat és alhora alumne i professor.

III. 1. 4. 2. Generalització, especialització i herència en alguns


classificadors altres que les classes

Entre interfícies hi pot haver herència, fins i tot múltiple, igual que entre classes. Si un classificador C
implementa una interfície I, implementa també totes aquelles interfícies de les quals I hereta.

Exemple:

Herència d’interfícies paral·lela a l’herència de les classes que les implementen

«interface»
C
I
op_a()
op-a() op_b()

«interface»
C1
I1
op_c()
op-c()

La classe C1 implementa les operacions op_a() i op_c() de la interfície I1; tant la classe com la interfície hereten l’operació
op_a() respectiva. op_b() de C no implementa cap operació d’I.

III. 1. 4. 3. Especialització d’associacions

Entre dues associacions hi pot haver una relació de generalització/especialització; si són classes associ-
atives, la generalització/especialització es pot representar entre les línies de les dues associacions i/o
entre els símbols de les classes associatives respectives. Una classe associativa pot heretar d’una classe
ordinària.

Exemples:

Especialització/generalització entre associacions


1..* client qualsevol 1..*

Empresa 0..* 0..* Client


client habitual

Tot parell empresa – client enllaçat per l’associació client habitual ho està també per l’associació client qualsevol però no vice-
versa. És a dir, un client habitual d’una empresa n’és també un client qualsevol.

Especialització/generalització entre classes associatives

ClientQualsevol

Empresa Client

ClientHabitual

ClientHabitual
ClientQualsevol ^vendes: Single
vendes: Single descompte: int
ADA – UML bàsic pàg. 19
És com el diagrama anterior però ara l’associació ClientQualsevol té una atribut, vendes, i per tant és classe associativa;
aquest atribut és heretat per la classe associativa ClientHabitual, que a més té l’atribut propi descompte; amb una de les dues
fletxes de generalització/especialització n’hi hauria prou. Si ClientQualsevol no tingués atributs no caldria que fos classe asso-
ciativa i aleshores una classe associativa heretaria d’una associació no classe.

ADA – UML bàsic pàg. 20


IV. ELS DIAGRAMES DE COMPORTAMENT
Els diferents diagrames de comportament descriuen els comportaments des de diferents punts de vista:
• El diagrama de casos d’ús identifica els diferents comportaments executants d’un sistema i les enti-
tats del món exterior amb les quals interactuen i també estableix determinades relacions entre
aquests comportaments.
• El diagrama d’estats mostra els possibles canvis d’una situació a una altra de les instàncies del
classificador de context i n’indica les causes, les condicions i les execucions de comportaments as-
sociades.
• El diagrama d’activitats descompon un comportament en activitats i descriu l’ordre i condicions de
l’execució respectiva i els fluxos d’informació entre elles.
• El diagrama d’interacció representa un comportament emergent per mitjà de missatges entre ins-
tàncies o classificadors i també pot especificar restriccions temporals relatives a aquests missatges;
ens centrarem al diagrama de seqüències, que posa èmfasi en l’ordre temporal dels missatges,

IV. 1. DIAGRAMA DE CASOS D’ÚS

El diagrama de casos d’ús identifica els comportaments executants d’un classificador generalment com-
plex (per exemple un programari) i especifica amb quins usuaris i altres entitats exteriors tenen in-
teracció (en el sentit que en reben informació o els en donen o són engegats per elles) i també certes
relacions entre aquests comportaments.

IV. 1. 1. Conceptes

IV. 1. 1. 1. Subjecte

El subjecte d’un diagrama de casos d’ús és el classificador de context dels comportaments executants
representats al diagrama. Pot ser qualsevol cosa que tingui comportaments: un sistema informàtic o
físic en general, un subsistema, un component o una classe.

Notació

El subjecte no se sol representar; ara bé, com que és un classificador, es pot representar pel símbol de
classificador; aleshores té un compartiment dins del qual hi ha representats els seus casos d’ús.

IV. 1. 1. 2. Actor

Un actor és un conjunt de papers que fa una entitat física o virtual externa al subjecte en relació als
comportaments d’aquest. A través d’aquests papers l’actor interactua amb el subjecte, i cada paper té a
veure amb un dels casos d’ús del subjecte.

A una sola d’aquestes entitats externes li poden correspondre diversos actors, si les interaccions que té amb el sistema de
maquinari i programari són prou diverses per considerar que fa diferents grups de papers en relació a ell. Aquesta circumstàn-
cia no es veuria pas al diagrama.

Els actors són classificadors instanciables.

Per exemple un actor Comptable representa tots els comptables que hi pugui haver que participin en els mateixos casos d’ús
de la mateixa manera.

Un actor pot ser:


• una persona (un usuari) que interactuï directament amb el subjecte (per tant si un usuari interac-
tua amb el subjecte per compte d’un altre, l’actor serà el primer usuari, no pas el segon);
• un sistema informàtic extern en temps d’execució que rebi informació del subjecte o n’hi doni;
• un dispositiu físic que tingui un cert comportament propi i autònom en relació al subjecte i interac-
ADA – UML bàsic pàg. 21
tuï directament amb ell;
• “Temps”, “Rellotge”, etc. quan un cas d’ús s’engega automàticament en una hora determinada.
En canvi ni la infraestructura de maquinari i xarxa i programari bàsic damunt la qual hi ha el subjecte ni
cap part d’ella no són actors perquè els actors són externs a tot això.

Notació de l’actor

Un actor es pot representar com un classificador sense atributs ni operacions amb l’estereotip “actor”, o
bé amb el dibuix següent acompanyat pel nom de l’actor (el qual va en cursiva en el cas d’un actor abs-
tracte); també es poden definir símbols específics, no estàndard, per a actors altres que els usuaris.

Actor1
Els actors es poden representar a nivell de classificador o a nivell d’instància, cosa que es distingeix
mitjançant el format del nom, de la mateixa manera que per a un classificador en general (vegeu
l’apartat II. 6. ).

IV. 1. 1. 3. Relacions entre actors

Entre actors pot haver-hi relacions de generalització/especialització i per tant herència, que con-
sisteixen en què l’actor especialitzat hereta els papers que té l’actor generalitzat en relació a casos d’ús
del subjecte. Pot haver-hi actors abstractes, qualsevol instància dels quals que intervingui en una
execució concreta d’un cas d’ús ha de pertànyer a algun dels actors que l’especialitzen.

Exemple:

Actor abstracte i herència entre actors

Usuari

Engegador

Rellotge
Aquest diagrama expressa que un Engegador (suposem que anomenarem així l’actor primari d’alguns casos d’ús d’un cert
subjecte) pot ser o bé un usuari o bé el rellotge; el fet que Engegador sigui un actor abstracte exclou altres possibilitats (és a
dir, tota instància d’Engegador ha de ser instància o bé d’Usuari o bé de Rellotge).

IV. 1. 1. 4. Cas d’ús

Un cas d’ús és un comportament executant del subjecte; és engegat de manera directa o indirecta (és
a dir, des de dins d’un altre cas d’ús) per un actor i lliura uns resultats concrets a un actor o a diversos
o a un altre cas d’ús.

Un cas d’ús designa un comportament que ha de tenir el subjecte, però el diagrama de casos d’ús no
descriu en què consisteix, aquest comportament.

ADA – UML bàsic pàg. 22


Notació

Els casos d’ús es representen per el·lipses que porten el nom respectiu a dins. Una representació alter-
nativa dels casos d’ús és amb un símbol de classificador amb una el·lipse com a icona representativa de
l’estereotip.

Cdu1

IV. 1. 1. 5. Relacions entre casos d’ús i actors

Entre actors i casos d’ús només hi ha associacions binàries, que representen la interacció entre ells.
Aquestes associacions poden tenir multiplicitats a les quals la cardinalitat màxima sigui més gran que 1
i aleshores

• en el cas de l’extrem corresponent a l’actor vol dir que en una sola execució del cas d’ús hi pot
intervenir més d’una instància de l’actor

• i en el cas de l’extrem corresponent al cas d’ús vol dir que una instància de l’actor pot intervenir
en diverses execucions del cas d’ús, per bé que no queda determinat si aquestes execucions són
simultànies o successives.

La interacció entre actor i cas d’ús pot incloure l’engegada del cas d’ús per l’actor (aleshores diem que
n’és l’actor primari), o bé pot consistir només en què l’actor rebi informació i en subministri quan el
subjecte li ho demani (és el cas dels actors secundaris del cas d’ús). A nivell de classificador un cas
d’ús pot tenir diversos actors primaris alternatius, però cada execució (és a dir, cada instància) del cas
d’ús serà engegada per una sola instància d’un dels actors primaris.

Exemple:

Biblioteca

Consulta

Lector
Prestec

Bibliotecari

El subjecte Biblioteca té dos casos d’ús, Consulta i Prestec, cadascun dels quals té un sol actor (necessàriament primari ja que
altrament no es podrien pas executar), Lector i Bibliotecari respectivament.

IV. 1. 1. 6. Relacions entre casos d’ús

Entre casos d’ús hi pot haver els següents tipus de relacions:


• Dependència d’extensió (estereotip “extend”): una dependència d’extensió del cas d’ús A (client)
al B (subministrador) amb una certa condició c i una referència a un punt d’extensió o diversos
de B significa que, si quan l’execució de B arriba al primer punt d’extensió es compleix c, els dife-
rents fragments d’A s’insereixen en els punts d’extensió corresponents.
• Dependència d’inclusió (estereotip “include”): si hi ha una dependència d’inclusió del cas d’ús A
(client) al B (subministrador), A inclou el comportament de B de manera que A fa servir el resultat
de l’execució de B d’una manera anàloga a una operació que en crida una altra.
• Relació de generalització/especialització/herència, que significa que un dels casos d’ús està
especialitzat en el sentit que conté alguna acció més que el cas generalitzat o bé que la mateixa

ADA – UML bàsic pàg. 23


acció hi té una semàntica diferent. Pot haver-hi casos d’ús abstractes, cada execució (és a dir,
cada instància) dels quals ha de ser necessàriament la d’algun dels casos d’ús que els especialitzen.

Regles pràctiques sobre les relacions entre casos d’ús:

Extensió: el cas d’ús cridat


• només s’executa quan es compleix una certa condició;
• pot ser que es pugui executar com a cas d’ús independent (i llavors ha de tenir algun actor primari)
o no (i llavors no en pot tenir); en tot cas pot tenir actors secundaris.
Inclusió: el cas d’ús inclòs (el B de la definició),
• és subministrador de més d'una dependència d’inclusió i/o també client en una dependència
d’extensió: és a dir, si no és compartit per diversos casos d’ús no val la pena que sigui un cas d’ús
a part;
• la seva execució dins del cas d’ús principal no cal que estigui subjecta a una condició;
• normalment no es pot executar com a cas d’ús independent i per tant normalment no té actors
primaris però pot tenir actors secundaris.
Especialització/generalització:
• un dels casos d’ús té un comportament més especialitzat que l’altre, però s’executen de manera to-
talment independent (tret dels casos d’ús abstractes, que no es poden executar), a diferència de
les relacions d’extensió i d’inclusió;
• no es pot separar fàcilment el comportament comú als dos casos d’ús del comportament específic
del cas d’ús més especialitzat, a diferència també de les relacions d’extensió i d’inclusió;
• un cas d’ús abstracte reuneix el comportament comú (els passos comuns, podríem dir-ne) a dos
casos d’ús o més, i pel fet de ser un classificador abstracte no es pot instanciar - o sigui executar-
a diferència d’un cas d’ús inclòs.
De vegades es dubta de quina relació hi ha entre uns certs casos d’ús. Les regles següents poden aju-
dar a decidir-se per una relació o una altra:
• perquè hi hagi extensió cal una condició;
• perquè hi hagi inclusió cal que hi hagi comportament A comú a dos casos d’ús B i C almenys (per
bé que pot ser que només un d’ells figuri al diagrama o que dins un d’ells - posem el B- l’execució
sigui condicional; en aquest darrer cas hi ha una extensió d’A cap a B i una inclusió de C cap a A);
• si el comportament compartit per diversos casos d’ús no consisteix en una seqüència de passos
consecutius aleshores no hi pot haver inclusió sinó herència des d’un cas d’ús que consisteix en
aquest comportament compartit; aquest cas d’ús serà concret si és executable i abstracte si no.
Val a dir que el procés de cadascun dels casos d’ús serà diferent si es defineix un cas d’ús inclòs o un
d’abstracte.

Exemples:

Extensió

Des del cas d’ús B quan es compleix una certa condició es crida l'A, que és un cas d’ús que també pot ser cridat directament
per un actor primari, el qual és el mateix per a tots dos casos d’ús. Per exemple quan B crea un enllaç segons una associació i
A crea un dels objectes enllaçats: aquest objecte es pot crear sense necessitat d'enllaçar-lo, i llavors A és executat directa-
ment pel seu actor primari; o pot ser executat perquè fa falta per a la creació d'un enllaç, i en aquest cas és cridat des de B.

Inclusió

En comptes de definir uns casos d’ús A, B, C, etc. que tenen una part Z en comú, es defineixen A' = A sense Z, etc. i es diu
que A', B', C', etc. inclouen Z. Z no pot ser engegat directament i per tant no té actor primari.

Especialització

El cas d’ús que crea un empleat estranger podria ser una especialització del que crea un empleat normal, ja que en el primer
cas s'ha de fer el mateix que en el segon i a més s'ha de donar informació sobre el permís de residència i el permís de treball.
Quan un cas d'ús A tracta un objecte d'una classe C i un altre B tracta un objecte d'una subclasse de C entre A i B hi haurà
sovint una relació d’especialització paral·lela a la de les classes esmentades. El procés de B sense el d’A no és cap cas d'ús in-
dependent, ni tan sols un cas d'ús.

ADA – UML bàsic pàg. 24


Generalització

La situació de l’exemple d’inclusió també es podria representar fent que A, B, C, etc. heretin de Z; aquesta opció és més gene-
ral que la inclusió perquè no cal que els passos heretats siguin consecutius dins el cas d’ús que els hereta mentre que en la in-
clusió el cas d’ús inclòs s’executa tot de cop.

Notacions

Les dependències d’extensió i d’inclusió es representen pel símbol general de dependència (fletxa dis-
contínua de punta oberta) amb la paraula clau “extend” o “include”, respectivament. Una dependència
d’extensió pot tenir associada una nota com aquesta:

Condition: {restr1}
Extension point: punt1

Els punts d’extensió d’un cas d’ús s’especifiquen en una llista de punts d’extensió dins un compartiment
del cas d’ús cadascun dels punts d’extensió té un nom que pot anar seguit de “:” i una explicació.

Cdu1
extension points
punt1

La relació de generalització/especialització es representa igual que en el cas de classes o classificadors


en general (és a dir, fletxa de línia contínua i punta triangular buida apuntant en el sentit de la genera-
lització). Un cas d’ús abstracte té el nom en cursiva.

IV. 1. 2. Exemple general


Casos d’ús d’un sistema, amb actors i relacions

Sistema de comptabilitat

Condition: {compte no trobat}


extension point : Compte llegit

1
Assentament
0..* «extend»
Extension points CreacioCompte
Compte llegit
Comptable
«include»

DadesCompte

2ari
TancamentMensual
«include» 0..* 1

1 0..* CapAdjunt
Tancament

TancamentAnual
CapComptable

L’actor CapComptable és una especialització de Comptable; Comptable només pot intervenir en el casos d’ús Assentament i
CreacioCompte (dels quals és l’actor primari ja que no n’hi ha d’altre), mentre que l’actor CapComptable és actor primari del
cas d’ús Tancament i també, per herència, d’Assentament i CreacioCompte. El cas d’ús CreacioCompte estén el cas d’ús As-

ADA – UML bàsic pàg. 25


sentament perquè quan s’intenta fer un assentament amb un compte inexistent cal crear aquest compte (aquesta creació no
és un cas d’ús executable independentment perquè no té actor primari); s’ha indicat el punt d’extensió dins del cas d’ús estès.
El cas d’ús DadesCompte consisteix en l’accés a les dades d’un compte, que és una part comuna als casos d’ús Assentament i
Tancament. Tancament és un cas d’ús abstracte, i TancamentMensual i TancamentAnual en són especialitzacions, i com a
conseqüència, n’hereten els actors i no cal associar-los-hi explícitament; TancamentMensual té, a més de l’actor heretat,
l’actor secundari CapAdjunt. Les multiplicitats de les associacions són innecessàries per trivials: en cada execució del cas d’ús
intervé una sola instància de l’actor i cada instància de l’actor pot participar en qualsevol nombre d’execucions del cas d’ús.

IV. 2. DIAGRAMA D’ESTATS

El diagrama d’estats descriu el conjunt dels comportaments de les instàncies d’un classificador, o el
d’un classificador no instanciable, en termes del seu pas per diferents situacions, que anomenem estats.
Els canvis d’un estat a un altre són, per una banda, conseqüència d’esdeveniments (apartat IV. 2. 1. 2.
), i per una altra, causa de l’execució de comportaments, i poden estar subjectes a condicions.

IV. 2. 1. Conceptes previs

IV. 2. 1. 1. Senyal

Un senyal és una instància que un objecte o1 envia a un altre o2 i com a conseqüència d’aquest envi-
ament s’executa un comportament que té o2 com a objecte de context. Aquest comportament no pot
tornar cap resposta a o1. Un senyal pot tenir paràmetres.

El senyal és un estereotip del classificador. Entre senyals pot haver-hi herència, i el que s’hereta són els
paràmetres i els efectes provocats pel senyal.

Notació

Un senyal es representa pel símbol de classificador amb l’estereotip “signal”.

Exemple

«signal»
Senyal1
-par1: String

Una recepció de senyal és un estereotip de l’operació que es troba generalment dins una classe o in-
terfície i indica que les instàncies del classificador que la conté reaccionen al senyal executant algun
comportament.

Notació
Una recepció de senyal es representa en forma d’una operació d’estereotip “signal”. Com que no pot
tornar cap valor no pot tenir paràmetres out ni inout ni valor de retorn. Tampoc no pot tenir visibilitat ni
la propietat “isQuery”.

IV. 2. 1. 2. Esdeveniment i disparador

Un esdeveniment (event) és un succés que pot produir-se dins el sistema o el seu entorn i quan té
lloc pot provocar l’execució d’un comportament o alterar-la. Aquest efecte de l’esdeveniment pot ser
immediat o bé diferit.

Al fet que es produeixi un cert esdeveniment en un instant concret se li diu ocurrència


d’esdeveniment i un conjunt de possibles ocurrències d’esdeveniment que tindrien el mateix significat
i efectes és un tipus d’esdeveniment. El terme “esdeveniment” pot significar una cosa o altra segons
el context.

Es considera que els esdeveniments que es van produint al llarg del temps es col·loquen en una cua, de
la qual el sistema els agafa per a processar-los un a un, de manera que fins que no ha acabat el procés
d’un esdeveniment no comença a processar el següent.
ADA – UML bàsic pàg. 26
Un disparador (trigger) és un element que especifica que una ocurrència d’esdeveniment del tipus
indicat en ell pot engegar un cert comportament.

I inversament, tant l’engegada com la fi d’un comportament generen esdeveniments que poden enge-
gar d’altres comportaments a través dels disparadors corresponents.

Classificació dels esdeveniments i dels disparadors

Els tipus d’esdeveniment es classifiquen així:


• Un esdeveniment de missatge correspon a la invocació d’una operació o l’arribada d’un senyal, i
pot ser
o esdeveniment de senyal, que és l’arribada d’un senyal;
o esdeveniment de crida (call event), que és la recepció de la invocació d’una operació damunt
l’objecte que rep l’esdeveniment;
o esdeveniment anyReceive, que comprèn tots aquells esdeveniments de missatge no esmentats
a la signatura de cap de les transicions que surten del mateix estat.
• Esdeveniment de temps, que representa que s’ha arribat en un cert instant, cosa que s’indica mit-
jançant una expressió de temps que especifica o bé un punt en el temps o bé una durada comptada
a partir d’un cert punt en el temps.
• Esdeveniment de canvi, que representa el fet que una certa expressió booleana passi a ser certa a
conseqüència de canvis en valors d’atributs o enllaços de l’objecte de context.
Els disparadors es classifiquen d’acord amb el tipus d’esdeveniment respectiu, és a dir la classificació
anterior s’aplica tant als esdeveniments com als disparadors.

Notacions dels tipus d’esdeveniment i dels disparadors

La notació dels tipus d’esdeveniment depèn de la seva categoria segons la classificació anterior:
• Esdeveniments de missatge:
▪ Un tipus d’esdeveniment de crida es descriu per mitjà de la llista d’operacions que engega, ca-
dascuna seguida opcionalment d’una llista entre parèntesi dels noms dels atributs de l’objecte
que rep l’esdeveniment, separats per comes, als quals s’assignen els successius paràmetres de
l’operació:
operació1”,” operació2 “(”atr1”, ”atr2,... “)”.
▪ Un tipus d’esdeveniment de senyal es descriu de manera anàloga a un esdeveniment de crida
senyal1”,” senyal2 “(”par1”, ”par2,... “)”.
▪ Un tipus d’esdeveniment anyReceive s’indica amb “all”.
• Esdeveniments de temps:
o Un esdeveniment de pas d’un cert temps es descriu amb l’expressió
“after” “(” expressió_que_permet_calcular_un_interval_de_temps “)”.
S’entén que l’interval comença a comptar-se des del moment en que l’objecte de context va en-
trar en l’estat actual.
o Un esdeveniment d’arribada a una certa hora o data es pot especificar amb
“at” “(” data_i_hora“)” .
• Esdeveniments de canvi:
o Un esdeveniment de canvi s’especifica per “when” seguit d’una expressió booleana que descriu
aquella condició que quan esdevé certa es produeix una ocurrència de l’esdeveniment.
La notació del disparador és la del seu esdeveniment.

IV. 2. 2. Màquina d’estats


Una màquina d’estats és una descripció del comportament d’un sistema o d’una part d’ell (per exem-
ple dels objectes d’una classe) per mitjà d’un graf orientat en el qual els nodes s’anomenen vèrtexs i
els arcs transicions simples; mentre el sistema recorre el graf s’executen activitats relacionades amb
els vèrtexs i transicions pels quals passa.

Els vèrtexs poden ser:


• estats,

ADA – UML bàsic pàg. 27


• referències a punts de connexió (vegeu l’apartat IV. 2. 7. 2. ), o
• pseudoestats.
Un diagrama d’estats és la representació d’una màquina d’estats o diverses.

Una màquina d’estats pot ser redefinida mitjançant especialització per a donar lloc a una altra (que es
diu que és una màquina d’estats estesa) la qual pot tenir estats i transicions simples heretats de la pri-
mera i d’altres de propis.

IV. 2. 3. Estat
Un estat és un vèrtex que representa una situació durant la qual es compleix un cert invariant (que pot
estar implícit) anomenat invariant de l’estat.

Aquest invariant pot consistir, per exemple, en què


• un objecte espera que es produeixi un esdeveniment d’un cert tipus per a executar un determinat
comportament, o bé
• hi ha un procés en curs que afecta un element que entra en l’estat en qüestió quan comença el
procés i en surt quan acaba.
Un estat pot tenir associats esdeveniments diferits. Una ocurrència d’esdeveniment que es produeixi
en un cert estat i no engega cap transició perquè no se’n compleix la guarda es perd a menys que el
tipus de l’esdeveniment estigui definit com a diferit a l’estat en qüestió; si és així l’ocurrència
d’esdeveniment roman en un pool fins que, com a conseqüència d’ocurrències d’altres esdeveniments,
s’arriba en algun altre estat en el qual o bé pot provocar una transició o bé l’esdeveniment no està defi-
nit com a diferit (i en aquest cas es perd definitivament sense provocar cap efecte).

Estat compost, estat simple i estat de submàquina

Un estat compost (composite state) és aquell que conté una regió, o més, cadascuna de les quals
conté una màquina d’estats; els estats d’aquesta màquina es diu que són subestats de l’estat com-
post. Cada subestat només pot estar en una de les regions.

Un esdeveniment que està especificat com a diferit en un estat compost és com si també ho estigués en
tots els seus subestats de qualsevol nivell.

Un estat simple és un estat no compost, és a dir que no conté regions ni per tant subestats.

Un estat de submàquina és un vèrtex en el qual s’insereix una màquina d’estats descrita en un dia-
grama a part. Equival a un estat compost llevat que permet la utilització de la mateixa màquina d’estats
en diversos estats de submàquina.

En un diagrama d’estats hi pot haver diversos estats de submàquina relatius a la mateixa màquina d’estats, igual que en un
diagrama d’objectes hi pot haver diversos objectes de la mateixa classe; en tots dos casos cal distingir-los pel nom.

IV. 2. 3. 1. Comportaments associats a un estat

Normalment són activitats, per bé que poden ser comportaments de qualsevol mena. N’hi ha els se-
güents tipus:

• Comportaments d’entrada, que s’executen immediatament que l’estat esdevé actiu i abans
que cap altre comportament.

• Comportaments de sortida que s’executen just abans que l’estat deixi d’estar actiu.

• Comportaments durant l’estat (do-activities) que s’executen a continuació dels comporta-


ments d’entrada i deixen d’executar-se o bé quan l’execució s’acaba per ella mateixa o bé quan
l’estat esdevé inactiu a conseqüència d’alguna transició.

Quan els comportaments d’entrada i durant l’estat completen el seu procés de manera normal es gene-
ra una ocurrència d’esdeveniment de finalització (completion event), que té prioritat superior a la de
qualsevol esdeveniment diferit (apartat IV. 2. 3. ) i pot engegar una transició de finalització que faci
sortir de l’estat. Un esdeveniment de finalització no té cap notació explícita (i es reconeix per això).

Els estats de les màquines d’estats de protocol no poden tenir comportaments associats.
ADA – UML bàsic pàg. 28
IV. 2. 3. 2. Notació de l’estat simple

La representació simplificada de l’estat simple és un rectangle amb els vèrtexs arrodonits amb el nom
de l’estat a dins o en un petit rectangle adossat. Els esdeveniments diferits (vegeu l’apartat IV. 2. 3. )
durant l’estat en qüestió s’especifiquen sota el nom de l’estat amb el nom de l’esdeveniment seguit de
“/defer”.
estat_1

estat_1

L’estat estat_1 està representat de dues maneres.

En la representació completa un estat simple pot tenir diversos compartiments separats per línies horit-
zontals; aquests compartiments són:
• El compartiment del nom, que no hi ha de ser si el nom s’indica dins un petit rectangle a part,
com hem vist. Pot contenir la mateixa informació de la notació de l’estat simple.
• El compartiment dels comportaments interns, que conté les especificacions dels comporta-
ments d’entrada, de sortida i durant l’estat, si existeixen.
• El compartiment de les transicions internes (apartat IV. 2. 5. ), on s’especifiquen aquestes.
Les notacions de l’estat compost i de l’estat de submàquina es descriuen respectivament als apartats
IV. 2. 7. 1. i 0

IV. 2. 4. Vèrtexs altres que l’estat en màquines d’estats no-


més amb estats simples

IV. 2. 4. 1. Pseudoestat inicial, estat final i pseudoestat terminal

Pseudoestat inicial

Dins una màquina d’estats hi pot haver un sol vèrtex, anomenat pseudoestat inicial de la màquina
d’estats, al qual no hi ha cap transició que hi porti i només en surti una transició cap a l’estat per defec-
te (default state) de la màquina d’estats, que és el primer estat “efectiu” al qual s’arriba; aquesta tran-
sició pot tenir associat un comportament però no pas disparador ni guarda.

Notació

Un pseudoestat inicial es representa per una circumferència plena:

Estat final

És un estat del qual no surt cap transició; una màquina d’estats pot no tenir cap estat final.

Notació

Un estat final es representa per una circumferència plena encerclada per una circumferència buida:

Pseudoestat terminal

Un pseudoestat terminal (terminate pseudostate) és un vèrtex tal que quan s’hi arriba s’acaba
l’execució de la màquina d’estats a què pertany, sense sortir de cap estat ni executar res més que
l’acció associada, si n’hi ha, a la transició cap a ell. Les activitats durant l’estat s’interrompen i si la mà-
quina d’estats correspon a un objecte, aquest és destruït.

Notació

Un pseudoestat terminal es representa per dues barres en X:

ADA – UML bàsic pàg. 29


IV. 2. 4. 2. Pseudoestats d’embrancament i de tria

Pseudoestat d’embrancament

A un pseudoestat d’embrancament (junction pseudostate) poden arribar transicions amb diferent


estat d’origen i/o en poden sortir transicions amb diferent estat de destinació; aquestes darreres transi-
cions han de tenir guardes, i en particular la guarda d’una d’elles pot ser “else”, que correspon al cas en
què no es compleix cap de les altres.

Notació

Es representa per una circumferència plena:

[a=1]
Est2 Est4

ev1
ev2

Est1 Est5
[else]

Per tant el pseudoestat d’embrancament es representa igual que el pseudoestat inicial, però no hi ha confusió possible perquè
el primer sempre és destinació de transaccions i el segon mai.

El diagrama anterior equival a aquest:


ev1 [a=1]
Est2 Est4

ev1[a<>1]
ev2[a=1]

Est1 ev2[a<>1 Est5


]

Pseudoestat de tria

Un pseudoestat de tria (choice pseudostate) és com l’anterior, llevat que en les guardes de les transi-
cions que en surten hi intervenen valors que es calculen en temps d’execució. Sempre s’ha de complir
almenys una de les guardes, i quan se’n compleix més d’una es tria arbitràriament una de les transici-
ons corresponents.

Notació

Es representa per un rombe, en qualsevol d’aquestes formes:

[x<=10] [x>10] [<=10] [>10]


x

IV. 2. 5. Transicions simples


Una transició simple expressa el pas d’un vèrtex d’origen a un altre de destinació.

Perquè es produeixi una transició simple cal que:


• s’hagi produït una ocurrència d’un dels esdeveniments associats al disparador de la transició,
• i pot ser que a més s’hagi de complir una condició anomenada guarda.
El fet que es produeixi una transició pot comportar l’execució d’un comportament associat a ella.

Una transició interna és com una transició simple llevat que no comporta cap canvi d’estat; però,
igual que la resta de transicions simples, és engegada per una ocurrència d’esdeveniment pot tenir

ADA – UML bàsic pàg. 30


guarda i donar lloc a l’execució d’un comportament. Una transició interna no és el mateix que una tran-
sició d’un estat cap a ell mateix (autotransició), ja que en aquest darrer cas s’executen els comporta-
ments de sortida de l’estat i d’entrada a ell, si existeixen.

Notació de la transició simple i la transició interna

Una transició simple s’indica mitjançant una fletxa de línia contínua i punta oberta d’un estat a l’altre
amb l’etiqueta següent:
disparador “[”guarda“]” “/” comportament
• Les notacions del disparador són les de l’apartat IV. 2. 1. 2. llevat del disparador corresponent a
l’esdeveniment de finalització, que no es representa. Quan hi ha atributs que reben els arguments
d’una operació o senyal poden ser atributs de l’objecte de context del comportament o bé atributs
locals del comportament associat a la transició, als quals s’assignen aquells arguments, que es de-
fineixen aquí mateix amb nom, “:” i tipus.
• La guarda és una condició booleana en termes dels paràmetres de l’esdeveniment i els atributs i
enllaços de l’objecte a què correspon la màquina d’estats, i també d’estats concurrents amb l’estat
en qüestió o d’estats d’altres objectes (condicions de la forma “objecte1 in estat1” o bé “objecte1
not in estat1”); els subestats poden estar qualificats per estats, amb “::” entremig.
• Pel que fa al comportament, hi pot constar
o o bé el nom d’un comportament amb els seus eventuals paràmetres i referències al seu objecte
de context,
o o bé una seqüència d’accions, que en particular poden comportar la tramesa de senyals i crides a
operacions.
La notació de la transició interna es redueix a l’etiqueta; les transicions internes formen una llista a
dins del compartiment corresponent del símbol d’estat (vegeu l’apartat IV. 2. 3. 2. ). L’etiqueta
dels comportaments interns és com la de les transicions simples; quant a l’esdeveniment,
o els comportaments d’entrada i sortida de l’estat s’assignen a sengles esdeveniments amb nom
reservat “entry” i “exit” respectivament, i no poden tenir arguments ni condició de guarda;
o els comportaments durant l’estat s’assignen a l’esdeveniment “do”.

IV. 2. 6. Exemples de diagrama d’estats amb estats simples

Autotransició

EnPrestec

entry / posar data retorn

peticio_renovacio (data: Date, codi_llibre: String) [no reservat]/ renovació préstec

Quan un usuari de la biblioteca té un llibre en préstec pot fer peticions de renovació del préstec (que són ocurrències d’un ti-
pus d’esdeveniment de senyal) i cada petició indica la data i el codi del llibre (que són els arguments del senyal). Una petició
es concedida si es compleix la guarda que el llibre no està reservat per a un altre lector. Els efectes de l’esdeveniment peti-
cio_renovacio són l’autotransició i l’execució del comportament renovació préstec; a més cada vegada que s’entra a l’estat En-
Prestec s’executa el comportament posar data retorn.

ADA – UML bàsic pàg. 31


Comportaments interns i transicions internes

Acadèmia

Sol·licitant
/entrada de sol·licitud [sol·licitud rebutjada]/ comunicació
entry/ registrar sol·licitud
do/ examinar sol·licitud
exit/ arxivar decisió

[sol·licitud acceptada]

Acceptat
entry/ comunicar acceptació
do/ comprovar vacants
canvi tarifa (nova_tarifa: double)/ comunicar canvi

when(vacant trobada)/comunicació horari after(30 dies)/ comunicació

[alumne renuncia]

[alumne accepta]

at(data de fi del curs)/ posar nota


Inscrit

El diagrama descriu el procés d’una sol·licitud de plaça en una acadèmia en termes dels canvis d’estat de l’aspirant a alumne.
Quant entra una sol·licitud l’aspirant a alumne corresponent passa a l’estat de sol·licitant (que és l’estat per defecte), i a con-
seqüència de l’entrada en aquest estat s’executa una activitat d’entrada que registra la sol·licitud i un cop registrada hom
examina la sol·licitud amb un comportament (activitat) dins l’estat. Quan s’ha acabat d’examinar–la es produeix un esdeveni-
ment de finalització que engega una transició de finalització que fa que l’alumne surti de l’estat Sol·licitant i en conseqüència
s’executa l’activitat de sortida arxivar decisió; aleshores si es compleix la guarda que la sol·licitud ha estat rebutjada es fa una
comunicació a l’aspirant i s’acaba tot el procés pel que fa a aqueix aspirant a alumne, mentre que si la guarda que es compleix
és que la sol·licitud ha estat acceptada l’aspirant a alumne passa a l’estat Acceptat. En entrar en aquest estat es comunica
l’acceptació a l’alumne i es va comprovant amb un comportament dins l’estat si hi ha vacants; si mentrestant es produeix un
canvi de tarifa es comunica a l’aspirant, però aquesta comunicació no comporta la sortida de l’estat i per aquesta raó se l’ha
associada a una transició interna. La comprovació de les vacants continua fins que o bé es produeix l’esdeveniment de temps
que han passat 30 dies – i aleshores llavors l’aspirant a alumne surt de l’estat Acceptat i se li fa una comunicació i s’acaba
l’execució de la màquina d’estats – o bé es produeix l’esdeveniment de canvi que s’ha trobat una vacant, i llavors l’aspirant a
alumne surt igualment de l’estat Acceptat i se li comunica l’horari del curs; llavors si accepta la inscripció entra en l’estat Ins-
crit, mentre que si renuncia s’acaba la màquina d’estats. Un cop un alumne està en l’estat Inscrit quan arriba la data de la fi
del curs – un esdeveniment de temps– es posa la nota i s’acaba la màquina d’estats.

IV. 2. 7. Conceptes i notacions propis dels diagrames amb es-


tats compostos i/o de submàquina

IV. 2. 7. 1. Notació de l’estat compost

Un estat compost es representa amb un compartiment més que els estats simples, el qual conté la re-
gió o regions de l’estat, una sota l’altra i separades per línies discontínues, cadascuna de les quals conté
una màquina d’estats; una regió pot tenir opcionalment un nom dins un rectangle adossat. El compar-
timent es pot afegir tant a la representació simplificada de l’estat simple com a la completa. Vegeu
exemples d’aquesta notació a l’apartat IV. 2. 7. 4.

Si es vol assenyalar que un estat és compost sense descriure la màquina d’estats que conté es pot fer
servir qualsevol de les representacions de l’estat simple i afegir-hi un petit diagrama d’estats a la part

ADA – UML bàsic pàg. 32


inferior dreta, així:

Estat_compost_1

Però aquesta notació no és obligatòria – sempre es pot representar un estat compost com si fos simple.

Es poden especificar esdeveniments diferits igual que en el cas d’un estat simple.

IV. 2. 7. 2. Tipus de vèrtex addicionals

A més dels vèrtexs que poden figurar en el cas d’estats simples hi pot haver els següents:

Pseudoestat inicial i estat final en estats compostos

Igual que les màquines d’estats en general, la màquina d’estats de cada regió d’un estat compost té un
pseudoestat inicial i un estat final; quan s’entra en un estat compost en conjunt (també es pot entrar
directament en un subestat seu) s’entra alhora en el pseudoestat inicial de cadascuna de les seves regi-
ons, i quan s’arriba als estats finals de totes les regions se surt de l’estat compost en conjunt, i alesho-
res quan a més hagin acabat els eventuals comportaments interns de l’estat compost es produeix un
esdeveniment de finalització que engega l’eventual transició de finalització. Ni poden entrar transicions
en un pseudoestat inicial, ni poden sortir-ne d’un estat final. Normalment tota regió té un pseudoestat
inicial, altrament s’entendria que es pot entrar a l’estat compost sense entrar en aquella regió, per bé
que es podria entrar directament als seus subestats amb transicions originades fora de la regió.

Pseudoestats d’unió i de bifurcació

Un pseudoestat d’unió (join pseudostate) serveix per a indicar que s’han d’haver produït totes les
transicions que hi entren (que tenen el subestat d’origen respectiu en regions diferents) perquè es pro-
dueixi la que en surt. Les transicions que entren en un pseudoestat d’unió no poden tenir guarda ni dis-
parador.

Notació

Es representa per una barra travessera gruixuda:

Un pseudoestat de bifurcació (fork pseudostate) assigna el mateix subestat d’origen a diverses tran-
sicions que tenen el subestat de destinació respectiu en regions diferents; les transicions que surten
d’un pseudoestat de bifurcació no poden tenir guarda ni disparador.

Notació

També es representa per una barra travessera gruixuda:

Pseudoestats de punt d’entrada i de punt de sortida i referències a punts de connexió

Un pseudoestat de punt d’entrada a una màquina d’estats (que només s’executi dins d’un estat de
submàquina) o a un estat compost és origen de transicions que tenen com a destinació respectivament
un estat de la màquina d’estats o un subestat de cada regió de l’estat compost.

Notació

Un pseudoestat de punt d’entrada es representa per una rodona buida. Una referència a un punt de
connexió quan aquest és un punt d’entrada es representa pel mateix símbol damunt la perifèria de
l’estat de submàquina:

ADA – UML bàsic pàg. 33


Quan s’arriba a un pseudoestat de punt de sortida d’una regió d’un estat compost se surt de l’estat
compost mitjançant una transició que té com a origen aquest pseudoestat. Quan s’arriba a un pseudo-
estat de punt de sortida d’una màquina d’estats que s’executa dins d’un estat de submàquina se surt de
l’estat de submàquina per la referència a punt de connexió corresponent a aquest pseudoestat de
punt de sortida.

Notació

Un pseudoestat de punt de sortida es representa per una rodona amb dos diàmetres en X. Una referèn-
cia a un punt de connexió quan aquest és un punt de sortida es representa pel mateix símbol damunt la
perifèria de l’estat de submàquina:

IV. 2. 7. 3. Transicions en el cas d’estats compostos

Transicions que entren en un estat compost o en surten

A un estat compost s’hi pot entrar de totes aquestes maneres:


• Per defecte, quan la transició té l’estat compost com a destinació; es com si s’arribés al pseudoes-
tat inicial de les màquines d’estat de totes les regions.
• Explícitament, quan la transició té com a destinació un subestat.
• Per un punt d’entrada.
I se’n pot sortir de totes aquestes altres:
• Per defecte, quan la transició té l’estat compost com a origen; es com si partís del estat final de les
màquines d’estats de totes les regions.
• Explícitament, quan la transició té com a origen un subestat.
• Per un punt de sortida.
En un estat compost perquè es generi l’esdeveniment de finalització cal que a més d’haver acabat tots
els seus comportaments d’entrada i durant l’estat s’hagi arribat als estats finals de totes les seves regi-
ons.

Un estat compost és encapsulat si


• Només s’hi pot entrar per defecte o per un punt d’entrada
• Només se’n pot sortir per defecte o per un punt de sortida.

Notació de la transició composta

Una transició composta es representa mitjançant un graf format per transicions simples i pseudoestats
d’unió, bifurcació, embrancament i tria.

IV. 2. 7. 4. Exemples amb estats compostos

Estat compost amb una regió

EnVerificacio

/ crear at(dia 30) / pagament


Inici Pagada
OK
PendentVer Revisat

ADA – UML bàsic pàg. 34


Estat compost amb dues regions

EnVerificacio

OK1
/ introduir PendentVer1 Revisada1
at(dia 30) / pagament
Inici Pagada

Reg1
OK2
PendentVer2 Revisada2

El diagrama representa un procés de revisió i pagament d’una factura dins el qual es fan 2 revisions en
paral·lel. A una de les regions se li ha donat un nom, Reg1.

Transicions amb estats de submàquina

Transicions que entren en un estat de submàquina o en surten

A un estat de submàquina s’hi pot entrar d’aquestes maneres:


• Per a, quan la transició té l’estat de submàquina com a destinació; es com si s’arribés al pseudoes-
tat inicial de la màquina d’estat.
• Per un punt d’entrada.
I se’n pot sortir d’aquestes altres:
• Per defecte, quan la transició té l’estat de submàquina com a origen; es com si partís de l’estat fi-
nals de la màquina d’estats.
• Per un punt de sortida.
En un estat de submàquina perquè es generi l’esdeveniment de finalització cal que a més d’haver aca-
bat tots els seus comportaments d’entrada i durant l’estat s’hagi arribat a l’estat final de la màquina
que conté.

IV. 2. 7. 5. Notació de l’estat de submàquina

La notació d’un estat de submàquina és la d’un estat simple llevat que el nom està format pel nom de
l’estat seguit del nom de la màquina d’estats associada a ell, separats per “:”.

Quan hi ha una transició que entra a l’estat de submàquina pel pseudoestat inicial o en surt pel seu es-
tat final la fletxa de la transacció acaba o comença al contorn del símbol de l’estat, però si l’entrada o
sortida es fa per un altre estat de la màquina (el punt d’entrada ent1 i el punt de sortida sort1, respec-
tivament) llavors per a representar la referència al punt de connexió (vegeu l’apartat IV. 2. 7. 2. ) cal
fer servir el símbol de pseudoestat de punt d’entrada o de sortida, respectivament, es representa així:

nom_estat:
nom_submàquina
ent1

sort1

IV. 2. 7. 6. Exemple d’estat de submàquina

Estat de submàquina i esdeveniment diferit

ADA – UML bàsic pàg. 35


Aquest diagrama descriu un procés hipotètic d’obtenció del carnet de conduir. Tot comença quan s’executa l’activitat matrícu-
la, que porta a l’estat per defecte, matriculat, del qual se surt quan arriba la data de la prova i s’entra a l’estat prova psíquica,
en entrar al qual s’executa l’activitat realització prova; se surt d’aquest estat quan es produeix l’esdeveniment de canvi prova
corregida, i aleshores si es compleix la guarda superada és passa a l’estat de submàquina exàmens, dins del qual s’executa la
màquina d’estats Exàmens de conducció, que es descriu a part (més avall) i si la guarda que es compleix és no superada es
produeix una transició cap a l’estat final, durant la qual s’executa l’activitat inhabilitació. De l’estat de submàquina exàmens es
pot sortir de diverses maneres:

• si s’ha arribat a l’estat final de la màquina d’estats continguda dins d’aquest estat es va a parar a l’estat final del pre-
sent diagrama, prèvia execució de l’activitat emissió carnet;

• si se’n surt pel punt de sortida sancionat es va al mateix estat final;

• si se’n surt pel punt de sortida pràctic pendent es torna entrar a l’estat de submàquina un cop es produeix
l’esdeveniment de temps que han passat 4 setmanes d’ençà que se’n va sortir, pel punt d’entrada només pràctic si es
compleix la guarda <3 vegades, i pel seu pseudoestat inicial si es compleix la guarda ha tornat a pagar;

• si se’n surt pel punt de sortida teòric pendent es torna entrar a l’estat de submàquina pel seu pseudoestat inicial un
cop es produeix l’esdeveniment de temps que han passat 2 setmanes d’ençà que se’n va sortir, si es compleix la
guarda <3 vegades o ha tornat a pagar.

L’esdeveniment de temps relatiu after (2 setmanes) s’especifica com a diferit per tal que si quan es produeix aquest esdeve-
niment no es pot produir la transició perquè no es compleix la guarda (és a dir que fa més de 2 vegades i no ha pagat encara)
la transició es produeixi quan es compleixi aquesta guarda (és a dir tan bon punt pagui). Una cosa semblant passa amb
l’esdeveniment after(4 setmanes) quan té pendent l’examen pràctic.

Màquina d’estats amb punts d’entrada i de sortida

Exàmens de conducció és la màquina d’estats a què fa referència l’estat de submàquina exàmens del diagrama anterior; a ella
a més de poder-s’hi entrar pel pseudoestat inicial i sortir-ne per l’estat final s’hi pot entrar pel pseudoestat de punt d’entrada
només pràctic i sortir pels pseudoestats de punt de sortida sancionat, teòric pendent i pràctic pendent. Quan s’hi entra pel
pseudoestat inicial s’executa l’activitat inscripció i s’arriba a l’estat per defecte d’aquesta màquina d’estats, inscrit, i quan arri-

ADA – UML bàsic pàg. 36


ba la data de l’examen es produeix una transició cap a l’estat examen teòric, i en entrar-hi s’engega l’activitat realització; se
surt d’aquest estat o bé quan l’examen està corregit o bé abans, si l’alumne ha estat atrapat copiant (aleshores s’interromp
l’activitat realització, que per aquesta raó s’ha especificat com a activitat durant l’estat i no pas com a activitat d’entrada) i en
aquest cas se surt de la màquina d’estats pel punt de sortida sancionat. Si es produeix l’esdeveniment de senyal examen cor-
regit, aleshores si es compleix la guarda suspès se surt de la màquina d’estats pel punt de sortida teòric pendent, mentre que
si es compleix la guarda aprovat passa a l’estat examen pràctic (al qual també es pot entrar directament des de l’exterior a
través del punt d’entrada només pràctic) i s’engega l’activitat durant l’estat recorregut, l’acabament de la qual genera un es-
deveniment de finalització que provoca la sortida de l’estat cap a l’estat final o bé cap al punt de sortida pràctic pendent, se-
gons quina de les guardes respectives es compleixi.

IV. 3. DIAGRAMA D’ACTIVITATS

El diagrama d’activitats descriu un comportament en forma d’un graf orientat que estableix relacions
entre les activitats que hi figuren; aquestes relacions són relacions de prerequisit, eventualment condi-
cionals, i poden reflectir el pas d’instàncies de classificadors d’una activitat a una altra. Als nodes del
graf se’ls anomena nodes d’activitat i als arcs, arcs d’activitat (activity edges).

IV. 3. 1. Classificació dels arcs i nodes d’activitat


Els arcs d’activitat poden ser
• arc de flux de control, que anomenarem simplement arc de control
• arc de flux d’objectes, que anomenarem simplement arc d’objectes.
Els nodes d’activitat poden ser:
• Nodes de control:
o node inicial,
o node final
▪ node final d’activitat
▪ node final de flux,
o node de fusió,
o node de decisió,
o node de bifurcació,
o node d’unió.
• Nodes executables:
o acció
o nodes d’activitat estructurada
▪ node de seqüència
▪ node condicional
▪ node de bucle
▪ node d’expansió
• Nodes d’objectes
o paràmetre d’activitat
o pin
▪ pin d’entrada
 pin de valor
▪ pin de sortida
o node central de buffer
▪ node d’emmagatzemament de dades
o node d’expansió
A grans trets els papers d’aquests diferents tipus de nodes i arcs d’activitat en la descripció del compor-
tament són els següents:
• els nodes executables representen activitats
• els arcs d’activitat representen les dependències entre activitats, així:
o els arcs de control representen relacions de prerequisit entre activitats, en forma de fluxos de
control;

ADA – UML bàsic pàg. 37


o els arcs d’objectes representen que dades creades o modificades per una activitat es fan servir
en d’altres, és a dir representen els fluxos d’instàncies de classificador entre activitats;
• els nodes d’objectes representen aquestes dades que entren i surten de les activitats, en forma de
còpies d’instàncies d’un classificador;
• els nodes de control són nodes auxiliars que es fan servir quan un arc d’activitat no comença i/o no
acaba en un node executable i només un.

IV. 3. 2. Signe d’objecte i signe de control


Es considera que pels arcs d’activitat circulen signes (tokens); els arcs d’objectes transporten signes
d’objecte i els arcs de control signes de control.

Un signe d’objecte és una còpia d’una instància de classificador i representa dades que un node exe-
cutable envia a un altre o a diversos. Un signe d’objecte sense contingut (sense dades) s’anomena sig-
ne nul. Dos signes d’objecte sempre són diferents, fins i tot si són dues còpies de la mateixa instància.

Un signe de control que arriba a una activitat representa el fet que ha acabat una altra activitat que
n’és prerequisit.

IV. 3. 3. Acció i activitat


Com sabem una activitat és un comportament que opcionalment es pot descompondre en altres activi-
tats i una acció és una activitat que no es pot descompondre. Dins un diagrama d’activitats una acció
pot rebre i enviar signes d’objectes i de control pels arcs corresponents.

Notació de l’acció

Es representa per un rectangle amb els angles arrodonits.

Acció1

Aquesta notació serveix també per a les activitats en general, encara que per a elles hi ha notacions
més específiques (vegeu l’apartat IV. 3. 7. ).

IV. 3. 4. Node d’objectes


S’ha vist la classificació dels nodes d’objectes a l’apartat IV. 3. 1.

Un node d’objectes pot emmagatzemar temporalment un o més signes corresponents a instàncies de


classificador, les quals opcionalment es pot exigir que pertanyin a un classificador especificat, i en
aquest cas es pot exigir a més que estiguin en un estat o estats especificats d’una màquina d’estats
associada al classificador.

Notació del node d’objectes en general

Es representa per un rectangle, per bé que si el tipus és un senyal es fa servir un altre símbol (vegeu
els exemples a continuació); a dins hi ha el nom del tipus de l’objecte precedit de “:” i opcionalment del
nom del node. Per a la notació del node d’expansió vegeu la notació de la regió d’expansió a l’apartat
IV. 3. 7. 3.

Si els objectes del node només poden estar en alguns dels estats possibles dels objectes del tipus en
qüestió, aleshores a dintre del símbol hi ha una llista dels estats acceptats, separats per comes, entre
“[” i “]”.

nom1:Tipus1
[estat1, estat2]

ADA – UML bàsic pàg. 38


IV. 3. 4. 1. Paràmetre d’activitat

Un paràmetre d’activitat és un node d’objectes pel qual un arc d’objectes entra en l’activitat de la
qual el node és paràmetre, o en surt.

L’efecte de l’activitat damunt cadascun dels seus paràmetres pot ser crear-ne signes, modificar-ne, lle-
gir-ne o esborrar-ne.

Es diu que un paràmetre d’entrada o de sortida és stream si l’activitat pot respectivament rebre o envi-
ar signes per mitjà d’ell durant tota la seva execució, (és a dir, pot començar sense haver rebut tots els
signes si és d’entrada o pot anar-hi enviant signes abans d’acabar si és de sortida).

Que un paràmetre de sortida sigui d’excepció vol dir que li arriba un signe quan es produeix una ex-
cepció. Un paràmetre d’excepció no pot ser stream perquè quan li arribi un signe s’acabarà l’execució
de l’activitat (vegeu l’explicació del significat de l’execució d’una activitat a l’apartat IV. 3. 8. ).

Notació

Es representa com a node d’objectes damunt el perímetre de l’activitat a la qual pertany. Si un paràme-
tre accepta stream s’indica amb “stream”, i si és d’excepció es marca amb un petit triangle al damunt.
Un grup de paràmetres s’indica representant els paràmetres com a pins i envoltant els paràmetres del
conjunt amb un rectangle.

IV. 3. 4. 2. Pin

Un pin és un node d’objectes destinat a contenir un signe d’objecte que


• o bé cal que entri en una acció (pin d’entrada)
• o bé ha de ser generat per una acció (pin de sortida).
Per tant un pin és a una acció allò que un paràmetre d’activitat és a una activitat.

En particular hi pot haver pins de sortida d’excepció, anàlegs als paràmetres d’excepció de les activitats
que acabem de veure.

En relació als pins, una acció pot


• rebre signes d’objecte des d’altres accions a través dels seus pins d’entrada (que no siguin pins de
valor) passant pels arcs d’objectes respectius;
• accedir als signes d’objecte dels seus pins de valor;
• enviar signes d’objecte a d’altres accions pels seus arcs de sortida passant pels pins de sortida res-
pectius.
Per tant una acció té tants pins d’entrada (que no siguin pins de valor) com arcs d’objectes d’entrada, tants pins de sortida
com arcs d’objectes de sortida i a més pot tenir pins de valor i arcs de control d’entrada i de sortida amb pins de control asso-
ciats).

Els pins poden tenir multiplicitat:


• El significat de la multiplicitat d’un pin de sortida és que l’execució de l’acció no pot acabar mentre
el pin no contingui tants signes com indica la seva cardinalitat mínima i que durant aquesta execu-
ció no es poden posar al pin més signes dels que indica la cardinalitat màxima.
• Un pin de valor té exactament un valor.
• En el cas d’un pin d’entrada que no sigui pin de valor la cardinalitat mínima és el nombre mínim de
signes que han de ser presents per tal que pugui executar-se l’acció, i la cardinalitat màxima indica
el nombre màxim de signes del pin que poden participar en una execució de l’acció.
Així com una activitat pot tenir paràmetres stream, una acció pot tenir pins stream i en conseqüència
durant una sola execució consumir diversos signes d’objecte del mateix pin d’entrada i/o enviar diver-
sos signes d’objecte al mateix pin de sortida.

ADA – UML bàsic pàg. 39


Notació

Un pin es representa per un petit rectangle annex a l’acció; si el pin es representa sense l’arc d’objectes
corresponent s’hi posa una petita fletxa a dins que indica si és d’entrada o de sortida:

A l’apartat IV. 3. 5. 1. , als exemples d’arcs d’objectes, hi ha més exemples d’accions amb pins.

IV. 3. 4. 3. Altres nodes d’objectes

Un node d’emmagatzemament de dades (data store node) és un node central de memòria intermè-
dia que emmagatzema signes d’objectes fins que acaba l’activitat que el conté.

La resta de nodes d’objectes poden emmagatzemar signes d’objecte només temporalment, a l’espera que comenci o acabi
l’execució d’una activitat o acció, com s’ha vist.

Quan d’un node d’emmagatzemament de dades ha de sortir un signe, el node el conserva i se n’envia
una còpia, i quan arriba al node un signe que és còpia d’una instància que ja hi era, el nou signe substi-
tueix el que hi havia.

Un objecte emmagatzemat en un node d’emmagatzemament de dades pot ser seleccionat i també mo-
dificat per mitjà d’un arc de sortida.

També són nodes d’objectes els nodes d’expansió (vegeu l’apartat IV. 3. 7. 3. ).

Notació

Un node central de memòria intermèdia porta l’estereotip “centralBuffer”; un node


d’emmagatzemament de dades l’estereotip “datastore” i a més d’un nom opcional i el tipus de les se-
ves instàncies pot tenir especificat un estat per les seves instàncies entre “[” i “]”:
«datastore»
nom2 : tipus3
[estat3]

IV. 3. 5. Arc d’activitat


Hem esmentat abans que un diagrama d’activitats és un graf orientat constituït per arcs d’activitat i nodes d’activitat. Vegem
ara amb més detall el concepte d’arc d’activitat.

Un arc d’activitat (activity edge) és una connexió unidireccional entre un node d’activitat d’origen i un
node d’activitat de destinació, al llarg de la qual transiten signes.

Perquè circuli un signe per un arc d’activitat cal que es compleixin les condicions que tinguin eventual-
ment el node d’origen, el node de destinació i l’arc mateix.

Un arc d’activitat pot tenir, opcionalment,


• un nom
• una condició, anomenada guarda; un signe només es transmet per l’arc d’activitat si en compleix
la guarda;
• un pes, que indica el nombre mínim de signes que han de ser presents i a més complir la guarda -
si n’hi ha- perquè se’n faci una transmissió; quan es compleix el pes s’envien d’un sol cop tots els
signes esmentats, encara que siguin més que els que indica el pes.

Notació de l’arc d’activitat

Es representa per una fletxa de línia contínua i punta oberta. El pes s’indica per “{weight=” expr “}”, on
expr és una expressió que dóna un nombre natural, o bé “*”.
arc1 {weight=3}

Un arc d’activitat que va a un altre diagrama o en ve es representa així respectivament:

ADA – UML bàsic pàg. 40


A A

IV. 3. 5. 1. Arc d’objectes i arc de control

Com hem vist, els arcs d’activitat s’especialitzen en arcs d’objectes i arcs de control, que tenen aques-
tes diferències:
• Un arc d’objectes és un arc d’activitat pel qual poden passar signes d’objecte de l’activitat
d’origen cap a l’activitat de destinació.
Un arc d’objectes pot seleccionar i transformar signes d’objecte mitjançant comportaments, però
sense efectes col·laterals, és a dir sense modificar la instància de la qual el signe d’objecte és una
còpia; les propietats create, read, update i delete indiquen l’efecte que fa l’activitat d’origen o de
destinació de l’arc d’objectes – no pas l’arc en si- en relació a aquestes instàncies.
• Un arc de control és un arc d’activitat que indica que un cop acabada l’activitat d’origen pot exe-
cutar-se l’activitat de destinació. Hi poden circular signes de control, sense fer-hi cap mena de se-
lecció o transformació.

Notació de l’arc d’objectes

Té la mateixa notació que l’arc d’activitat en general, però a més


• si té associat un comportament, aleshores si aquest fa una selecció dels signes transmesos, la res-
tricció corresponent s’especifica dins un signe de nota amb l’estereotip “selection”;
• es pot especificar com a propietat entre “{” i “}” l’efecte (“create”, “read”, “update” i “delete”) que
l’activitat d’origen o de destinació pot tenir damunt el signe; aquesta especificació es posa a
l’extrem corresponent de l’arc.
Aquesta propietat sovint ja és òbvia pel sentit de l’arc d’objectes; només cal especificar-la quan aquest arc té com a destinació
un node d’emmagatzemament de dades, ja que aleshores pot ser create, update o delete.

A més cal indicar d’alguna manera els nodes d’objectes corresponents als signes que circulen per l’arc
d’objectes, cosa que es pot fer
• representant explícitament el símbol de node d’objectes, amb un arc d’objectes des de l’acció
d’origen cap al node d’objectes i un altre des d’aquest node cap a l’acció de destinació;
• amb la representació dels pins corresponents (que poden portar el nom i estat de l’objecte corres-
ponent i també si escau “{stream}” o el triangle que denota un pin d’excepció, igual que en el cas
dels paràmetres d’activitat);
• o indicant amb un petit quadrat al costat del flux que els pins no es representen.

Notació de l’arc de control

Es representa amb la fletxa d’arc d’activitat en general.

IV. 3. 6. Nodes de control


Els nodes de control distribueixen els signes d’objecte i de control que hi arriben entre els arcs
d’activitat que en surten.

Les especialitzacions del node de control són aquestes:


• Node inicial, que només té fluxos de sortida, a tots els quals es posa un signe de control quan
s’engega l’activitat que el conté; per a una activitat pot haver-n’hi més d’un. Si per a cap dels arcs
de control que en surten es compleixen les condicions per què hi circuli un signe, aquest és retingut
fins que es pugui acceptar.
• Node final, del qual no surt cap arc d’activitat i pot ser
o Node final de flux, que només fa que destruir els signes que hi arriben per l’arc d’entrada, i és
únic dins l’activitat que el conté directament.
o Node final d’activitat; quan hi arriba un signe per qualsevol dels arcs d’entrada el destrueix,
s’envien signes a tots els arcs de sortida de l’activitat que el conté directament i acaba aquesta.
• Node de decisió, amb un arc d’activitat que hi entra i diversos que en surten; aquests darrers te-
nen associades una guarda cada un (una de les guardes pot ser “else”) tals que sempre se’n com-
pleixi exactament una; quan arriba un signe al node s’avaluen les guardes dels arcs i el signe és

ADA – UML bàsic pàg. 41


tramès a l’arc d’activitat corresponent a la guarda que es compleix. Els arcs d’activitats del node
han de ser o bé tots de control o bé tots d’objectes.
• Node de fusió (merge), al qual entren diversos arcs d’activitat i del qual surt un de sol; és com-
plementari del node de decisió en el sentit que pot ajuntar en una les diverses seqüències d’arcs
d’activitat originades en un node de decisió. Els arcs d’activitat del node han de ser o bé tots de
control o bé tots d’objectes. Un node pot ser de decisió i de fusió alhora, i aleshores hi pot haver
múltiples arcs tant d’entrada com de sortida.
• Node de bifurcació (fork), amb un arc d’activitat d’entrada i diversos de sortida concurrents; ca-
dascun dels arcs de sortida rep una còpia de cada signe que arriba al node.
• Node d’unió (join), amb diversos arcs d’activitat d’entrada i un de sortida, que per tant és com-
plementari del node de bifurcació igual que el de fusió és complementari del d’unió. Es pot especifi-
car una condició perquè s’enviï un signe a l’arc de sortida, que per defecte és que hi hagi un signe
a cada arc d’entrada. Si tots els arcs d’entrada són de control, el de sortida també ho és (i alesho-
res tots els signes que entren es combinen en un de sol), altrament l’arc d’activitat de sortida és
d’objectes.
Notacions dels nodes de control

Cada especialització té la seva notació (que sovint coincideix amb la d’algun pseudoestat del diagrama
d’estats que hi fa una funció anàloga):
• Un node inicial es representa per una rodona plena.
• Un node final d’activitat es representa per un “ull de bou”.
• Un node final de flux es representa per una circumferència amb una X inscrita.
• Un node de decisió i/o de fusió es representa per un rombe. Un comportament de decisió d’entrada
al node es pot representar per un rombe unit a una nota amb l’estereotip “decisionInput” que des-
criu la condició. Un node de fusió seguit d’un de decisió es poden representar per un sol rombe.
• node de bifurcació i/o d’unió es representa per una línia curta i gruixuda perpendicular als fluxos;
quan és de fusió pot portar una expressió lògica entre “{joinSpec=“ i “}”, que per defecte és un
“and” de tots els arcs d’activitat que hi arriben.

Node inicial Node final d’activitat Node final de flux Node de decisió i fusió Node d’unió i bifurcació

IV. 3. 7. Nodes executables altres que l’acció

IV. 3. 7. 1. Notació ampliada de l’activitat

El símbol gràfic de l’activitat és el mateix de l’acció llevat que damunt el seu contorn se’n poden repre-
sentar els seus paràmetres i a l’interior pot tenir una especificació dels paràmetres i un diagrama de les
activitats que la componen.

IV. 3. 7. 2. Node d’activitat estructurada

És un node executable que comprèn un grup d’activitats que compleix aquestes condicions
• s’executa com una unitat, cosa que vol dir que
o no se’n pot executar cap activitat mentre no hagin arribat tots els signes de control i d’objectes
corresponents als seus fluxos d’entrada, i que
o no s’envia cap signe de sortida del node estructurat mentre no hagin acabat totes les seves acti-
vitats, i a més
• els seus nodes i arcs d’activitat no poden ser compartits amb cap altre node estructurat.

Node de seqüència

ADA – UML bàsic pàg. 42


Un node de seqüència és un node d’activitat estructurada constituït per una seqüència d’accions.

Node condicional

Un node condicional és un node d’activitat estructurada que representa una elecció entre alternatives
que s’exclouen mútuament.

Aquestes alternatives estan descrites per clàusules (clauses), cadascuna de les quals consta de
• una secció de prova (test section), que conté una condició, i
• una secció de cos (body section), que especifica allò que s’ha d’executar quan es compleixi aquesta
condició.
En cada execució del node condicional només es pot executar la secció de cos d’una sola clàusula; si es
poden complir les condicions de més d’una secció de prova alhora, cal especificar-ne l’ordre d’execució.
Es pot garantir que doni “true" una secció de prova com a mínim o com a màxim.

Node de bucle

Un node de bucle (loop node) és un node d’activitat estructurada que s’executa repetidament mentre es
compleix una condició.

Té tres seccions:
• secció de preparació (setup), que s’executa un sol cop abans d’entrar en el bucle,
• secció de prova (test), que comprova repetidament si es compleix la condició,
• secció de cos (body), que s’executa fins que la condició deixa de complir-se.
La secció de preparació s’executa sempre primer; la de prova es pot executar (totes les vegades que
s’executi el bucle) abans o després de la de cos.

L’execució del node de bucle comença un cop hi han arribat tots els signes d’objectes i de control cor-
responents als fluxos d’entrada. Aleshores tots aquells nodes de la secció de preparació que no tenen
cap predecessor reben els signes corresponents a tots els arcs d’entrada respectius i comença l’execució
de la secció de preparació; aquesta execució acaba quan ha acabat l’execució d’aquells nodes de la sec-
ció que no tenen cap successor dins ella; es pot considerar que aleshores el node de bucle envia un
signe de control a la secció següent (la de prova o la de cos, segons s’ha dit).

L’execució de la secció de prova i de la secció de cos procedeix de la mateixa manera, llevat que la sec-
ció de prova normalment només tindrà un node que no tingui cap successor i aquest node tindrà un
valor booleà en un dels seus pins de sortida (normalment l’únic); si aquest valor és ”true” s’executarà
un cop més la secció de cos.

Notació del node d’activitat estructurada

Es representa per un rectangle de línia discontínua, amb els angles arrodonits i l’estereotip “structured”,
que envolta les seves accions i els arcs d’activitat entre elles:
«structured»

Aquesta notació val per al node condicional, per al de bucle i per al de seqüència.

IV. 3. 7. 3. Regió d’expansió

Una regió d’expansió és una activitat estructurada que conté una grup d’activitats i té com a punts
d’entrada i de sortida uns nodes d’objectes especials, anomenats nodes d’expansió, que tenen aques-
tes característiques:
• Són col·leccions de signes d’objecte que són còpies d’instàncies del mateix classificador, que és el
tipus del node d’expansió; els diferents nodes d’expansió d’una regió d’expansió no són pas neces-
sàriament del mateix tipus.
• Cada node d’expansió de sortida correspon a un node d’expansió d’entrada, en el sentit que és una
col·lecció del mateix tipus, però hi pot haver nodes d’expansió d’entrada als quals no correspongui

ADA – UML bàsic pàg. 43


cap node d’expansió de sortida.
El tipus d’expansió (expansion kind) és un tipus d’enumeració que denota com tenen lloc les execuci-
ons de la regió d’expansió corresponents als successius elements dels nodes d’expansió; aquestes opci-
ons són:
• en paral·lel, és a dir independentment,
• iterativament, que vol dir que les execucions corresponents als diferents signes d’objecte tenen lloc
en el mateix ordre en què figuren aquests dins la col·lecció,
• en stream, que consisteix en què els diferents elements de la col·lecció entren en una sola execució
i en l’ordre que tenen en la col·lecció.
Llevat del cas de l’opció stream, per a cada un dels signes d’objecte dels nodes d’expansió d’entrada
(del que en té menys, si no tots els nodes d’expansió tenen el mateix nombre d’elements) la regió
d’expansió s’executa una vegada i en principi genera un element de cada node d’expansió de sortida.

Notació de la regió d’expansió

Una regió d’expansió es representa per un rectangle com el del node d’activitat estructurada que té
• damunt el perímetre, els nodes d’expansió representats en forma de rectangles dividits vertical-
ment;
• i a dins, cap a l’angle superior esquerre, un estereotip que indica el tipus d’expansió: parallel, itera-
tive o stream.
Per exemple,

«iterative»

a1:acció1

a2:acció2

En el cas que la regió d’expansió consti d’una sola acció, com a notació simplificada es pot fer servir el
símbol de l’acció en comptes del d’activitat estructurada, amb els pins representats com abans:

«iterative»

:acció1

IV. 3. 8. Execució d’una acció i d’una activitat estructurada


Execució d’una acció

Tota acció s’executa dins del marc d’una activitat, que serveix perquè aquestes accions es passin dades.

Perquè s’executi una acció cal que


• li hagi arribat un signe de control per cada arc de control que hi acaba (és a dir, hagin acabat aque-
lles accions que en són prerequisit),

ADA – UML bàsic pàg. 44


• li hagi arribat a cada pin d’entrada un nombre de signes d’objecte no inferior a la seva cardinalitat
mínima i els signes que excedeixin la cardinalitat màxima no es processen; als pins d’entrada stre-
am no cal que els hagi arribat cap signe, però si tots els pins d’entrada fossin stream caldria que
almenys un hagués rebut un signe;
• es compleixin les precondicions locals.
I quan acaba l’execució d’una acció
• posa signes d’objectes a cadascun dels seus pins de sortida (igual que una operació posa valors als
seus paràmetres de sortida i al seu resultat),
• posa un signe de control a cada arc de control que en surt, per tal que es puguin executar aquelles
accions que la tenen com a prerequisit,
• es compleixen les postcondicions locals.
Quan comença l’execució d’una acció els signes d’entrada s’esborren de l’origen del flux respectiu. Quan
l’execució de l’acció acaba normalment (és a dir, sense que es produeixi cap excepció) es posen signes
d’objecte als seus pins de sortida i signes de control als seus arcs de control de sortida.

Els pins de sortida poden emmagatzemar signes d’objecte temporalment fins que són acceptats per les
accions successores, però no pas els arcs d’activitat ni els nodes de control. A més es considera que una
acció només pot acceptar signes en un pin d’entrada si en pot acceptar a tots els altres, per tal d’evitar
situacions de deadlock. Si d’un pin de sortida surten diversos arcs d’objectes, cada signe d’objecte no-
més va per un d’ells (en canvi d’un node d’emmagatzemament en poden sortir múltiples còpies d’un
signe, com hem vist).

Si durant l’execució d’una acció es produeix una excepció,


• s’abandona l’execució,
• no s’envien més signes als arcs de sortida, ni d’objectes ni de control,
• els signes que puguin haver arribat als pins de sortida no stream no s’envien i aquells que hagin ar-
ribat a pins de sortida stream abans que es produís l’excepció sí que es transmeten,
• si hi ha pins de sortida d’excepció l’acció passa un objecte d’excepció en forma de signe per mitjà
d’un d’aquests pins a un gestor d’excepcions que tracti aquesta excepció, si és que aquesta té ges-
tor; si no en té, el signe es passa al gestor d’excepcions corresponent de l’activitat que la conté di-
rectament, i si aquesta tampoc el té s’acaba l’execució d’aquesta activitat i se’l passa a l’activitat de
nivell superior, si n’hi ha.
Execució d’una activitat estructurada

Quan s’engega una activitat es posa un signe de control a cada node inicial i en general a cada acció o
activitat estructurada de l’activitat que no tingui cap flux d’entrada ni sigui gestor d’excepcions.

El tractament de les excepcions és anàleg al del cas d’una acció.

IV. 3. 9. Partició d’activitats


Molt sovint convé descompondre un diagrama d’activitats en diversos grups d’activitats segons algun
criteri. Una partició d’activitats (que també anomenarem simplement partició) és un grup d’activitats
que tenen en comú almenys una d’aquestes coses:
• ser responsabilitat d’instàncies del mateix classificador;
• ser responsabilitat d’una instància de classificador;
• correspondre a un cert valor d’un atribut.
Aquí “responsabilitat” vol dir que la instància en qüestió sigui l’objecte de context de l’activitat. En tots
aquests casos hi pot haver diverses particions segons el mateix criteri (és a dir, que corresponguin res-
pectivament a diferents classificadors, a diferents instàncies del mateix classificador i a diferents valors
de l’atribut).

El grup d’activitats d’una partició pot estar subdividit en grups que pertanyen també a d’altres partici-
ons, que poden estar contingudes dins la primera o no. Una partició no continguda en cap altra és una
dimensió.

ADA – UML bàsic pàg. 45


IV. 3. 9. 1. Notació de la partició d’activitats

Una partició d’activitats es representa per una franja horitzontal o vertical (carril, swimlane) del dia-
grama d’activitats delimitada per dues rectes paral·leles; el nom de la partició figura centrat dins un
compartiment en un extrem de la franja. Les diferents particions segons un mateix criteri (per exemple,
corresponents a diferents instàncies d’un classificador) es representen per un conjunt de franges verti-
cals o horitzontals consecutives. Una subpartició d’una partició representada per franges verticals, per
exemple, es representa per subfranges també verticals d’ella; en canvi dues particions independents
s’han de representar una per una franja vertical i l’altra per una d’horitzontal. Un node d’activitat pot
estar alhora en una franja vertical i una d’horitzontal però no pot estar damunt una línia de separació
entre franges, però els nodes d’objecte no pertanyen a cap franja i els arcs d’activitat poden creuar líni-
es de separació entre franges.

Dins una partició hi pot haver subparticions amb les línies i noms corresponents. Aquest és un exemple
de partició amb dues particions de segon nivell:
Partició12
Partició1

Partició11

Acció1

Una partició que correspon a un atribut (vegeu l’apartat III. 1. 1. 1. ) - que normalment serà una di-
mensió- té com a nom l’estereotip “attribute” seguit del nom i tipus de l’atribut. L’estereotip “external”
com a nom de partició denota que els nodes que conté són externs a l’objecte de context del diagrama.
«attribute» atr1: ValAtr1
valor1 valor2

ValAtr1 és una enumeració que té els valors valor1 i valor2.

A l’exemple següent hi ha un diagrama d’activitats particionat segons dues dimensions ortogonals:


DimensióB

ParticióB1 ParticióB2
ParticióA2

Acció2
DimensióA

Partició1

ADA – UML bàsic pàg. 46


IV. 3. 10. Exemple de diagrama d’activitats
Unitat organitzativa
Dept. peticionari Control de gestió Departament de compres Servei tècnic

{create} c1:Compra
FerPeticio
[petició]

«datastore»
c1:Compra
[petició]
RevisarPressupost

c1:Compra [no hi ha saldo] [hi ha saldo] c1:Compra


[rebutjada] {update} {update}
[autoritzada]

c1:Compra {update} «structured»


Cancellar [feta] GestioCompra

DadesOrdinadors

«iterative»
Recepcio

Verificar

GenerarOrdreInstallacio OrdresInstallacio

Installar

Es tracta de la gestió de la compra d’ordinadors en una empresa, dins la qual intervenen les 4 unitats organitzatives (Depar-
tament peticionari, etc.) representades per sengles particions de la dimensió Unitat Organitzativa. UnitatOrganitzativa és un
classificador i cada partició de la dimensió correspon a una instància seva. El comportament representat al diagrama s’engega
quan el departament peticionari fa l’acció FerPeticio, que crea un objecte c1 de la classe Compra (que especifica una compra
de diversos ordinadors) en l’estat peticio, del qual mitjançant el node de bifurcació se’n fan dues còpies, una que s’arxiva en
un node d’emmagatzemament de dades del qual només surt per a ser esborrada, i una altra que entra a l’acció RevisarPres-
supost. Com a resultat d’aquesta acció, si no hi ha saldo pressupostari per a la compra (guarda “no hi ha saldo”) l’objecte de

ADA – UML bàsic pàg. 47


Compra és actualitzat (propietat “update” del flux i canvi de l’estat de l’objecte) i retornat al departament peticionari, el qual
duu a terme l’acció Cancellar, amb la qual s’acaba el comportament representat pel diagrama. En canvi si la guarda que es
compleix és “hi ha saldo”, l’objecte de la classe Compra passa a l’estat “autoritzada” i entra dins el node d’activitat estructura-
da GestioCompra (el procés de la qual s’haurà de descriure en un diagrama d’activitats a part). GestioCompra passa els objec-
tes de la classe Compra a l’estat feta i també crea objectes amb les dades dels diferents ordinadors comprats en aquella com-
pra i els passa a la regió d’expansió Recepcio que per a cada un d’aquests objectes fa les activitats Verificar i GenerarOrdre-
Installacio. Les ordres d’instal·lació generades s’envien en bloc al servei tècnic, que fa l’activitat Installar amb la qual s’acaba
l’activitat del conjunt del diagrama per aquest camí.

IV. 4. DIAGRAMES D’INTERACCIÓ

Els diagrames d’interacció descriuen un comportament emergent en termes dels senyals i crides
d’operacions que circulen entre diferents instàncies de classificador.

Aquesta representació es pot fer amb quatre tipus de diagrames que fan servir essencialment els ma-
teixos conceptes:
▪ diagrama de seqüències, que serà l’únic que veurem
▪ diagrama de comunicacions,
▪ diagrama de visió general de la interacció,
▪ diagrama temporal.

IV. 4. 1. Interacció
Una interacció és un comportament emergent descrit en termes de missatges (vegeu l’apartat IV. 4.
2. 3. ) entre instàncies.

Entre interaccions hi pot haver herència i redefinició, en particular en el cas que hi hagi herència entre
els classificadors dels objectes de context respectius.

Un ús d’interacció és una referència a una interacció dins una altra, assignant arguments als seus
paràmetres i connectant-ne els portals (vegeu l’apartat IV. 4. 2. 3. ).

IV. 4. 2. El diagrama de seqüències


El diagrama de seqüències és un diagrama d’interacció que posa èmfasi per una banda en els missatges
i per una altra en la seqüència temporal dels esdeveniments associats a llur emissió i recepció; per
aquesta raó una de les dimensions – normalment la vertical, cap avall– representa el transcurs del
temps.

IV. 4. 2. 1. Línia de vida

Una línia de vida (lifeline) representa una instància o més d’un classificador, o bé un classificador (per
exemple quan es crida una operació de classe). De les instàncies en representa tota l’existència, des de
la seva creació fins a la seva destrucció, tot i que en general només una part d’aquest temps estan par-
ticipant en la interacció que conté la línia de vida.

Notació

Una línia de vida es representa per una línia vertical discontínua que comença just a sota del símbol
(per exemple, el rectangle propi dels classificadors en general) que descriu el classificador o la instància
de classificador corresponent. Dins aquest símbol hi ha
• o bé el nom de la línia de vida seguit del nom del classificador precedit de “:”, així1:
nom_lína_vida “:” nom_classificador
(cadascuna d’aquestes clàusules és opcional);

1
Tot aquest text no va mai subratllat, ni tan sols en el cas que correspongui a una sola instància.

ADA – UML bàsic pàg. 48


• o bé “self”, que vol dir que la instància ho és del classificador de context del comportament repre-
sentat pel diagrama.
L’ordre d’esquerra a dreta de les diferents línies de vida d’un diagrama de seqüències no té cap signifi-
cat.

Quan la instància corresponent a la línia de vida és creada dins la interacció la fletxa del missatge que
produeix aquesta creació acaba en el símbol del començament de la línia de vida; quan la instància és
destruïda durant la interacció aquesta destrucció es marca amb dues línies curtes que es creuen en X
damunt la línia de vida.

IV. 4. 2. 2. Fragment d’interacció

Un fragment d’interacció es una interacció que és part d’una altra (com a mínim de la que representa
el diagrama en conjunt).

Un fragment (d’interacció) combinat es un fragment d’interacció que es defineix mitjançant una ex-
pressió que combina d’altres fragments d’interacció; està constituït per un operador d’interacció i diver-
sos operands d’interacció, que representen els fragments d’interacció que es combinen.

Un operand d’interacció és un fragment d’interacció que pot tenir associada una restricció anomena-
da restricció d’interacció.

Un operador d’interacció pot tenir un d’aquests valors:


• “alt”, que representa una elecció entre els operands, dels quals només se’n pot executar un com a
màxim. Quan l’operador d’interacció té aquest valor cada operand pot tenir una restricció
d’interacció (que pot ser “else”), i si no en té es com si en tingués una que es compleixi sempre.
• “break”, que té una guarda i un operand i significa que quan es compleix la guarda s’executa
aquest operand en comptes de tota la resta del fragment d’interacció que el conté.
• “loop”, en el qual el fragment combinat conté un sol operand amb una restricció d’interacció consti-
tuïda o bé per dues expressions que indiquen el nombre mínim i màxim, respectivament, de vega-
des que es pot executar l’operand o bé per una condició que s’ha de complir perquè l’operand
d’interacció s’executi una vegada més.
• “opt”, amb un sol operand que s’executa o no d’acord amb una restricció; és equivalent al cas “alt”
amb dos operands, un dels quals és nul i té la restricció “else”.
• “par”, que vol dir que els diferents operands s’executen en paral·lel.
• “ref”, que representa un ús d’interacció, el nom de la qual és l’únic operand.
Notació del fragment d’interacció

Un fragment d’interacció es representa per un marc com el dels diagrames d’UML (apartat II. 8. ) que
té a la capçalera el nom del fragment precedit d’un mot clau que indica el tipus de fragment; aquest
mot clau pot ser un dels següents:
• “sd”, per a una interacció sencera; els atributs locals es poden definir, amb la mateixa sintaxi
que els de les classes, o bé a la part de dalt de l’interior del rectangle.

sd interacció1 atributLocal1: Tipus1

ADA – UML bàsic pàg. 49


• El mot clau de l’operador d’interacció (sense cap nom al costat), en el cas d’un fragment combi-
nat; aleshores els operands es representen en franges horitzontals separades per línies discontí-
nues si n’hi ha més d’una, i l’eventual restricció d’interacció d’un operand va entre “[” i “]”:

alt

[restricció1]

[else]

• En el cas d’un ús d’interacció (operador ref) dins el rectangle hi ha el nom de la interacció a què
es fa referència, i si aquesta té paràmetres i valor de retorn aquest nom pot tenir el mateix for-
mat que el nom d’un missatge de resposta (vegeu l’apartat següent).

ref

nom_interacció

IV. 4. 2. 3. Missatge

Un missatge és una comunicació entre instàncies de classificador2 per la qual una (l’emissor) envia un
senyal a l’altra (el destinatari) o li demana l’execució d’una operació o en retorna el valor de retorn i els
valors dels paràmetres out i inout d’una operació demanada en un missatge previ.

Un missatge que crida una operació és síncron si, quan s’emet, l’execució de l’operació que l’ha emès
roman aturada fins que rep un missatge de resposta del receptor; en canvi quan s’emet un missatge
asíncron l’operació que l’ha emès continua executant-se. Un missatge asíncron consisteix en la trame-
sa d’un senyal o la crida d’una operació, un de síncron només pot consistir en una crida d’una operació.

Dins una interacció l’emissor i el destinatari d’un missatge estan representats per sengles línies de vida.

Notació del missatge

Un missatge es representa per una fletxa de l’emissor al receptor; diferents tipus de missatge es repre-
senten per diferents tipus de fletxa:
• Un missatge asíncron s’indica per una fletxa de línia contínua i punta oberta.
• Un missatge síncron es representa per una fletxa de línia contínua i punta plena.
• Un missatge de resposta d’un missatge síncron s’indica per una fletxa de línia discontínua i punta
oberta.
• Un missatge que provoca la creació d’un objecte s’indica per una fletxa de línia discontínua i punta
oberta; a més l’extrem del missatge coincideix amb el començament de la línia de vida del recep-
tor.
L’origen i l’extrem d’un missatge poden ser punts d’alguna línia de vida o bé un portal (gate), que re-
presenta que el missatge o bé surt de la interacció o fragment d’interacció i provoca un esdeveniment a
fora o bé procedeix de fora; en el cas d’un portal la fletxa del missatge comença o acaba en un punt –
que pot tenir nom- del contorn del rectangle que representa el fragment d’interacció (vegeu l’apartat
IV. 4. 2. 2. ).

2
De fet l’origen i/o la destinació d’un missatge també pot ser un classificador, per exemple quan demana una operació de classe
o en retorna un resultat.

ADA – UML bàsic pàg. 50


Notació del nom del missatge

Els missatges tenen un nom, l’estructura del qual també depèn del tipus de missatge; així,
• El nom d’un missatge que crida una operació o envia un senyal té aquesta estructura:
nom_operació_o_senyal “(”argument1“,” ... “)”
en què cada argument correspon, per ordre, a un paràmetre de l’operació o senyal i consta d’un
valor precedit opcionalment del nom del paràmetre corresponent de l’operació i “=”; un argument
de valor indefinit s’indica per “-“.
• El nom d’un missatge de resposta a un missatge síncron té una d’aquestes estructures:
atribut “=” nom_operació “(” argument1”,” ... “)” “:” valor_de_retorn
nom_operació “(” atribut “=” valor“,”...“)”
Els atributs esmentats són o bé atributs de l’objecte corresponent a la línia de vida de l’origen del
missatge síncron, o bé paràmetres de la interacció, o bé atributs del classificador o objecte de con-
text de la interacció. En la primera estructura s’ha especificat l’obtenció del valor de retorn i en la
segona el d’un paràmetre out o inout de l’operació corresponent. argument1 és el valor donat a un
paràmetre in o inout en fer la crida, precedit opcionalment del nom del paràmetre i “=”.
Com a conseqüència del significat temporal de la dimensió vertical, si la fletxa d’un missatge és horit-
zontal s’entén que la transmissió del missatge o bé és pràcticament instantània o bé la seva durada no
importa; una fletxa descendent indica en canvi que la durada de la transmissió del missatge té un valor
no negligible. La durada de la transmissió d’un missatge i el temps que es triga a emetre o rebre un
missatge de resposta poden estar subjectes a restriccions temporals.

Exemple de diagrama de seqüències

L’objecte de context (self, de la classe Context, que podem suposar que té l’atribut x de tipus int) engega la interacció In-
teraccio1 quan rep el missatge miss1 de l’exterior i a continuació s’engeguen 2 processos en paral·lel, procés 1 i procés 2.
Dins procés 1 self crea l’objecte o1 de la classe Cl1 per mitjà de l’emissió d’un missatge de creació; aquesta creació engega un
fragment combinat amb l’operador alt, en el qual

- si x és positiu o1 envia un missatge de creació que crea l’objecte o2 de la classe Cl2 i després o2 demana per mitjà
de missatges síncrons entre 1 i 3 vegades l’operació op4() successivament a entre 1 i 3 objectes ja existents de la lí-
nia de vida o4s; aquest missatge de crida duu l’argument x assignat al paràmetre par41, que suposem que és inout.

ADA – UML bàsic pàg. 51


Cada vegada que s’executa op4() s’envia un missatge de retorn que posa el nou valor de par41 a w (que podem su-
posar que és un atribut de Cl2) i després o2 destrueix un dels objectes d’o4 i al final l’objecte o2 s’autodestrueix.
- Si x no és positiu s’executa la interacció Interacció2, descrita amb el diagrama de seqüències de la dreta. Dins In-
teraccio2 l’objecte o1 envia a l’objecte o3 de la classe Cl3 un missatge en el qual li demana l’execució de l’operació
op3(), la qual té un valor de retorn que s’assigna a u, que seria un atribut d’o1.

Dins procés 2 l’objecte de self envia un missatge asíncron pel qual es demana a l’objecte o5 ja existent de la classe Cl5
l’execució de l’operació op51(). Hi ha una restricció de temps per la qual entre l’emissió i l’arribada d’aquest missatge no han
de transcórrer més de dues unitats de temps.

ADA – UML bàsic pàg. 52

You might also like