Post on 28-Jan-2021
Jordi Cazorla Riera / Eduard Rando Segura
1 21-FEB-2012
ENGINYERIA DEL SOFTWARE II – Treball de Teoria UML
INTRODUCCIÓ
En aquest treball parlarem de la notació UML i del seu ús, però abans de poder-ho fer,
necessitem tenir una idea prèvia de l’estudi on s’utilitza l’UML, que és l’enginyeria del
software.
Al final dels anys 70 i principi dels 80 va haver-hi un elevat volum de gent que va començar a
programar i a treballar com a programador. Alguns dels programadors havien estudiat per a
ser-ho, però una gran part eren gent autodidacta que volien entrar al mon de la informàtica.
Això va provocar que les aplicacions que es van desenvolupar seguissin la intuïció del
programador i no pas uns estàndards.
En aquesta situació, es va veure la necessitat d’un estudi que permetés als informàtics
desenvolupar un bon software. Aquesta disciplina va ser coneguda com l’enginyeria del
software.
L’enginyeria del software, a grosso modo, é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, és a dir, que ens ajudin a desenvolupar un bon software.
Així doncs, un bon software és aquella aplicació que compleix les següents propietats:
Eficient: El software s’ha de desenvolupar en el temps esperat i s’ha de executar en
diversos ordinadors dins del temps esperat i sense malgastar recursos del sistema.
Fiable: El software ha de respondre com s’espera i no fallar més del que està
especificat. En sistemes multiusuaris, el software ha de respondre tot i haver-hi
altres programes inicialitzant-se en el sistema.
Utilitzable: El software ha de ser usat correctament. En general ens referim a tenir
present els usuaris que hauran d’utilitzar el software, encara que també es refereix
a que el software ha de funcionar amb el sistema operatiu del ordinador.
Escalable: El software ha de ser fàcilment modificable.
Portable: El software s’ha de poder canviar d’ordinador sense necessitat de
modificar el codi del software.
Comprovable: El software ha de poder ser testejat fàcilment. Aquest punt fa
referència a desenvolupar el software per mòduls.
Reutilitzable: Una part del software, o tot, s’ha de poder utilitzar de nou en un
altre projecte. Aquest punt fa referència a que el software ha de ser modular, per
tant, que cada mòdul del software ha de tenir un interfície ben definida i una
sortida clara.
Jordi Cazorla Riera / Eduard Rando Segura
2 21-FEB-2012
Manteniment fàcil: El software ha de ser fàcilment entès i s’ha de poder canviar en
el futur si sorgeixen problemes. Per poder assolir aquesta finalitat es quasi
imprescindible una bona documentació del software.
Interacció amb altres softwares: El software ha de poder interactuar
adequadament amb altres sistemes.
Correcte: El software ha de generar una sortida correcte.
Per poder garantir que el software que desenvolupem tingui aquestes característiques,
l’enginyeria del software ens proporciona diferents coneixements com: metodologies de
treball, els cicle de vida d’una aplicació, patrons, etc.
Imatge 1 - Diagrama cicle de vida d’una aplicació
Com veiem en la imatge, una aplicació té diferents etapes al llarg de la seva vida, en aquest
treball ens centrarem en la fase de disseny, ja que és on es fa necessari l’ús del UML. Cal tenir
en compte, que el procés del desenvolupament d’una aplicació pot ser molt llarg i costós, per
la qual cosa, hi solen intervenir moltes persones en un mateix projecte. L’UML és fa
imprescindible en la fase de disseny, ja que tot el grup de treball haurà de treballar sobre
aquest disseny, amb la qual cosa no es poden permetre ambigüitats o mals entesos.
Jordi Cazorla Riera / Eduard Rando Segura
3 21-FEB-2012
UML
La combinació entre dades i comportaments entre objectes, com bé sabem, té un seriós efecte
en el disseny d’aplicacions. De fet, als anys setanta, un elevat nombre de mètodes s’estaven
desenvolupant per tal de poder explotar de la millor manera possible els nous conceptes
sorgits en la programació orientada a objectes. I és que la majoria de desenvolupadors es van
adonar ràpidament que la programació orientada a objectes feia possible un procés de
desenvolupament a on parlar d’aplicació també era parlar de codi. També van veure que era
relativament senzill dibuixar els objectes i les relacions entre elles tot representant-ho en un
diagrama conjunt. A partir d’aquí, uns quants anys després, i gràcies a què es van adonar que
la transició de model a codi era fàcil, van començar a sorgir diferents models al respecte.
Cap els anys noranta, van sorgir diferents líders amb idees de diferents mètodes i notacions.
Així, Object-Oriented Software Engineering (OOSE) va ser una de les primeres empreses que hi
va començar a treballar, basant-se principalment en el concepte de casos d’ús que facilitava la
comunicació entre el projecte i l’usuari, fet que va tenir una rellevància significativa i va ser
una de les primers elements a destacar.
Tot seguit va veure la llum Object-Modeling Technique que posava molt d’èmfasi en l’anàlisi
del negoci i del sistema de dades com a problema. Aquest va ser el segon element clau i a tenir
en compte.
A continuació va sorgir el mètode Booch que es centra en el disseny i la implementació, tot
definint un plantejament al problema objectiu, el tercer element que va tenir incidència en
clau de futur.
Aquests tres elements, correctament combinats, fan que es pugui crear un projecte únic,
comprensiu i fàcilment modelable.
A partir d’aquí ens trobem en un punt clau ja que apareixen molts mètodes que van intentar
combinar aquests tres factors, ara ve, aquests no va tenir gaire èxit perquè no van ser prou
agressius en la cerca dels objectius estàndards pel modelatge de software. Tot i que, a
l’octubre de 1994, dos treballadors de Rational Software Corp., van començar a fusionar dos
de les notacions esmentades. De fet, ells dos eren els seus creadors. Van aconseguir trobar
punts en comú per tal d’apropar les seves notacions i així començar a adreçar-se cap a un
mateix camí. D’aquí, i gràcies a l’esforç realitzat, va sorgir una bona simplificació de la notació i
la idea clara de buscar una veritable arquitectura de llenguatge.
Un any després, van acabar el primer esborrany referent a la notació coneguda com a Unified
Modeling Language. Al mateix temps que va sorgir aquest primer esborrany, es va afegir a la
empresa el creador dels casos d’ús. Va ser llavors quan van integrar aquesta part al que fins
llavors havien creat aconseguint l’objectiu de què UML fos estàndard.
A partir d’aquí, tot i la competència que va tenir en els seus orígens, UML ha anat evolucionant
fins tal i com el coneixem a dia d’avui.
Jordi Cazorla Riera / Eduard Rando Segura
4 21-FEB-2012
De fet, i a mode resum, podem afirmar que l’UML ens permet descriure un model d’anàlisi i
disseny d’un sistema mitjançant els diagrames que hem comentat amb la utilització d’unes
certes nomenclatures semàntiques, sintàctiques i pràctiques. Aquestes nomenclatures són:
Les regles semàntiques ens indiquen el significat dels símbols emprats i com
interpretar aquests, ja sigui en un sistema aïllat com amb la combinació d’altres
elements del diagrama.
Pel que fa a la sintaxi, ens marca les normes de com mostrar i combinar els diferents
símbols que tenim per tal d’obtenir els diferents diagrames del nostre model.
Les regles que fan referència a la pràctica, aquestes ens defineixen com emprar el
seguit de símbols per tal de que els nostres diagrames siguin comprensibles per a
altres persones.
Tal i com hem dit fins ara, l’UML es va marcar una sèrie d’objectius amb unes característiques
molt marcades per tal de què fos més senzill seguir els estàndards establerts. Així, van sorgir
els següents objectius:
Proporcionar a tots aquells que realitzaran models un llenguatge de modelatge visual
per el correcte desenvolupament i l’intercanvi de models significatius.
Proveir mecanismes per a l’extensió i l’especialització per una bona ampliació dels
dissenys inicials.
Donar suport a les especificacions que són independents dels llenguatges de
programació i dels processos referents al desenvolupament.
Proporcionar una base formal per entendre el llenguatge de modelatge.
Impulsar la utilització de la programació orientada a objectes ja que aquesta aporta
beneficis significatius.
Donar suport a conceptes d’alt nivell en el desenvolupament com poden ser els
patrons.
Un cop vistos els objectius que té l’UML, ens centrarem en les seves característiques. Aquestes
són les que segueixen tot seguit.
Realització de mecanismes extensibles mitjançant estereotips i restriccions.
Donar suport als fils d’execució i als processos mitjançant els diagrames d’activitat.
Facilitat en l’aplicació dels diferents models de patrons.
Implementació de diferents diagrames per tal d’un millor modelatge.
Augment del perfeccionament per tal de poder manejar d’una manera més correcte
les relacions entre els diferents nivells d’abstracció.
Utilització d’interfícies facilitant la realització dels diagrames, pas previ a la realització
del codi.
Restriccions en el llenguatge mitjançant The Object Constraint Language (OCL).
Possibilitat d’utilitzar les esmentades accions semàntiques per tal de què el model
sigui el més acurat possible.
Després de veure tots els objectius i les característiques de l’UML, podem afirmar que estem
parlant d’una notació i no d’una metodologia.
Jordi Cazorla Riera / Eduard Rando Segura
5 21-FEB-2012
Així doncs, veiem que tenim un sistema a on la seva estructuració serà important. D’aquesta
manera en sorgeix l’arquitectura.
ARQUITECTURA
Tota arquitectura ben definida consisteix un conjunt organitzat d’elements, com subsistemes,
interfícies, distribució física, cohesió i acoblament, correctament estructurats. A més, una
correcta arquitectura que, des d’un bon principi, estigui ben definida i ben organitzada
permetrà que en un futur, els canvis que puguin anar sorgint no impliquin moltes
modificacions en la feina feta fins el moment, que no tinguin una afectació greu.
Cal dir, que els nostres models d’UML són, tal i com hem comentat anteriorment, conductors
per a la visualització, l’especificació, la construcció i la correcta documentació de
l’arquitectura. De fet, aquesta arquitectura es pot descriure per mitjà d’una col·lecció de vistes
que seran les que ens permetran fer-nos una correcta visualització de l’aplicació que tenim
entre mans.
Aquestes vistes són les que tenim en la figura que segueix a continuació. A més, en aquesta
figura també podem veure com es relacionen entre ells.
Jordi Cazorla Riera / Eduard Rando Segura
6 21-FEB-2012
Imatge 2 – Conjunt de vistes de l’arquitectura
Finalment, podem afirmar que tenim una perspectiva de l’organització i l’estructura del
sistema, representada mitjançant un conjunt de diagrames, que són els que definirem en els
següents apartats. Les vistes que apareixen en la imatge anterior, la 2, no hi farem més èmfasis
ja que el que realment ens interessa explicar són els diagrames que formen l’UML.
Jordi Cazorla Riera / Eduard Rando Segura
7 21-FEB-2012
DIAGRAMES
Primer de tot, abans de centrar-nos en els diagrames, i a tall de recopilació, podem afirmar
que l’UML (Unified Modelling Language) ens serà útil per poder realitzar una correcta
visualització, especificació, bona construcció i documentació dels elements de les nostres
aplicacions de software que estan orientades a objectes. Cal remarcar també, que el que fem
és seguir un model per tal de poder extreure els detalls essencials del problema buscant una
solució al nostre domini. Finalment, també destacar que, l’UML és una notació i no una
metodologia que, de metodologies que utilitzin el nostre llenguatge, en podem trobar varies.
Tot seguit, tenim una imatge característica del model UML, a on mostrem a molt alt nivell, com
està format el nucli d’UML:
Imatge 3. Nucli de l’UML amb els tipus de diagrames.
Un cop vist com està estructurat el nostre model ja ens trobem en condicions d’analitzar, part
per part, cada diagrama.
Jordi Cazorla Riera / Eduard Rando Segura
8 21-FEB-2012
Diagrama de Casos d’Ús
Els diagrames de casos d’ús tenen la finalitat de definir cadascun dels casos d’ús del sistema, és
a dir, definir el comportament (funcionalitats) d’un sistema quan interactua amb un usuari
extern (Actor).
Cal tenir en compte que un cas d’ús defineix les funcionalitats del sistema, però no
especifiquen com és fa. També cal tenir present que no hi ha cap relació entre l’estructura dels
casos d’ús i l’estructura del software, ja que els casos d’ús no són eines de disseny.
Aquest diagrama està format per: actors, casos d’ús i comunicacions.
Actors: són una entitat externa (persona, dispositiu, procés subsistema, temps, ...)
que interactuen amb el sistema interpretant un determinat rol. Per tant, els actors
no pertanyen al sistema, però són els encarregats d’entrar informació al sistema i
de recollir la informació que retorna aquest.
Casos d’ús: són una referència a una funcionalitat del sistema.
Comunicacions: són les relacions entre actors i casos d’ús.
En el diagrama també ens trobarem característiques especials com: relacions entre actors
d’especialització/generalització amb herència i relacions de generalització, inclusió i extensió
entre els casos d’ús.
Tot seguit veurem les normes per a fer el diagrama.
Sintaxi
Com ja hem vist, el diagrama esta format per actors, casos d’ús i comunicacions, el principi
bàsic del diagrama consisteix en associar, mitjançant comunicacions, els actors amb els casos
d’ús que interactuaran.
A més de les comunicacions, hem vist que també podem relacionar actors entre ells i casos
d’ús entre ells.
Les relacions entre actors estableixen un herència entre ells, és a dir, especifiquem que un dels
actors pot fer el mateix que un altre, però ampliant les seves funcionalitats (Especialització).
Les relacions entre casos d’ús poden ser de tres tipus com ja hem vist:
Generalització: mostra que un cas d’ús E és un tipus especial 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.
Inclusió: un cas d’ús pot incorporar explícitament el comportament d’altres casos
d’ús com a fragment del seu propi comportament. Serveix per a mostrar
funcionalitats comunes entre diversos casos d’ús i permet que el sistema utilitzi
components pre-existents.
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. Pot haver-hi
diverses extensions d’un mateix cas d’ús.
Tot seguit veurem com representarem aquest elements i característiques dins del diagrama.
Jordi Cazorla Riera / Eduard Rando Segura
9 21-FEB-2012
Semàntica
Representació dels elements i característiques del diagrama:
Els actors els representarem amb una figura:
Els casos d’ús els representarem amb un oval i un nom descriptiu al seu interior:
Les comunicacions les representarem mitjançant una línia que uneix un actor amb
un cas d’ús:
Les relacions entre actors les representarem com una fletxa que surt del actor més
específic i que es dirigeix cap al més general:
La relació de generalització entre casos d’ús es representa mitjançant una fletxa
que surt del cas més específic cap al més general i etiquetada amb :
Jordi Cazorla Riera / Eduard Rando Segura
10 21-FEB-2012
La relació d’inclusió entre casos d’ús es representa amb una fletxa puntejada que
surt del cas d’ús que necessita a un altre cas d’ús fins al cas d’ús que es necessita i
etiquetada amb :
La relació d’extensió entre casos d’ús es representa amb una fletxa puntejada que
surt del cas d’ús que necessita a un altre cas d’ús fins al cas d’ús que es necessita i
etiquetada amb :
Un cop vist el significat dels diferents elements del diagrama i la seva representació, definirem
els passos a seguir per fer un bon diagrama de 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.
Finalment veurem un exemple complert d’un diagrama de casos d’ús per posar en conjunt les
explicacions realitzades sobre el diagrama. L’exemple que mostrarem esta basat en la gestió
d’una biblioteca.
Jordi Cazorla Riera / Eduard Rando Segura
11 21-FEB-2012
Especificació d’un cas d’ús
L’especificació d’un cas d’ús ha de tenir:
- El nom.
- La versió i la data.
- La descripció dels objectius.
- Els actors.
- Quan comença (precondicions, activació) i quan acaba.
- El comportament esperat dels actors i del sistema.
- El flux principal d’esdeveniments i la seqüència de variacions possibles.
- Les excepcions: possibles contingències que poden afectar el flux dels esdeveniments.
A continuació veurem un exemple de fitxa d’especificació d’un cas d’ús:
CAS D’ÚS Nom del cas d’ús
Versió Nº Versió Data dd/mm/aa
Autors Autors del document
Descripció Descripció informal dels objectius del cas d’ús
Actors Actors que intervenen
Precondició Condicions que han de complir-se perquè es pugui realitzar el cas d’ús
Flux principal Flux principal d’events del cas d’ús
Subfluxos Diferents alternatives dins del flux principal
Fluxos alternatius Variacions en els fluxos principals o casos d’excepció
Postcondició Postcondició del cas d’ús
Requeriments no funcionals Llista de restriccions relacionades amb aquest requeriment funcional
Prioritat {urgent, normal, no prioritari}
Comentaris Comentaris addicional
L’especificació dels casos d’ús es va actualitzant durant tot el procés de desenvolupament del
software.
Per cada cas d’ús hi ha d’haver com a mínim:
a) Fitxa orientada al usuari, que es fa servir a la fase de requeriments i anàlisi.
b) Fitxa orientada al informàtic, que es fa servir a la fase de disseny i implementació.
Jordi Cazorla Riera / Eduard Rando Segura
12 21-FEB-2012
Exemple de fitxa de cas d’ús:
CAS D’ÚS Gestionar Préstec Exemplar
Versió Visió Usuari Data dd/mm/aa
Autors -
Descripció Un usuari vol treure un exemplar d’un llibre en préstec
Actors Bibliotecari
Precondició Usuari i exemplar donat d’alta al sistema
Flux principal
1. Identificar usuari 2. Comprovar usuari no sancionat 3. Comprovar usuari no té en préstec el màxim d’exemplars
autoritzats 4. Identificar exemplar 5. Comprovar exemplar en préstec 6. Comprovar llibre no reservat altre usuari 7. Si llibre reservat per propi usuari cancel·lar reserva 8. Fer préstec
Subfluxos -
Fluxos alternatius 1. Si usuari sancionat o té en préstec màxim exemplars autoritzats o
exemplar no en préstec o llibre reservat altre usuari llavors refusar préstec.
Postcondició Si tot O.K. préstec fet altrament préstec refusat
Requeriments no funcionals
-
Prioritat -
Comentaris -
Jordi Cazorla Riera / Eduard Rando Segura
13 21-FEB-2012
Diagrama de Classes
Pel que fa al diagrama de classes és el cor del nostre model, dels nostres diagrames.
El nostre objectiu d’aquest diagrama serà mostrar, de forma correcte i entenedora, els blocs
d’un sistema orientat a objectes. De fet, aquest diagrama és la clau per convertir el model a
codi i viceversa. Aquest ens servirà per construir i operar amb el sistema.
De fet, podem afirmar que els principals valors dels diagrama de classes són:
Definir els recursos essencials d’un sistema.
Definir les relacions entre els recursos del nostre sistema.
Generar codi.
Realització del model a partir del codi, és a dir, enginyeria inversa, tot i que aquesta no
és la seva principal utilitat.
Proporcionar un punt de partida per a la resta de diagrames que, a partir d’aquest,
podran elaborar-se.
Aquest diagrama està format per les classes, amb diferents tipus d’aquestes, i les relacions
entre elles, que també poden ser diferents.
Classe: Una classe, o altrament dit entitat, es representa mitjançant un requadre que
està dividit en tres parts.
A la primera part, la superior, hi trobarem el nom de la nostra classe.
Tot seguit, en la segona part, hi trobarem els atributs d’aquesta classe amb els tipus
que corresponen cada un d’aquests atributs.
Finalment, la tercera part, està formada pels mètodes que formen la classe en si.
Relacions: Són associacions conceptuals entre classes. Més endavant es detallaran
aquestes i els diferents tipus que tenim.
A continuació ens centrarem en les diferents regles que emprarem per la correcta realització
del diagrama descrit.
Sintaxi
Tot seguit explicarem els diferents elements que ens podem trobar en una classe i els tipus de
relacions que tenim.
Pel que fa els elements d’una classe, hem de tenir presents que, com bé sabem, tant els
atributs com els mètodes poden ser privats, públics, protegits o formar part de paquets. A
més, pel que fa als mètodes, també hi tindrem, per a cada mètode si s’escau, el tipus de
retorn, els paràmetres i els àmbits.
Jordi Cazorla Riera / Eduard Rando Segura
14 21-FEB-2012
Si ens centrem per cada un d’ells, tenim que la sintaxi pels atributs ha de ser:
Visibilitat nomAtribut: tipus = valorInicial
Cal dir que la única part obligatòria és el nom de l’atribut, ara ve, és del tot aconsellable
introduir-hi també la visibilitat i el tipus, ja que d’aquesta manera estem donant més
informació al respecte de l’atribut.
Pel que fa als mètodes continguts a la classe tindran l’estructura que segueix:
Visibilitat nomOperacio(nomParàmetre: tipusParàmetre): tipusRetorn
Aquesta seria l’estructura general, tot i que, a on tenim els paràmetres, encara que en aquest
exemple només se’n vegi un, hi podem tenir una llista. Cal remarcar també que, les operacions
de creació i destrucció no s’acostumen a posar, al igual que els sets i gets.
Pel que fa al tipus de classes, en tenim de diferents, com poden ser les classes abstractes que
són les que no es poden instanciar directament els objectes, les interfícies que són contractes
per garantir un comportament de les subclasses, taules que fan referència sobretot a les bases
de dades i classes d’associació que són els atributs de les relacions.
Si ens centrem en les diferents relacions que tenim entre classes tenim les associacions que
són les interrelacions entre instàncies de dues classes, agregacions que són una associació en
la qual tenim un tot i una part, les composicions que volen dir que una associació en la qual
una classe no pot existir sense estar relacionada amb una altra classe, associacions qualificades
en les quals tenim un atribut qualificador a l’associació, una classe d’associació que tal i com
hem dit anteriorment són una associació que té el mateix comportament que una classe i que
té diferents atributs d’una relació, dependències que un canvi a una classe ens pot implicar un
canvi a l’altre classe, restriccions, estereotips que ens permeten obtenir informació addicional
dels elements del model, generalització i especificació que ens indiquen la relació d’herència.
Cal dir que, si tenim una classe interfície, aquesta estarà connectada amb les seves
implementacions per unes associacions concretes.
No hem d’oblidar que podem tenir les associacions reflexives que són aquelles que
interaccionen amb elles mateixes.
Cal dir que les associacions poden tenir diferent cardinalitat que ens indica el nombre possibles
d’instàncies que podem tenir d’aquelles classes. Cal dir també que les associacions poden tenir
un cert sentit, que ens indica la direcció dels missatges que es poden enviar entre classes, ara
ve, si no tenim sentit voldrà dir que les relacions entre classes seran bidireccionals.
Jordi Cazorla Riera / Eduard Rando Segura
15 21-FEB-2012
Semàntica
Tot seguit tenim una representació dels diferents elements que ens podem trobar en aquest
diagrama:
Les classes, tal i com hem comentat, està representada per un rectangle que conté tres
subdivisions:
Les classes abstractes es representen pràcticament igual que les classes però amb la
única diferència que s’acostumen a posar en itàliques:
Les interfícies per una classe concreta s’anomenen realització. La classe interfície es
diferencia de la resta perquè porta l’estereotip sobre el nom concret
d’aquesta, tal i com es veu a continuació:
Jordi Cazorla Riera / Eduard Rando Segura
16 21-FEB-2012
Les taules per les bases de dades, contenen el nom d’aquesta, i les seves restriccions
concretes dels atributs i mètodes:
Una classe associació es representa mitjançant un rectangle, al igual que una classe,
però aquesta s’uneix, gràcies a una línia puntejada, a la línia que representa
l’associació. Tot seguit un exemple il·lustratiu molt entenedor:
Per entendre millor la visibilitat dels mètodes i atributs tenim la taula il·lustrativa
següent:
Símbol Accés
+ Públic
- Privat
# Protegit
~ Paquet
Jordi Cazorla Riera / Eduard Rando Segura
17 21-FEB-2012
Les associacions es representen mitjançant una línia que uneix dues classes:
Per poder comprendre millor la cardinalitat i les seves diferents opcions tenim la taula
següent:
Multiplicitats Significat
0..1 Zero o una instàncies
n..m De n a m instàncies
0..* o * Nombre indeterminat d’instàncies, inclòs el zero
1 Una única instància
1..* Nombre indeterminat d’instàncies essent una com a mínim
Pel que fa les agregacions, tal i com hem comentat, ens indiquen que tenim un tot i
una part, de fet, un exemple molt explicatiu és el que fa referència al cotxe ja que
parlar d’aquest no tindria sentit sense parlar de les parts d’aquest. A continuació
veiem com queda representat:
Jordi Cazorla Riera / Eduard Rando Segura
18 21-FEB-2012
Tot seguit veurem un exemple de composicions, recordem que significava que una
classe no pot existir sense l’existència d’una altra:
Associacions qualificades. Aquestes les tenim representades tot seguit:
Les dependències de classes són les que tenim a continuació:
Pel que fa les restriccions, a continuació les veiem representades:
Jordi Cazorla Riera / Eduard Rando Segura
19 21-FEB-2012
La relació entre una interfície i la seva implementació la tenim en la figura que segueix:
Una altre tipus d’associacions que tenim i que veurem tot seguit són les reflexives:
El darrer element que veurem són els estereotips, que és informació addicional que
s’aporta a la classe. Els veurem molt ben il·lustrats tot seguits:
Aquell tipus d’associacions que hem mencionat en la sintaxi i no en la semàntica és degut a
què ja les hem explicat anteriorment en algun altre diagrama i la representació és la mateixa.
Jordi Cazorla Riera / Eduard Rando Segura
20 21-FEB-2012
Tot seguit tenim un exemple il·lustratiu d’un diagrama de classes a on hi intervenen diferents
parts mostrades anteriorment.
Jordi Cazorla Riera / Eduard Rando Segura
21 21-FEB-2012
Diagrama d’objectes
En aquest apartat veurem els diagrames d’objectes. Aquests diagrames són un tipus especials
de diagrames de classes que mostren quines instàncies tenim en el nostre model en comptes
de les classes que hem explicat anteriorment.
Aquest tipus de classes són molt útils per explicar amb un millor aprofundiment certes
relacions que tenen un elevat grau de complexitat.
Per tal d’expressar-ho en aquest diagrama, el que farem serà emprar rectangles semblants als
de les classes amb la diferència que aquests no tindran subdivisions sinó que únicament el
nom subratllat de la instància a la que fa referència. A més, si volem anotar el nom de la classe
de la instància en qüestió anirà precedit per dos punts (:). De fet, cada rectangle que
representem serà un únic objecte de la classe i la unió entre aquestes serà únicament amb
una línia.
El fet de què cada rectangle sigui una instància concreta fa que si volem representar tot el
nostre model de magnituds significatives fos pràcticament impossible. És per això que, tal i
com hem comentat, el seu ús es limitarà en explicar certes relacions complexes.
Tot seguit tenim un exemple d’aquest tipus de diagrames, els d’objectes.
Un cops vistos els dos diagrames més importants, com són el diagrama de casos d’ús i el de
classes, ja que el primer ens dona una visió de les funcionalitats del software i dels actors que
intervenen, i el segon ens mostra l’estructura del software, passarem a veure més per sobre
els altres diagrames.
Jordi Cazorla Riera / Eduard Rando Segura
22 21-FEB-2012
Diagrama d’Activitat
Aquest diagrama és basa en mostrar el flux d’activitats que intervenen en un procés,
generalment està relacionat amb un o diversos casos d’ús. Per ser més explícits, podem dir que
un diagrama d’activitat mostra l’ordre en que s’executen les diferents parts d’un procés i com
depenen unes de les altres.
Cal tenir en compte que els diagrames d’activitat no proporcionen informació ni del
comportament del objecte ni de les col·laboracions entre objectes.
La sintaxis que segueix el diagrama és la següent:
Tot diagrama començarà amb un cercle negra d’inici situat a la part superior esquerra del
diagrama i acabarà amb un cercle negre inscrit en un de blanc situat a la part inferior o dreta
del diagrama. Les activitats s’indiquen amb rectangles arrodonits.
El diagrama d’activitat es pot subdividir en carrers (swimlines) per a mostrar el responsable
(actor, objecte, unitat organitzacional, cas d’ús, ...) de les activitats que engloba. Cada activitat
té una transició que la connecta amb la següent activitat.
Una transició pot derivar a vàries noves transicions excloents entre si, com si d’un if/else es
tractés. Les expressions que controlen quina ha de ser la nova transició es posen dins de [], i
l’inici i final de branca s’indiquen amb un rombe. Una transició també pot derivar cap a vàries
activitats que es desenvolupen en paral·lel. L’inici d’activitats en paral·lel i la unió de
retrobament final d’aquesta activitats es simbolitza amb barres sòlides.
Jordi Cazorla Riera / Eduard Rando Segura
23 21-FEB-2012
Diagrama de descripció d’iteracions
Aquests diagrames, són molt semblants als que acabem d’explicar, els d’activitats. De fet, per
això el trobem aquí per tal de poder veure més clarament la semblança amb aquest.
Aquest diagrama el que farà serà dir-nos que, el que fins ara era un activitat, ara serà un
diagrama d’interacció.
Tot seguit en podem veure un exemple tot apreciant que la notació és la mateixa.
Diagrama de seqüència
En aquesta part veurem els diagrames de seqüència, que són aquells diagrames d’interacció
que ens detallaran com s’executen cada una de les operacions en una línia temporal . Així hi
podrem veure quins missatges són enviats pels objectes, quin d’aquests l’envia i cap a on
l’envia, i tot en una línia de temps que ens permetrà veure quan es realitza aquesta acció.
Els objectes es representen mitjançant un requadre a on hi haurà el nom de l’objecte que hi
intervé, precedit per dons punts (:) i tot subratllat. Cal dir que podem tenir un conjunt de
classes que, si es dona el cas, ho representarem després del nom de la classe, mitjançant un
asterisc entre claus [*]. Aquests requadres tindran una línia discontinua vertical, que
anomenarem línia de vida, que representa el temps en el qual l’objecte en qüestió existeix.
L’aparició dels diferents objectes que intervenen en una determinada acció aniran apareixen
d’esquerra a dreta d’acord amb el moment que intervenen en la seqüència dels missatges en
qüestió.
Abans de les classes però, tindrem un actor que serà el que interactuarà amb el que
anomenarem pantalla que és qui realment determinarà quina acció es vol realitzar. Tot seguit
Jordi Cazorla Riera / Eduard Rando Segura
24 21-FEB-2012
la pantalla enviarà el missatge a la unitat de control que serà aquesta la que es començarà a
comunicar amb les classes per tal de què la funció demanada per un actor es dugui a terme.
Aquest darrer element, el control, serà qui s’encarregarà de la lògica del cas d’ús.
La notació de l’actor ja l’hem vist en els diagrames anteriors. Ara ve, tant la pantalla com la
unitat de control es representen tal i com tenim tot seguit:
Pantalla Unitat de control
Tot seguit comentarem el pas de missatges entre classes. Es representarà mitjançant una
fletxa a on cada una d’elles representa la crida d’un missatge. Aquestes van des de l’emissor
fins a la part superior de la barra d’activació del missatge que trobarem situada en la línia de
vida del receptor. Cal remarcar que quan parlem de barra d’activació fem referència al temps
d’execució del missatge esmentat. A més, i de manera opcional, els valors de retorn es poden
indicar mitjançant una fletxa puntejada.
Jordi Cazorla Riera / Eduard Rando Segura
25 21-FEB-2012
A continuació tenim un exemple molt genèric d’aquest fet:
Un altre element que tenim en aquests diagrames, els de seqüència, són els anomenats
requadres, que podran fer referència a diferents elements. Als elements que fan referència
vindran indicats per una etiqueta i/o una clàusula condicional. Abans de veure un exemple
però, tenim una taula a on hi podem veure les diferents etiquetes o operadors i quin significat
tenen cada una d’elles.
Operador Significat
alt Fa referència a, quan tenim un condicional, a l’altrament
break Si es compleixen les condicions que tenim predeterminades
s’executaran les instruccions de dins d’aquest requadre i acabarà,
per tant, els missatges posteriors a aquest requadre no es tindran
en compte.
loop És un bucle que, mentre la condició establerta sigui verdadera
s’anirà executant.
opt Si la condició és verdadera s’executarà la part de dins del
requadre.
par Els fragments s’executaran en paral·lel.
ref Permet fer referència a altres diagrames de seqüència tot
permetent la reutilització d’aquets fent-los més simples.
Jordi Cazorla Riera / Eduard Rando Segura
26 21-FEB-2012
Tot seguit tenim un exemple de loop per veure el funcionament dels requadres:
Diagrama de Comunicació
Els diagrames de comunicació tenen la mateixa finalitat que els de seqüència, però centrant-se
més en els rols dels objectes en comptes de centrar-se en la temporització dels missatges que
s’envien als objectes.
Per representar els objectes en el diagrama utilitzarem ovals. Els objectes estaran connectats
per lligams (links). Els lligams es representaran mitjançant un segment entre els dos objectes. A
un lligam li podran correspondre múltiples missatges i missatges en dues direccions, la direcció
del missatge s’indicarà amb una petita fletxa situada al costat del missatge.
Cada missatge del diagrama tindrà associat un numero de seqüència. El missatge inicial és el
número 1. Els missatges de igual nivell, és a dir, els enviats per la mateixa crida, tenen com a
prefix el mateix número, seguit d’un sufix 1, 2, etc. D’acord amb la seqüència de missatges.
Jordi Cazorla Riera / Eduard Rando Segura
27 21-FEB-2012
Diagrama de temps
Tot seguit farem una breu descripció dels diagrames de temps. Aquests fan referència als
canvis que pot patir una instància al llarg del temps. A més, en aquests diagrames es pot
apreciar millor els missatges enviats entre objectes en una línia temporal ja que si posa més
èmfasi.
Així doncs, estem tornant a recalcar els dos diagrames anteriors.
Tot seguit tenim un exemple del que estem comentant:
Diagrames d’estat
Els objectes i els sistemes a cada instant estan en estats concrets, l’estat ve determinat pels
valors dels atributs. L’estat actual del sistema o d’un objecte ens permet determinar el seu
comportament futur. Els canvis d’estat venen provocats per esdeveniments, d’aquests canvis
en direm transicions. Per tant, el diagrama d’estats ens servirà per modelar comportaments
complexes d’objectes i sistemes.
També podem fer servir els diagrames d’estats per mostrar tots els estats pels quals pot passar
un objecte al llarg de la seva “vida”.
En un diagrama d’estats, els estats es representen com rectangles arrodonits amb tres
compartiments: el primer pel nom de l’estat, el segon per a valors característics del sistema o
objecte quan es troba en aquest estat, i el tercer per a les accions que s’executen al entrar,
m’entres s’està o al sortir de l’estat.
L’estat inicial es marca amb un cercle negre i el final amb un cercle negre inscrit en un de
blanc.
Jordi Cazorla Riera / Eduard Rando Segura
28 21-FEB-2012
Les transicions es representen amb fletxes que van d’un estat a un altre. Les fletxes van
etiquetades de la següent forma: esdeveniment [condició] /acció. Com veiem en l’etiqueta,
tenim un camp per indicar un nom representatiu del esdeveniment ocorregut. Pot ser que
l’esdeveniment sigui condicionat, en aquest cas ho indicarem amb la condició entre []. Per
últim, pot ser que la transició comporti una acció, s’indica amb / i l’acció corresponent.
El següent exemple mostra un diagrama d’estat amb els possibles estats d’un exemplar d’un
llibre d’una biblioteca.
Jordi Cazorla Riera / Eduard Rando Segura
29 21-FEB-2012
Diagrama de components
El diagrama de components fa referència a un conjunt de components que són la part física
d’un sistema. Aquestes components representen l’empaquetament físic d’elements que són
lògics, així doncs, contenen informació sobre el codi font, binari, executables, llibreries,
documents, bases de dades, entre d’altres. Aquests diagrames mostren les relacions entre
aquests esmentats components. La relació entre aquests components es representa
mitjançant una fletxa discontinua que va des d’un component al que depèn, apuntant a aquest
últim.
La seva representació és molt senzilla, mitjançant un rectangle amb dues pestanyes a la part
esquerra, tal i com veiem a continuació:
Diagrama de desplegament
Els diagrames de desplegament són aquells que ens mostren la configuració de diferents
nodes, que són elements físics que representen el hardware sobre el qual es desplega i
s’executen els diferents components esmentats anteriorment, que participen en l’execució. A
més, podem veure quins components resideixen en aquests nodes.
La utilitat d’aquests diagrames la trobem quan volem expressar arquitectures distribuïdes on
generalment hi acostumen haver aplicacions i servidors en diferents ubicacions.
Tot seguit podem veurem com s’expressa un node i l’associació entre elles, que ens serveixen
per mostrar una connexió física entre dos dels esmentats nodes:
Jordi Cazorla Riera / Eduard Rando Segura
30 21-FEB-2012
Finalment, en la darrera il·lustració, podem veure com s’estructura un node, com s’expressa un
component dins d’aquest i les relacions entre els diferents components:
Actualment hem vist els diagrames més comuns. Ara ve, aquests van sorgir a la versió 1.0 i
actualment estem treballant amb la versió 2.0. Tot seguit veurem una breu descripció d’altres
diagrames que podem tenir a partir d’aquesta nova versió.
Diagrama de paquets
El diagrama de paquets consisteix en un conjunt de paquets que pot contenir un nombre
indeterminat de diferents diagrames en ell. Així, en aquest diagrama i podem trobar-n’hi
d’altres.
És per això que, es pot donar el cas de què tinguem més classes o objectes que paquets.
Cal remarcar que aquest diagrama és opcional, i si en fem ús, és degut a què ens interessa
remarcar l’estructura de carpetes que té la nostra aplicació.
Així doncs, tot seguit veiem un exemple del que acabem de comentar.
Jordi Cazorla Riera / Eduard Rando Segura
31 21-FEB-2012
Cal remarcar que aquest diagrama té subtipus de diagrama que tot seguit veurem amb un breu
resum de cada un d’ells i un exemple il·lustratiu. Aquests diagrames han estat extrets de
www.omg.org. Just a sota de cada imatge podrem trobar la pàgina allà a on trobarem una
explicació més extensa de cada un d’ells. Cal remarcar que, per ser més exactes, la pàgina web
a on trobarem aquest pdf, més concretament, és
http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/.
Diagrama de tipus
El diagrama de tipus defineix meta-classes abstractes que relacionen el nom amb el tipus dels
elements.
Referència: pàgina 104.
http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/
Jordi Cazorla Riera / Eduard Rando Segura
32 21-FEB-2012
Diagrama d’operacions
Aquest diagrama, el d’operacions, es centra en les característiques de comportament,
operacions i paràmetres de construcció. Altre cop, tenim un exemple.
Referència: pàgina 163
Jordi Cazorla Riera / Eduard Rando Segura
33 21-FEB-2012
Diagrama de noms
Aquest diagrama es tracta de descriure l’espai de noms del nostre sistema o aplicació.
L’exemple de continuació exposa aquest diagrama.
Referència: pàgina 155
Jordi Cazorla Riera / Eduard Rando Segura
34 21-FEB-2012
Diagrama de tipus de dades
Pel que fa al diagrama de tipus de dades, aquest especifica el tipus de dades, les
enumeracions, les enumeracions literals i els tipus primitius. A més, hi afegeix característiques
dels constructors, com poden ser les propietats i les operacions. Són comuns per a definir el
tipus d’atributs que tenim.
Referència: pàgina 149
Diagrama de restriccions
Diagrama que defineix les restriccions que podem arribar a tenir a la nostra aplicació. Tot
seguit podem veure aquest diagrama a la figura que segueix.
Referència: pàgina 147
Jordi Cazorla Riera / Eduard Rando Segura
35 21-FEB-2012
Diagrama de classificadors
Pel que fa al diagrama de classificadors, aquest especifica els conceptes de classificadors, tipus
d’elements, multiplicitat dels elements, refinament d’aquests elements i característiques
estructurals. L’exemple de continuació fa referència a aquest diagrama.
Referència: pàgina 141
Diagrama d’expressions
Pel que fa a aquest diagrama, el d’expressions, el que ens intenta especificar són els valors
especificatius, les expressions i les construccions d’expressions opaques.
Referència: pàgina 120
Jordi Cazorla Riera / Eduard Rando Segura
36 21-FEB-2012
Diagrama arrel
Pel que fa al darrer diagrama que comentarem, el diagrama arrel, aquest ens descriu els
elements, les relacions, les relacions directes i els comentaris que tenim en l’estructura de la
nostra aplicació.
Tot seguit tenim la darrera il·lustració que mostra aquest exemple.
Referència: pàgina 117
Jordi Cazorla Riera / Eduard Rando Segura
37 21-FEB-2012
BIBLIOGRAFIA
- “Introduction to SOFTWARE ENGINEERING”, Ronald J. Leach
- “ Bible UML”, Tom Pender
- Apunts “Introducció a UML”, Toni Sellarès
- www.omg.org