Archivo para la categoría UML

Qué es un modelo?

Llamamos modelo a toda representación simplificada de la realidad, donde se han conservado aquellos elementos considerados importantes y se han descartado todo lo demás.

Los modelos son importantes dentro de la industria del software, y son utilizados para toda suerte de fines. Es posible apoyarse en el uso de modelos para entender y comunicar una enorme variedad de aspectos de nuestros productos de software e incluso, de los proyectos en si mismos.

En general, ya sea dentro de la industria del software o no, los modelos vienen a ayudar la comprensión de la realidad, al presentarnos solo aquellos aspectos o características de la situación que sean relevantes en un momento dado.

Pongamos un ejemplo. El New Beetle es un producto muy conocido de la compañía alemana Volkswagen y es el automóvil que podemos ver en la primera imagen. En este caso, es un automóvil de color negro.

Automóvil Volkswagen New BeetleFig 1. Volkswagen New Beetle.

Es posible decir mucho de este automóvil. Podemos indicar cualidades obvias, como que tiene cuatro ruedas, dos puertas, un volante, que su techo es curvo o cualquier otra que se nos pueda ocurrir. Aunque también es posible indicar cualidades más sutiles, como el hecho que el automóvil de la foto no tiene placa. Hemos de recordar que después de todo, el producto no es solo muy conocido, sino que lo que tenemos ante nosotros es una foto y por lo tanto, tenemos muchos detalles a la vista.

Es posible sin embargo, que en un momento dado lo que nos interese decir sobre el automóvil sean sus medidas. Si este el caso hemos de construir un modelo en el cual se eliminen todas estas cualidades observadas y se queden solo aquellas que permitan ver con claridad las medidas del automóvil.

Naturalmente siempre podremos comunicar nuestra versión simplificada del automóvil por medio de una imagen, quizás una imagen como la siguiente.

Esquema del Volkswagen New BeetleFig 2. Esquema del Volkswagen New Beetle.

Nuestra segunda imagen resalta el aspecto de interés: las medidas del automóvil. Al hacerlo nos presenta una vista inusual del producto real, quizás una que no tendremos ocasión de ver jamás en el mundo físico, pero que comunica en forma muy directa lo que necesitamos.

Un modelo es pues, definido como para el glosario:

Modelo: toda construcción hecha con información de una situación, idea o fenómeno real, en la cual hayamos resaltado ciertos aspectos de interés al tiempo que hemos ocultado todo lo demás.

Para construir modelos no hace falta necesariamente recurrir a diagramas e imágenes, pero es definitivamente una forma popular de hacerlo. Además de los planos o diagramas como los que se ilustran en el ejemplo del Volkswagen, contamos con herramientas más propias de nuestra profesión, como el lenguaje de construcción de modelos UML.

De esta forma, cuando se trate de aplicaciones de software, lo más común será encontrar modelos construidos y presentados por medio del uso del UML, actividad para la cual contamos con una gran variedad de herramientas útiles disponibles hoy en día, tanto comerciales como libres.

Anuncios

2 comentarios

Diagramas de Clase

De entre todos los tipos de diagramas UML, el más común y conocido es el diagrama de clases. Dicho diagrama ilustra una vista de los componentes estáticos del sistema, ya sean estos clases o módulos, indicando las relaciones entre estas y los atributos (datos) de las clases, así como sus métodos (código).

El diagrama de clases puede ser utilizado para presentar la vista estática del modelo de dominio, del modelo de diseño, o bien, del detalle de la implementación de un sistema en un lenguaje de programación orientado a objeto, como Eiffel, Java o C++. Para todos estos usos, lo que se desea es expresar las unidades en que el código se organiza -las clases- así como algunas características de estas, notablemente como dije antes, sus relaciones, atributos y métodos.

Es valido combinar los diagramas de clase con paquetes, dando lugar a un diagrama que muestra simultáneamente clases y paquetes. Dicha práctica ayuda a documentar elementos que estén en distintos paquetes pero que guarden alguna relación, aún cuando la especificación de UML habla de diagramas de tipos diferentes para los paquetes y las clases.

En este blog se encuentran muchos ejemplos de diagramas de clase, ya que se han incluido en los post que lo requieren como parte del asunto tratado. Algunos de estos son:

Por lo anterior, si se queiren ver ejemplos de un diagrama de clases, basta con dar un paseo por el blog, seguro encontrará muchos ejemplos apropiados.

, , , , ,

2 comentarios

Diagrama de definición de Elemento: UML::Classes::Kernel::Root

UML es un lenguaje de modelado capaz de describir sistemas como conjuntos de elementos y relaciones. Esta forma de describir sistemas es lo suficientemente potente como para poder describir las nociones del propio lenguaje UML como un conjunto de elementos y relaciones.

Como ejemplo de lo anterior podemos tomar el diagrama UML::Classes::Kernel::Root, parte del metamodelo de UML, en el cual se describe la noción de Elemento, en termino de sus relaciones con otros conceptos. Dicha descripción se presenta como un diagrama de clases convencional.

Fig. 1 – Descripción del concepto “Elemento” de UML
(Diagrama UML::Classes::Kernel::Root del metamodelo de UML)

Esta forma de definir los conceptos del lenguaje UML recurriendo a los propios mecanismos del lenguaje es conocido como Metamodelado y es uno de los puntos fuertes del lenguaje UML. Ahora, con el diagrama en mano, podemos ver los detalles del concepto de elemento simplemente leyendo las relaciones presentadas en el diagrama.

Por ejemplo, se deja ver en el diagrama que:

  • Un elemento puede tener cualquier número de comentarios. Cero, uno o más.
  • Un elemento puede o no, tener un dueño. En caso que lo tenga será único.
  • Un elemento puede ser dueño de cualquier número de elementos.
  • Las relaciones y comentarios son elementos a su vez.
  • Las relaciones tienen un tipo especializado: las relaciones dirigidas. Estas tienen un elemento de origen y otro de destino.
  • El origen y el destino de una relación dirigida puede ser el mismo elemento.

Entre otros posibles puntos mostrados en el gráfico.

, , , ,

3 comentarios

Casos de Uso: Herencia de Actores

La propiedad de mayor interés de los actores, más allá de su identidad, es la relación que estos guarden con los distintos casos de uso de nuestro sistema – las líneas que unen a unos con otros. Es decir que las dos partes más expresivas de un actor son el nombre propio y la activación de un caso de uso.

Aceptado lo anterior, la herencia de actores va a ser la distribución a lo largo de una jerarquía de roles, de las actividades a realizar, representadas estas como casos de uso. O lo que es lo mismo, la herencia nace como una forma de organizar los enlaces entre actores y casos de uso a fin de simplificar los diagramas y reducir la necesidad de presentar información repetida.

Nuevamente pero algo más técnico: a lo largo de la jerarquía de herencia lo que vamos a organizar son las activaciones de casos de uso de cada actor con ayuda de categorías intermedias o actores abstractos.

A diferencia de la herencia de casos de uso, considero que la herencia de actores es una práctica básica y que no tiene mayor problema en ser entendido por los stakeholders ni mucho menos, presenta problemas a los analistas. La razón es que la dificultad de la herencia de los casos de uso es la definición detallada de como los múltiples elementos de información de un caso de uso se comporta durante la herencia, dificultad esta que no existe en la herencia de actores por ser estos tan sencillos.

Como dije antes, la herencia de actores es una forma legible de mejorar la presentación de nuestros modelos, por lo que ejemplo que daré tiene por motivación el mejorar la legibilidad de un por lo demás, muy sencillo modelo de casos de uso.

A efectos del ejemplo, supongamos que trabajamos con un sistema de ventas, que permite tanto a los promotores como a los empleados del departamento de ventas el visualizar las existencias de productos así como la consignación de mercancía, pero que excluye a los promotores de la posibilidad de aceptar devoluciones. La situación es presentada en el siguiente diagrama de casos de uso:

Ejemplo de modelo de casos de uso sin herencia

Fig. 1 – Ejemplo de modelo de casos de uso sin herencia

Si se observa con atención el diagrama 1, se ve como las líneas de activación se cruzan entre actores. Claro que podemos tratar de organizar un poco mejor el diagrama para evitar esto, pero hemos de reconocer que esto solo será una solución temporal. Conforme se incremente la cantidad de casos de uso nos encontraremos una y otra vez en esta situación. No es solo una cuestión de estética, de utilizar líneas segmentadas bien podríamos llegar a hacer el diagrama por completo ilegible. Es entonces necesario un enfoque alternativo.

Dicho enfoque alternativo naturalmente va a ser la herencia. En el segundo diagrama se ven exactamente los mismos casos de uso y los mismos actores, pero se ha establecido una relación de herencia con respecto a un actor abstracto u operador como estrategia para presentar la información sin tanto barullo de líneas.

Ejemplo de modelo de casos de uso con relación de herencia entre actores

Fig. 2 – Ejemplo de modelo de casos de uso con herencia entre actores

En este segundo diagrama hemos indicado que el operador puede realizar las dos tareas comunes, en tanto que por herencia hemos dicho que los empleados del departamento de ventas son los únicos autorizados a aceptar devoluciones de mercancías. Aquí hay que notar que no he establecido una relación de herencia entre promotor y ventas, sino que por el contrario he introducido un actor abstracto nuevo, que articula la presentación del modelo sin correr el riesgo de equivoco: promotor no es ventas y ventas no es promotor. El hecho que compartan dos casos de uso si es algo digno de mención pero sus identidades siguen por completo desligadas.

La presencia de un actor abstracto puede ser considerada una fuente de ruido a la hora de explicar el modelo, pero dado que es solo para simplificar las líneas de activación encuentro que la sobrecarga de información no es nociva. Por otra parte lo que hemos ganado en claridad es en mi opinión, mucho mayor a lo que hemos sacrificado al utilizar una notación un poco más técnica.

, , , , , , , , , ,

13 comentarios

Las 4+1 Vistas

Un enfoque en la presentación de un sistema en UML es conocida como 4+1 vistas. Esta forma de documentar nuestros modelos divide lo que sabemos de él en cinco áreas:

  • Vista de Casos de Uso: que contiene requisitos desarrollados en las restantes vistas.
  • Vista Lógica: Muestra la estructura estática del sistema.
  • Vista Física: Muestra el despliegue de la aplicación en la red de computadoras.
  • Vista de Procesos: Muestra los hilos y procesos de ejecución así como la comunicación entre estos.
  • Vista de Desarrollo: Muestra la estructura en modelos del código del sistema.

Estas vistas se presenta tradicionalmente en una figura de cuatro cajas con un ovalo central que representa al modelo de casos de uso. Dicho gráfico no es UML pero al ser tan conocido no puedo menos que incluirlo en el post. La siguiente figura corresponde a esta imagen de la que hablo:

Fig. 1 – Diagrama simple del enfoque 4+1 vistas.

El enfoque 4+1 vistas fue desarrollado originalmente por Philippe Kruchten en 1995, el artículo original puede ser encontrado en la Internet en: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf.

De acuerdo al Sr. Kruchten, las distintas vistas del enfoque responden a las necesidades de las distintas partes interesadas: clientes, programadores, administradores, etc. Para cada uno de estos, se presenta una visión resumida del sistema con la información que requieren para satisfacer sus necesidades.

Es así que la vista de desarrollo le dice al programador como iniciar y organizar su código; la vista física ayuda a los administradores de sistemas a decidir la infraestructura que se ha de dedicar al sistema; la vista de procesos es útil para realizar análisis de integridad y tomar decisiones de integración con otros sistemas; finalmente, siempre de acuerdo con el Sr. Kruchten, la vista lógica le sirve a los usuarios y clientes a visualizar la funcionalidad que el sistema les provee.

Este enfoque es uno de los más extendidos en la literatura, sin embargo su aplicación es de alcance limitado en los tiempos modernos, donde las aplicaciones tradicionales han dejado su lugar a sistemas basados en Web. Es entonces un enfoque digno de estudio aunque es probable que en nuestros proyectos sigamos otras aproximaciones para la organización y presentación de nuestros modelos.

, , , , , , , , , ,

5 comentarios

Presentación de Modelos en UML

UML documenta los sistemas de software que modela desde dos puntos de vista básicos: dinámico y estático. Por modelado dinámico nos referimos al comportamiento del sistema en tiempo de ejecución, en tanto que por modelado estático nos referimos a la descripción de los componentes del sistema así como de sus relaciones.

El siguiente diagrama de paquetes ilustra la situación:

Fig. 1 – Modelo de sistema con parte dinamica y estatica.

Dicha división no significa que nosotros tengamos que dividir nuestros modelos en dos paquetes para acto seguido crear elementos y diagramas en cada uno de estos; muy por el contrario, la presentación de la parte dinamica y estatica se hace para cada modelo del sistema es decir, ya sea que estemos creando un modelo de requisitos, uno de análisis o presentando el modelo físico, en todos los casos tendremos diagramas que visualicen tanto el comportamiento dinamico como la estructura estatica del sistema.

Es mucho más habitual el presentar los sistemas con una colección de puntos de vista, y para cada uno de estos, mezclar diagramas dinamicos y estaticos.

, , , , ,

3 comentarios

Tipos de Datos Primitivos de UML

En parte de la especificación de UML se detalla los llamados tipos de datos primitivos, que son los tipos mínimos que conocemos aún antes de comenzar a definir clases en nuestros modelos. La especificación nos habla de cuatro tipos primitivos:

  • Integer: números enteros tal como los conocemos. Incluyen tanto los positivos como los enteros así como el cero.
  • Boolean: tipo de dato lógico, acepta los valores true y false; representado los valores de una expresión verdadero/falso.
  • String: tipo de dato de texto o de cadena de caracteres. El nombre viene de la palabra inglesa cadena.
  • UnlimitedNatural: Son enteros igual o mayores a cero, el valor de infinito se denota con un asterisco: *.

El siguiente diagrama de clases es tomado de la especificación de UML (conocida como meta-modelo de UML) y presenta los tipos de datos primitivos como parte del paquete respectivo: UML::AuxilliaryConstructs::PrimitiveTypes:

Fig. 1 – Diagrama del paquete PrimitiveTypes del Meta-modelo de UML

Estos tipos de datos primitivos son los únicos que legitimamente vamos a utilizar en la sección de atributos de nuestras clases; para todos los restantes elementos de datos se debe preferir por presentar una relación entre clases. Es decir, que las variables que colocamos en la sección de atributos de las clases van a ser casi sin excepción, de uno de los tipos primitivos: Integer, Boolean, String, UnlimitedNatural.

, , , ,

1 comentario