UML herencia y clases abstractas para estructuras de datos

Una pequeña entrada, para recordar todos los apuntes de UML que se han ido haciendo a los largo del tiempo en este blog.

La herencia sirve para solucionar en diseños de software, cuando una clase debe heredar comportamientos de otra, los ejemplos más habituales de herencia, son los de animales, el clásico de clase padre Animal, de la que herada Pajaro y por debajo de Pajaro se crea una clase hija tipo Canario o Loro.

Vamos a suponer que necesitamos definir un objeto, que estará representado por una cantidad variable de propiedades, como puede ser, el objeto persona, que puede tener una serie de propiedades, pero aunque muchas veces comunes, no siempre las mismas. Y no solo no siempre las mismas, sino que incluso a veces solo necesito una o dos y no quiero crear el objeto con todas sus propiedades.

Como se puede ver la realción entre Persona y la propiedad, es de (rombo vacio o blanco) agregación y no de compoosición, ya que el objeto persona está definido por sus propiedades, pero no tiene una relación tan fuerta como para ser una composición (rombo negro)



Como es habitual, vamos a complicar los ejemplos habituales de herencia, y poner un ejemplo de una estructura de metadatos, que ya de por si puede ser molesta, y esa estructura de metadatos, vamos a representarla en forma de que cada propiedad que tenemos en el sistema de metadatos, puede ser de diferentes tipos, en este caso, vamos a contemplar (Entero, lista de enteros, cadena, lista de cadenas, booleanos y fechas) esta lista puede alargarse lo que se quiera.


Para solucionar la estructura de metadatos que pueden tener nuestros datos, vamos a definir un objeto que tendrá un conjunto de propiedades, vamos a llamar al objeto

Una representación posible de la herencia en UML, consiste en el ejemplo que podemos ver justo debajo, donde las clases de tipo IntegerProperty...*Property, heredan de la calse AbstractProperty, de la cual heredan el parámetro name.

 

Una cosa curiosa del ejemplo que se puede ver en este caso, es que las clases hijas de AbstractProperty, no solo heredan de su padre, sino que también deben hacer sobreescritura "override" de los métodos que declara la interfaz IProperty.

Otras entradas de UML en este blog:

UML casos de uso escenarios
UML - Agregación vs composición
Diseño de clase asociativa