Entradas etiquetadas como UML

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.

Anuncios

, , , , ,

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

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

Definimos Actor como…

En teatro, un actor representa un papel según las indicaciones de un guión. Nosotros tomamos esa metáfora para indicar que un agente externo realiza una acción sobre el sistema, acción esta que puede ser capturada como un guión que sea parte de un caso de uso.

Es interesante observar que llamamos actor a toda entidad externa que demanda funcionalidad del sistema, ya sea un ser humano o un sistema de software; por lo cual el término usuario puede ser un poco limitado.

Normalmente representamos a los actores de nuestro sistema por medio de la simple imagen de una figura humana de rayas. pero dada la flexibilidad del UML es posible representarlo también como una clase estereotipada o bien, con una imagen provista por nosotros según algún criterio artístico.

La siguiente imagen ilustra las tres formas que he mencionado:

Fig. 1 – Tres formas de representar un Actor en un diagrama de UML

La especificación UML lidía con el lenguaje visual pero como en otras ocasiones esta no es más que una fracción de lo que queremos decir sobre nuestros modelos, en este caso, es de interes capturar información adicional de nuestros actores, para lo cual podemos pensar en tener una tabla como la siguiente para cada uno de ellos:

Nombre: Actor
Representado por: Nombre y datos de contacto del stakeholder que puede responder preguntas sobre este actor
Facilidades de comunicación: Protocolos o estilos de comunicación que el actor entiende.
Relación con otros actores: Relaciones de herencia o dependencia entre actores

Tabla 1 – Definición de un Actor

La definición anterior la podemos llevar en el cuerpo de comentarios de nuestro modelador UML y exportarlo a un documento de texto cada vez que sea necesario.

Los actores nos sirven para capturar a los usuarios del sistema pero también, son la forma en la que podemos expresar el contexto del mismo. Es decir, que los actores toman el lugar de cualquier entidad de interes con la que nuestro sistema interactua.

Pese a lo anterior, ciertas cosas generalmente vistas como externas al sistema no son considerados buenos actores. Los sistemas de persistencia como las bases de datos o los archivos, si bien externos, no son actores. Entre otras cosas, debido a que estos no demandan funcionalidad del sistema (son pasivos respecto a él) además, es de interes que estos elementos estén bajo la definición del diseño de nuestro sistema, por lo que puede resultar de más provecho considerarlos parte del mismo.

, , , , , , ,

15 comentarios

Tipos de Diagramas en UML

Grandes clásicos conocidos por todos, los diagramas de clases, distan mucho de ser los únicos definidos en el lenguaje. De hecho en la versión UML 2 existen trece (13) diagramas concretos y varias categorías de diagramas abstractos, creados como toda clase abstracta, para articular la presentación de los diagramas.

La siguiente figura UML muestra los tipos de diagramas:

Fig. 1 – Tipos de diagramas en UML2

En su momento detallaré cada uno de los tipos de diagramas, lo importante por ahora es señalar que existen dos grandes grupos: estructurales y de comportamiento; esto conforme a lo dicho sobre la presentación de modelos en UML.

Los diagramas estructurales presentan elementos estáticos del modelo, tales como clases, paquetes o componentes; en tanto que los diagramas de comportamiento muestran la conducta en tiempo de ejecución del sistema, tanto visto como un todo como de las instancias u objetos que lo integran.

Por otra parte, en la figura se ve que hay tres tipos de diagramas señalados en un color distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interacción. Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los menos conocidos. También aspiro a tener una descripción de ellos en los días por venir.

Hay que tener en cuenta, que cada diagrama sirve para documentar un aspecto distinto del sistema; el criterio para usarlos es el de tener algo que decir, una historia sobre nuestro sistema que debe ser contada; el tipo de diagrama que utilizaremos será el que nos dé mayor poder expresivo y solo muy difícilmente, la construcción de una serie de diagramas puede ser explicitamente ordenada por un método de desarrollo. Algunos sistemas simples serán bien documentados con pocos diagramas, en tanto que algunos sistemas grandes bien podrían beneficiarse de un conjunto mayor.

Entonces que valga la advertencia: no hacemos diagramas porque un método nos lo ordene, hacemos diagramas para contar algo importante de nuestro modelo, por lo que indicar que en un sistema haya que hacer tantos de tal o cual diagrama es una declaración objetable.

, , , , , , , , , ,

23 comentarios