mòdul 4 - anàlisi uml

Anlisi UML

Jordi Pradel MiquelJose Raya Martos

PID_00171147

FUOC PID_00171147 Anlisi UML

Cap part d'aquesta publicaci, incloent-hi el disseny general i la coberta, no pot ser copiada,reproduda, emmagatzemada o transmesa de cap manera ni per cap mitj, tant si s elctric comqumic, mecnic, ptic, de gravaci, de fotocpia o per altres mtodes, sense l'autoritzaciprvia per escrit dels titulars del copyright.


ndex

Introducci.................................................................................................. 5

Objectius....................................................................................................... 6

1. Anlisi orientada a objectes amb UML........................................ 71.1. Anlisi orientada a objectes ........................................................ 71.2. El llenguatge UML ...................................................................... 7

1.2.1. Motivaci del llenguatge UML ...................................... 71.2.2. Origen del llenguatge UML ........................................... 91.2.3. Tipus de diagrames UML ............................................... 9

1.3. Exemple ....................................................................................... 14

2. Model de casos d's............................................................................ 162.1. El diagrama de casos d's ........................................................... 16

2.1.1. Actors ............................................................................. 172.1.2. La frontera del sistema .................................................. 172.1.3. Els casos d's .................................................................. 172.1.4. Relacions entre casos d's i actors ................................. 182.1.5. Relacions entre casos d's: inclusi ............................... 182.1.6. Relacions entre casos d's: extensi .............................. 19

2.2. El diagrama d'activitats ............................................................... 202.2.1. Lgica condicional ......................................................... 212.2.2. Parallelitzaci ................................................................ 222.2.3. Organitzaci: carrils ....................................................... 232.2.4. Altres elements de notaci ............................................ 24

2.3. El model resultant ....................................................................... 24

3. Modelitzaci de la interfcie........................................................... 283.1. Casos d's concrets ..................................................................... 283.2. Models de les pantalles ............................................................... 29

3.2.1. Diagrama d'estat de les pantalles (mapanavegacional) ................................................................. 30

3.3. Contractes de les operacions del sistema ................................... 31

4. Model del domini............................................................................... 334.1. Convencions en els diagrames UML .......................................... 334.2. Classes .......................................................................................... 34

4.2.1. Notaci UML ................................................................. 344.2.2. Tcniques de modelitzaci ............................................ 34

4.3. Atributs ........................................................................................ 384.3.1. Notaci UML ................................................................. 38


4.3.2. Tcniques de modelitzaci ............................................ 394.4. Associacions ................................................................................. 42

4.4.1. Notaci UML ................................................................. 424.4.2. Tcniques de modelitzaci ............................................ 42

4.5. Herncia ....................................................................................... 514.5.1. Notaci UML ................................................................. 514.5.2. Tcniques de modelitzaci ............................................ 52

4.6. Informaci derivada i regles d'integritat ..................................... 594.6.1. Regles d'integritat .......................................................... 594.6.2. Informaci derivada ...................................................... 62

4.7. Classes i atributs: elements avanats .......................................... 634.7.1. Tipus de dades ............................................................... 634.7.2. Atributs: notaci UML avanada ................................... 65

4.8. Associacions: elements avanats ................................................. 664.8.1. Composici .................................................................... 664.8.2. Associacions amb repeticions o amb ordre ................... 674.8.3. Notaci UML avanada ................................................. 684.8.4. Associacions ternries (i N-ries en qu N > 2) .............. 68

4.9. El model resultant ....................................................................... 70

Resum............................................................................................................ 72

Activitats...................................................................................................... 73

Exercicis d'autoavaluaci........................................................................ 77

Solucionari.................................................................................................. 78

Glossari......................................................................................................... 88

Bibliografia................................................................................................. 90

FUOC PID_00171147 5 Anlisi UML

Introducci

Tal com hem vist al mdul "Orientaci a objectes", l'orientaci a objectes sun paradigma que pot resultar molt til no solament per a tasques de progra-maci, sin tamb per a tasques d'anlisi. D'altra banda, al mdul "Requisits"hem vist els requisits i la importncia de fer una documentaci de requisitsde qualitat, i tamb els casos d's com una manera flexible de documentarrequisits funcionals.

En aquest mdul veurem com combinar l's de l'orientaci a objectes i elscasos d's per a fer una documentaci de requisits fent servir UML. El tipusde documentaci que elaborarem s fora completa i pot arribar a ser formal,per pot ser til per a tot tipus de metodologies.

En primer lloc veurem com el concepte d'orientaci a objectes es pot aplicara l'anlisi i com UML constitueix un llenguatge estndard per a crear modelsvisuals de programari. Tamb veurem una petita introducci al llenguatge imostrarem els diferents tipus de diagrames que suporta.

A continuaci veurem com podem fer servir UML per a complementar les es-pecificacions textuals de casos d's. Veurem el diagrama de casos d's, que re-presenta de manera visual els casos d's, els actors i les relacions entre aquests,i el diagrama d'activitats, que permet modelitzar visualment el comportamentd'un cas d's com si fos un procs.

Els casos d's que haurem vist fins a aquest punt no estan encara enllaatsamb una interfcie grfica d'usuari. El pas segent ser, per tant, crear unmodel d'aquesta interfcie, que ens permetr resoldre dubtes d'usabilitat od'arquitectura de la informaci, entre altres.

Finalment veurem com podem fer modelitzaci del domini fent servir UML.El model del domini ser una representaci de les classes conceptuals del mnreal en el domini del sistema que estudiem.

Al llarg de tot el mdul farem servir, com a fil conductor, exemples basats,tots, en un mateix sistema: una universitat que vol oferir un campus virtualper als seus alumnes i professors.


Objectius

Els objectius que l'estudiant ha d'haver assolit una vegada treballats els con-tinguts d'aquest mdul sn:

1. Saber fer servir l'orientaci a objectes per a fer anlisi de programari pera sistemes d'informaci.

2. Saber fer servir la notaci UML per a documentar models d'anlisi orientatsa objectes.

3. Saber fer servir els casos d's per a fer anlisi funcional de programari pera sistemes d'informaci.

4. Saber fer servir els diagrames d'activitats per a documentar detalladamentels casos d's complexos com a processos.

5. Saber modelitzar la interfcie grfica d'usuari del programari mitjanantcasos d's concrets, esbossos de les pantalles i mapes navegacionals.

6. Saber fer modelitzaci del domini mitjanant diagrames de classes UML.


1. Anlisi orientada a objectes amb UML

1.1. Anlisi orientada a objectes

L'orientaci a objectes va nixer com una eina de programaci en qu els pro-gramadors construeixen una abstracci del problema que estan mirant de re-soldre en lloc de construir una abstracci de l'ordinador. Els programadors quefan servir orientaci a objectes, per tant, creen classes de programari que re-presenten aquells conceptes del mn real que sn rellevants al sistema.

A mesura que l'orientaci a objectes va guanyar terreny, els analistes es vanadonar que podia ser una eina molt til per a construir els seus modelsd'anlisi. A ms, resultava molt til fer servir models deliberadament sem-blants al programari que es construeix, ja que expressar l'anlisi en termes f-cilment traslladables a programari orientat a objectes facilita no solament latasca de disseny i programaci sin tamb el canvi, l'extensi i el manteni-ment del programari un cop desenvolupat.

1.2. El llenguatge UML

1.2.1. Motivaci del llenguatge UML

El llenguatge UML s el llenguatge estndard per a crear models visualsde programari.

Com a tal, UML s un llenguatge de propsit general (intenta cobrir tots elspossibles models de tots els tipus de programari) i visual (els models es repre-senten, principalment, en forma de diagrames).

Un dels motius de l'xit del llenguatge UML s que s independent del mtodede desenvolupament emprat. Aix doncs, diferents mtodes de desenvolupa-ment utilitzaran de manera diferent els diagrames proposats per UML.

Com a llenguatge, la utilitat principal de l'UML s permetre la comunicaci.L'adopci per part de tota la indstria d'un mateix llenguatge permet que tot-hom pugui entendre els models creats per una altra persona o equip i, per tant,que es puguin discutir les propietats d'un sistema a partir dels models.

Vegeu tamb

L'orientaci a objectess'estudia al mdul "Orientacia objectes".


Segons Fowler (2004) podem distingir tres usos principals per al llenguatgeUML:

Comallenguatgeperaferuncroquis. Es tracta de fer un s informal(normalment dibuixant a m alada) per tal d'explicar o explorar algunaspecte en concret d'un sistema informtic. La clau aqu s la selectivitat:noms tenim en compte els detalls que sn rellevants per a la discussique estem duent a terme en aquest moment i obviem la resta. D'aquestamanera, aconseguim maximitzar la relaci entre l'esfor dedicat a la crea-ci dels models i la utilitat obtinguda en canvi.

Comallenguatgeperaferunplnol. Construir models ms detallatsque ens permetin documentar el sistema amb prou detall per a facilitar-nela implementaci (fins i tot amb generaci automtica de codi) o per acapturar de manera visual els detalls sobre l'estructura i comportamentd'un sistema existent (enginyeria inversa). La idea s poder aconseguir queun dissenyador cre els plnols del sistema i que, ms endavant, els pro-gramadors noms hagin d'escriure el codi, per no prendre decisions sobrecom ha de ser el sistema per desenvolupar.

Comallenguatgedeprogramaci. Aquest seria el cas de les eines MDA.Es tracta de crear models tan detallats del sistema que el codi que es puguigenerar de manera automatitzada no hagi de ser modificat (ni tan sols lle-git) pels desenvolupadors. Aquest s un camp en qu, actualment, s'estanfent molts esforos de recerca.

Una altra manera de caracteritzar l's de l'UML s tenint en compte qu es volmodelitzar. Segons Fowler (2004) podem distingir entre dues perspectives:

Perspectivaconceptual. El model representa una descripci dels concep-tes del domini que estem estudiant.

Perspectivadeprogramari. El model representa el sistema informtic i,per tant, hi ha una correspondncia directa entre els elements del modeli les parts del sistema.

A l'hora d'estudiar el llenguatge UML caldr decidir quin s en voldrem fer sotaaquestes dues classificacions, ja que en funci de la necessitat que tinguem,farem servir l'UML d'una o altra manera.

Pel que fa a la primera classificaci, la majoria dels models que crearem serancroquis del que seria un sistema real. Aix ens permetr centrar-nos en elsaspectes didctics dels models sense haver-nos de preocupar pels detalls delsistema real. D'altra banda, aix tamb ens permetr no haver de dependre decap eina CASE en concret.

Vegeu tamb

Podeu trobar ms informacisobre MDA al mdul "Intro-ducci a l'enginyeria del pro-gramari".


Pel que fa a la segona classificaci, durant l'anlisi ens situarem en la perspec-tiva conceptual. Els models que fem fan referncia als conceptes del dominique estem analitzant (l'espai del problema), per no al programari en si mateix(l'espai de la soluci).

1.2.2. Origen del llenguatge UML

Per a comprendre el valor (i alguns dels defectes) de l'UML s important coni-xer el seu origen. Abans de la publicaci de l'UML cada mtode de desenvo-lupament utilitzava la seva prpia notaci. Aix era un problema, ja que difi-cultava enormement la comunicaci entre enginyers de programari.

Part del problema era que, mentre que totes les notacions eren ms o menyssimilars, hi havia multitud de detalls que canviaven d'una a l'altra, la qualcosa feia encara ms complicada la comunicaci. Tot i que hi va haver algunsesforos d'estandarditzaci, la reacci per part dels metodlegs no va ser gairepositiva.

Aquesta situaci va comenar a canviar quan Jim Rumbaugh va passar a tre-ballar, juntament amb Grady Booch, a la companyia Rational, en la creacidel mtodeunificat. Ms endavant, Ivar Jacobson es va unir a la companyiai, entre els tres, van assentar les bases del que seria el llenguatge UML.

Durant la segona meitat de la dcada dels noranta va tenir llocl'estandarditzaci, per mitj de l'OMG, del llenguatge UML. D'aquesta manera,UML deixava de ser un producte d'una sola companyia (Rational) per a passara ser un estndard obert que qualsevol altra companyia podia implementar.

Aquest procs d'estandarditzaci va ser clau perqu s'incorpors la feinad'altres metodlegs i es pogus arribar a un estndard que tota la indstria ac-cepts. Com a contrapartida, tenim un estndard que, de vegades, pot semblaruna mica inconsistent, ja que incorpora elements amb orgens molt diferents.

1.2.3. Tipus de diagrames UML

La versi 2 d'UML defineix 13 tipus de diagrama. A continuaci veurem unexemple de cada tipus de diagrama. La idea no s estudiar els diagrames endetall sin fer-nos una idea general del seu aspecte visual i la seva utilitat.

El diagramadecasosd's (use case diagram) serveix per a modelitzar quinssn els casos d's del sistema i quins sn els actors que hi estan relacionats.


El diagrama de classes (class diagram) s, probablement, el diagrama msconegut de l'UML. Serveix per a modelitzar les classes d'objectes i les sevesrelacions, fent mfasi en els aspectes estructurals ms que no pas en el com-portament.

La versi 2 del llenguatge UML va oficialitzar per primer cop el diagramad'objectes (object diagram). Aquest s un diagrama similar al de classes en quel que representem no sn classes sin intncies de classe (objectes).


El diagramadepaquets (package diagram) ens permet modelitzar les depen-dncies entre paquets. Un paquet s un grup d'elements UML com ara classes ocasos d's. Per tant, podem fer servir la notaci de paquets en altres diagrames.Aix doncs, un paquet d'un diagrama de paquets pot representar un subsiste-ma, un grup de classes, o qualsevol altra agrupaci d'elements. Al diagrama depaquets mostrarem els paquets i les dependncies entre aquests.

El diagramadecomunicaci (communication diagram) (anomenat diagramade collaboraci a la versi 1 d'UML) ens permet modelitzar la interacci en-tre diversos objectes fent mfasi en l'aspecte estructural (quins objectes estan"connectats" a quins altres i hi collaboren).

El diagramadeseqncia (sequence diagram) s similar al de comunicaci enel sentit que modelitza el mateix (la interacci entre diversos objectes) per,en aquest cas, fent mfasi en la seqncia temporal.


El diagramad'activitats (activity diagram) s'utilitza, habitualment, per a des-criure processos de manera similar als diagrames flow-chart.

Els dos diagrames anteriors (seqncia i activitats) els podem combinar enun diagramadevisigenerald'interacci (interaction overview diagram). Elpodem veure com un diagrama d'activitats en qu hem substitut les activitatsper diagrames de seqncia. Aquest s un tipus de diagrama que va introduirper primer cop la versi 2 d'UML i no est tan difs com els altres.


El diagramad'estats (state machine diagram) modelitza estats i transicions. Laidea del diagrama d'estats s modelitzar com afecten a un objecte els diferentsesdeveniments que poden tenir lloc al sistema

El diagramadecomponents (component diagram) modelitza els diferents com-ponents que formen part del nostre sistema i les interfcies que fan servir pera comunicar-se entre si.

El diagramad'estructuracomposta (composite structure diagram) ens permetmodelitzar l'estructura interna en temps d'execuci d'una classe o component.


El diagramadedesplegament (deployment diagram) modelitza la distribucifsica, en temps d'execuci, dels diferents artefactes de programari.

El diagrama de temps (timing diagram) s molt habitual en el mn del'electrnica i, a partir de la seva versi 2, forma part del conjunt de diagramesestndard d'UML, tot i que la seva aplicabilitat al desenvolupament del pro-gramari es limita a casos molt concrets, com ara el programari de temps real.

1.3. Exemple

Al llarg d'aquest mdul farem servir un exemple de domini que anirem desen-volupant en petits exemples al llarg del mdul.

Prendrem com a exemple una universitat per a la qual volem desenvoluparun sistema d'informaci que gestioni la informaci dels cursos impartits, lesmatrcules dels estudiants i les activitats que fan, incloent-hi les qualificacions.

La universitat t un seguit d'assignatures, per a cadascuna de les qualss'imarteix una edici (que tamb anomenem curs) cada semestre. Per a cadacurs d'una assignatura es creen un seguit de grups, cadascun dels quals t unprofessor i una srie d'alumnes matriculats.

Alguns cursos sn presencials i, per a aquests, volem saber l'horari setmanal i,per a cada franja horria del curs, l'aula on s'imparteix. Les aules estan situadesen edificis que, alhora, pertanyen a un determinat campus.

Programari de temps real

El programari de temps real saquell que es fa servir en siste-mes en qu hi ha restriccionsde temps real, s a dir, hi haun lmit de temps entre que esprodueix un esdeveniment ique el sistema hi dna respos-ta.


Hi ha, tamb, un campus virtual, on cada grup disposa d'un tauler una bstiade missatges on el professor pot escriure per els alumnes noms poden llegiri un frum una bstia de missatges on tant el professor com els alumnespoden participar. Els missatges, dins el tauler o frum, es poden agrupar percarpetes.

Els professors proposen, cada curs, unes activitats comunes a tots els grups del'assignatura com ara exmens o prctiques. La qualificaci de cada alumneen una assignatura es calcular a partir de les qualificacions que tregui a cadaactivitat entregada.


2. Model de casos d's

Anteriorment hem vist la tcnica dels casos d's per a la documentaci derequisits. Tamb hem vist que la notaci ms habitual per a documentar elscasos d's s la documentaci textual. En aquest apartat veurem com podemutilitzar el llenguatge UML per a complementar la documentaci dels casosd's mitjanant diagrames.

2.1. El diagrama de casos d's

El primer diagrama que veurem s el diagrama de casos d's. La notaci deldiagrama s molt senzilla; de fet, a continuaci veurem un exemple d'aquestdiagrama on s'utilitza tota la notaci que necessitarem en aquest mdul.

Cal fixar-se, per, que aquest diagrama no cont informaci sobre quin s elcomportament del sistema (per exemple, qu passa si un estudiant intentalliurar una activitat fora de termini).

Vegeu tamb

Hem vist la tcnica dels casosd's per a la documentaci derequisits al mdul "Requisits".

El diagrama de casos d's complementa, per en cap cas no substitueix,la descripci textual dels casos d's, ja que no inclou informaci sobrequin s el comportament del sistema.

Quina s, doncs, la utilitat d'aquest diagrama? Per una banda, ens permet re-lacionar visualment els actors i els casos d's i, per l'altra, ens dna una visirpida de quina s la funcionalitat que el sistema ofereix als diferents actors.

Vegeu tamb

Podeu trobar ms informacisobre els casos d's i la sevaespecificaci textual al mdul"Requisits".


2.1.1. Actors

Al diagrama d'exemple podem veure tres actors: "Estudiant", "Professor" i"Membre aula", que es representen amb una mena de ninot. Aix s perqu,habitualment, els actors seran persones (els usuaris del sistema) tot i que, finsi tot en el cas en qu un actor sigui un sistema extern, el representarem ambel mateix smbol.

La fletxa que va d'Estudiant a Membre aula (i la que va de Professor a Membreaula) significa que aquest actor s una especialitzaci de l'actor Membre aula.A efectes prctics, aix vol dir que tot el que es diu sobre l'actor Membre aulas aplicable a l'actor Estudiant (i tamb a l'actor Professor).

L'avantatge de l's de la relaci de generalitzaci/especialitzaci entre actorss que ens permet simplificar el diagrama, ja que elimina la necessitat de re-presentar per repetit all que s com a ms d'un actor (com ara les seves re-lacions amb els casos d's). Aix, a l'exemple, no ens cal representar la relacid'estudiants i professors amb el cas d's "Consultar el calendari de lliuraments",ja que l'hem representada a l'actor ms general.

2.1.2. La frontera del sistema

El requadre amb l'etiqueta "Lliurament exercicis" representa la frontera del sis-tema: tot el que queda dintre del requadre forma part del sistema, mentre quetot el que queda fora del requadre (en aquest cas, els actors) no en forma part.

L'etiqueta ens pot ajudar a aclarir l'mbit dels casos d's: quin sistema o sub-sistema estem tenint en compte.

2.1.3. Els casos d's

Els casos d's es representen mitjanant ellipses que inclouen un text: el nomdel cas d's. D'aquesta manera podem relacionar els casos d's que apareixenal diagrama amb els casos d's que apareixen a la documentaci dels requisits.

Per a facilitar la comprensibilitat del diagrama, s molt convenient evitar bar-rejar casos d's de nivell d'abstracci diferent al mateix diagrama. Per exemple,al nostre diagrama d'exemple, tots els casos d's (menys "Adjuntar arxiu", delqual parlarem ms endavant) sn del mateix nivell (usuari).

Si volem representar grficament els casos d's en qu es descompon un altrecas d's, sempre ho podem fer en un diagrama a part.


2.1.4. Relacions entre casos d's i actors

Les lnies que veiem entre els casos d's i els actors indiquen que hi ha algunarelaci entre aquests. Un actor pot estar relacionat amb un cas d's perqu ensigui l'actor principal o b perqu en sigui un actor de suport.

En el nostre exemple, podem veure que qualsevol membre de l'aula (i aixinclou els estudiants i els professors) pot consultar el calendari de lliuraments,que els estudiants poden lliurar una activitat o b lliurar una versi nova d'unaactivitat i que els professors poden corregir una activitat o publicar un enun-ciat.

2.1.5. Relacions entre casos d's: inclusi

Al diagrama d'exemple podem veure una relaci d'inclusi entre els casos d's"Lliurar una activitat" i "Adjuntar arxiu" i una altra entre "Publicar enunciat" i,de nou, "Adjuntar arxiu". La manera de llegir aquesta relaci s, per exemple,que "Lliurar una activitat" inclou "Adjuntar arxiu", tal com indica el sentit dela fletxa.

Com ja hem vist, les relacions d'inclusi, sovint, es donen entre casos d's dediferent nivell. Tenint en compte el que hem dit anteriorment sobre barrejarcasos d's de diferent nivell al mateix diagrama, s discutible la conveninciade mostrar el cas d's al mateix diagrama que la resta, ja que la presncia delcas d's al diagrama pot confondre ms que no pas ajudar els seus destinataris.

Un error molt habitual s intentar representar el flux d'esdeveniment del casd's fent servir relacions d'inclusi per a descompondre'l en objectius ms con-crets:


El problema amb aquest tipus de descomposici s que es corre el riscd'intentar substituir la descripci textual, cosa que no es pot fer, ja que s msdifcil de llegir i entendre i, alhora, no aporta tota la informaci que contla descripci. Per exemple, no tenim cap manera d'indicar la seqncia delsesdeveniments ni de relacionar l'escenari principal amb les extensions: primeradjuntem un arxiu i desprs seleccionem l'activitat o a l'inrevs?

El primer que cal tenir en compte s que el diagrama de casos d's no mostra laseqncia d'esdeveniments d'un cas d's; la distribuci a l'espai dels casos d'sno t cap significat i no implica, per tant, que un cas d's vagi abans de l'altre.

A ms, per assegurar-nos que els diagrames sn fcils d'entendre, no hauremde tenir grans diferncies pel que fa al nivell dels seus objectius. Cal evitarcasos, doncs, com el de l'exemple en qu tenim, per exemple, un cas d's denivell d'usuari "Lliurar una activitat" i els casos d's a escala de subtasca "Esco-llir aula" i "Escollir activitat".

En tot cas, si ho considerem necessari, sempre podem fer servir ms d'un di-agrama i agrupar aix els casos d's segons el criteri que considerem ms adi-ent. D'altra banda, tamb cal tenir en compte que un cas d's pot aparixer enms d'un diagrama sense que aix impliqui cap duplicitat, ja que la descripcitextual noms ser en un lloc.

En aquest cas hem creat dos diagrames. En el primer hem agrupat els casos d'spel nivell del seu objectiu mostrant noms els de nivell usuari. En el segon, encanvi, ens centrem en la descomposici d'un cas d's i mostrem, per tant, elcas d's i els de nivell immediatament inferior al seu que hi estan relacionats.Podrem fer un tercer diagrama que mostri la descomposici de "Respondre aun company del frum", un altre per a "Seleccionar activitat", etc.

2.1.6. Relacions entre casos d's: extensi

A l'exemple inicial podem trobar un exemple d'extensi entre els casos d's"Lliurar una activitat" i "Lliurar una versi nova d'una activitat". En aquest cas,el sentit de la fletxa ens indica que "Lliurar una versi nova d'una activitat" suna extensi de "Lliurar una activitat".


Com hem vist anteriorment, aquesta relaci es fa servir poc. Habitualment, enlloc de crear un nou cas d's "Lliurar una nova versi d'una activitat" hauremafegit aquesta extensi al cas d's "Lliurar una activitat" modificant-ne, pertant, la descripci textual.

Opcionalment, UML permet indicar l'anomenat punt d'extensi, que s un textque identifica en quin punt de l'escenari principal es produeix l'esdevenimentque provoca el comportament alternatiu: d'aquesta manera podem identificarel punt on s'inicia el nou comportament sense necessitat de fer referncia a unnmero de pas concret, facilitant aix el manteniment del model de requisits.El problema, per, s que s necessari identificar, a priori, tots els possiblespunts d'extensi del cas d's i, per aix, s una prctica en dess.

2.2. El diagrama d'activitats

El diagrama d'activitats combina diferents idees del mn de la modelitzacide processos i, per tant, ens pot ajudar a documentar el comportament delsistema si el veiem com un procs. La modelitzaci d'activitats fa mfasi en laseqncia i la coordinaci de les possibles accions per documentar ms queno pas en qui s responsable d'executar-les.

L'element bsic d'aquest diagrama s l'activitat, que representa el fet que algfa quelcom. L'altre element bsic sn les transicions o fluxos, que representenel fet que es passa d'una activitat a la segent. A continuaci, tenim un dia-grama d'activitats molt senzill per al cas d's "Lliurar una activitat".


En aquest cas, cada pas del cas d's l'hem representat com una activitat i lesdiferents transicions ens donen una idea sobre quina s la seqncia en laqual tenen lloc les diferents activitats. S'acostuma a facilitar la lectura de laseqncia, indicant-ne l'inici i el final:

En aquest exemple podem veure fcilment que el procs comena per "Escolliraula", tal com indica el punt negre, i el final es produeix desprs de "Confir-mar", tal com indica la transici cap al punt negre dins un cercle. Tot i que,en aquest cas, noms n'hi ha un, podem posar tants smbols de final com vul-guem al nostre diagrama.

2.2.1. Lgica condicional

Un dels avantatges del diagrama d'activitats s que podem representar la lgicacondicional que ens porta a l'execuci dels diferents escenaris. Aix doncs,continuant amb el cas anterior, podrem fer el diagrama segent:

En aquest diagrama hem introdut un nou element de notaci, la condici,tamb anomenada condici de guarda, que es representa mitjanant el text en-tre claudtors a la transici. La condici existeix lliurament previ ens indica queaquesta transici noms es produeix quan la condici s certa. Per tant, "Es-collir activitat" t dues transicions possibles: una es produeix quan hi ha unlliurament previ i l'altra quan no s aix.

Si volem fer ms explcit el punt en qu hi ha una presa de decisi, el podemrepresentar mitjanant l'element grfic de decisi, que es representa com unrombe:


La decisi t un flux d'entrada i diversos fluxos de sortida, cadascun amb unacondici. Noms un dels fluxos de sortida (aquell per al qual la condici escompleixi) ser el que es prengui en un escenari concret. Per aix, les diferentscondicions haurien de ser mtuament excloents.

Un altre element condicional que podem fer servir s la fusi (Merge), que esrepresenta com un rombe (igual que la decisi) per que t diversos fluxosd'entrada i noms un de sortida, que es prendr quan s'arribi per algun delsfluxos d'entrada:

Com hem vist, les decisions i fusions sn elements opcionals que ens permetenfer mfasi en la lgica condicional. Habitualment, per, noms farem servir,amb aquest propsit, les decisions.

2.2.2. Parallelitzaci

Amb els elements de lgica condicional, els diferents camins sn excloents: Ob se'n pren un o b es pren l'altre, per sempre hi ha un nic cam (i, per tant,una nica activitat) executant-se en un moment concret. De vegades, per, enspot interessar poder indicar que dos camins s'executen de manera parallela:


En aquest exemple, un cop s'ha fet la proposta de matrcula, s'inicien dos flu-xos parallels: un que comprova la compatibilitat amb el pla d'estudis i un altreque comprova que el pagament es faci correctament. Tots dos s'executen enparallel, ja que no cal esperar que un acabi per a comenar l'altre. La primeralnia gruixuda del diagrama s un exemple de bifurcaci (fork); cada bifurcacit un flux d'entrada i diversos fluxos de sortida.

L'element contrari a la bifurcaci s la uni (join). Aquest element (l'altra barragruixuda) t diversos fluxos d'entrada i un de sortida que, a diferncia de lafusi, no s'executa fins que no s'han executat tots els fluxos d'entrada.

Aix doncs, en el nostre exemple, no es confirma la matrcula fins que no s'havalidat la compatibilitat amb el pla d'estudis i s'ha validat el pagament.

2.2.3. Organitzaci: carrils

Finalment, hi ha un element de notaci que ens pot ajudar a organitzar lesactivitats. Els carrils (swimlanes) es fan servir, tpicament, per a indicar quinesactivitats fa cadascun dels actors del procs (o, en el nostre cas, del cas d's)que estem documentant. S'indiquen, grficament, de la manera segent:


En aquest cas, veiem que l'alumne s el responsable de fer la proposta de ma-trcula, el tutor de validar-ne la compatibilitat amb el pla d'estudis i el depar-tament d'administraci de validar-ne el pagament i confirmar-la.

2.2.4. Altres elements de notaci

El diagrama d'activitats suporta altres elements de notaci (com, per exemple,els senyals o les subactivitats) que no veurem en aquest mdul, ja que servei-xen per a modelitzar comportaments ms complexos que els que trobem tpi-cament en un cas d's.

2.3. El model resultant

El model de casos d's resultant ha de contenir una especificaci basada encasos d's especificats textualment, tal com es va explicar al mdul "Requisits".Aquesta es complementar amb els diagrames UML que siguin oportuns pera ajudar a comprendre el model.

A continuaci veurem un exemple del model de casos d's resultant per al'exemple de les universitats. Per brevetat, ens centrarem, per, en noms doscasos d's del sistema.


El diagrama de casos d's mostra visualment els actors, els casos d's, les re-lacions de generalitzaci/especialitzaci entre casos d's, quins actors interve-nen en cada cas d's i, si n'hi ha, les relacions entre casos d's. En el nostreredut exemple, mostraria els dos casos d's:

Com s'ha comentat, per, els diagrames de casos d's noms complementenl'especificaci textual d'aquests, que tamb ha de formar part del model decasos d's.


En alguns casos, ens pot interessar documentar un o ms casos d's vistos coma processos. Els diagrames d'activitats ens permetran mostrar visualment laseqncia de passos que fan els actors, la lgica condicional, el parallelisme, sin'hi ha, i, fins i tot, com diferents actors intervenen en un mateix cas d's (enforma de carrils). Al nostre exemple podrem documentar els dos casos d'smitjanant un diagrama d'activitats:


En realitat, per, noms val la pena crear un diagrama d'activitats quan es voldocumentar com a procs un cas d's (o un conjunt de casos d's) ms complexque els d'aquest exemple. De fet, la majoria de casos d's de nivell d'usuarisn prou simples per a no necessitar cap diagrama que els complementi. Altrescasos d's, per, especialment alguns de nivell d'organitzaci, poden ser mscomplexos i fer-se ms comprensibles si els complementem amb un diagramad'activitats.


3. Modelitzaci de la interfcie

El model de casos d's que hem vist fins ara se centra a recollir els objectiusdels actors envers el sistema. Per aquest motiu, no hem incls, en cap mo-ment, detalls sobre la interfcie d'usuari (no volem que els detalls de la inter-fcie d'usuari ens distreguin del que ens interessa: els objectius dels actors).

D'altra banda, tenim tota una srie de requisits, com ara la usabilitat ol'arquitectura d'informaci que, en ser els casos d's independents de la inter-fcie d'usuari, no queden recollits en aquest model.

Necessitem, per tant, un altre model que ens documenti, abans de dissenyarla interfcie d'usuari, aquests requisits, i que ens ajudi a entendre com els di-ferents usuaris del sistema hi interactuaran.

Aquest model de la interfcie d'usuari ens ha de donar indicacions sobre elsegent:

De quina manera el sistema presenta la informaci als usuaris (mitjanantuna interfcie grfica, un sistema de veu, etc.).

Com navega l'usuari a travs de la informaci que li mostra el sistema pertal d'aconseguir els seus objectius.

Com es relaciona el comportament indicat al model de casos d's amb lainterfcie d'usuari.

3.1. Casos d's concrets

S'anomenen casosd'sessencials els casos d's que descriuen la in-teracci entre actors i sistema de manera independent de la tecnologiai de la implementaci. En contraposici, anomenarem casosd'scon-crets aquells que tenen en compte la tecnologia i la implementaci.

Aix doncs, a partir d'un mateix model de casos d's essencials, s possiblearribar a diversos models de casos d's concrets, segons quina sigui la tecno-logia que utilitzem per a la interfcie amb els usuaris i quin sigui l'intercanvid'informaci entre usuaris i sistema. En endavant, suposarem que el sistemaper desenvolupar es comunica amb els seus usuaris mitjanant una interfciegrfica basada en pantalles.

Per a decidir el contingut de les diferents pantalles s'ha de tenir en comptel'opini de diversos especialistes. A continuaci en descrivim alguns:


Especialistaeninteracci. La seva finalitat s aconseguir que els usuarisdel sistema aconsegueixin complir els seus objectius. Per a fer-ho, estudiales diferents tasques per a aconseguir un objectiu concret (per exemple,qu cal fer per a matricular un alumne a la universitat) i la manera en ques duen a terme.

Especialista en usabilitat. Aplica el mtode cientfic a l'estudi il'observaci de la manera en qu els usuaris fan servir el sistema per tal defer que l's sigui cmode i intutiu.

Arquitected'informaci. S'encarrega d'organitzar la informaci de ma-nera que sigui fcil de trobar i d'utilitzar. Per exemple, s l'encarregatd'assegurar-se que els estudiants poden accedir rpidament al frum de laseva aula i que no han de navegar per un munt de pantalles abans d'arribar-hi.

Aix doncs, podem escriure una versi concreta (sense tenir en compte lespossibles extensions) del cas d's "Llegir un missatge del frum".

3.2. Models de les pantalles

Una tcnica molt til en aquesta fase s crear models de les pantalles. Els mo-dels de les pantalles ens ajuden a fer-nos una idea de com ser la interfciegrfica d'usuari final sense necessitat de preocupar-nos dels detalls concretsdel disseny grfic (colors, tipus de lletra, etc.).


Els models de les pantalles se centren en els conceptes per mostrar i enl'estructura de la pantalla ms que no pas en com ser finalment. Per exemple,no es tenen compte els colors, ni els elements exactes d'interfcie grfica que esfaran servir. Per aix moltes vegades es fan, fins i tot, manualment (o simulantun dibuix a m alada).

Aquests models ens ajuden a explorar possibles models d'interacci id'organitzaci de la informaci i tamb a detectar requisits sobre quina infor-maci cal mostrar a cada pantalla.

L'objectiu, doncs, dels models de les pantalles s deixar clar:

Quina informaci es mostra.

La distribuci de la informaci a la pantalla.

Quines accions pot prendre l'usuari a partir de la informaci mostrada.

Quin s el procs que segueix l'usuari per a completar el cas d's.

3.2.1. Diagrama d'estat de les pantalles (mapa navegacional)

El mapa navegacional s un model que ens dna informaci sobre quins el flux entre pantalles que pot seguir l'usuari. Aix doncs, la finalitatdel mapa navegacional s donar una visi general de quines accions espoden fer a cada pantalla i en quins casos es passa d'una pantalla a unaaltra.

Per a fer el model del mapa navegacional podem fer servir una versi moltsimplificada del diagrama d'estats UML:


El diagrama d'estats UML s molt similar al d'activitats i, per tant, s molt fcilentendre'n la notaci. Els estats representen les diferents pantalles (i el puntnegre indica l'estat inicial) i les fletxes representen esdeveniments als quals elsistema ha de reaccionar.

Al diagrama de l'exemple, hi ha dues pantalles (Llista de Missatges i MostrarMissatge) i tres esdeveniments:

seleccionarCarpeta(nomCarpeta) a Llista de Missatges seleccionarMissatge(posicioMissatge) a Mostrar Missatge seleccionarCarpeta(nomCarpeta) a Llista de Missatges

Com podem veure, el mapa navegacional ens dna una visi molt resumidade la interacci entre l'usuari i el sistema, ja que ens diu quina informaciaporta l'usuari al sistema (el nom de la carpeta o la posici del missatge).

3.3. Contractes de les operacions del sistema

En el cas que necessitem elaborar una documentaci formal dels requisits delsistema, els models vistos fins ara no seran suficients, ja que no formalitzenquin s el comportament del sistema davant de cada esdeveniment; nomsindiquen quina transici de pantalles es produeix.

Si necessitem aquest nivell de formalisme, podem fer servir operacions o es-deveniments de sistema. El que fem en aquest cas s identificar operacions apartir dels esdeveniments del mapa navegacional i escriure, en un llenguatgems o menys formal, un contracte que estableixi quin s el comportament delsistema quan es crida aquesta operaci.

Un contracte consta de tres parts:

Lasignatura. Ens diu el nom de l'operaci, la informaci que rep d'aquellque la crida (els parmetres d'entrada) i la informaci que es retorna a quiha cridat l'operaci (els parmetres de sortida o el resultat).


Lesprecondicions. Les obligacions que ha de complir aquell qui cridal'operaci per tal que el sistema executi correctament l'operaci. En el casque aquestes precondicions no es compleixin, suposarem que el sistemarebutja l'esdeveniment i que no es produeix cap canvi.

Lespostcondicions. Les obligacions a qu es compromet el sistema quans'invoca l'operaci. Sn condicions que el sistema es compromet que si-guin certes un cop executada l'operaci.

Exemple de contracte

obtenirNombreMissatgesCarpeta(nomCarpeta:String):Integer

pre: el nom de la carpeta es correspon a una carpeta del frum

post: el resultat s el nombre de missatges que hi ha a la carpeta amb independncia desi s'han llegit o no

Aquest senzill exemple ens permet veure com el contracte documenta:

El nom de l'operaci (obtenirNombreMissatgesCarpeta). La informaci que aporta l'usuari (nomCarpeta de tipus String, s a dir,

un text). La informaci que retornar el sistema (en aquest cas, un nombre enter). Les obligacions de l'usuari (donar un nom de carpeta que existeixi). Les obligacions del sistema (calcular el nombre de missatges de la carpeta

i retornar-lo).

Com ja hem mencionat, podem escriure els contractes fent servir un llenguat-

ge ms formal, com ara OCL1, el llenguatge estndard de restriccions d'UML.

Exemple de contracte en OCL

context System::obtenirNombreMissatgesCarpeta(nomCarpeta:String):Integer

pre: Carpeta.allInstances()->exists(c|c.nom=nomCarpeta)

post: result = Carpeta.allInstances()->select(c|c.nom=nomCarpeta).missatge->size()

(1)OCL sn les sigles d'object cons-traint language, en catal, llenguat-ge de restriccions d'objectes.


4. Model del domini

Un model del domini s una representaci de classes conceptuals del mn realen un domini d'inters. Aquest model ha de servir a les persones que interve-nen en el desenvolupament de programari per a entendre millor el domini delsistema que han de desenvolupar.

Per a documentar un model del domini en UML es faran servir un o ms dia-grames de classes, mitjanant els quals es representaran les classes conceptuals(o classes del domini), els seus atributs i les seves associacions.

4.1. Convencions en els diagrames UML

Abans de comenar amb la descripci dels diagrames del model conceptual,establirem algunes convencions que farem servir pel que fa al nom de classes,atributs i associacions.

UML no posa cap restricci respecte de quins noms sn vlids i quins no pernormalment preferim fer servir noms que ms endavant, quan es passi a fertasques de disseny i de programaci, es puguin conservar. D'altra banda, seguiruna determinada convenci de noms ajuda a donar coherncia al conjuntd'artefactes que elaborem durant el desenvolupament de programari.

Per aquesta ra, en aquests materials seguirem les convencions segents:

Farem servir noms en minscules en general. Per a les classes, les associa-cions i els tipus dels atributs, la primera lletra estar en majscula, com sies tracts d'un nom propi.

Exemple

No farem servir noms de classe com ALUMNE o alumne sin Alumne. Els noms d'associaciseran com Enregistra o EsMatricula, i els dels tipus d'atribut seran com Integer o Boolean.

Els noms d'atribut seran en minscules, com ara nom o cognoms.

No farem servir noms que continguin espais, sin que separarem les pa-raules posant en majscula la primera lletra de cada paraula.

Exemple

Com a nom d'atribut farem servir, per exemple, dataNaixement en lloc de data de naixe-ment.

No farem servir carcters fora del rang d'ASCII, com ara els signes de pun-tuaci, els accents, la , etc.


Exemple

En lloc de data d'inscripci farem servir dataInscripcio.

4.2. Classes

4.2.1. Notaci UML

En UML una classe s'indica mitjanant una caixa amb tres compartiments, dosdels quals sn opcionals.

Representaci de les classes en el llenguatge UML

El primer compartiment s per al nom de la classe i s l'nic compartimentobligatori. El segon compartiment cont els atributs de la classe i, tot i ques opcional, en els models del domini el farem servir. El tercer compartimentcont les operacions i tamb s opcional; en aquest cas, per, no el farem servirals models del domini.

4.2.2. Tcniques de modelitzaci

Identificaci de classes del domini

Per a identificar classes del domini cal fer una llista d'aquells conceptes del'espai del problema que sn rellevants per al sistema que s'analitza.

Exemple

En l'exemple de partida de la universitat, ens diuen que la universitat ofereix un seguitd'assignatures de les quals s'imparteix una edici cada semestre.

Sabem, tamb, que per a cada edici d'una assignatura es creen grups, cadascun dels qualst un professor i una srie d'alumnes matriculats.

Alguns cursos sn presencials i, per a aquests, en volem saber l'horari setmanal i, per acada franja horria del curs, l'aula on s'imparteix. Les aules estan situades en edificis que,alhora, pertanyen a un determinat campus.


Hi ha un campus virtual on cada grup disposa d'un tauler i un frum que contenenmissatges agrupats per carpetes.

Els professors proposen activitats.

Una manera de completar la llista inicial de classes del domini s la tcnica,usada per diversos autors, de fer servir categories de classes conceptuals. Con-sisteix a repassar una llista de categories tpiques de classes per a identificarclasses d'aquella categoria que ens poden haver passat per alt.

Coad, Lefebvre i Luca (1999) proposen la llista de categories segent:

Participants,llocsicoses. Classes que representen persones o organitza-cions del domini (participants), llocs i coses. Els magatzems de qu disposauna empresa, els productes que ven o les persones que hi treballen o quehi compren materials, per exemple, pertanyen a aquesta categoria.

Exemple

En l'exemple de les universitats, les persones que hi intervenen (estudiants, professors iqualsevol altre personal implicat) sn exemples clars de participants.

D'altra banda, aules, edificis i campus sn exemples clars de llocs.

Rols. Classes que representen els rols que poden tenir les persones o or-ganitzacions en les activitats que es desenvolupen en el domini analitzat.Els rols de comprador o venedor que poden tenir les persones en moltsnegocis sn un bon exemple.


Exemple

En el nostre exemple els dos rols ms importants sn l'alumne i el professor, que ja havemidentificat.

Momentso intervals. Classes que representen moments en el temps ointervals de temps, com ara un lloguer, una venda, etc. Tot sovint, aquestsmoments o intervals tenen un conjunt de parts.

Exemple

En l'exemple de les universitats, les diverses edicions d'una assignatura ja identificadessn un exemple clar d'interval.

Descripcions. Classes que representen la tpica descripci de tipus catlegd'una certa "cosa", tpicament, un producte. Aix, per exemple, distingimun cotxe concret, que t la seva matrcula i nmero de bastidor, del modelde cotxe, que s una descripci de tipus catleg associada a aquell cotxeconcret.

Exemple

L'Assignatura es pot veure com una descripci de les diverses edicions que se'n fan, ja queens indica el nombre de crdits, que s el mateix per a totes les edicions d'una assignatura.

Larman (2005) proposa una llista de categories menys genrica:

Transaccions,lniesdetransacciiproductesoserveis: les transaccions,tpicament de negoci. Un exemple clssic sn les vendes d'un supermer-cat. Cada venda t un conjunt de lnies de venda en qu cada lnia t unproducte venut, un nombre d'unitats i un preu total de lnia.

Esdevenimentsimportants, sovint en una data o lloc que s rellevant,com per exemple un vol o un passi d'una pellcula.

Catlegsidescripcionsdecoses: les descripcions, en el mateix sentit queen parla Coad, es poden agrupar en catlegs.

Contenidorsfsicsolgicsielselementsquecontenen, com ara magat-zems i els productes que hi desem o un tauler d'escacs i les caselles quecont.

Exemple

En el nostre exemple, el campus i els edificis sn contenidors fsics d'altres llocs.

Sistemesexterns amb els quals interactuar el sistema que estem analit-zant.

Enregistraments de treballs, contractes, afers legals, etc., com ara els re-buts.


Exemple

En el nostre exemple, els estudiants pagaran la seva matrcula i tindrem un rebut d'aquestpagament.

Instruments financers com un xec, efectiu, etc. Agendes, manuals, documents, etc.

Exemple

En l'exemple, l'horari dels cursos presencials, que ja hem identificat com una classe, espot veure com una agenda.

La llista de categories de Larman inclou, a ms, un seguit de categories moltcoincidents amb la llista de Coad: llocs, objectes fsics i rols d'organitzacionsi persones.

Una altra tcnica til per a identificar classes del domini consisteix a reutilitzarmodels existents. Tot i que no podrem reutilitzar tal qual l'anlisi feta per aun sistema existent, ja que si pogussim fer-ho, probablement, no ens caldriadesenvolupar un sistema a mida nou, sin que podrem reutilitzar directamentel sistema existent, s que podem fer servir una anlisi existent com a punt departida per a identificar classes en el nostre model.

En aquest sentit, l'obra de Coad i altres (1999) proposa una srie de modelsgenrics que poden ser tils com a punt de partida, i Fowler (1997) proposafer servir el concepte de patr per a documentar patrons d'anlisi que podemaplicar adaptant-los al domini concret que estem analitzant.

Nomenclatura de les classes

A l'hora de donar nom a les classes del domini que s'identifiquen conv teniren compte el que s'anomena la regladelcartgraf. Es tracta del segent:

Fer servir la terminologia que fan servir les persones i experts del dominique s'est modelitzant, igual que un cartgraf fa servir la toponmia localal lloc que est cartografiant.

Exemple

A l'exemple hem fet servir un nom de classe fora estrany, que no t res a veure amb el quefa servir la gent que treballa i estudia a la universitat d'exemple: ForumNomesLectura.Conv, doncs, que ens fixem en la nomenclatura que fa servir la gent que estudia i treballaa la universitat per a la qual desenvolupem el projecte. En aquest cas, dels frums onnoms algunes persones autoritzades poden escriure, en diuen Taulers.

Vegeu tamb

Podeu trobar ms informa-ci sobre els patrons aplicatsa l'enginyeria del programa-ri al mdul "Introducci al'enginyeria del programari".


Excloure aspectes irrellevants del domini que estem analitzant igual queels cartgrafs fan una abstracci de la realitat i noms representen aquellstrets del terreny que interessen en un mapa.

Exemple

En el nostre cas, hem identificat una classe RebutMatricula que no s rellevant en elsistema que estem analitzant, ja que l'abast d'aquest sistema no inclou el pagament il'elaboraci de rebuts de les matrcules dels estudiants.

No afegir res que no sigui realment al domini que analitzem.

Errada freqent: classes de domini, no de programari

Cal tenir clar que l'objectiu del model del domini s documentar conceptesdel mn real, no classes de programari. Per tant, no tindrem classes que repre-sentin artefactes de programari com ara bases de dades, botons o finestres.

Per la mateixa ra, hi ha certs conceptes de l'orientaci a objectes que no faremservir quan fem anlisi. Aix, per exemple, no assignarem a les classes d'aquestmodel responsabilitats de comportament i no els assignarem operacions. Tam-poc no farem servir el concepte de visibilitat.

4.3. Atributs

4.3.1. Notaci UML

Dins la caixa que representa una classe, al compartiment dels atributs, cadaatribut s'indica textualment escrivint-ne el nom i, opcionalment, dos puntsseguits del tipus de l'atribut.

Exemples d'atributs

Els segents sn alguns exemples d'atributs:

nom: StringdataNaixement: Dataalada: Longitud


El llenguatge UML defineix un seguit de tipus primitius estndard que podemfer servir per a indicar els tipus dels atributs. Per, en general, podem fer serviraltres tipus d'atributs sempre que quedi prou clar, pel nom del tipus, a quens referim.

UML permet, opcionalment, indicar la multiplicitat d'un atribut afegint, des-prs del tipus, i entre claudtors, un indicador d'aquesta, que pot ser:

"0..1" per a indicar que un atribut s univaluat per opcional.

"1" per a indicar que un atribut s univaluat i obligatori. Aquesta opci sla que considerarem per defecte i, per tant, no indicarem aquesta multi-plicitat de manera explcita.

"*" per a atributs multivaluats ("1..*" si com a mnim han de tenir un valor).Una manera equivalent s indicar "0..*", per com que "*" s ms curt,farem servir aquesta segona manera.

Altres multiplicitats, com per exemple "3..5" (entre 3 i 5 valors).

Exemples d'atributs tenint en compte la seva multiplicitat

Els segents sn alguns exemples d'atributs tenint en compte la seva multiplicitat:

nom: String dataNaixement: Data [0..1] telefon: Telefon[1..*]

En el primer cas, com que no hem indicat cap multiplicitat, entenem que la multiplicitats 1; s a dir, que el nom s obligatori i univaluat.


Identificaci d'atributs

A mesura que anem identificant classes de domini, els podem anar afegintatributs que indiquin la informaci rellevant dels objectes d'aquella classe. Pera identificar de manera ms completa els possibles atributs d'una classe pot serinteressant repassar una llista dels tipus d'atributs ms freqents:

Nombres: sovint ens conv saber si es tracta de nombres naturals (enterspositius, que anomenarem Nat), enters (Int), o nombres no enters en ge-neral (Real).

Textos: Strings (cadenes de carcters sense format) i textos amb format.

Booleans: cert o fals, s o no.

Informacitemporal: com ara Data (1 de gener de 1980), Hora (12.43),Moment (1 de gener de 1980 a les 12.43), Durada (63 minuts)

Vegeu tamb

Al subapartat 4.3.2 es dnauna llista de tipus d'atributs t-pics que ens poden facilitar laidentificaci d'atributs en lesclasses del domini.

Multiplicitat d'un atribut

La multiplicitat d'un atribut in-dica quines cardinalitats snvlides per a aquell atribut; sa dir, quina restricci hi ha res-pecte al nombre de valors quepot tenir un atribut.


Quantitats: com ara Import (per exemple 23 ), Longitud (com ara 23,5m), Temperatura (15), Massa, etc.

Altresvalorssenseentitatprpia: Color (com ara el color RGB 70,0,130),Coordenades (com ara 4123'N 211'E), CodiPostal, NumeroTelefon, etc.

Exemple d'identificaci d'atributs

Desprs de parlar dels detalls amb els stakeholders, en el nostre exemple, hem identificatatributs a cada classe.

Les persones tenen nom, cognoms i DNI. Com que hi haur un campus virtual, ens diuenque tamb en volem tenir un text amb un petit currculum i una foto, i tamb una adreade correu electrnic de contacte.

Dels professors, en volem saber tamb la data de contractaci, i dels alumnes, la de nai-xement.

Les assignatures tenen un nom i un nombre de crdits. Cada semestre t l'any i el nmerode semestre en qu s'imparteix (primavera o tardor). De les edicions que es fan d'unaassignatura cada semestre, de moment, no en tenim atributs.

Els grups que t cada curs tenen un nmero.

Dels horaris, no en tenim cap atribut, per de les franges horries que els formen, s. Enun horari, una franja horria pot ser, per exemple, el dilluns a les 15 h o el dimecres ales 9 h. Suposarem que si en un horari hi ha dues hores seguides de classe, vol dir quehi ha dues franges horries.

Les aules, edificis i campus tenen tots un nom (Aula C, edifici Shakespeare, campus Llull,per exemple). Dels edificis, volem saber-ne l'adrea postal.

Atributs o associacions

Una edici correspon a la im-partici d'una assignatura enun semestre. Aleshores, perqu no posem els atributs as-signatura: Assignatura i semes-tre: Semestre a la classe Edicio?Ho veurem al subapartat 4.4.


De taulers i frums, no en tenim atributs.

Els missatges tenen un assumpte, un cos i una data i hora d'enviament. No tenen desti-natari perqu sn missatges enviats a un tauler o un frum, no missatges de correu elec-trnic. Les carpetes en qu s'organitzen els missatges tenen un nom.

Per a la data i hora d'enviament, en lloc de fer servir dosatributs separats, s'ha decidit fer servir un atribut que representiel moment exacte (data i hora) en qu es va enviar el missatge.

Les activitats de les assignatures tindran un ttol i una data d'entrega:

Atributs opcionals i atributs multivaluats

Per a la majoria d'atributs, caldr decidir, tan sols, si l'atribut s opcional o noho s. Per alguns atributs poden ser, a ms, multivaluats.

Exemples d'atributs opcionals i multivaluats

Suposem, per exemple, que les persones poden no indicar el seu currculum i poden notenir fotografia. I, a ms, que poden tenir mltiples adreces de correu electrnic, perque com a mnim n'han de tenir una:

D'altra banda, podem considerar que el cos d'un missatge s opcional perqu ambl'assumpte, de vegades, n'hi ha prou.


4.4. Associacions

4.4.1. Notaci UML

Una associaci, en UML, s'indica mitjanant una lnia contnua entreles dues classes associades, i pot incloure un nom, noms de rol i multi-plicitats, entre d'altres elements.

Notaci UML de les associacions

Els noms de rol de l'associaci indiquen el rol que t cada classe a l'associaci i,per tant, s una manera de referir-se a les instncies associades a una instnciades d'aquesta. Aix, a l'exemple de la figura, des de Grup, el professor associats'anomena responsable, mentre que des de Professor, el conjunt de grups quet associats s'anomena grups.

La multiplicitat dels extrems d'associaci s'indica fent servir la mateixa no-menclatura que la dels atributs. Tot i que UML considera, si no s'indica elcontrari, que la multiplicitat per defecte s 1, en aquests materials sempres'indicar explcitament la multiplicitat de cada extrem d'associaci.


Noms d'associaci i de rols

Normalment fem servir noms d'associaci que es puguin llegir formantuna frase del tipus NomClasse-NomAssociacio-NomClasse, en qu el nom del'associaci s un verb que permet formar una frase amb sentit.

Exemples de noms d'associaci

Alguns exemples de noms d'associaci i la frase que formen poden ser:

Alumne EsMatriculaDe Assignatura Professor Imparteix Grup Estudiant Entrega Activitat


Per als noms dels rols d'associaci, en canvi, fem servir noms semblants alsdels atributs.

Tant el nom d'associaci com els de rol sn totalment opcionals i, de fet, indi-car tant el nom d'associaci com el de rol sol ser fora redundant. Per aquestara moltes vegades no s'indica el nom de les associacions. En aquests materi-als, indicarem un nom de rol quan sigui especialment interessant indicar-lo.

En el cas de no indicar nom de rol, UML assumeix que el nom de rol s el nomde la classe, per comenant en minscula. En el nostre cas, a ms, preferirempassar-lo a plural si aquell extrem de l'associaci s multivaluat, ja que elsnoms de rol seran, aix, ms naturals.

Exemple d'associaci amb els noms de rol implcits

En aquest cas, els noms de rol serien professor i grups

Caldr, per, indicar, com a mnim, un nom de rol, en aquells casos en qu hipugui haver confusi. Aix, per exemple, ser necessari indicar com a mnimun nom de rol si tenim dues associacions entre les dues mateixes classes.

Exemple de dues associacions entre les mateixes classes

Imaginem que volem conixer el departament al qual pertany un professor i quin pro-fessor s responsable de cada departament. En aquest cas ens cal fer servir els noms de rolper a distingir el professor responsable d'un departament d'aquells que en sn membres.

En el cas de les associacions recursives, tamb s especialment important in-dicar clarament el rol de cada extrem d'associaci.

Exemple d'associaci recursiva

Suposem, per exemple, que una assignatura pot tenir requisits: altres assignatures quecal haver cursat abans de cursar l'assignatura en qesti. Posem per cas que una assigna-tura pot tenir fins a 3 requisits per que pot ser requisit de qualsevol nombre d'altresassignatures.


Identificaci d'associacions

A mesura que anem identificant classes del domini i poblant-les amb els seusatributs tamb podem anar identificant les associacions existents entre aques-tes que, com sempre, siguin rellevants per al sistema que analitzem.

Identificarem una associaci sempre que descobrim que a l'espai del problemales instncies de dues classes poden estar associades, de tal manera que recor-dar l'associaci entre aquestes s rellevant.

Per a identificar les associacions al model del domini un bon punt de partida sestudiar les classes ja identificades i plantejar quines poden ser les associacionsentre aquestes.

Exemple d'identificaci d'associacions

Algunes associacions del nostre cas d'exemple es poden identificar d'entrada.

Cada aula s en un edifici que, alhora, s en un campus. Aix, per exemple, podrem teniruna aula de nom 112, situada en un edifici anomenat B que, al seu torn, est ubicat enun campus anomenat Llull.

Cada semestre t un horari que est format per un conjunt de franges horries. A cadafranja horria es programen qualsevol nombre de classes. Aix, per exemple, en un de-terminat horari, la franja horria del dilluns a les 9 h podria tenir programada una clas-se del grup 2 d'Enginyeria del Programari a l'aula 112 abans mencionada. Com que nol'havem detectada abans, introdum ara la classe Classe, que representa una d'aquestesclasses programades i que t associada l'aula i grup que s'han programat.


Cada edici d'una assignatura correspon a un semestre, t un professor responsable i uno ms grups.

Cada grup t un professor i alguns alumnes. Suposem, per exemple, que en un grup hiha d'haver, com a mnim, 5 alumnes. A cada grup assignem, tamb, un tauler i, opcio-nalment, un frum.

Cada edici d'una assignatura t una srie d'activitats:

De cada missatge, en voldrem saber l'autor i qui l'ha llegit i qui no:


A partir d'aqu, es pot millorar la identificaci fent servir, com ja s'ha mencio-nat en el cas de les classes, llistes de categories d'associaci.

La llista de categories de classes del domini de Coad, Lefebvre i Luca (1999)proposa les associacions tpiques segents:

Els participants, coses o llocs poden tenir associada una descripci Cada participant, per tamb les coses o llocs, pot tenir associats qualsevol

nombre de rols, en qu cada instncia de rol correspon a un nic partici-pant.

En el nostre exemple, les persones poden tenir el rol de Professor o d'Alumne (o tots dos).Una persona pot ser professor o no ser-ho i, per tant, la multiplicitat de l'associaci dePersona amb el rol Professor tindr multiplicitat 0..1. Igual passar amb la classe Alumne.

Els moments o intervals poden tenir associats diversos rols corresponentsals participants, llocs i coses que hi intervenen (sota un rol determinat,com ara comprador o venedor).

Una altra llista de categories d'associaci ens la proposa Larman (2005). Algu-nes de les categories ms interessants d'aquesta llista sn:


Les transaccions poden tenir associades altres transaccions, com aral'associaci entre una venda i el seu pagament.

Algunes transaccions tenen associades lnies de transacci, com ara les l-nies de venda d'una venda d'un supermercat.

Les transaccions o lnies de transacci poden tenir associat un producteo descripci de producte, com ara l'associaci entre la lnia de venda delsupermercat i la descripci del producte venut.

Les transaccions poden tenir associats participants per mitj dels seus rols.

Algunes classes representen objectes que estan compostos lgica o fsica-ment per objectes d'una altra classe, com els seients d'una sala de cinemao els pisos d'un edifici.

Ens pot interessar la relaci de contenidor-contingut entre instncies, coms el cas d'un cotxe i la plaa d'aparcament on est aparcat.

Exemple

Aquest s el cas dels taulers. Cada tauler contindr un conjunt de carpetes; com a mnimuna, on aniran a parar els missatges per defecte. Aquestes no seran compartides, sinque cada carpeta estar al tauler on es va crear i noms en aquell. Dins de cada carpetahi haur missatges; de nou, un missatge noms podr estar en una carpeta. Les carpetespoden, per, contenir altres carpetes. Per tant, cada carpeta t una carpeta mare (tret deles carpetes arrel) i pot tenir qualsevol nombre de subcarpetes.

Els frums funcionaran de manera semblant als taulers.

Si tenim productes per tamb descripcions de producte, tindrem una as-sociaci entre aquests, com la que hi pot haver entre una edici d'una as-signatura i la seva assignatura, que ja hem identificat prviament.


Classes associatives

Les classes associatives permeten afegir atributs i associacions a les ins-tncies d'associaci. La representaci en UML d'una classe associativa sla d'una classe amb una lnia discontnua sense fletxes que la connectaamb l'associaci corresponent.

Exemple de classes associatives

Suposem, per exemple, que volem saber quins alumnes entreguen quines activitats.

Per, a ms, volem fer un seguiment de la data i hora d'entrega, de les qualificacions quees posa a cada alumne de cada activitat i tenir el document entregat per l'alumne; s adir, de cada entrega, volem tenir ms informaci en forma d'atributs. Una manera derepresentar aquesta informaci s afegint una classe associativa per a les entregues.

Representaci de les entregues com una classe associativa

Hem indicat que la qualificaci s de tipus Qualificaci perqu no volem entrar en detallsencara sobre si s un nombre del 0 al 10, un nombre del 0 al 100, una lletra (A, B, C, D),etc. D'altra banda, hem indicat la qualificaci com a opcional, perqu noms aquellesentregues ja corregides tindran qualificaci.

Alguns autors prefereixen no usar classes associatives, ja que introdueixen msconceptes i smbols grfics dels estrictament necessaris.

Tota classe associativa es pot representar, de fet, com una classe normal quetingui, al seu torn, dues associacions amb les dues classes que associava.

Vegeu tamb

Les classes associativess'estudien al mdul "Orientacia objectes".


Les multiplicitats als dos extrems d'associaci ms allunyats de la classe origi-nalment associativa sempre tenen multiplicitat 1, ja que, per definici, cadainstncia de la classe AB associa una i noms una instncia de la classe A i unai noms una de la B.

Les multiplicitats als extrems d'associaci propers a la classe AB sn les que hihavia a l'associaci original: cada instncia d'A t associades mb instncies deB i, per a cada associaci, tindr una instncia d'AB; per definici, doncs, cadainstncia d'A tindr associades mb instncies d'AB.

Representaci de les entregues com una classe no associativa amb duesassociacions

En el nostre exemple, les entregues es poden representar tamb sense classes associatives.

Associacions o atributs de tipus de classes del domini

Tant les associacions com els atributs acaben definint propietats de les clas-ses. Formalment, en UML, una classe t un conjunt de propietats format pelsatributs de la classe i els extrems d'associaci de les associacions de la classe.Prenguem l'exemple d'associaci entre un professor i els grups que imparteix:


Aquesta associaci defineix dues propietats noves que no sn atributs:

La classe Grup, a ms de la propietat numero de tipus Nat, t una propietatresponsable de tipus Professor amb multiplicitat 1.

La classe Professor, a ms de la propietat dataContractacio de tipus Data, tuna propietat grups de tipus Grup amb multiplicitat *.

Per tant, en realitat, els dos models segents sn molt semblants:

Representaci ms adequada: en forma d'associaci

Representaci menys adequada: en forma d'atributs

La diferncia est en el fet que la primera representaci s ms visual i ensindica que les propietats grups i responsable sn inverses. s a dir, que si canviemel responsable d'un grup, els grups d'aquest responsable i del que hi haviaabans hauran canviat.

Per tant, per a relacionar classes del domini preferirem sempre associacions ino atributs.

Errada freqent: s de "claus foranes"

Un cas particular i molt tpic d's d'atributs quan caldria fer servir associacionss el de les claus foranes. Quan es dissenya una base de dades, les associacionss'emmagatzemen en forma d'atributs que contenen identificadors de registresde la taula relacionada.

A causa d'aix, alguns analistes fan servir atributs semblants en els seus modelsUML, ja sigui a ms de l'associaci corresponent o en lloc d'aquesta.

Com hem vist anteriorment, tots dos casos sn un error, ja que cal representarl'associaci com a tal i no com a atribut.

Noms de rol d'associaciidentificatius

Els noms de les propietats deles classes han de ser nics.Per tant, de la mateixa maneraque no podem tenir dos atri-buts d'una mateixa classe quees diguin igual, tampoc no po-dem tenir dos noms de rol endues associacions d'una matei-xa classe que defineixin propi-etats amb el mateix nom o unnom de rol que defineixi unapropietat amb el mateix nomque un atribut.


Exemple

Si, per exemple, hagussim dit que l'autor d'un missatge s un atribut de tipus String quecont el DNI de l'autor, estarem cometent aquest error:

Representaci incorrecta d'una associacifent servir claus foranes

Errada freqent: Classes d'associaci amb atributs erronis

Un error habitual s fer servir classes associatives per a afegir atributs a una as-sociaci que, en realitat, pertanyen a una de les classes associades. Aix passa,especialment, en associacions amb una multiplicitat d'1 en un dels extrems.

Exemple

Un exemple d'aquest error seria pensar que la data d'entrega d'una activitat s un atributde l'associaci entre Activitat i Edicio. Com que cada activitat noms es fa en una edici,aquesta data depn de l'activitat per no de l'edici.

4.5. Herncia

4.5.1. Notaci UML

La notaci UML de l'herncia, que UML anomena generalitzaci, s una lniacontnua des de la subclasse cap a la superclasse amb un triangle a la punta.

Exemple

Exemple de notaci UML de la generalitzaci:


En el cas que una classe tingui ms d'una subclasse, solem agrupar les lniesde generalitzaci en una nica lnia.

En UML, les classes abstractes (aquelles en qu totes les instncies han de serinstncia d'alguna de les seves subclasses) s'indiquen posant-ne el nom en cur-siva.


Identificaci de l'herncia: generalitzaci i especialitzaci

Els processos que ens permeten identificar l'herncia sn la generalitzaci il'especialitzaci.

En un moment donat, examinant una determinada classe, podem detectaruna possible subclasse per especialitzaci quan ens trobem algun dels casossegents:

Vegeu tamb

Els processos de generalitzacii especialitzaci s'estudien almdul "Orientaci a objectes".


La subclasse candidata t atributs addicionals d'inters (que no tenen totesles instncies de la classe examinada).

La subclasse candidata t associacions addicionals d'inters (que no tenentotes les instncies de la classe examinada).

La subclasse candidata es comporta de manera diferent en un sentit relle-vant. Pot ser que es faci servir o s'hi operi de manera diferent o b querepresenti una persona, animal o sistema que t un comportament propidiferent.

Exemple d'especialitzaci

En el nostre cas, ens podem fixar en les activitats. Suposem que tenim activitats que snprctiques (s'han d'entregar al campus virtual), d'altres que sn exmens presencials i,finalment, projectes de final de carrera.

A part de la informaci comuna a tota activitat, de les prctiques, com que es fan pelcampus virtual, en voldrem tenir l'enunciat. Dels exmens ens caldr desar l'hora i el lloc.Els projectes de final de carrera (que es poden considerar l'nica activitat de cada edicide l'assignatura de projecte de final de carrera), tenen un tribunal format per un o msprofessors. Per tant, podem especialitzar les activitats de la manera segent:

Pel que fa a la generalitzaci, podem detectar-ne una oportunitat si es dnaalgun dels casos segents:

Les subclasses potencials representen variacions d'un mateix concepte. Les subclasses potencials tenen un o ms atributs en com que es poden

expressar com a atributs de la nova superclasse. Les subclasses potencials tenen una o ms associacions en com que es

poden representar com a associacions de la nova superclasse.

Exemple de generalitzaci

Seguint amb el nostre exemple, fins ara hem identificat que cada grup d'un curs t untauler i, opcionalment, un frum:


Tamb hem vist que el tauler cont missatges organitzats en carpetes:

Per resulta que els frums tamb tenen missatges organitzats en carpetes. Per tant, f-rums i taulers sn bsties de missatges amb algunes caracterstiques particulars de funci-onament i algunes associacions particulars (el tauler s obligatori en un curs, per el f-rum no ho s) i podem fer una generalitzaci per a abstraure les parts en com a tots dos:


Errada freqent: Herncies falses

La relaci d'herncia es pot estudiar sota la teoria de conjunts com la perti-nena de determinades instncies a determinats conjunts. Si representem cadaclasse com un conjunt de les instncies d'aquella classe, la relaci d'hernciaentre Activitat i Examen, per exemple, es pot representar de la manera segent:

Per tant, tota instncia d'examen ha de ser tamb una instncia d'activitat i,tot el que hem definit de les activitats (associacions i atributs) ha de ser 100%cert per a exmens, tamb.

Cal evitar, doncs, les falses herncies, en qu alguna instncia d'una pretesasubclasse no ho s de la superclasse o en qu algun atribut o associaci d'unapretesa superclasse no s aplicable a totes les seves subclasses.

Exemple

Suposem, per exemple, que ens interessa modelitzar les persones jurdiques. Com quetenim ja una classe persona, tot sembla indicar, a priori, que una persona jurdica ser unasubclasse de persona:

El problema s que les persones jurdiques no tenen cognoms, CV, ni foto, i en lloc de DNItenen un CIF. Per tant, en realitat, no s cert que tot all que podem dir de les personestamb sigui cert de les persones jurdiques.


Distinci entre classes abstractes i classes concretes

Quan modelitzem una herncia, cal plantejar-se si tota instncia de la super-classe ha de ser, forosament, instncia d'alguna subclasse o, al contrari, potser que alguna instncia de la superclasse no ho sigui de cap subclasse. En elprimer cas, la superclasse es definir com a abstracta.

Exemple de classe abstracta

En el cas de la generalitzaci de taulers i frums en bstia de missatges, ens trobem queno tindrem mai una bstia de missatges que no sigui un tauler o un frum, ja que estemsuposant que el sistema que modelitzem no ofereix bsties de cap altra mena. Per tant,caldria indicar que la classe Bustia s abstracta posant-ne el nom en cursiva.

De manera semblant, la classe Activitat tamb ser abstracta.

Modelitzaci de l'estat dels objectes

Molt sovint ens trobem amb una classe els objectes de la qual poden estaren diversos estats. Aix, per exemple, les entregues d'activitats per part delsalumnes es poden considerar pendents, fetes i corregides. Per a les entreguesja fetes ens pot ser d'inters la data en qu es va entregar, mentre que per a lesja corregides ens interessar la qualificaci atorgada.

Una manera de representar aquests possibles estats s fer servir l'herncia:

Amb aquest model, estem dient que les instncies d'entrega, quan es creen, sninstncies de PendentDeCorregir que, un cop corregides passen a ser instnciesde Corregida. Aquesta herncia s, per tant, dinmica.


Diem que una herncia s dinmica quan una instncia de la superclas-se, al llarg de la seva vida, pot canviar de subclasse.

Aquest enfocament t l'inconvenient que el concepte d'herncia dinmica spoc natural i, per tant, poc entenedor.

Un altre problema habitual en aquest s de l'herncia s que pot induir a errorsrespecte de quins atributs sn rellevants en cada estat. El model anterior, perexemple, sembla prou natural, per hem coms l'error de considerar que per ales entregues corregides no ens interessa saber la data en qu es van entregar.

Una manera alternativa de representar aquesta situaci s fer servir un atributque indiqui l'estat de l'objecte (discriminador) i fer opcionals aquells atributsque noms prenen valor en determinats estats, tal com ja havem fet.

Exemple

Representaci de la classe Entrega sense reflectir, al diagrama de classes, els seus estatspossibles:

En aquest cas, l'atribut qualificaci pot actuar com a discriminador ja que, perdefinici, una entrega corregida s aquella que t qualificaci. Un altre cas ha-bitual seria fer servir un atribut boole (corregida: boolean) o d'un tipus especficper a casos amb ms de dos estats (estatEntrega: EstatEntrega).

Una altra soluci consistiria a afegir una classe que representi l'estat. En aquestcas caldr anar amb compte de no cometre el mateix error respecte de l'atributdataEntrega:

Exemple

Representaci de la classe Entrega reflectint els seus possibles estats mitjanant una classeassociada:

Forma ms naturald'entendre l'herncia

L'herncia s un concepte del'orientaci a objectes i, pertant, s originari dels llenguat-ges de programaci. Ats quegaireb cap llenguatge de pro-gramaci no permet que unainstncia canvi de classe alllarg de la seva vida, la ma-nera ms natural d'entendrel'herncia s com a hernciaesttica.


Modelitzaci del rol d'objectes i persones

Una situaci habitual s que un objecte, especialment si representa una per-sona del mn real, pugui tenir un rol determinat dins el domini analitzat. sel cas, per exemple, dels professors i alumnes d'una universitat.

Suposem, per exemple, que s'han identificat professors i alumnes de la facultatcom a dues classes d'objectes:

En aquesta situaci, tal com s'ha explicat, trobem una oportunitat molt clarade generalitzar les parts comunes en una classe Persona:

Aquesta soluci, per, planteja el problema ja plantejat anteriorment de lesherncies dinmiques. Una mateixa persona podria passar d'alumne a profes-sor i, per tant, l'herncia es pot considerar dinmica.

Per, a ms, presenta una problemtica addicional: suposem que una personapot ser, alhora, Alumne i Professor (per exemple, perqu s alumne d'uns es-tudis i professor d'uns altres). En tal cas, un mateix objecte de classe Personahauria de pertnyer a totes dues subclasses alhora.

Diem que una herncia s overlapping quan una mateixa instncia de lasuperclasse pot pertnyer a ms d'una subclasse alhora.


Per raons semblants al cas de les herncies dinmiques, considerem que lesherncies overlapping no sn naturals; sn confuses, difcils d'entendre i, pertant, no considerem el seu s gaire recomanable.

Un soluci millor consisteix a modelitzar els rols com a classes prpies asso-ciades a la classe que pot tenir aquests rols. s, de fet, el que proposen Coad,Lefebvre i Luca (1999) quan ens proposen els rols com una categoria de classesa l'hora d'identificar-les, tal com s'ha explicat al subapartat 4.2.2.

Exemple

Modelitzaci dels possibles rols de les persones al nostre sistema com a classes associades.En aquest cas, una persona pot tenir el rol de Professor, el d'Alumne, tots dos, o cap delsdos.

4.6. Informaci derivada i regles d'integritat

4.6.1. Regles d'integritat

Una de les funcionalitats bsiques del programari per a sistemes d'informaciconsisteix a desar informaci de manera persistent que permeti fer consultes iguiar la presa de decisions en el dia a dia de l'empresa, organitzaci o personaque fa servir el sistema d'informaci.

Exemple

El programari per a la universitat, per exemple, permetr fer consultes dels expedientsdels alumnes i permetr guiar l'avaluaci dels estudiants, ja que, per exemple, pot pro-porcionar al professor, a l'hora d'introduir les qualificacions, una llista dels estudiantsmatriculats al seu grup.

Perqu aquesta informaci sigui til ser important mantenir-ne la integritat:caldr evitar situacions en qu la informaci s contradictria o incompleta.

En el cas que ens ocupa ser important evitar, per exemple, situacions en qu es qualificauna entrega d'una activitat a un alumne que no est matriculat d'aquell curs, o situacionsen qu no es disposa de la qualificaci d'una activitat que es va corregir.

El model del domini, per tant, ha de documentar quines restriccionsd'integritat han de satisfer les dades que gestiona el sistema. Els diagrames declasses UML ens permeten representar grficament algunes d'aquestes restric-cions d'integritat. s el cas, per exemple, de les multiplicitats.


Exemple

En el fragment de diagrama mostrat, que s una part del que ja hem analitzat, hem docu-mentat diverses restriccions d'integritat. Diem, per exemple, que un grup ha de tenir coma mnim 5 alumnes i que, per tant, si es dons el cas que tenim un grup amb menys de 5alumnes, el sistema ho hauria de considerar una situaci errnia. De manera semblant,indiquem que cada grup t un i noms un professor i que, per tant, no es pot donar elcas que un grup tingui dos professors o que no en tingui cap.

Per moltes altres restriccions d'integritat no poden ser representades grfica-ment en el llenguatge UML. Per a aquestes, caldr redactar un document queles recopili.

Claus de les classes del domini

Un subconjunt especialment important de les restriccions d'integritat que cal-dr documentar sn les claus de les classes del domini. Gaireb cada classe deldomini tindr, tpicament, un atribut o conjunt d'atributs que n'identifica lesinstncies de manera nica. Per tant, caldr que el sistema garanteixi que no hipot haver dues instncies d'una mateixa classe en qu la clau sigui la mateixa.

Exemple

En el cas que ens ocupa, si, per exemple, el sistema detects que s'est donant d'alta unapersona amb el mateix DNI que una persona existent, caldria que indiqus que es tractad'un error: o b la persona ja s'ha donat d'alta al sistema amb anterioritat o b hi ha unaerrada al DNI de la nova persona que s'est donant d'alta. En qualsevol dels dos casos,permetre l'alta de dues persones amb el mateix DNI voldria dir trencar la integritat deles dades.

Diem, doncs, que la clau de persona s el DNI. Al document on hi ha la llista de les clausde les classes del domini, indicarem, per tant:

Les classes del domini tindran les claus segents:

Persona: dni Assignatura: nom Campus: nom

En el cas dels semestres, l'identificador ser l'any i el nmero de semestre, cosa que in-dicarem com:

Semestre: any + num

Els edificis, en principi, s'identificaran per nom. Per hi podria haver dos edificis que esdiguessin igual, sempre que estiguessin en campus diferents, ja que continuaria sensehaver-hi confusi possible. Per tant, el nom de l'edifici l'identifica dins el campus. Podr-em considerar, doncs, que la clau d'edifici s nom del campus + nom de l'edifici. Per asimplificar, per, direm que la clau d'edifici s campus + nom (s a dir, un cop identificatun campus, l'edifici s'identifica per nom). De manera semblant, la clau de la classe Aulaestar formada per l'edifici i el nom.

Edifici: campus + nom Aula: edifici + nom

DNI com a clau

Tot i que el DNI sembla unaclau bvia per a identificar per-sones a l'Estat espanyol, en re-alitat, hi ha tota una proble-mtica associada als nombresrepetits que nosaltres no tin-drem en compte per que enspodria afectar en sistemes re-als.


Cada semestre t el seu propi horari. Per tant:

Horari: semestre

Per el cas de les franges horries mereix una atenci especial:

En un horari, la franja horria s'identificar pel dia de la setmana i l'hora:

FranjaHoraria: horari + dia + hora

Pel que fa a les classes, en una mateixa franja hi pot haver ms d'una classe sempre quees compleixin una srie de condicions: no pot hi haver dues classes del mateix grup a lamateixa franja horria, i no hi pot haver dues classes a la mateixa aula i la mateixa franjahorria. Per tant, en aquest cas, tenim dos identificadors:

ClasseProgramada: franjaHoraria + aula, franjaHoraria + grup

Cada edici d'una assignatura es correspon a un semestre d'una assignatura. I, en unaedici, els grups s'identifiquen per nmero. Per tant:

Edicio: semestre + assignatura Grup: edicio + numero

Cada tauler t associat noms un grup i s l'nic tauler del grup. Igual passa amb elsfrums, en cas que el grup en tingui. Per tant:

Tauler: grup Forum: grup

Taulers i frums tenen una superclasse Bustia, per no tenim cap manera d'identificar lesbsties per si mateixes. Per tant, la classe Bustia no t clau.

Les activitats d'una edici d'una assignatura han de ser identificades per ttol. bviament,hi podria haver dues activitats amb el mateix ttol sempre que siguin de diferents edicionsd'assignatura.

Activitat: edicio + titol

Cada instncia de rol de professor o d'alumne es correspon a una nica persona i saquesta persona el que les identifica:

Professor: persona Alumne: persona

El cas de les carpetes de les bsties tamb cal mirar-lo amb atenci:


s clar que no hi pot haver dues carpetes amb el mateix nom dins

mòdul 4 - anàlisi uml

Documents