Nota: Este artículo se puede econtrar traducido al español siguiendo este enlace

Introducció

Per resoldre la complexitat de la lògica de domini en un Sistema d’Informació, Fowler [FOW] ens proposa aplicar el patró Domain Model. Aquest consisteix en crear, a la Capa de Domini, un model d’objectes (Software) del domini que incorpori dades i comportament. D’aquesta manera, tindrem objectes que representen dades del nostre domini i que contenen regles de negoci associades a aquestes dades (comportament).

El primer pas per a aplicar aquest patró consisteix a crear l’estructura estàtica inicial per al model OO a partir del model d’anàlisi. Suposaré que aquest model d’anàlisi està disponible i que inclou, entre altres coses, un model conceptual de dades. El model conceptual de dades de l’anàlisi, expressat mitjançant un diagrama de classes UML, representa les dades que conceptualment el sistema manipularà i les estructura en forma de classes (amb atributs, però sense operacions), associacions, relacions de generalització/especialització, etc.

Per a crear un model del disseny, partirem d’associar a cada classe conceptual una classe software que representi aquell concepte, per a cada atribut conceptual, un atribut software, etc. Hi ha, però, una dissonància pel que fa a la capacitat expressiva dels models orientats a objectes de l’anàlisi i els del disseny, ja que certes eines que es poden utilitzar durant l’anàlisi no tindran una representació trivial en el llenguatge orientat a objectes que triem. És per això que caldrà aplicar aquest procés intermig d’adaptació del model a les capacitats del llenguatge. Alguns autors (especialment en l’entorn [UPC-ES2]) anomenen a aquest procés Normalització.

Per a la majoria de llenguatges orientats a objectes (sobretot per als majoritaris), caldrà plantejar-se especialment el tractament de:

• Associacions binàries
• Classes associatives
• Associacions no binàries
• Informació derivada
• Especialització/Generalització dinàmica

Associacions binàries

Les associacions binàries usades durant l’anàlisi associen dues instàncies de dues classes (que poden ser la mateixa) de forma navegable en tots dos sentits; és a dir, des de qualsevol instància (de tots dos extrems de l’associació) podrem navegar cap a les instàncies que té associades a l’altre extrem.

Els llenguatges de programació orientats a objectes, en canvi, permeten que una instància tingui apuntadors cap a d’altres instàncies, però que només tenen un sentit de navegació. A més, si una instància pot tenir més d’una altra instància associada, caldrà fer servir les capacitats del llenguatge per a representar conjunts (normalment, una llibreria de col·leccions).

Per a representar una associació d’anàlisi, per tant, farem servir dues representacions: Una a la classe origen, en un sentit de navegació, i l’altra a la classe destí en el sentit contrari. Per a cada sentit de navegació, la representació dependrà de la multiplicitat:

• Multiplicitat màxima igual a 1: Atribut del tipus de la classe destí de la navegació
• Multiplicitat màxima superior a 1: Atribut de tipus col·lecció d'instàncies de la classe destí de la navegació (normalment un Set, és a dir, un conjunt sense repetits)

Exemple

A la classe Persona, hi faríem servir un atribut opcional “departament” de tipus Departament i a la classe Departament un atribut “persones” de tipus Set<Persona>:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
class Persona {

Departament departament;

...

}

class Departament {

Set<Persona> persones;

...

}

Malgrat que podríem representar un diagrama de classes UML on totes les associacions haguessin estat transformades en atributs, aquest procés és prou senzill com per a que no sigui necessari. D’altra banda, si es representés cada associació en forma d’atributs, es perdria molta expressivitat gràfica al diagrama del disseny.

És per aquest motiu que, tot i aquesta etapa de transformació, normalment es continua representant les associacions de forma gràfica (al diagrama de classes del disseny) enlloc de representar-les com a atributs. La representació en forma d’atributs és més adequada per als casos en que mostrem el disseny detallat d’una única classe en un diagrama UML o bé quan mostrem directament el codi o pseudocodi d’aquesta mateixa classe.

Classes associatives (d'associacions binàries)

En cas de tenir una classe associativa per a una associació, l’enfocament vist per a les associacions binàries és insuficient, ja que perdem la informació continguda a la classe associativa. És per això que serà necessari transformar aquestes associacions.

La transformació a aplicar és:

1. Transformar la classe associativa en una classe (no associativa)
2. Transformar cada extrem de l'associació en una nova associació
3. Traslladar les multiplicitats
4. Afegir restriccions d'integritat

Traslladar multiplicitats

Per a traslladar les multiplicitas cal tenir en compte que per a una associació entre dues classes A i B, cada instància de la classe associativa tindrà associades una i només una instància de cada (A i B). En el sentit invers, cada instància de la classe A tindrà associades tantes instàncies de la classe associativa com instàncies de la classe B tingués associades i viceversa.

Afegir restriccions d'integritat

Donat que, en UML, no pot haver-hi dues instàncies d’una associació que associïn les mateixes instàncies de classe, ara no hi podrà haver dues instàncies de l’antiga classe associativa que tinguin associades les mateixes instàncies de les classes associades.

Exemple

Anàlisi:

Disseny:

Associació original

Una associació amb classe associativa que ha estat transformada mitjançant el procés anterior amaga l’associació directa entre les classes originalment associades. Així, a l’exemple, a la solució de disseny, la classe Persona ja no està directament associada a la classe Projecte. Si es vol mantenir l’associació directa entre les classes originalment associades, es pot mantenir l’associació com a derivada i, més endavant, resoldre aquesta informació derivada com sigui necessari.

Associacions no binàries

Els mecanismes de transformació descrits per a les associacions binàries tampoc són útils per a associacions N-àries on N > 2 (ternàries, quaternàries, etc.). En cas de trobar-nos-hi, serà necessari, doncs, adaptar també aquest tipus d’associacions.

L’adaptació a fer és la mateixa tant si l’associació té classe associativa com si no:

• Si no n'hi ha, afegir una classe associativa sense atributs ni associacions amb el mateix nom que l'associació
• Transformar la classe associativa de la matexia manera que per a associacions binàries

L’única precaució addicional que cal prendre és que en el cas d’aquest tipus d’associacions, traslladar les multiplicitats no serà tant directe com en el cas de les binàries.

Informació derivada

La informació derivada indicada en un anàlisi és informació que es pot calcular a partir de la informació no derivada (i que, per tant, és redundant amb ella) però que és interessant d’indicar i destacar. Si ens interessa traslladar aquesta informació derivada directament al model, ho podem fer de dues maneres:

• Materialització
• Càlcul

Materialització

La materialització de la informació derivada consisteix a mantenir, en tot moment, la informació redundant al sistema, de tal manera que es pugui consultar la informació derivada com si no ho fos. Per a fer-ho, el sistema s’haurà d’encarregar de mantenir consistent en tot moment tota la informació materialitzada, ja que, com s’ha dit, serà redundant amb altra informació al sistema.

Sota aquest supòsit, l’únic pas necessari pel que fa a l’aspecte estàtic del sistema, serà convertir tota la informació derivada en informació no derivada. Però un cop fet aquest pas, caldrà dissenyar cada cas d’ús del sistema (i, per tant, cada operació) tenint en compte que ha de mantenir sempre actualitzada aquesta informació redundant.

Càlcul

L’alternativa del càlcul consisteix a calcular de nou la informació derivada cada cop que es necessiti.

En aquest cas, al diagrama s’hi afegirà una operació per cada atribut calculat (amb el mateix nom que l’atribut, el mateix tipus de retorn que el tipus de l’atribut i sense paràmetres).

En el cas de les associacions derivades, caldrà afegir una operació per a cada extrem de l’associació que retornarà instàncies o conjunts d’instàncies de la classe a l’altre extrem en funció de la cardinalitat.

Exemple

Anàlisi:

Disseny:

Especialització/Generalització dinàmica

Una relació d’especialització/generalització dinàmica és aquella en que una mateixa instància pot canviar d’una a una altra sublcasse al llarg de la seva vida. Els llenguatges de programació orientats a objectes no permeten que una instància d’una classe pugui passar a ser d’una altra classe. Per a fer-ho, caldria destruir la instància i crear-ne una de nova, la qual cosa

implicaria copiar-hi els valors dels atributs i associar les instàncies que abans tenia associades (en tots dos sentits).

És per això que les relacions d’especialització/generalització usades durant l’anàlisi i que són dinàmiques, esdevenen un problema de disseny.

Una solució durant el disseny consisteix a aplicar el patró de disseny estat, que proposa associar l’estat de cada instància de la classe com una instància d’una nova classe estat. Però com que és un patró ben documentat, no s’entrarà a discutir a fons en aquest document.

Referències

• [FOW] Fowler, M (2005). Patterns of Enterprise Application Architecture. Boston, US: 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