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.

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.

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.

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.

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.

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.

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)

Ejemplo de análisis de caso de uso

Si el análisis pone en descubierto las partes de aquello que se ha visto como un todo, entonces el análisis de casos de uso ha de poner en descubierto las instancias que intervienen en el sistema a la hora de realizar la funcionalidad descrita en dicho caso de uso.

Para efectos de la tarea análisis de caso de uso, en su versión con modelo de domino, dichas instancias van a pertenecer a alguna de las clases descritas en el modelo de dominio. El objetivo del análisis va a establecer los detalles de la relación que es necesaria que tengan estas clases para lograr la funcionalidad descrita en el caso de uso.

Tomemos el siguiente modelo de dominio para el sistema de subterráneo (Metro) de una ciudad cualquiera:

Fig. 1 – Diagrama de clases del modelo de dominio del sistema metro

Y complementemos con el siguiente modelo de casos de uso; asumiendo de momento que los casos de uso han sido descrito en detalle en algún documento apropiado.

Fig. 2 – Diagrama de casos de uso del sistema metro

Finalmente, tomemos el caso de uso Compra de Ticket para completar nuestro ejemplo:

Nombre: Compra de Ticket.
ID: N/A.
Actor: Usuario del Metro.
Descripción breve: El usuario del metro compra un boleto del sistema luego del pago de la cantidad apropiada.

Tabla 1 – Detalles del caso de uso: Compra de Ticket

Ya armados con todos estos detalles, nos podemos hacer la siguiente pregunta:

¿Qué clases del modelo de dominio intervienen en el caso de uso?

No existe una respuesta necesariamente correcta, queda a juicio del analista el tomar una u otra clase según su visión y particular enfoque del problema; en mi caso, he tomado las clases Usuario del Metro, Venta de Ticket, y Ticket.

Luego de identificar que conceptos de nuestro modelo de dominio intervienen en el caso de uso, necesario ahora indicar cuales son los mensajes que estas instancias deben intercambiar para completar la funcionalidad. Este intercambio lo presentamos en un diagrama de UML, típicamente un diagrama de secuencia.

Fig. 3 – Diagrama de secuencia con el escenario de análisis
del caso de uso: Compra de Ticket

El resultado de nuestro análisis ha sido una primera versión de los mensajes que han de intercambiar las instancias de las clases Usuario del Metro, Venta de Ticket y Ticket, para lograr la funcionalidad requerida en el caso de uso Compra de Ticket.

Hay que fijarse que el modelo de domino original tenía pocos o ningún atributo o método para sus clases. El resultado del análisis es que ahora estas clases han sido detalladas un poco más, indicando para algunas de ellas (las que intervienen en el los escenarios de análisis) cuales métodos son necesarios e incluso, el proposito de cada uno de estos.

Cuando se parte de un modelo de dominio, el análisis de caso de uso no hace más que enriquecer este modelo, detallando como he dicho ya, cuales métodos son necesarios que estén presentes. Al final, el análisis habrá completado un esbozo de un modelo del sistema; modelo este que ya habrá asumido todos los requisitos de nuestros clientes y presentará una relación de clases capaz de instanciar lo visto en el análisis.

Queda por supuesto más pasos antes de contar con un sistema listo para su uso; es necesario que realicemos la integración con las clases de análisis (si las hemos usado) así como llevar a cabo el diseño del sistema; es decir, aún no estamos listos para programar, pero si estamos listos para diseñar.

Capacidades y Competencias

Cualquier organización, sin importar su área de trabajo, puede ser modelada como un conjunto de procesos, que buscan elaborar uno o más productos que estén de acuerdo con las especificaciones dadas. Esta definición abarca no solo a las empresas de software dedicadas al desarrollo, sino también a las dedicadas al servicio, a la adquisición o a la consultoría.

Incluso es posible pensar que la definición dada abarca a todas las organizaciones, sin importar si de dedican al software o no, sin importar si se dedican a la manufactura o al sector servicios e incluso, sin importar si se dedican a la búsqueda de un beneficio económico o por el contrario son una entidad estatal o de beneficencia. Todas las organizaciones persiguen objetivos, los cuales pueden ser caracterizados como productos de procesos realizados en conformidad con las metas y especificaciones dadas.

Entonces, podemos definir sobre esta búsqueda de la calidad, los siguientes dos conceptos:

Capacidad: habilidad de la organización, sistema o proceso, para realizar un producto que cumpla con sus requisitos. (ISO 3534-2)

Y también

Competencia: capacidad demostrada de aplicar conocimiento y habilidades. (ISO 19011)

Nuestras organizaciones deben contar con competencias suficientes para competir en el mercado, de lo contrario quedarán fuera de este. De ahí entonces, que el desarrollo de dichas competencias sea un interés constante en la dirección estratégica de toda organización, en particular de aquellas dedicadas al desarrollo de software.

Lo que llamamos mejores prácticas o simplemente prácticas, son referencias a las distintas capacidades que se han identificado como presentes en las organizaciones con éxito; complementadas cada una con la descripción de sus objetivos y productos típicos.

Existen gran variedad de mejores prácticas, por lo que en la industria han surgido varios esfuerzos por organizar estas en paquetes que faciliten su estudio y de ser posible, su asimilación por nuestras organizaciones. El objetivo de dichos paquetes de mejores prácticas, es la de establecer una ruta de mejora de los procesos, que vaya desde lo simple a lo más complejo, dando así una guía para los esfuerzos de mejorar que iniciemos.

Modelo de Dominio

Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física.

Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el análista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir.

El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterraneo de una ciudad cualquiera.

Fig. 1 – Ejemplo de Modelo de Dominio de un sistema de subterráneo

En este diagrama se ve que un Usuario del Metro tiene cero o más boletos, comprados estos en una maquina de Venta de Boletos; dicha maquina “crea” los boletos los cuales son consumidos en un viaje, el cual tiene una estación de origen y otra de destino. Finalmente se ve que una estación tiene una o más maquinas de venta así como empleados de limpieza, seguridad y operaciones.

Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cuanto detalle va a ser necesario y hasta donde llegar a modelar. El objetivo es capturar lo necesario para comprender donde va a funcionar el sistema que estamos diseñando y esto demanda una cantidad distinta de detalles cada vez.

El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.

En la aproximación llamada Desarrollo Guiado por Modelos al modelo de dominio se le conoce como Modelo Independiente del Computador o CIM, por sus siglas en inglés. El CIM es el que da inicio al proceso de desarrollo y ocupa el rol, tanto de modelo de requisitos como de modelo análisis.

Por otra parte, cuando se sigue una aproximación Centrada en Casos de Uso como RUP/UP, el modelo de dominio es utilizado como entrada en la tarea análisis de los casos de uso en la construcción de los llamados escenarios de análisis.

Es decir, y con esto quiero concluir, que el modelo de dominio ocupa un rol protagonico en el desarrollo moderno de software y constituye un artefacto que vale la pena tener en nuestros proyectos.