Modelo Unificado

En este modelo se relaciona la información de todos los concerns (del Modelo de Contenido), obteniendo un único modelo. Este modelo se deriva del Modelo de Contenido y la unificación se basa en la detección de las correspondencias entre las clases de los diferentes concerns. Para derivar la unificación se debe elegir uno de los concerns digitales como Core, según el dominio que se quiera representar. La información de los demás concerns aparece como roles [Cabot and Raventós, 2006] de las clases Core.

La composición de los concerns no se ve afectada según la elección del concern que actúa como Core, sino que se cambia el foco del concern principal de la aplicación. Si una clase no está representada en el concern Core pero aparece en otros concerns,

23 _{La notación simple usada en la Sección 3.3 se basa en la notación de OOHDM presentada} en [Nanard et al., 2008] para separación de concerns en Hipermedia.

se decide cuál de los concerns en los que aparece la clase es el más conveniente para que actúe como Core de la misma y las demás clases son roles de la clase elegida. Nunca el Core es el concern físico, al excluir este concern como Core se asegura consistencia con la Hipermedia de base. Si se necesita usar la aplicación de HM como una aplicación de Hipermedia tradicional basta con sacar el concern físico. De otra manera hay que reestructurar todo el modelo.

En la unificación de los concerns a un modelo único no se deben agregar ni sacar información ya sean concerns, clases, atributos o relaciones que hayan sido definidas en el Modelo de Contenido. El Modelo Unificado sirve para logra relacionar las clases representadas en los distintos concerns, las cuales modelan la misma clase de objeto desde diferentes puntos de vista.

El Modelo Unificado también puede ser representado como un grafo, el cual agrega al Modelo de Contenido la información respecto de las relaciones de rol que se establecen entre las clases Core y sus roles. La representación del Modelo Unificado como grafo se puede apreciar en la Definición 3.4.

UnifiedModel= (ClassesUnifiedModel, RelationshipsUnifiedModel, RoleOfUnifiedModel)

ClassesUnifiedModel = {Class1-UnifiedModel,..,Classn-UnifiedModel}

RelationshipsUnifiedModel = {<Classi,Type,Classj>:

(Type ∈ {association, agregation, composition,

generalisation, specialization})

and (Classi,Classj ∈ ClassesUnifiedModel)}

RoleOfUnifiedModel = {<Classl,RoleOf,Classk>:

(Classl, Classk ∈ ClassesUnifiedModel)and

(Classl ∈ Cj and Classk ∈ Ci, i≠j and (Ci,Cj ∈ ConcernsUnifiedModel))}

Definición 3.4: Grafo que representa el Modelo Unificado.

Se puede apreciar en la Definición 3.4, que la especificación de RoleOfUnifiedModel

requiere de la definición de los concerns (ConcernsUnifiedModel). Esto se debe a que

esta relación se establece entre clases de diferentes concerns. Los concerns del Modelo Unificado (ConcernsUnifiedModel) se pueden representar como subgrafos como

se puede apreciar en la Definición 3.5. Estos subgrafos se representan de la misma manera que los concerns del Modelo de Contenido (Definiciones 3.2 y 3.3).

ConcernsUnifiedModel = DigitalCsUnifiedModel U {PhysicalCUnifiedModel}

DigitalCsUnifiedModel = {DigitalC1-UnifiedModel,.., DigitalCn-UnifiedModel}

DigitalCi-UnifiedModel = (ClassesDCi-UnifiedModel, RelationshipsDCi-UnifiedModel)

DigitalCi-UnifiedModel es un subgrafo de UnifiedModel, por lo tanto:

ClassesDCi-UnifiedModel ⊆ ClassesUnifiedModel y

RelationshipsDCi-UnifiedModel ⊆ RelationshipsUnifiedModel

PhysicalCUnifiedModel = (ClassesPC-UnifiedModel, RelationshipsPC-UnifiedModel)

PhysicalCUnifiedModel es un subgrafo de UnifiedModel, por lo tanto:

ClassesPC-UnifiedModel ⊆ ClassesUnifiedModel y

RelationshipsPC-UnifiedModel ⊆ RelationshipsUnifiedModel

ClassesDCi-UnifiedModel = {ClassDCi-UnifiedModel:

(ClassDCi-UnifiedModel ∈ ClassesUnifiedModel) and

(ClassDCi-UnifiedModel ∉ ClassesDCj-UnifiedModel, i≠j) and

(ClassDCi-UnifiedModel ∉ ClassesPC-UnifiedModel, i=1..n)}

ClassesPC-UnifiedModel = {ClassPC-UnifiedModel :

(ClassPC-UnifiedModel ∈ ClassesContentModel) and

(ClassPC-UnifiedModel ∉ ClassesDCi-UnifiedModel, i=1..n)}

Como se menciono anteriormente, el Modelo Unificado se deriva a partir del Modelo de Contenido. Al grafo que representa el Modelo de Contenido se le puede aplicar reglas de transformación (de grafos) para obtener así el grafo que representa al Modelo Unificado.

En [Varró et al., 2002] se describe una forma para definir reglas de transformación para grafos en general. En [Kuske et al., 2009] se amplían estas reglas de transformación mostrando cómo usarlas para grafos que representan diagramas de clases de UML.

Usando como bases las ideas presentadas por [Varró et al., 2002] y [Kuske et al., 2009], a continuación, definiremos la regla de transformación necesaria para obtener el grafo que representa un Modelo Unificado a partir de un Modelo de Contenido. Según [Varró et al., 2002] una regla de transformación se define con un grafo izquierdo (L), uno grafo derecho (R) y eventualmente una condición necesaria que se debe cumplir para aplicar la regla. La regla (de transformación) se aplica a un grafo origen obteniendo un grafo resultante.

El grafo L sirve para identificar la estructura que se quiere reemplazar del grafo origen (en nuestro caso, el Modelo de Contenido), cada ocurrencia del grafo L se reemplaza por el grafo R obteniendo así el grafo resultante de la transformación (en nuestro caso, el Modelo Unificado). El reemplazo de las ocurrencias del grafo L por el grafo R sólo se realiza si se cumple, en el caso de estar especificada, la condición indicada en la regla.

La regla de transformación para generar el grafo del Modelo Unificado a partir del grado del Modelo de Contenido (ContentModel R3.1 UnifiedModel), sólo necesita definir cuando agregar las relaciones de rol entre las clases Core y sus contrapartes en los demás concerns. El resto del Modelo de Contenido pasa igual al Modelo Unificado.

La Regla de Transformación 3.1, muestra visualmente los grafos L y R definidos para esta regla. La condición para aplicar la regla es que la clase A del concern Cj sea un rol de la clase A del concerns Ci (roleOf(Acj) = ACi). Depende de cuales son las clases

Core elegidas, si se cumple o no esta condición, y sólo hay reemplazo de L por R

cuando dicha condición se cumple.

L R

Regla de Transformación 3.1: Establecer la relación de rol, entre una clase (Core) y sus contrapartes en los demás concerns.

Al Modelo de Contenido presentado en la Figura 3.13, le aplicaremos la Regla de Transformación 3.1, logrando como resultado obtener un Modelo Unificado. A continuación se muestra como a partir del Modelo de Contenido (Figura 3.13) y eligiendo diferentes concerns como Core, se pueden derivar diferentes Modelos Unificados. Esto es posible porque la Regla de Transformación 3.1 establece la condición que una de las clases sea rol de otra (que está en otro concerns). Por lo tanto, si varia el Core elegido, al aplicar la transformación se obtienen diferentes Modelos Unificados (cada uno con un Core en particular).

Si se toma el concern Tourist como Core entonces el Modelo Unificado queda conformado como se muestra en la Figura 3.14. Para las clases que no están

representadas en el concern turístico se debe elegir cuál es el concern Core de la misma, esto sucede con las clases Church y Monument. En la Figura 3.14.a estas clases tienen como Core el concern histórico mientras que en la Figura 3.14.b tienen como Core el concern arquitectural.

Hay otras clases que sólo están representadas en un único concern digital, en este caso se representan con ese concern como Core, como es el caso de las clases

ArchitecturalStyle y Architect.

Las clases que están representadas en un único concern digital y en el concern físico, como son Fountain y Monument, se toma como Core de las mismas el único concern digital.

a.

b.

Figura 3.14: Modelo Unificado tomando como Core el concern turístico.

El Modelo Unificado resultante de la transformación depende de cuál fue el Core

elegido para cada clase. Esto se puede visualizar en la Figura 3.14 donde a partir del mismo Modelo de Contenido (Figura 3.13) se obtuvieron dos Modelos Unificados diferentes, ya que al variar el Core de alguna de las clases la Regla de Transformación 3.1 da diferente resultado.

Hay diferentes criterios que se pueden usar para elegir cuál es el Core de una clase si esa clase no existe en el concern que se elige como Core de la aplicación. Una posibilidad es que sea al azar entre los demás concerns digitales que tiene la clase. Otra alternativa es tener priorizados los demás concerns y de esta manera poder elegir el concern Core de la clase según el nivel de prioridad de los mismos.

En el caso de tomar para el Modelo Unificado el concern histórico como Core hay un sólo modelo resultante al aplicar la Regla de Transformación 3.1, como se puede visualizar en la Figura 3.15.

Las clases ArchitecturalStyle y Architect son las únicas clases que no tiene una representación en el concern histórico, pero como estas clases aparecen en un único concern no hay otra opción de Core posible que el concern arquitectural.

Figura 3.15: Modelo Unificado tomando como Core el concern histórico.

Se puede observar que en ninguno de los Modelos Unificados presentados se pierde información, sino que cambia el foco de cual es el concern Core de la aplicación. Es decir, cambia el punto de entrada para cada clase. Como se pudo observar también en los diferentes Modelo Unificados presentados, el concern físico siempre se pasa como un rol de la clase Core.

Se pueden tener distintos Modelos Unificados a partir del mismo Modelo de Contenido. Permitiendo especificar según el Core elegido cuál va a ser el foco de la aplicación.