Archivos para 31 julio 2008

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

Estereotipos en UML

Si bien UML es un lenguaje apropiado para el modelado de sistemas de software, es indudable que estos sistemas van a contener tantas particularidades que ningún formalismo o lenguaje, va a poder describirlos todos a la vez. Es por esto que parte de la especificación del UML se dedica a definir mecanismos de extensión con miras a incrementar el campo de aplicación del lenguaje.

Uno de estos mecanismos de extensión, quizás el más usado, son los llamados estereotipos; pequeñas etiquetas que aplicadas a los elementos o relaciones de un diagrama indican significado adicional. Es decir, que por medio de los estereotipos vamos a poder aplicar las herramientas UML a nuevas áreas de modelado, presuponiendo que estas áreas trabajan con los conceptos básicos del lenguaje y requieren solo de expresar las ideas propias del sector.

La definición de un estereotipo es muy simple, basta con una tabla como la siguiente:

Nombre: include
Aplica a: dependencias entre casos de uso
Significado: El caso de uso base refiere al caso de uso incluido como parte de su flujo de eventos.

Tabla 1 – Especificación de un estereotipo

Luego, utilizamos esta definición como parte de nuestros modelos simplemente etiquetando a los elementos a los que aplica con el nombre del estereotipo.

El significado de un estereotipo puede estar más o menos formalizado, según nuestra necesidad; en aquellos casos en que se requiere una definición formal del nuevo significado, UML nos propone el Lenguaje de Restricción de Objetos u OCL por sus siglas en inglés.

Las herramientas de modelado más avanzadas pueden aceptar las definiciones de los estereotipos y comprobar que se haya aplicado correctamente en el modelo, a lo largo de todos los diagramas. Esto es una forma muy útil de incrementar la capacidad de las herramientas de software, transformándolas en medios útiles en áreas tan dispares como la planificación de proyectos o la simulación de eventos discretos.

Por ultimo, siendo UML un lenguaje visual, como parte de la definición de un estereotipo podemos incluir una imagen o icono de manera de hacer más atractivos y legibles a nuestros diagramas. De hecho, cuando vemos un diagrama UML con imagenes ocupando el lugar de elementos, lo que estamos viendo es en realidad, elementos estereotipados.

, , , , ,

4 comentarios

Plantillas: Plan de Iteración

El Plan de Iteración recoge la planificación detallada de un periodo corto de tiempo dentro del proyecto – una iteración. Entre otras cosas, debe identificar las actividades, los riesgos involucrados, los artefactos a actualizar o crear, las necesidades de adquisición de bienes o servicios y los hitos esperados durante la iteración.

Adicionalmente, esta plantilla contiene los rudimentos para la evaluación regular y controlada de la calidad de los productos y del proceso: las pautas de evaluación indicadas en el plan de iteración sirven para este fin. Se complementa esto con los detalles de la evaluación contenidos en el artefacto de Cierre de Iteración.

El documento es una variación de la plantilla de reportes, por lo cual no contiene número de versión y se identifica solo por la fecha de emisión.

Finalmente, he aquí la plantilla:

Plan de Iteración(en PDF)

Plan de Iteración(en Scribd)

, , , , , , , , , , ,

2 comentarios