ENGINYERIA DEL SOFTWARE II Treball de Teoria UMLima.udg.edu/~sellares/EINF-ES2/Present1112/Treball...

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.


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.


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.


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.


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.


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.


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.


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.


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 :


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.


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ó.


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 -


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.


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.


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ó:


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


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:


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:


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.


20 21-FEB-2012

Tot seguit tenim un exemple il·lustratiu d’un diagrama de classes a on hi intervenen diferents

parts mostrades anteriorment.


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.


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.


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


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.


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.


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.


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.


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.


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:


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.


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/


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


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.



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.


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.



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.


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.



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.



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

ENGINYERIA DEL SOFTWARE II Treball de Teoria UMLima.udg.edu/~sellares/EINF-ES2/Present1112/Treball...

Documents

Transcript of ENGINYERIA DEL SOFTWARE II Treball de Teoria UMLima.udg.edu/~sellares/EINF-ES2/Present1112/Treball...