1 desembre

INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML

de 2020

EL SOFTWARE

Un sistema de software, també anomenat aplicació, programari o simplement software,és un

conjunt integrat de programes, bases de dades, documentació...que permeten un sistema
informàtic realitzar les tasques per les quals ha estat dissenyat.

Què es desitja d'un software?

1. Fàcil manteniment, ben dissenyat i ben documentat.
2. Fiable i robust
3. Eficient >>>no ha de malgastar recursos del sistema.
4. Bona interfície>>Cal tenir presents els usuaris que l'utilitzaran

L'ENGINYERIA DEL SOFTWARE

L’Enginyeria del Software és una disciplina que integra processos, mètodes i eines amb
l’objectiu de desenvolupar i mantenir sistemes de software que siguin econòmics,
fiables i eficients.
· Els processos defineixen un marc de treball que permeten un desenvolupament racional de
la enginyeria del software. Formen la base del control de gestió dels projectes de software i
estableixen el context en el qual s’apliquen els mètodes i es produeixen els resultats del treball:
models, documents, dades, informes, formularis,etc.
· Els mètodes indiquem com construir el software. Ofereixen tècniques de modelatge
per a les diferents etapes del procés: definició de requeriments, anàlisi, disseny,
implementació, proves, explotació i manteniment.
· Les eines proporcionen suport automàtic o semiautomàtic per al procés i els
mètodes. Les eines CASE (Computer assisted system enginery) ajuden a
l’automatització de tot el procés de construcció del software, ajudant a l’obtenció de
resultats d’alta qualitat.

L’enginyeria del software és una activitat de modelat per a la solució dels problemes
plantejats pel client del sistema.

Primera etapa, d’investigació:

els conceptes del mon real es representen per mitjà d’un conjunt de models -
construïts fent servir el llenguatge del client - que conformen l’anomenat domini
del problema.
Segona etapa, de creació:
es fan servir els models del domini del problema per a construir els models (de disseny i
d’implementació) que resolen els problemes plantejats pel client i que conformen l’anomenat
domini de la solució

El resultat final del procés de desenvolupament d’un sistema de software ha de ser un

producte que ha d’ajustar-se als requeriments i s’ha d’haver obtingut en els terminis i
amb els costos previstos.

Versió 3.0 1
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

MODELS DEL PROCÉS DE DESENVOLUPAMENT DELSOFTWARE

S'han plantejat diversos models pel desenvolupament (cicle de vida) del software, que
comentarem breument tot seguit.

Model seqüencial

També conegut com a cicle de vida clàssic o model del salt d'aigua, és el primer model
que es va establir. Tot i que és molt simple (i no reflexa adientment la realitat), estableix
clarament quines són les fases que apareixen en la producció del software.
Esquemàticament, el model seqüencial consta de les següents fases:

Els problemes d'aquest enfocament del cicle de vida clàssic són els següents:
1. És massa seqüencial i no respon a la vida real: la construcció del software acostuma
a ser un procés iteratiu, amb refinaments progressius.
2. Acostuma a ser molt difícil poder establir tots els requeriments en la fase d'anàlisi
inicial.
3. Es triga molt a tenir una versió operativa que pugui ser validada pel client.

Hi ha altres metodologies com la programació experimental i el model d'espiral.

Versió 3.0 2
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

L’ORIENTACIÓ A OBJECTES

Un dels grans reptes de l’enginyeria del software es aconseguir desenvolupar fragmentsdel

software (components) que assegurin la qualitat (estiguin ben provats) i que siguinreutilitzables.
Una de les formes d’aconseguir una certa reutilització del software és fer servir elparadigma
orientat a objectes. En un sistema orientat a objectes el mon real esrepresenta en termes
d’objectes que interactuen enviant-se missatges.

El paradigma orientat a objectes es fonamenta en cinc conceptes bàsics:

objecte, classe,encapsulació, herència i polimorfisme.

· Forma natural d'estructurar el domini d'un problema:

- Objectes
- Mètodes
- Missatges

· Els objectes estan definits per:

- Variables que emmagatzemen les dades
- Mètodes que manipulen les dades
· Enviament de missatges:
- Els objectes s'envien missatges entre ells

· Característiques dels objectes:

- Identitat
- Classificació
- Herència
- Polimorfisme
- Encapsulació

· Identitat:
- Les dades estan associades amb entitats diferenciables
- Poden existir dos objectes amb dades idèntiques
- S'accedeix als objectes per mitjà del seu identificador
· Classificació:
- Agrupació d'objectes similars: classe
* mateixos atributs
* mateixes operacions
· Herència:
- Atributs i operacions comunes a diferents classes
- Les subclasses hereten tots els atributs i mètodes de les superclasses
- Les subclasses defineixen els seus propis atributs i mètodes
· Avantatges de l'herència:
- Evita redundàncies: el codi idèntic només s'ha d'escriure una vegada
- Reducció de la grandària del codi
- Reutilització del codi
· Polimorfisme:
- Sobrecàrrega d'operacions = mateix nom de funció, diferents implementacions

· Encapsulació: empaquetat de mètodes i atributs dins d'un objecte mitjançant una

interfície de missatges:
- Ocultació de detalls no necessaris o no importants
- Accés utilitzant només operacions predefinides

Versió 3.0 3
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

EL LLENGUATGE DE MODELAT UNIFICAT

UML permet descriure un model d’anàlisi i disseny d’un sistema mitjançant diagramesconstruïts
utilitzant símbols que tenen regles semàntiques, sintàctiques i pràctiques.
· Les regles semàntiques ens diuen que significa cada símbol i com interpretar-lo,
tant quan es troba aïllat com quan es combina amb altres símbols en undiagrama.
· La sintaxis ens diu com mostrar i combinar els símbols per a obtenir elsdiagrames del model.
· Les regles pràctiques defineixen com utilitzar els símbols per a obtenir elsdiagrames del
model de manera que siguin comprensible per altres persones.

DIAGRAMES QUE FA SERVIR UML

Diagrames de Casos d’Us

Diagrames de Classe
Diagrames d’Objectes
Diagrames d’Estats
Diagrames d’Activitat
Diagrames de Seqüència
Diagrames de Col·laboració
Diagrames de Components
Diagrames de Desplegament

VISTES

Un sistema es pot representar per cinc vistes diferents, representades mitjançant un

conjunt de diagrames, que el descriuen des de diferents perspectives:

· Vista de l’usuari:
representació del sistema des del punt de vista dels actors. Es modela fent servir els diagrames
de casos d’us.
· Vista estructural:
les dades i funcionalitats es mostren des de dins del sistema. Modela l’estructura estàtica:
diagrames de classes, objectes i associacions.
· Vista del comportament:
representa els aspectes dinàmics del sistema. Mostra les interaccions entre els diferents
elements estructurals del sistema: diagrames d’activitat, seqüència, col·laboració i estats.
· Vista d’implementació:
representa els elements estructurals i els aspectes de comportament tal com seran
implementats: diagrames de components.

· Vista de l’entorn:
elements estructurals i aspectes de comportament relatius al’entorn de l'organització en el qual
residirà el sistema a construir: diagrames dedesplegament.

DEFINICIÓ DE REQUERIMENTS
Abans que el software es pugui construir s’han d’entendre els elements de l’entorn
organitzacional en el qual residirà el sistema informàtic: les persones, els procediments
operacionals, el hardware i el propi software (domini del problema).
Els Requeriments del software recullen, a grans trets, els objectius d’un sistema
informàtic i les seves funcionalitats desitjades. El document de Requeriments serveix de
base per a la posterior construcció del software.
Un document de requeriments del software, redactat utilitzant el paradigma d’orientació
Versió 3.0 4
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

a objectes, ha d’identificar: guions, actors, activitats, casos d’us i proporcionar un model

de classes preliminar (objectes, classes, interaccions entre classes, ...) . També ha de
descriure les interfícies d’usuari que haurà de tenir el sistema amb l’ajuda, si cal, de
diagrames d’estat. La definició de requeriments orientada a objectes (ROO) es centra
en la de vista d’usuari.

ANÀLISI
L’objectiu de l’anàlisi és obtenir una comprensió precisa de les necessitats del sistema.
L’anàlisi s’ocupa de traduir els requeriments a un llenguatge més formal. El procés
d’anàlisi no comença preocupant-se pels objectes, sinó intentant comprendre com es
farà servir el sistema per persones, per màquines o per altres sistemes. Després es
procura definir, identificar i descriure els objectes dins del domini del problema.
El propòsit de l’anàlisi orientat a objectes (AOO) és definir totes les classes que són
rellevants pel problema a resoldre, els atributs i operacions associats a les classes, les
associacions i comportaments lligats a les classes. Les característiques estàtiques i
dinàmiques de les classes es modelen amb UML. S’obté un model que refina el casos
d’us (elimina redundàncies i afegeix casos d’us no demanats pels usuaris però
necessaris) i defineix els atributs de cada classe, les associacions i comportaments i les
comunicacions entre classes, així com el comportament de les classes en el temps. Es
generen diagrames de classe (d’anàlisi), i diagrames de seqüència i de col·laboració
d’alt nivell. L’AOO es centra en les vistes d’usuari i estructural.
Els models creats durant les fases de definició de requeriments i anàlisi formen part del
domini del problema.

DISSENY

El disseny orientat a objectes (DOO) transforma el model d’anàlisis obtingut fent servir
AOO en un model de disseny que serveix d’avantprojecte per a la construcció del
software. Durant el disseny es procuren definir els objectes lògics del software que
finalment seran implementats en un llenguatge de programació orientat a objectes.
Es dissenyen els objectes a partir de diagrames de seqüència i de col·laboració de baix
nivell (assignant responsabilitats a les classes i fent servir patrons de disseny), centrant-se en
els detalls interns de cada classe (de disseny), la definició d’atributs (estructures
de dades), de les operacions (algorismes) i en detalls relatius als missatges. Es fa el
disseny arquitectònic, identificant les classes que són encapsulades pels diferents
components i subsistemes, per mitjà dels diagrames de components i de desplegament.
S'especifiquen les interfícies d’usuari (amb l’ajuda de diagrames d’estat), la gestió de
dades i els mecanismes d’administració de tasques. El DOO es centra en les vistes del
comportament i de l’entorn.
Els models creats durant la fase de disseny formen part del domini de la solució.

Versió 3.0 5
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

DISSENY D’INTERFÍCIES D’USUARI

Les interfícies d’usuari (IU) més habituals són entrades mitjançant teclat, pantalla i
sortides per pantalla i impressora, entrades i sortides sonores i entrades per escàner. Els
usuaris interactuen amb el software a través de les interfícies d’usuari. Les interfícies d’usuari
tenen una influència molt gran en la comoditat i productivitat dels usuaris.
Moltes vegades els usuaris jutgen la qualitat del software per les interfícies amb les que
interactuen amb més freqüència.
El disseny d’interfícies gràfiques d’usuari (IGU), implementades per mitjà de pantalles
gràfiques i generalment fent servir el ratolí, considera tres aspectes: contingut, el format
i la interacció. És pràctic dissenyar les IGU a partir de diagrames d’estat.

DISSENY DE LA PERSISTÈNCIA

Entre les bases de dades utilitzades per a emmagatzemar dades persistents, actualment (i
previsiblement en el futur immediat) les bases de dades relacionals són les més
àmpliament utilitzades. La orientació a objectes es centra en la construcció d'aplicacions
basant-se en objectes, que tenen atributs (dades) i mètodes (comportament), mentre que
el model relacional es centra tan sols en el fet d'emmagatzemar dades. En el paradigma
orientat a objectes s'accedeix als objectes via relacions entre objectes, mentre que en el
model relacional es dupliquen dades que possibiliten lligar files de diferents taules.
Aquestes dues fonamentacions teòriques tan diferents fan difícil la combinació dels dos
paradigmes. No obstant, a l'igual que hi ha regles de transformació dels diagrames del
model entitat-relació al model relacional, també hi ha regles per a transformar de forma
raonable els diagrames de classes al model relacional.

PATRONS DE DISSENY

A l'enfrontar-nos a un problema nou (per a nosaltres), no cal dissenyar una nova

solució. Els patrons de disseny permeten reutilitzar les solucions d’altres dissenyadors.
Els patrons permeten al dissenyador crear l’arquitectura de disseny integrant
components provats i reutilitzables. Un patró soluciona problemes de disseny
específics.

Versió 3.0 6
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Introducció a UML

El Llenguatge Unificat de Modelat (UnifiedModelling Language - UML) és unllenguatge per a

visualitzar, especificar, construir i documentar els elements d’unsistema de programari des
d’una perspectiva orientada a objectes.

Un model és una abstracció que captura coneixement sobre un problema. El model

extreu els detalls essencials del problema.
Els models de la part del mon real (generalment complex) on s'ha de resoldre un
problema conformen l’anomenat domini del problema.
La solució d'un problema fent servir l'orientació a objectes comporta la construcció d'un
model compost per objectes que interactuen enviant-se missatges entre ells.
Els models de disseny i implementació del sistema que resolen el problema conformen
el domini de la solució.
UML proporciona un vocabulari comú a totes les persones involucrades en un procés de
creació de software: analistes d'empresa, analistes, dissenyadors, programadors, … .
UML és una notació, no és una metodologia. Existeixen diverses metodologies que fan
servir UML: Procés unificat (UnifiedProcess-UP), ICONIX, desenvolupament guiat per
elements (FeatureDrivenDevelopment-FDD), ... .

Versió 3.0 7
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Vista de casos d’ús

• Descriu el sistema com un conjunt de transaccions des del punt de vista dels
actors externs;
• Es fa servir per a certificar la validesa de les altres vistes;
• Amb UML, els aspectes estàtics d’aquesta vista es capturen amb els diagrames
de casos d’ús; els aspectes dinàmics es capturen amb els diagrames d’activitat.
Vista lògica
• Es centra en aspectes relatius als requeriments funcionals del sistema en termes
de classes i objectes;
• Compren classes, interfícies, col·laboracions i paquets de la solució dissenyada;
• Amb UML, els aspectes estàtics d’aquesta vista es capturen amb els diagrames
de classes i d’objectes; els aspectes dinàmics es capturen amb els diagrames de
seqüència, de col·laboració d’estat i d’activitats.
Vista de processos
• Es centra en els processos de sincronització i concurrència del sistema;
• Ha de tenir en compte requeriments no funcionals: rendiment, integritat,
fiabilitat, seguretat, escalabilitat i administració del sistema;
• Amb UML, els aspectes estàtics i dinàmics es capturen amb els mateixos tipus
de diagrames que la vista de disseny, però fent èmfasi en les classes que
representen processos.
Vista d’implementació
• Organització de les components dins de l'entorn de desenvolupament;
• Mostra el repartiment de classes en components i subsistemes; mòduls,
subsistemes;
• Amb UML, els aspectes estàtics d’aquesta vista es capturen amb els diagrames
de components.
Vista de desplegament
• Descriu els diferents recursos de hardware (nodes) i la implementació del
programa en aquests recursos, considerant-ne: disponibilitat, rendiment i
escalabilitat;
• Amb UML, els aspectes d’aquesta vista es capturen amb els diagrames de
desplegament

Casos d’ús

• Descriu el comportament (funcionalitats) d’un sistema quan interactua amb

un usuari extern (actor).
• Representa un conjunt d’interaccions entre un o més actors i el sistema.
• Defineixen el comportament d'un sistema des del punt de vista dels actors.
• Representen els requeriments funcionals d’un sistema;
• Descriuen què fa un sistema, no com ho fa;
• Dirigeixen tot el procés de desenvolupament d’un sistema.

Versió 3.0 8
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Versió 3.0 9
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Diagrames de Casos d'Ús

A un diagrama de casos d’ús:

• els actors es representen per figures;
• els casos d'ús es representen amb òvals;
• les comunicacions es representen per línies que uneixen actors i casos d'ús.

Convé fer notar que una comunicació només indica que hi ha una interrelació entre un
actor i un cas d’ús. Evidentment, aquesta interrelació pot comportar diversos intercanvis
d’informació en les dues direccions. Per tant no implica cap flux d’informació només
en un determinat sentit.
Encara que una persona del mon real pot interactuar amb un actor (Usuari amb
Bibliotecari), aquesta interacció no la reflectirem en els diagrames de cas d’ús (convé
observar però que alguns autors la permeten).
Hi ha certs esdeveniments que passen regularment (el salari es paga mensualment).
S’acostuma a fer servir un actor Temps que s’ocupa d’inicialitzar aquests tipus
d’esdeveniments.

Característiques addicionals dels diagrames de casos d'ús

Un diagrama de casos d'ús es pot ampliar amb característiques addicionals per tal de
recollir millor tota la informació relacionada amb el sistema: fronteres, especialització i
generalització d’actors, generalització de casos d’ús, includes i extensions.

Per a simbolitzar la frontera entre el sistema i els actors es fa servir un rectangle. Així
queden delimitades clarament les accions dels actors de les funcionalitats del sistema.
Entre actors es poden establir relacions d’especialització/generalització amb herència, és a
dir:
Els actors descendents hereten els rols i les comunicacions amb els casos d’ús pròpies
de l’actor pare.
L’exemple següent mostra que l’actor CapBiblioteca pot fer totes les funcions que fan
els actors Bibliotecari més altres de pròpies:

Entre els casos d’ús hi pot haver tres tipus de relació:

Versió 3.0 10
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Generalització.

Una generalització d'un cas d'ús mostra que un cas d'ús E és un tipusespecial d'un
altre cas d'ús G. El cas d'ús E fa tots els processos del cas d'ús G més
algun procés específic. Una generalització es simbolitza per mitjà d'una fletxa
queapunta cap el cas d'ús G etiquetada amb <<generalize>>.

Inclusió.

Un cas d'ús pot incorporar explícitament el comportament d'altres casos d'ús

com a fragments del seu propi comportament. Serveix per a mostrar
funcionalitatscomunes entre diversos casos d'ús. Permet que el sistema utilitzi
components preexistents.
Aquesta relació s'anomena d'inclusió. El nou cas d’ús I és activat pels casos
d'ús que l'inclouen. Per tant, no és un cas especial del cas d'ús original. Es fa servir
unainclusió quan se sap exactament quan invocar un cas d’ús. En el diagrama es
representaper una fletxa puntejada en direcció cap a I, amb una etiqueta <<include>>. El cas
d’úsI, si és un cas d’ús complet, pot set activat directament per un actor.

Extensió.

Un cas d'ús E es pot definir com una extensió opcional d'un cas d'ús base B:
dins de B s'executa E quan es compleix una condició determinada. Aquesta
relaciós’anomena d'extensió. I pot haver vàries extensions d'un mateix cas d'ús.
En el diagramaes representa per una fletxa puntejada en direcció cap el cas d'ús B,
amb una etiqueta<<extend>>. Dins del cas B s'hi poden posar punts d’extensió que
serveixen per adeterminar quan la utilització del cas E és apropiada. El cas d’ús E no
acostuma a ser uncas d’ús complet activable per un determinat actor.

Escenaris

Un escenari és un recorregut específic d’un cas d’ús. Cada cas d’ús té un

escenariprincipal. A l’escenari principal d’un cas d’ús se suposa que tot funciona
idealment: nohi ha ni errors, ni alternatives, ni interrupcions.
Els casos d’ús complexos poden tenir diversos escenaris secundaris que
representenalternatives a l’escenari principal (errors, alternatives i interrupcions).
L’escenari principal i els escenaris secundaris es poden representar en un
mateixdiagrama de casos d’ús. No obstant, l’escenari principal i els escenaris
secundariss’especifiquen separadament (fitxa).

Passos per a la creació del conjunt dels casos d'ús

1. Identificar tots els actors del sistema;

2. Per a cada actor trobar totes les formes d’interactuar amb el sistema;
3. Crear un cas d’ús per a cada forma d’interactuar (opcional);
4. Estructurar els casos d’ús;
5. Revisar i validar els casos d’ús amb l’usuari.

Avantatges de l'utilització dels diagrames de casos d'ús

• Proporcionen un llenguatge de comunicació entre usuaris i desenvolupadors.

• Faciliten la determinació de requeriments i la comprensió detallada de les

Versió 3.0 11
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

funcionalitats del sistema.

• Ajuden a gestionar el risc dels projectes (complexos).
• Faciliten l'estimació del temps, dels recursos i de les prioritats dels projectes.
• Faciliten la verificació de la traducció de requeriments a codi executable.
• Permeten un major control del manteniment de les successives revisions dels
programes.
• Ajuden a la generació de documentació d’usuari.
• Permeten la generació de casos de prova per a diversos escenaris.

Exemple:Gestió d’una biblioteca

Guió d’un préstec

Quan un usuari vulgui retirar un llibre en préstec el bibliotecari:
• identificarà a l’usuari;
• verificarà que l’usuari no està sancionat;
• comprovarà que l’usuari no té ja en préstec el màxim de llibres autoritzats;
• identificarà el llibre;
• verificarà que un exemplar del llibre es pot deixar durant el període sol·licitat per
l’usuari;
• si l’usuari té el llibre reservat, en cancel·larà la reserva;
• farà el préstec.

Glossari
Usuari: pot ser un professor o un estudiant.
Bibliotecari: s’encarrega de mantenir el catàleg de llibres, de fer préstecs i
reserves.
Cap biblioteca: fa totes les tasques d’un bibliotecari, excepte catalogar llibres. És
l’únic amb la capacitat de modificar sancions.
Llibre: s’identifica amb la signatura.
Exemplar llibre: s’identifica amb signatura i número de còpia.
Catàleg: conjunt de tots els llibres de la biblioteca.
Préstec: es deixa un exemplar d’un llibre a un usuari per a un període de temps
determinat.

Reserva d’un llibre a nom d’un usuari.

Versió 3.0 12
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Observis que l’Usuari interactua amb el sistema per mitjà de l’actor Bibliotecari (actor
facilitador). Per tant no és pròpiament un actor, i no hi ha acord sobre si és millor posar-lo no a
un diagrama. El criteri que farem servir a partir d’ara, en general, serà de no
posar-lo, tal com fem a l’exemple modificat que presentem a continuació:

A l’anterior diagrama hi podem observar casos d’ús de diferent nivell.

Generalmentdibuixarem un diagrama de casos d’ús de context que complementarem amb una
fitxaper a cada cas d’us.
Diagrama de casos d’ús de context per l’exemple de gestió de la biblioteca:

refinem el diagrama...

Versió 3.0 13
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Plantilla fitxa per als casos d'ús:

Versió 3.0 14
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Exercicis:

Fer les fitxes de Gestionar préstec exemplar des de la visió del usuari i del dissenyador

Versió 3.0 15
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Diagrames d'Activitat

Definició:

i. Es centren en el flux d’activitats involucrades en un procés, generalment dins del marc

d'un o diversos casos d'ús.
ii. Mostra en quin ordre s’executen les parts del procés i com depenen unes de les altres.
iii. No proporcionen informació del comportament d’un objecte o de les col·laboracions
entre objectes.

Disseny:

i. En un diagrama d’activitat, el procés comença a partir del cercle negra d'inici situat a la
part superior o esquerra del diagrama i acaba al cercle blanc/negre de final situat a la
part inferior o dreta del diagrama.
ii. Les activitats s'indiquen amb rectangles arrodonits.
iii. Els diagrames d'activitat es poden subdividir en carrers (swimlanes) per a mostrar el
responsable (actor, objecte, unitat organitzacional, cas d´ús, ...) encarregat de l’activitat.
iv. De cada activitat se'n deriva una transició que connecta amb la següent activitat.
v. L'inici i final de branca s'indiquen amb un rombe.
vi. Una transició pot derivar cap a vàries noves transicions (branques) mútuament
excloents. Les expressions que controlen quina ha de ser la nova transició es posen
dins de [ ]. L'inici i final de branca s'indiquen amb un rombe.
vii. Una transició pot derivar cap a vàries activitats que es desenvolupen en paral·lel.
viii. L'inici d’activitats en paral·lel i la unió de retrobament final d’aquestes activitats
(sincronització) es simbolitzen amb barres sòlides.

Versió 3.0 16
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Exemples:

Diagrama d'activitats referit a la gestió de la biblioteca:

Versió 3.0 17
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Diagrama d'activitats amb el procés de pagament d’una compra a un supermercat:

Versió 3.0 18
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Diagrama d'activitats d'un caixer automàtic:

Versió 3.0 19
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Diagrama d'activitats de l'emissió d'un bitllet aeri:

Versió 3.0 20
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Diagrames d'Estats

Els objectes i els sistemes a cada instant estan en un estat concret. L’estat actual d’un objecte
o sistema en determina el seu comportament futur.
La transició entre estats és deguda a un esdeveniment.
A un diagrama d’estat, els estats es representen per rectangles arrodonits que poden tenir tres
compartiments:
✓ pel nom de l’estat
✓ per a valors característics del sistema o objecte quan es troba en aquest estat
✓ per a les accions que s’executen a l’entrar, mentre s’està o al sortir de l’estat.

L'estat inicial es simbolitza amb un cercle negre i l'estat final amb un cercle negre/blanc.

Les transicions es representen per fletxes, que van d'un estat a l'altre.

El nom dels esdeveniments que disparen les transicions s'escriuen al costat de les fletxes.
Pot ser que una transició comporti una acció, indica per /acció.
Una acció pot anar precedida d'una condició que es representa per [condició].
Així doncs, el text que acompanya a una transició té la forma: esdeveniment [condició] /acció

L'estat d’un objecte està determinat pels valors dels seus atributs. Podem fer servir un
diagrama d’estat per a mostrar tots els estats pels quals pot passar un objecte al llarg de la
seva “vida”.
El següent exemple mostra un diagrama d’estat amb els possibles estats d’un exemplar
d’un llibre d’una biblioteca.

Versió 3.0 21
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Classes

Amb UML una classe es representa per mitjà d'un rectangle dividit en tres parts que contenen:
· la part superior: el nom de la classe;
· la part central: els atributs de la classe;
· la part inferior: les operacions de la classe (mètodes a la fase de disseny).

Els atributs

La sintaxi d’un atribut és:

visibilitat nomAtribut: tipus = valorInicial on nomAtribut és la única part obligatòria.

Les operacions

La sintaxi d’una operació és:

NOTA: En Java i C++ el tipusRetorn és ignorat.

Quan un objecte rep un missatge, en compara la signatura amb la signatura de les seves
operacions, i si troba una coincidència llavors invoca la corresponent operació.
La representació d’una classe acostumen a ometre les operacions de creació/destrucció i
set/get.

Versió 3.0 22
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Visibilitat d’atribut i d’operació

La visibilitat d'un atribut o d'una operació indica com aquests poden ser accedits des d'objectes
d’altres classes. La visibilitat s'indica situant davant de l'atribut o de l'operació un dels símbols
de la taula següent:

Amb UML, si la visibilitat no s’indica explícitament, se sobreentén que els atributs són privats i
els mètodes públics.

Àmbit

S'indica que una operació és operació de classe subratllant-la. Si una operació no està
subratllada se sobreentén que és operació d'objecte.

Classes abstractes

Una classe abstracta és una classe de la qual no se'n poden instanciar directament objectes.
Per tant els objectes lligats a una classe abstracta s'han de crear necessàriament en alguna de
les seves subclasses (especialització).
Una classes abstracta s'acostuma a posar en itàliques.
Convé observar que depenent de la fase de desenvolupament del programari en la qual es fan
servir, la representació de les classes és més o menys completa.

Versió 3.0 23
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Diagrames de Classes

Un diagrama de classes conté:

· classes
· relacions entre classes.

Una relació entre classes es representa en el diagrama per un segment que les connecta.
Exemple (inicial) per a la gestió d’una biblioteca:

Els diagrames de classes es fan servir per a:

· explorar conceptes del domini del problema a la fase de definició de requeriments.
· analitzar/especificar requeriments a l’hora de construir el model d’anàlisi.
· descriure detalladament el programari a construir a la fase de disseny.

Versió 3.0 24
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

A l’igual que passa amb les classes, la representació dels diagrames de classe és més o
menys completa depenent de la fase de desenvolupament del programari en la qual es fan
servir.

Un diagrama de classes proporciona una visió estàtica del sistema a desenvolupar:

· mostra les classes que interactuen.
· no mostra què passa quan les classes interactuen.

Generalització/Especialització

és una relació d'herència en la qual una classe és

superclasse (subclasse) de l'altra. Una generalització/especialització es representa per un
segment amb un extrem triangular apuntant cap a la superclasse.

Existeixen tres tipus de relacions:

· Associació: interrelació entre instàncies de dues classes. Una instància d'una classe ha
de disposar d'informació d'una instància de l'altra classe per a poder fer el seu treball.
A un diagrama, una associació es representa per mitja d'un segment que connecta les dues
classes.

· Agregació: una associació en la qual es distingeixen un tot i una part: una instància d'una
classe (tot) es relaciona amb una col·lecció d'instàncies de l'altra classe (part).
Una agregació es representa per un segment amb un extrem en forma de diamant apuntant
cap a la classe singular.

· Composició: una associació en la qual una instància d'una classe (feble) no pot existir sense
estar relacionat amb una instància d'una altra classe. Una composició es representa per un
segment amb un extrem en forma de diamant ple apuntant cap a la classe no feble.

Versió 3.0 25
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Exemple de gestió d’una comanda:

A continuació descriurem amb més de detall el tres tipus de relacions:

Associació

A un dels dos extrems d'una associació s'hi pot posar el nom d'un rol per a clarificar la
natura de l'associació.
A una associació se li pot afegir una fletxa per a mostrar el sentit (de navegació) en el
qual es poden fer consultes. Una fletxa serveix per a mostrar qui és el "propietari" de
l'associació. Només es poden enviar missatges en la direcció de la fletxa. Les associacions
sense sentit de navegació són bidireccionals.
La multiplicitat situada a un extrem d'una associació indica el nombre de possibles instàncies
de la classe d'aquest extrem que es poden associar amb una instància de la classe de l'altre
extrem.
A continuació donem una taula que mostra les multiplicitats més comunes:

A un diagrama de classes hi han de figurar obligatòriament: les classes, les associacions i les
multiplicitats. El sentit de navegació i els rols es poden posar de forma opcional per a fer més
entenedor el diagrama.

Versió 3.0 26
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Agregació i composició

El diagrama de l'exemple següent mostra que:

· una guixeta (classe feble) va inseparablement lligada a l'existència d'una sala de
cinema (composició).
· a una sala de cinema s'hi passen diverses pel·lícules (agregació).

Convé observar que a l’hora de generar codi hi ha molt poca diferència entre una associació,
una agregació i una composició. En cas de dubte, sobre tot a la fase d’anàlisi, no és cap
problema deixar les relacions en forma d’associació.

Associacions qualificades
Un qualificador és un atribut d’una associació binària que serveix per a determinar unívocament
un objecte o conjunt d’objectes d’una de les classes, la classe objectiu, que estan relacionats a
través de l’associació.
Un qualificador es representa per un rectangle que s’adjunta a l’extrem de l’associació situat al
costat de la classe font, que és la classe oposada a la classe objectiu.

Els qualificadors, bàsicament, es fan servir com a identificadors: un objecte de la classe font
conjuntament amb un valor del qualificador selecciona unívocament un objecte o conjunt
d’objectes de la classe objectiu.
La multiplicitat assignada a la classe objectiu acostuma a ser: 0..1, 1 i * .
Convé comparar aquesta situació amb la que tindríem si no utilitzéssim una associació
qualificada:

Versió 3.0 27
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

En aquest cas, per a saber si una entrada ha estat venuda, hauríem de buscar entre les
entrades d’una obra fins a arribar a la que busquem, i llavors fer-ne la comprovació.

Classes associació

Una classe associació és una associació que té el mateix comportament que una classe.
Una classe associació es representa amb un rectangle de classe que s’uneix per mitjà d’una
línia puntejada a la línia que representa l’associació.
L’associació i la classe associació representen un sol element del model i, per tant, els noms de
l’associació i de la classe associació han de coincidir.
Només es pot fer servir una classe associació quan hi ha una única relació entre dos objectes
en un moment donat en el temps.

Algunes eines CASE (i tampoc Java) no permet treballar amb classes associació. En aquest
cas cal transformar el model. A continuació donem un exemple de transformació per la classe
associació propietari que acabem de veure.

Versió 3.0 28
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Dependències

Una dependència entre dues classes A i B és una relació, que no sigui una associació
(visibilitat d’atribut), en la qual un canvi a la classe B (proveïdora) pot forçar canvis a la classe A
(client). A un diagrama de classes, la dependència d’A respecte de B s’indica amb una fletxa
puntejada que va des d’A fins a B.
Una classe depèn d’una altra classe si:
· U objecte de la classe B és fa servir de paràmetre a una operació de la classe A (visibilitat de
paràmetre).
· Una operació de la classe A retorna un objecte de la classe B (visibilitat de paràmetre).

· Una operació de la classe A crea un objecte de la classe B i el fa servir dins d’un mètode,
però sense mantenir-ne cap referència (visibilitat local).
· Una operació de la classe A fa servir un mètode estàtic de la classe B (visibilitat global).

Restriccions

Una restricció és una condició que tota implementació del disseny ha de satisfer. En un
diagrama de classes les restriccions s'escriuen entre { }. En el diagrama de l'exemple una
Section pot ser part d'una CourseSchedule només si no ha estat cancel·lat.

Versió 3.0 29
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Estereotips

Un estereotip permet afegir informacions extres als elements del model (classes,
dependències, color/tipus de rol, …). El nom d'un estereotip s'escriu entre << >> sobre del nom
de l'element.
El següent diagrama de classes és un model d'un congrés:

Les classes del model són SessionTalk, que és refereix a una presentació, i Session,
que són el conjunt SessionTalks d'un dia. ShuttleSchedule, la llista de ShuttleStops, és
important pels congressistes allotjats a hotels allunyats de la seu del congrés.
El diagrama té una restricció, les ShuttleStops estan ordenades. La classe ShuttleStop té
l'estereotip <<place>>.

Interfícies

Una interfície és una classe que dóna nom a una llista d’operacions abstractes, sense
indicar-ne la implementació. Una interfície només defineix la signatura completa de les seves
operacions (nom, tipus de paràmetre i tipus de retorn), però no té atributs ni implementa les
operacions. D’aquesta forma l’especificació d’una funcionalitat queda separada de la seva
implementació.
Una interfície pot ser una especialització d’una interfície de més alt nivell. Una interfície
no pot ser instanciada.
La implementació d’una interfície per una classe concreta s’anomena realització. La
classe interfície porta l’estereotip «interface» sobre el nom de la interfície. Una realització es
simbolitza per una línia a trossos amb una fletxa que apunta des de la classe implementadora a
la classe interfície. No hi pot haver cap realització que tingui per origen la interfície. Una classe
pot implementar diverses interfícies, i una interfície pot ser implementada per més d’una classe.

Versió 3.0 30
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

Exemples:

I al diagrama del model d’un congrés hi ha tres interfícies: IDated, ILocatable, and ITimed. El
nom de les interfícies acostuma a començar amb la lletra I.
Els noms de les interfícies i de les seves operacions s'escriuen en itàliques. Una classe com
ShuttleStop, amb una operació que coincideix amb la de la interfície, com ILocatable, és una
implementació de la interfície.

Interfícies i associacions

Es pot establir una associació entre una classe C i una interfície I, sempre que la navegabilitat
sigui des de C cap a I. Tot i que la interfície I no pot ser instanciada, cal interpretar aquesta
associació en el sentit que un objecte de la classe C té referències a objectes de classes que
implementen la interfície I, i que per tant poden rebre missatges de C.

Exemple

Versió 3.0 31
 1 desembre
INTRODUCCIÓ A L'ENGINYERIA DEL SOFTWARE - UML
de 2020

A més a més de la notació per a representar interfícies que acabem de descriure i utilitzar a
l'exemple anterior, a UML hi ha una segona notació que fa servir cercles per a representar
interfícies. Amb la notació cercles, l'exemple anterior es representaria com:

Amb la nova notació, les interfícies són cercles connectats per fletxes puntejades amb origen a
les classes que les implementen. Al ser més compacta, però amb menys detall, la notació
cercles simplifica els diagrames originals.

Versió 3.0 32