Aquest article documenta una sèrie d’errors freqüents que he detectat que es solen produir en els diagrames de seqüència dels dissenyadors novells. No es tracta tant de documentar errades de disseny com d’explicar les errades de llenguatge UML a l’hora d’expressar un disseny mitjançant un diagrama de seqüències.

Documents illegibles

Un diagrama de seqüències és un document que una persona ha de poder llegir en paper o en pantalla. Encara que sembli absurd, molts dissenyadors fan diagrames tant grans que, mostrats sencers en una pantalla o impresos en una pàgina de paper són impossibles de llegir. La situació és especialment greu quan ni tant sols en format digital i fent zoom es pot llegir el contingut del diagrama.

Exemple:

Diagrama illegible

Les causes d’això poden ser moltes no relacionades amb UML:

• Format d’imatge incorrecte: S’ha fet servir un format amb pèrdua de qualitat que ha introduït massa soroll per a que es pugui llegir el diagrama
• Nivell de zoom massa allunyat: El nivell de zoom del diagrama no permet llegir-lo sobre paper o sobre pantalla quan es mostra tot el diagrama a la pantalla
• …

Des del punt de vista UML, però, hi ha solucions aplicables per a simplificar diagrames. Qualsevol operació es pot deixar, en un diagrama de seqüències, sense documentar. Aleshores cal, però, fer un altre diagrama de seqüències on es mostri només el disseny d’aquella operació. Vegeu l’apartat “Operacions no dissenyades” per a un exemple d’operació documentada en un diagrama a part.

Errades en la representació de participants

Els participants, en un diagrama de seqüències del disseny, són objectes i classes de programari. Un participant que representi una classe es pot fer servir per mostrar la invocació d’operacions amb àmbit de classe (estàtiques).

Un participant es representa amb una etiqueta:

• El participant representa una classe. Ex: Controller
• El participant representa un objecte anònim. Ex: erson
• El participant representa un objecte amb nom. Ex: d:Department

Un objecte anònim és un objecte al que no donem nom al diagrama de seqüència. Això fa que no poguem identificar d’on surt aquest objecte. Per tant sol ser recomenable posar nom a tots els objectes que apareixen al diagrama. Com a excepcions a aquesta norma hi ha:

• Objecte inicial del diagrama: Un diagrama de seqüències documenta el comportament d’un conjunt d’objectes a partir d’un objecte inicial del que documentem una operació. A aquest objecte inicial pot ser innecessari donar-li un nom.
• Objectes singleton: De les classes singleton només n’hi ha una instància. Per tant, no cal que aquesta instància tingui nom.

Errades a les activacions

L’activació és la banda que es dibuixa damunt la línia de vida d’una instància quan aquesta rep la invocació d’una operació (o, en general, qualsevol missatge). Aquesta banda representa el temps que l’objecte està actiu ja sigui perquè està fent alguna mena de càlculs o perquè està esperant una resposta d’una invocació que, al seu torn, ha fet sobre un altre objecte.

Més d’un missatge cap a la mateixa activació

Activació espontània d’una instància

En aquest exemple el missatge 2 s’origina des de la instància p:Persona sense que aquesta estigués prèviament activa. La instància, per tant, s’ha activat espontàniament. Si estem modelant un programari OO tradicional (sense objectes actius) això no pot passar mai, ja que qualsevol instància – i p:Person en particular – només pot actuar com a resposta a una invocació.

No mostrar quina operació inicial es documenta

Un diagrama de seqüències de disseny documenta com interactuen un conjunt d’objectes quan un d’ells (o una classe) rep la invocació d’una operació. Cal mostrar, però, quina és l’operació que s’està documentant.

Aquest diagrama de seqüències documenta una operació de la classe Controller que fa dues invocacions sobre una instància p:Person. Però no sabem quina és l’operació de Controller que estem documentant.

En aquest diagrama podem veure que s’està documentant l’operació Controller::getPersonData.

Nota: En aquest article, la majoria de figures mostren fragments de diagrames de seqüència. Per tant, no ens hem preocupat de mostrar en tots els casos quina operació s’està documentant.

Errades d’instanciació d’objectes

Missatge de creació mal representat

El missatge 1 d’aquest exemple pretén representar la creació de la instància p:Person, però en realitat mostra la invocació d’una operació create() sobre una instància p de tipus Person que existeix prèviament. El missatge 2, en canvi, mostra la forma correcta de representar la instanciació d’una instància.

Instàncies inexistents

En un diagrama de seqüències del disseny, tota instància que aparegui ha d’estar clar d’on surt. Si estem dissenyant per a un llenguatge de programació orientat a objectes típic una instància només podrà invocar operacions en algun determinats escenaris escenaris.

Suposem que estem documentant la invocació d’una operació op1() sobre una instància a de tipus A. La instància a només podrà invocar operacions:

• Amb àmbit de classe (estàtica) sobre qualsevol classe visible per A
• Amb àmbit d’instància (no estàtica) sobre una instància b:B quan:
  • La classe A té un atribut b de tipus B i la instància a té un objecte en aquest atribut (i no un null)
  • L’operació A::op1 té un paràmetre b de tipus B i la invocació ha rebut un argument no null en aquest paràmetre
  • La instància b de tipus B ha estat creada des de la mateixa operació op1() abans d’invocar-hi l’operació. Aquest cas no és gaire freqüent.

En aquest exemple :Controller fa servir una instància erson que no se sap d’on surt. A menys que la classe Controller tingui un atribut de tipus Person (i, en tal cas, caldria indicar com a nom de la instància erson el nom de l’atribut), la instància :Controller no pot enviar missatges a erson.

En el segon exemple s’ha corregit l’error: :Controller fa servir una instància anònima de Dictionary

(que probablement ha rebut per injecció de dependències) i obté, a partir de l’identificador d’una persona, una instància p:Person. És sobre aquesta instància sobre la que invoca getName().

Instàncies anònimes

En alguns casos particulars, no mostrem d’on surt una instància quan està molt clar a quina instància ens referim i quin és el seu origen. És el cas d’instàncies de classes Singleton per a les que no volem mostrar el funcionament del patró Singleton o el cas d’instàncies de serveis que s’han injectat a la instància que fa la crida per injecció de dependències. Per a que quedi clar aquest ús, és recomenable no donar nom a aquestes instàncies.

En el cas dels diagrames de seqüència de la Capa de Domini, per exemple, recomano reservar aquest tractament per als controladors de la Capa de Gestió de Dades (o per als Diccionaris si encara no s’han introduït aquests controladors).

Cas general: Variables inexistents

El cas de les instàncies inexistents es pot extendre a qualsevol variable utilitzada en el diagrama de seqüències:

• Nom d’instància
• Variables fetes servir en arguments a la invocació d’operacions
• Variables fetes servir en condicions de marcs OPT, LOOP i ALT

Operacions no dissenyades

En un diagrama de seqüències del disseny, habitualment, ens cal mostrar tot el disseny de totes les operacions que apareixen al diagrama. Qualsevol operació que sigui invocada ha de ser dissenyada, al seu torn, com a part de mateix diagrama de seqüències o en un diagrama de seqüències a part.

Les úniques operacions per a les quals no apareixerà cap disseny, per tant, són aquelles que una instància atén sense delegar en cap altra instància; és a dir, aquelles que la instància resoldrà sense invocar cap operació sobre cap altra instància:

• Operacions consultores (getter) que només retornen el valor d’un atribut
• Operacions modificadores d’atribut (setter) que només canvien el valor d’un atribut
• Operacions que efectuen algun tipus de càlcul només amb valors (per oposició a objectes) que siguin atributs o arguments de la crida: Manipulació de números, strings, dates, etc.

En aquest exemple, l’operació getHighestPayedEmployee, suposant que no es tracti només d’una consulta d’un atribut, necessitarà recórrer els empleats associats a la companyia i trobar quin és el que està millor pagat. Per a fer-ho, haurà d’invocar operacions sobre instàncies de classe Employee. En aquest diagrama no es mostra el disseny d’aquesta operació.

Això no seria un problema sempre que en un diagrama a part es mostri el disseny d’aquesta operació:

Notes:

• En aquest exemple s’han fet seriv comentaris al costat de l’activació per explicar aquelles parts del disseny que no impliquen la interacció amb altres objectes. Per exemple, com s’inicialitza i modifica la variable maxSalary.
• En aquest exemple s’ha fet servir un LOOP amb condició “for each emp in employees” enlloc de mostrar l’ús a baix detall d’un iterador.
• Fixeu-vos que emp:Employee és una instància correctament identificada, ja que correspon a l’empleat actual de la iteració (apareix explícitament a la condició del LOOP). Pel que fa a employees hem de suposar que es tracta d’un atribut de Company (o una associació navegable des de Company cap a Employee amb nom de rol employees al costat d’Employee).

Errades de disseny

Finalment, moltes de les errades dels diagrames de seqüència són errades de disseny. És a dir, el diagrama de seqüències no només ha de tenir sentit i documentar correctament un disseny possible, sinó que, a més, ha d’estar correctament dissenyat.

Malgrat que no és la intenció d’aquest article parlar d’aquest tipus d’errors (que no són específics dels diagrames de seqüència, sinó que també es poden trobar en un disseny expressat directament en codi, per exemple), dóno aquí una llista dels que són més habituals:

• L’operació no compleix amb el contracte (ja sigui un contracte explícitament documentat o un contracte implícit) i, per tant, no fa el que ha de fer.
• No s’ha aplicat correctament els patrons Expert i Creador de Larman i, per tant, la cohesió i acoblament de la solució obtinguda són dolents.
• Els noms donats a les operacions no són indicatius de la semàntica de les mateixes. Exemple: Una operació getEdat que, en realitat, modifiqui l’atribut dataNaixement de la instància sobre la que s’invoca.
• No s’honora el principi de No Repetició de Hunt i Thomas i, per tant, hi ha dues o més operacions que tenen total o parcialment el mateix disseny. És especialment curiós quan es fa servir una operació ja dissenyada en un altre diagrama de seqüències tal qual i, malgrat tot, es torna a mostrar tot el disseny intern de l’operació en qüestió.

Referències

• [LARMAN] Larman, Craig (2002) Applying UML and Patterns. Prentice Hall.
• [PRAGPROG] Andy Hunt, David Thomas (2000) The Pragmatic Programmer – from journeyman to master. Addison Wesley
• [UPC-ES2] Franch, Xavier (professor responsable) Assignatura ES2 de la secció de SI, departament LSI, UPC.
• [UOC-EPOO] Jordi Fernández Gonzalez, Jordi Pradel i Miquel i Jose Antonio Raya Martos (coordinadors Jordi Cabot i Isabel Guitart). (2005) Enginyeria del programari orientat a l’objecte. Barcelona: UOC

Aquest document conté un compendi de les errades més freqüents a l’hora d’utilitzar UML per a fer l’anàlisi d’un sistema d’informació Orientat a Objectes. S’ha considerat que la metodologia d’analisi utilitzada és la metodologia simplificada que es pot trobar a [EPOO].

Diagrama de casos d’ús

Concepte de cas d’ús

Dels apunts d’EP de la UOC: Un cas d’ús documenta una interacció entre el programari i un actor o més. La interacció en qüestió ha de ser en principi una funció autònoma dins el programari.

L’errada més freqüent en el diagrama de casos d’ús és, en aquest concepte. Un cas d’ús no és part d’una funcionalitat ni un pas d’un algorisme.

Un cas d’ús ha de ser tal que tingui sentit que un actor accedeixi al sistema, realitzi aquell cas d’ús i deixi de treballar al sistema; és a dir, per definició, ha de ser un possible cas d’ús del sistema per part de l’usuari. Si una funcionalitat no es pot aïllar d’aquesta manera, segurament no és un cas d’ús.

Un bon indicador que estem confonent el concepte de cas d’ús són diagrames de casos d’ús amb un nombre excessiu de casos d’ús.

Excepcionalment, podem modelar casos d’ús que agrupen un conjunt de funcionalitats d’aquest tipus. Podríem, per exemple, modelar un cas d’ús “Gestió de departaments” que representés l’alta, la baixa, la modificació, la consulta i el llistat de departaments. En tal cas, però, cal no barrejar graus de granularitat: O bé parlem del cas d’ús “Gestió de departaments” o bé parlem dels casos d’ús “Alta de departament”, “Llistat de departaments”, etc. però no de totes dues coses.

Relacions entre casos d’ús

include

El cas d’ús A està inclòs en el cas d’ús B (B inclou A) si A és un conjunt d’interaccions entre l’usuari i el sistema que forma part del cas d’ús B. En tal cas, el cas d’ús A no és necessàriament un cas d’ús complet segons la definició donada abans: Pot ser un fragment d’un altre cas d’ús.

En general, no té sentit que indiquem que un cas d’ús A està inclòs dins un cas d’ús B si el cas d’ús A no és inclòs, alhora, en altres casos d’ús, ja que si només està inclòs dins un únic cas d’ús i en forma part, no cal que el modelem com a cas d’ús.

Una relació d’inclusió s’indica amb una línia discontínua, amb punta de fletxa oberta que va del cas d’ús general al cas d’ús inclòs i que porta l’etiqueta <<include>>.

Un cas d’ús inclòs en algun altre hauria d’estar inclòs en dos o més casos d’ús. Molt excepcionalment, i mai com a regla general, podem indicar un cas d’ús només inclòs en un altre; i, en tal cas, ha de ser degut a una gran complexitat.

extends

Una extensió d’un cas d’ús és un conjunt d’interaccions entre l’actor i el sistema que es pot produir en algun moment del cas d’ús, normalment en una situació fora del flux principal d’esdeveniments.

Un cas d’ús A extén un cas d’ús B si A és una extensió del cas d’ús B que, a més, té sentit com a cas d’ús independent.

Una relació d’extensió s’indica amb una línia discontínua, amb punta de fletxa oberta que va del cas extensió al cas d’ús general (extès) i que porta l’etiqueta <<extend>>.

Un cas d’ús que n’extén un altre ha de tenir sentit com a cas d’ús independent. Per tant, ha de passar les validacions pròpies d’aquests.

General

Un bon indicador que estem sobre-utilitzant les relacions entre casos d’ús és la seva presència en excessiu nombre. No és habitual que la majoria de casos d’ús participin en una o més relacions, excepte escenaris de reutilització massiva de fragments de cas d’ús (per exemple, quan pràcticament tots els casos d’ús del sistema inclouen una sèrie de passos d’interacció per a que l’usuari s’autentiqui al sistema, conegut com a procés de login); en tal cas, la majoria de relacions seran d’inclusió cap al cas d’ús reutilitzat.

Actors

Dels apunts d’EP de la UOC: “La finalitat del programari és proporcionar informació a persones, màquines i dispositius o programaris de l’exterior, el conjunt de tots els quals anomenarem entitats exteriors; també hi ha entitats exteriors – les mateixes o d’altres – que demanen funcions al programari o bé li subministren informació per a tractar. Un actor és un conjunt de papers d’una entitat exterior en relació amb el sistema de programari considerat.”

Per tant, considerem actors els diferents papers (o conjunts de papers) que poden prendre les persones o sistemes externs que interactuïn amb el sistema que analitzem.

En un determinat cas d’ús, un actor en pot ser iniciador (el qui ha iniciat el cas d’ús activament) o pot ser-hi participant (sense haver iniciat el cas d’ús).

La relació entre un actor i un cas d’ús s’indica mitjançant una línia contínua sense etiquetes ni puntes de fletxa de cap mena.

Cada actor ha de participar, com a mínim en un cas d’ús.

Cada cas d’ús ha de tenir, com a mínim, un actor iniciador, tot i que pot tenir altres actors (iniciadors o no). Excepció: Els casos d’ús inclosos no tenen sentit per si mateixos i, per tant, no tindran actors iniciadors (tot i que en poden tenir de participants sense ser iniciadors).

Especificació textual de casos d’ús

Un diagrama de casos d’ús només és una forma gràfica de mostrar un índex dels casos d’ús i actors del nostre sistema i les relacions entre ells. Però en cap cas, els requisits funcionals d’un sistema queden prou documentats amb un diagrama de casos d’ús. Cal, per a cada cas d’ús, donar-ne l’especificació textual.

Existeixen diversos formats per a l’especificació textual de casos d’ús; alguns són més breus i d’altres més complets. Si no es diu el contrari es considerarà que es vol una especificació completa del cas d’ús.

Cal fer servir un format consensuat a l’organització on es treballi. N’hi ha un exemple al mòdul 3, apartat 1.2.1 dels materials d’EPOO de la UOC.

Nom

El nom d’un cas d’ús que especifiquem textualment ha de coincidir necessàriament amb algun dels casos d’ús indicats al diagrama de casos d’ús!!

Flux d’esdeveniments principal

Un cas d’ús ha de tenir clarament associat un objectiu que l’actor principal del cas d’ús vol assolir, com per exemple, donar d’alta un nou empleat o llistar els empleats d’un departament. Per a cada cas d’ús, triarem un flux d’esdeveniments principal que és aquell a través del qual l’usuari obté el seu objectiu de la forma més directa o habitual.

En el flux d’esdeveniments principal cal indicar la sèrie de passos que formen la interacció entre el sistema i els actors implicats. Cada pas ha de ser una acció simple que fa UN actor o el sistema i ha d’anar numerat per a poder-hi fer referència més endavant.

En el cas que el cas d’ús n’inclogui un altre, tot el cas d’ús inclòs es considerarà un únic pas i no s’indicarà els diferents passos que el formen, ja que per això s’ha utilitzat la relació d’inclusió: Per a no haver de documentar cada cop els diversos passos que formen el cas d’ús inclòs.

Ha d’estar format per una sèrie de passos numerats

Cada pas hauria de ser quelcom que fa el sistema o quelcom que fa un actor

El flux d’esdeveniments principal hauria de documentar un diàleg entre diverses parts i, per tant, el més normal és que tingui forma d’una sèrie de passos que alternen peticions dels actors amb respostes del sistema.

Cada pas del sistema ha de deixar clar quines dades mostra el sistema com a resultat; normalment n’hi ha prou amb indicar clarament la pantalla mostrada.

Cada pas d’un actor ha de deixar clar quines dades proporciona al sistema; normalment n’hi ha prou indicant clarament la pantalla on s’introdueixen i quines dades d’aquesta s’introdueixen (típicament totes)

Flux d’esdeveniments alternatius

El flux d’esdeveniments principal ha de ser un escenari d’ús del cas d’ús a través del qual tot funciona correctament i que es consideri l’escenari més habitual. Qualsevol flux alternatiu (errades de l’actor, opcions que no siguin la principal, etc.) s’ha de documentar en un flux d’esdeveniments alternatiu.

Cada flux d’esdeveniments alternatiu ha d’indicar en quin pas de l’escenari principal es produeix i sota quina condició. Aleshores ha d’incloure els passos numerats que es segueixen (amb les mateixes regles que el flux d’esdeveniments principal).

Moltes vegades, un flux d’esdeveniments alternatiu finalitza retornant a algun pas del flux d’esdeveniments principal.

Cada flux d’esdeveniments alternatiu ha d’indicar en quin punt es produeix (un número), s’ha d’identificar dins aquest punt (típicament amb una lletra) i ha de descriure quan es produeix (una frase explicant l’alternativa triada o l’error comès).

Model conceptual de dades

El Model Conceptual de Dades modela les dades que el sistema gestiona classificant-les en classes, que tenen atributs i associacions entre elles. Algunes classes, a més, poden mantenir una relació d’especialització/generalització que té un tractament especial.

Classes

Cada classe ha de tenir un nom que sigui descriptiu del que representa i, normalment, n’han de poder existir diverses instàncies al sistema. Cada instància tindrà certs valors als atributs de la classe i certes altres instàncies associades a través de les associacions.

Els noms de classe han de ser únics

Una classe de la qual no en puguem imaginar més d’una instància al sistema sol ser una classe innecessària.

En el cas excepcional que d’una classe només en pugui existir una instància, cal marcar la classe com a singleton fent servir l’indicador de cardinalitat de classe propi d’UML.

Una classe que no tingui atributs és molt poc habitual i, gairebé sempre, indicadora d’alguna errada de modelat. Les instàncies d’una classe així només es podrien distingir les unes de les altres per les instàncies que tinguin associades.

Una classe sense atributs ni associacions és un error, ja que les seves instàncies no es podrien distingir les unes de les altres i no tindrien cap informació útil.

Les classes d’un model conceptual de dades no han de tenir operacions.

Atributs

Els atributs indiquen el tipus d’informació que coneixem de cada instància d’una classe. Cada atribut ha de tenir un nom identificatiu i autoexplicatiu i un tipus, que ha de ser un “tipus primitiu”.

Un atribut no pot ser del tipus d’una classe del model conceptual de dades. En tal cas, cal substituir-lo per una associació.

Un atribut no pot ser de tipus llista, col·lecció, array, etc. En tal cas cal fer servir atributs multiavaluats.

Els atributs multiavaluats no són freqüents i, molts cops, indiquen que estem modelant incorrectament una associació com a atribut.

Si no s’indica el contrari, un atribut és obligatori. Per a indicar que un atribut és opcional (pot no prendre valor per a algunes instàncies del sistema), cal indicar-ne la cardinalitat [0..1].

Un atribut no pot funcionar com una clau forana del model relacional: Un atribut no pot contenir un valor que identifiqui una altra instància d’alguna classe del model conceptual; en tal cas, cal substituir-lo per una associació.

Suposem que tenim una classe Departament i una classe Empleat amb un atribut dni que n’identifica les instàncies. Per indicar que de cada departament en sabem el cap, que és un empleat, cal fer servir una associació entre les dues classes, mai un atribut dniCap a la classe Departament.

Associacions

Cada associació associa dues (en alguns casos més) classes.

A cada extrem d’una associació cal indicar-hi la cardinalitat.

Les associacions ternàries, quaternàries, etc. (N-àries on N>2) són poc habituals i és possible fer models correctes sense utilitzar-les. En cas de dubte o si no se’n coneix molt bé el funcionament, és millor no fer-les servir.

Quan una associació indica una certa relació de tot-part, es considera que és una agregació (i es dibuixa un rombe a l’extrem del tot). Si aquesta relació és especialment forta (i segueix certes restriccions semàntiques) aleshores l’agregació és una composició (i el rombe es dibuixa ple).

No és habitual que la majoria d’associacions siguin agregacions o composicions. La majoria haurien de ser associacions simples.

Si no es coneix molt bé la diferència que hi ha entre una composició i una agregació, és millor no fer servir composicions.

En una agregació, la cardinalitat a la part del tot sol ser 1 o 0..1.

En una composició, la cardinalitat a la part del tot sempre ha de ser 1.

Generalització / Especialització

Quan modelem una classe A1 com una especialització d’una classe A, indiquem que tota instància d’A1 és, també de tipus A. Per tant, tot allò que sigui cert sobre les instàncies d’A, ho serà també per a les instàncies d’A1, però no a l’inrevés. En particular, tota instància de la classe A1 tindrà les mateixes associacions i atributs que les instàncies de la classe A, però tindrà associacions i atributs propis.

Un atribut d’una classe (A1) no pot tenir el mateix nom que un atribut de la seva superclasse (A)

Restriccions d’integritat

En tot sistema hi ha certes restriccions d’integritat que s’han de complir en tot moment (no entrem en la definició formal de què vol dir en tot moment). Algunes restriccions d’integritat es poden representar amb UML, però d’altres s’han de representar com a notes del diagrama (entre { i }) o com a restriccions textuals al peu del diagrama.

Si no pot haver-hi, en cap moment, dues persones amb el mateix dni, direm que aquesta és una restricció d’integritat.

Un cas especial de restricció és la de clau. Quan una classe té un atribut o conjunt d’atributs que identifica les instàncies d’aquella classe (i que, per tant, no puguin prendre valors repetits), direm que aquest atribut o conjunt d’atributs formen la clau externa d’aquella classe.

Seguint l’exemple anterior, direm que dni és clau externa de la classe Persona.

Normalment la majoria de classes del sistema haurien de tenir una clau externa. És convenient indicar-la explícitament.

Disseny extern del sistema

El disseny extern del sistema consisteix a dissenyar l’aspecte que ofereix el sistema als seus usuaris. En una primera fase, es sol dissenyar només els aspectes més rellevants d’aquest disseny extern sense entrar en detalls.

És important dissenyar quins tipus d’entrades i sortides permet fer el nostre disseny extern i quins fluxos de navegació entre pantalles permet, però podem deixar per a més endavant qüestions com el color de les pantalles o el tipus de lletra qui hi farem servir.

Per a fer un disseny extern del sistema n’analitzarem l’aspecte estàtic (fent esboços de les pantalles que formen la interfície gràfica d’usuari) i de l’aspecte dinàmic (indicant en un diagrama d’estats els fluxos navegacionals entre pantalles del sistema).

Disseny extern: Aspecte dinàmic (diagrama de la interfície gràfica)

Un diagrama d’estats de la interfície gràfica ha de mostrar, per a un cas d’ús (o més d’un), els diversos estats pels quals passa la interfície mostrada a l’usuari. Cada estat es correspondrà (informalment) amb una pantalla i permetrà diverses transicions cap a altres estats.

Tot estat ha de tenir un nom identificatiu i autoexplicatiu

Cada transició és originada per un esdeveniment (normalment ocasionat per l’usuari) i pot tenir una condició (indicada entre [ i ]). L’esdeveniment d’una transició ha de tenir un nom identificatiu i autoexplicatiu i pot tenir paràmetres.

Tota transició ha de tenir associat un esdeveniment.

Un esdeveniment s’ha de correspondre amb un esdeveniment d’alt nivell. No cal tenir en compte, doncs, esdeveniments que no afecten l’estat del sistema com ara omplir un camp de text, minimitzar, fer servir l’scroll…

Si, en un formulari d’alta d’empleat, un usuari indica un nom en un camp, un dni en un altre, una data de naixement en un tercer i, a continuació, prem el botó ok, podem considerar que altaUsuari(nom,dni,dataNaixement) és un bon nom d’esdeveniment amb els seus paràmetres. En canvi, omplirNom, omplirDni, premerOk, etc, són noms d’esdevniment a massa baix nivell d’abstracció.

Des d’un mateix estat, no en poden sortir dues transicions amb el mateix esdeveniment, a menys que tinguin una condició excloent, és a dir, que les distingeixi.

Si entre dos estats hem modelat una transició (incorrecta) sense esdeveniment, probablement l’estat origen de la transició no és un estat, ja que el sistema no s’hi està fins que es produeixi un esdeveniment.

Un diagrama d’interfície gràfica té com a únic objectiu mostrar els estats (pantalles) pels que navega l’usuari. No cal que hi aparegui informació sobre altres tasques realitzades pel sistema, que molts cops es modelen incorrectament com a estats amb transicions sense esdeveniments.

El diagrama ha de tenir un únic estat incial que és la primera pantalla que l’usuari veu (del cas d’ús o del conjunt de casos d’ús).

Aquell estat (pantalla) en el qual es doni per finalitzat el cas d’ús modelat (a partir del qual ja no s’admetin transicions), ha de ser marcat com a estat final.

Tot diagrama ha de tenir, com a mínim, un estat final.

Normalment no és necessari fer servir altres característiques avançades dels diagrames d’estat UML. En particular, si es modela un diagrama per cas d’ús no és necessari fer servir subestats, estats històrics, estats paral·leles, etc. Si ens trobem amb lògiques complexes, val la pena fer un diagrama simple i anotar-lo per a complementar-lo amb un comentari UML o al peu del diagrama.

Tota transició que, en fer-se, reculli dades introduïdes per l’usuari, ha de tenir paràmetres que representin aquelles dades. Només el fet de prémer un botó, una opció de menú o esdeveniments així de senzills corresponen a transicions sense paràmetres.

Disseny extern: Aspecte estàtic (esboç de les pantalles)

Per a cada possible estat de la interfície d’usuari (pantalla) el diagrama de l’aspecte dinàmic del disseny extern ens mostra les possibles transicions que es poden produir, però no els tipus d’elements d’interfície gràfica que es faran servir i com s’organitzaran. Per a cada estat, doncs, cal fer un esboç on es mostri quins elements es faran servir.

Cada esboç s’ha de correspondre amb un estat del diagrama d’estats i cal identificar-lo clarament.

Normalment cada pantalla tindrà un títol visible al seu disseny extern que hauria de coincidir amb el nom de l’estat del diagrama d’estats.

A cada esboç de pantalla cal identificar la forma de fer cada una de les transicions del diagrama d’estats (no menys).

Si el diagrama d’estats indica que hi ha una transició altaEmpleat(nom, dni, dataNaixement), l’esboç de la pantalla ha d’incloure elements que ens permetin introduir un nom, un dni, una data de naixement i, finalment, confirmar l’entrada (per exemple, amb un botó amb l’etiqueta “D’acord”).

En un esboç de pantalla només han de ser possibles les transicions definides al diagrama d’estats (no més).

Si, des d’un determinat estat, no hi ha cap transició cancel·lar, no hauria d’haver-hi cap botó etiquetat “Cancel·lar” (que no es correspongui a alguna altra transició vàlida des d’aquell estat).

Quan no sigui obvi, cal indicar en un comentari al peu de cada esboç, la correspondència entre els elements d’IGU dibuixats i els esdeveniments identificats al diagrama d’estats.

Si es fa servir dos components de llistes i volem que, en arrossegar un element d’una llista a una altra es produeixi un des esdeveniments identificats al diagrama, aquest comportament no serà obvi a l’esbós de la pantalla. En tal cas, cal afegir un comentari explicant-lo.

Símbols utilitzats:

Validació: Característica que sempre cal comprovar

Indicador: Característica que sol ser indicadora d’algun problema, però que no és precisa com una validació.

Exemple: Exemple concret d’algun dels aspectes mencionats

Referències:

• [EPOO]: Jordi Fernández Gonzalez, Jordi Pradel i Miquel i Jose Antonio Raya Martos, Enginyeria del programari orientat a l’objecte. UOC, 2005

Value Object

En un anàlisi UML hi poden aparèixer classificadors (diguem-ne classes, si es vol) que no tenen semàntica d’objectes. Fowler diu que tenen semàntica de valor per oposició a la semàntica d’objectes amb referència.

Els valors (objectes amb semàntica de valor, segons Fowler) es comparen pel seu contingut, però no tenen identitat. Això fa que no tingui sentit pensar en termes de quina és la llista d’instàncies d’un tipus de valor en un sistema. Els objectes, en canvi, es comparen per la seva identitat, no pel seu contingut, i ens interessa saber quines instàncies en tenim al sistema.

Exemple

Vegem un exemple. Suposem que disposem d’un model conceptual molt senzill format per les dues classes següents:

En aquest cas, les classes Person i Department tenen semàntica de referència, ja que, efectivament, ens interessa distingir cada un de les instàncies que en tenim i distingim entre aquestes per la seva identitat.

Les “classes” String i Date (que podrien haver aparegut com a classificadors explícitament, en forma de caixa al diagrama) tenen semàntica de valor, ja que no ens interessa saber quines instàncies de Date o d’String hi ha al sistema i les comparem pel seu contingut (una data és igual que una altra si tenen el mateix dia, mens, any, etc).

Value Objects típics

Tots els tipus primitius es poden considerar objectes per valor. Des d’un punt de vista d’anàlisi m’agrada utilitzar tipus independents de llenguatges de programació, com ara, natural, enter, real, String, data, hora, etc. UML proposa una sèrie de tipus primitius que podem usar des del punt de vista d’anàlisi.

Altres Vaule Object són menys obvis i poden tenir, inclús, atributs:

• Quantitats: Un cas paradigmàtic és el resultat d’aplicar el patró Quantity de Larman [LAR], on indiquem una magnitud (com el preu d’un producte, per exemple) mitjançant valor i unitats (ex 12 €). Es dóna le cas que aquest cas particular del patró Quantity aplicat a diners és anomenat, per Fowler, patró Money.
• Intervals de temps: Resultat d’aplicar el patró Range, també de Larman
• Enumeracions: Com, per exemple, els mesos de l’any

Embedded Value

Fowler resumeix molt bé com tractar els Value Objects a l’hora de dissenyar bases de dades amb un bon exemple. Cito textualment (en traducció lliure de de l’anglès): “Cap persona amb dos dits de seny voldria una taula de valors monetaris”. El cas de les dates és més flagrant.

La solució que proposa en forma de patró Embedded Value és mapejar els camps del Value Object com camps de la taula que conté una referència cap a aquest Value Object. Això implica, evidentment, no crear taules per a aquests valors.

Així, per exemple, si una persona té una data de naixement, a la taula persona hi posarem una columna dataNaixement de tipus Date (com a primer exemple obvi). Si la persona tingués, a més, una associació cap a un Diner (quantiat i moneda) anomenada limitCrèdit, posaríem a la taula persona, dues columnes: quantitatLimitCredit i monedaLimitCredit.

Per si a algú li preocupa, en el cas que sobre aquesta base de dades estiguem desenvolupant una aplicació orientada a objectes amb Domain Model i Data Mapper, els bastiments de Data Mapper actuals solucionen prou bé aquesta solució. Hibernate, per exemple, permet mantenir aquesta estructura de base de dades però utilitzant una classe Java per a representar el tipus de dades (per exemple, la classe Diner). Per a més detalls, vegeu [HIB].

Referències

• [FOW] Fowler, M (2005). Patterns of Enterprise Application Architecture. Boston, US: Addison-Wesley
• [LAR] Larman, C. (2002). Applying Uml and Patterns: An Introduction to Object-oriented Analysis and Design. US: Prentice-Hall
• [HIB] Bauer C., King, G. (2007). Java Persistence with Hibernate. US: Manning

Fowler menciona a [FOW] un patró anomenat Identify Field consistent a representar la clau primària d’un registre d’una Base de Dades en forma d’atributs (en un Domain Model). El cas és que inclou una dissertació força bona a l’hora de triar una clau primària a la base de dades. Bona part d’aquesta dissertació és independent del fet d’aplicar o no Domain Model i, en general, independent del fet de desenvolupar o no aplicacions sobre la base de dades en qüestió.

Clau natural vs artificial

Una dels primers punts a discutir és si es farà servir una clau natural (és a dir, que té significat en el nostre domini, Fowler les anomena meaningful) o una clau artificial (sense significat propi, anomenades meaningless per Fowler). Si tenim una taula de persones, per exemple, una clau natural seria el DNI de la persona, mentre que una clau artificial seria un identificador numèric generat per la base de dades.

Per a que una clau funcioni correctament ha de ser única (evidentment) i immutable. Com comenta Fowler, les claus naturals no són immutables degut, principalment, als errors humans. Com que una clau natural té significat en el domini, és important que el seu valor sigui el que ha de ser. I per tant, en cas d’error, caldrà corregir-la.

Per tant, com a norma general, cal utilitzar claus artificials.

Clau composta vs clau simple

Una clau composta està formada per una combinació de camps que han de ser únics, mentre que una clau simple només té un camp.

Les claus simples són més senzilles de fer servir i manipular. En particular, des d’un punt de vista de bases de dades, és més senzill establir claus foranes cap a una clau primària si aquesta és simple. Les claus artificials són simples per la seva pròpia naturalesa, però les claus naturals poden ser tant simples com compostes.

Aleshores: Quan usar un substitut?

Resposta ràpida: Sempre.

Excepcions a la norma: Associacions M:N, o N-àries on N>2 sense classe associativa

Les taules que, des d’un punt de vista d’anàlisi, no es corresponen a cap classe no mereixen, sota el meu punt de vista, un substitut de la clau primària. Aquestes taules només es consultaran per a veure les relacions entre altres taules i no tenen altra informació que aquesta relació. Per tant, cada fila d’una d’aquestes taules es correspon amb una associació entre files d’altres taules. No té sentit que cada una d’aquestes associacions tingui un identificador propi, ja que mai les recuperarem per identificador.

Si l’associació té una classe associativa, però, l’analista està indicant que hi ha informació addicional. En tal cas, és possible que interessi identificar aquestes instàncies i, per tant, si que recomanaria usar substitut de la clau primària.

En aquesta excepció, la clau primària serà composta, però continuarà sent artificial si les taules a les que refereix l’associació tenen, al seu torn, claus artificials. I per tant, continuarà sent immutable.

Unicitat del substitut de la clau primària

Fowler menciona també un punt a tenir en compte. Un substitut de la clau primària es pot dissenyar de tal forma que sigui:

• Únic a la taula: No poden haver-hi, a la mateixa taula, dues files amb el mateix identificador. Però podria ser que hi hagi en alguna altra taula una altra fila amb el mateix identificador.
• Únic a tota la base de dades: No poden haver-hi en tota la base de dades dues files amb el mateix identificador. Però podria ser que en alguna altra base de dades existeixi alguna fila que fagi servir el mateix identificador.
• Únic globalment: No pot haver-hi en tot el món una altra fila amb aquest identificador

Resumint-ho ràpidament, els identificadors únics globalment són difícils de dissenyar i aporten aventatges relatius en la majoria de casos. Entre les claus úniques a la taula o a la base de dades, els avantatges i inconvenients sorgeixen en manipular aquestes files fora de la base de dades (per exemple, quan cal fer URLs per identificar recursos en una aplicació web o quan cal fer servir un data mapper). En aquests casos la meva experiència és que un identificador únic a la taula sol ser suficient.

Per a una discussió detallada de quina és la millor opció recomano llegir Fowler.

Referències

• [FOW] Fowler, M (2005). Patterns of Enterprise Application Architecture. Boston, US: Addison-Wesley
• [DBD] Sistach et al. (?) , Disseny de Bases de Dades. Barcelona: UOC

Un cop acceptem que és necessari assumir un cert grau d’acoblament al sistema, necessitem establir criteris per a decidir, entre dos acoblaments, quin és més greu per tal de mantenir un bon disseny. El propi Larman ens ofereix algunes pistes a la discussió del patró GRASP: Hem d’evitar l’acoblament cap als elements menys estables o amb més possibilitats d’evolucionar.

Però en Larman no és l’únic autor que ha tractat aquest tema. D’altres, com ara en Robert C. Martin, l’han tractat des del punt de vista de la gestió de dependències. El principi d’inversió de dependències diu que:

• a. Els elements d’alt nivell (d’abstracció) no haurien de dependre dels de baix nivell. Tots dos haurien de dependre d’abstraccions
• b. Les abstraccions no haurien de dependre dels detalls. Els detalls haurien de dependre de les abstraccions

D’aquest principi podriem extreure un altre criteri: Evitar els acoblaments cap a elements de més baix nivell d’abstracció.

Finalment, una tercera variable que hem de tenir en compte és que el concepte d’acoblament depèn de quina sigui la unitat organitzativa que volguem tractar. Per exemple, podem considerar els acoblaments entre classes, entre paquets, mòduls o subsistemes. En Robert C. Martin [MAR] dedica un capítol sencer a la gestió de l’acoblament entre paquets, mentre que altres autors com en Bertrand Meyer [MEY] o en Martin Fowler també tracten el tema de l’acoblament associat al concepte de mòdul o subsistema. Per tant, és molt important gestionar l’acoblament a nivell de paquets.

Recapitulant, doncs, ens trobem amb tres variables o criteris per decidir: La possibilitat de canvis, el nivell d’abstracció i la pertanyença a un mateix paquet. En realitat, però, si hem fet una bona organització de paquets, totes les classes d’un mateix paquet tindran un mateix nivell d’abstracció i, a més, hauran previst el mateix tipus de canvi, de manera que, si hem fet una bona organització de paquets, el criteri principal és evitar els acoblaments cap a classes d’altres paquets, especialment si el seu nivell d’abstracció és més baix que el del paquet de la classe en qüestió ja que son les que ténen més possiblitats de treballar a un nivell d’abstracció diferent o de canviar per motius que poden no haver estat previstos al disseny de la nostra classe.

Significa això que la resta d’acoblaments no s’han d’evitar? Mai. Això només significa que, en termes generals, hem d’evitar, de manera preferent, els acoblaments cap a classes que pertanyin a altres paquets. Per exemple, és una mala decissió afegir un acoblament cap a una classe d’un altre paquet per evitar un acoblament cap a una classe del mateix paquet.

Referències:

[LAR] Craig Larman, Applying Uml and Patterns, 3rd Edition
[MAR] Robert C. Martin, Agile Software Development: Principles, Patterns and Practices
[MEY] Bertrand Meyer, Object Oriented Software Construction