Entradas etiquetadas como Artefactos

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 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

Características que debe tener un Documento de Arquitectura

Encontré en el blog de Angel “Java” Lopez, una traducción de la lista de características de un buen documento de arquitectura del sistema que es traducción del trabajo de Michael Stal, bávaro de origen, quien nos dice las siguientes características:

  • Describa la arquitectura de arriba a abajo: presente la visión general primero, y luego vaya tratando cada uno de los puntos más en detalle, ya sea de diseño o implementación.
  • Agregue un glosario: algo que podemos olvidar, pero muchos términos serán desconocidos o confusos, o peor, serán mal entendidos por alguien que tenga un contexto distinto al nuestro.
  • Cada vez que introduzca un término que se conoce por una sigla, no presuma que todo el mundo sabe qué significa: coloque la sigla, y las palabras completas que describe.
  • Que no exceda las 50 páginas: si es más extenso, no será leído en detalle. Recuerde que muchas personas que lo lean serán personas con cargos de responsabilidad, que pueden no tener todo el tiempo del mundo para leer su obra maestra.
  • Todos los documentos de arquitectura que entregue, deben usar la misma plantilla: distintos tipos de letras y formatos entre documentos, confunden a los lectores. La estructura debe ser la misma para todos: si usa una tabla de contenido, un resumen, una conclusión en un documento, deberá usarse en todos.
  • Si usa diagramas, úselos consistentemente. Si para explicar un concepto usa UML, cuando tenga que exponer un concepto similar siga con ese tipo de diagrama. Y use los mismos elementos: si en un diagrama UML usó algunos estereotipos, siga usándolos cuando sean necesarios, con las mismas notaciones e íconos.
  • Agregue referencias a otros documentos que pueden ser importantes para entender algún concepto o explicitar una fuente consultada.
  • Explique siempre cómo la arquitectura descrita cumple con los requerimientos que se quieren alcanzar. Debe haber una trazabilidad desde los requerimientos a la arquitectura definida.
  • Coloque al comienzo un resumen: sea gentil con el lector, prepárelo para lo que va a encontrar. Por lo mismo, si un documento lleva varias páginas y abarca varios temas, incluya un índice. Si es necesario, describa los prerrequisitos que debe cumplir de antemano un lector que quiera entender el documento.
  • Si tiene que entregar varios documentos, estructure el conjunto como un árbol. El documento raíz describirá la arquitectura desde un punto de vista alto, estratégico. Desde ahí, los documentos nodos hijo irán explicando los subsistemas relevantes, y los elementos que atraviesan los demás, como seguridad y escalabilidad.
  • Describa la especificación de la arquitectura, y cómo esa especificación puede ponerse a prueba, como cuando programamos “unit tests”.
  • Compruebe que el documento acompañe, describa la implementación actual del sistema. Sino, será una pérdida de tiempo para quien lo lee, y hasta puede provocar errores, al tomar decisiones sobre una especificación que no corresponda con el producto actual.
  • Describa las decisiones de diseño en detalle, que no quede solamente la descripción de la decisión tomada, debe quedar claro que hubo una decisión en ese punto, por ejemplo, mencionando alguna alternativa.
  • Relacionado con lo anterior, no sólo describa el “cómo” sino también el “por qué”. Es importante que otra persona entienda las razones que llevaron a tomar un camino en el diseño.
  • Si se refiere a algún software entregado con el documento, o a utilizar, incluya la versión del mismo: no presuma que será evidente cuál es la versión a la que se refiere.
  • Agregue diagramas y dibujos para explicar las decisiones de diseño tomadas. Los diagramas llevan tiempo de armado, pero el resultado vale la pena.
  • Explique los diagramas: una imagen vale más que mil palabras, pero también hay que entenderla.
  • Pida que otras personas revisen el documento. Uno siempre escribe desde su propio contexto, y tal vez lo que a nosotros nos parece claro, para otro no lo sea. Trate que sea una persona que no esté en el mismo proyecto, para probar si el documento es entendible para alguien que no está al tanto de los conceptos tratados.
  • Use un sistema de control de versiones: no pierda la historia del documento.
  • Escriba los nombres del autor o autores, y forma de contactarlos, en caso de ser necesario. Incluya fecha y hora de versión.
  • No tiene que escribir todo el documento desde el principio al fin: vaya utilizando otros documentos menores que haya producido durante el proceso de discusión y diseño de arquitectura, pero asegúrese su consistencia. Recuerde: ¿cómo se come uno un elefante? Bocado a bocado.
  • No necesita explicar el sentido de cada patrón usado: remita su descripción a la literatura especializada.
  • Como en todo documento, sea consistente en el uso de los tiempos verbales, el uso o no de la forma pasiva, la forma de usar pronombres, si “dialoga” o no con el lector, el uso de la primera o tercera persona.

Pienso que muchas de estas características valen también para los restantes documentos del proceso. Después  de todo, la claridad, la consistencia, el formato legible, el buen uso del lenguaje, el buen uso del UML, entre otras cosas son puntos que se toman en cuenta durante una Revisión de Forma y definitivamente tiene impacto en la calidad del documento.

Para ser justo con mis propios documentos, aprovecho para apuntar que ya varios de estos consejos se habían considerado en la progresión de documento en blanco y documento del proceso (véa también la segunda parte), por lo que hasta donde puedo ver, mi propia plantilla de arquitectura del sistema cumple con estas ideas.

, , , , , , ,

1 comentario

Selección de Artefactos de Requisitos

Dado que son muchos los posibles artefactos a incluir en un proyecto, es imperativo el desarrollar una visión de conjunto que nos permita escoger solo aquellos que son realmente capaces de otorgar valor al desarrollo. Esto es, necesitamos tener una visión o mapa estructural de todos los artefactos, para luego saber cual incluir en el desarrollo y cual dejar por fuera.

En este artículo analizaremos los artefactos de la disciplina de requisitos.

Primero tenemos los documentos básicos: El Documento de Visión del Sistema y El Glosario de Requisitos. Estos documentos son tan importantes que simplemente los tendremos siempre en nuestros desarrollos. En ellos tendremos el vocabulario del cliente así como la captura de las necesidades y las características de alto nivel de la solución propuesta. Ambos forman una suerte de paraguas que cobija a los restantes artefactos del proceso, tanto si son de requisitos como si son de otras disciplinas.

Para el resto de los artefactos de requisitos tenemos tres enfoques: el tradicional, los casos de uso y el dual o mixto.

El enfoque tradicional esta representado por el documento de Especificación de Requisitos del Sistema, que contiene los requisitos en un formato estilo “el sistema debe…”. En este enfoque, no dividimos los requisitos en funcionales y no funcionales, por lo que nos basta con un solo documento.

Por otra parte, en el enfoque de casos de uso, es necesario contar con algún tipo de documento para capturar los requisitos no funcionales, ya que los casos de uso como es sabido por todos, solo nos ayudan con los requisitos funcionales. El rol del documento de Requisitos Suplementarios es justamente este: complementar los casos de uso y documentar cualquier requisito no funcional al lado de cualquier requisito funcional que sea general a todo el sistema.

El ultimo enfoque es el dual. Es simplemente mantener tanto un documento tradicional de requisitos como un modelo de casos de uso. En este enfoque surge un nuevo artefacto: El Cruce de Requisitos; con cuya ayuda mantendremos el control de la duplicidad de cada requisito: una vez en el documento de especificación y otra en el modelo de casos de uso.

El siguiente diagrama muestra las relaciones entre estos artefactos, organizados en lo que llamamos un Artifacflow o Flujo de Artefactos. En este diagrama vemos la forma en que la información viaja desde la visión hacía los restantes documentos. Los rombos representan las decisiones que tomamos durante la creación del Caso de Desarrollo y el criterio de decisión.

Fig. 1 – Flujo de Artefactos de la Disciplina de Requisitos

Las decisiones son simples de plantear, aunque no necesariamente fáciles de contestar. ¿Debemos utilizar casos de uso o un enfoque tradicional? ¿Quizás debamos optar por el enfoque mixto? Finalmente, de utilizar casos de uso ¿vale la pena mantener un documento de requisitos suplementarios? ¿No es todo esto simplemente mucho trabajo?

La verdad es que si es un proyecto pequeño, tomar todos los artefactos es demasiado. De hecho, en un proyecto pequeño lo mejor es aprovecharse de un detalle interesante: en ciertas condiciones los artefactos se pueden combinar.

Un ejemplo de esto es el Documento de Visión. Dado que este incluye secciones suficientes para documentar requisitos no funcionales y considerando también que podemos hacer un anexo que cubra el glosario, es simple obtener un conjunto de artefactos combinados que resulten apropiados para un proyecto pequeño.

La situación es planteada en el siguiente diagrama:

Fig. 2 – Flujo de Artefactos de la Disciplina de Requisitos
para un Proyecto Pequeño

En el caso planteado, es de esperar que los costos de construir y mantener estos artefactos sean mucho menores que en el caso de tener documentos separados. Así que han de resultar mucho más adecuados para un proyecto de pequeñas dimensiones.

, , , , , ,

2 comentarios

Control de Calidad: Trazas

La moderna practica de la ingeniería del software se basa en la construcción de modelos que capturen progresivamente, el avance desde los requisitos al diseño y eventualmente, a la implementación y despliegue de la solución final. Esto representa un reto importante desde el punto de vista de la calidad ya que ha de existir alguna manera de seguir la pista de como se ha elaborado lo requerido a través de los múltiples modelos, hasta esa deseada implementación ejecutable.

La solución a este reto son las llamadas Trazas. A lo largo de los modelos, mantendremos notas y relaciones de realización de los casos de uso; de manera de seguir la pista de como se han dado solución a lo planteado como requisito. Es de observarse que las trazas son quizás, la única forma sistemática de comprobar que el proceso de desarrollo no ha tomado un camino propio y terminado por desarrollar algo diferente a lo solicitado.

Entonces, para el glosario:

Trazas. Indicaciones sobre la realización de los artefactos de un proyecto; indican la forma en que los artefactos se han elaborado respetando la información contenida en otros artefactos, generalmente de requisitos o previos en el proceso de desarrollo.

Las trazas son pues, un artificio de control que sigue la elaboración de modelos y artefactos a partir de lo indicado en algún otro documento. Es responsabilidad de todos en el proyecto de asegurar el fiel y cabal cumplimiento de lo requerido, por lo que también es necesario que todos se involucren en mantener las trazas entre los artefactos.

En lo que a los modelos se refiere, las trazas pueden adoptar la forma de un diagrama de paquetes, que muestre las trazas como dependencias estereotipadas de UML entre los modelos, aquí representados a su vez, como paquetes estereotipados. El siguiente diagrama ilustra el punto:

Ejemplo simple de trazas entre modelos UML

Fig. 1 – Ejemplo de Trazas entre Modelos UML

Por otra parte, en cuanto a los documentos, la forma más simple es la de mantener un anexo o apartado en cada documento, donde se indique cual documento con su número de versión y fecha, a sido tomado como insumo y a su vez, cuales son los documentos derivados que están en uso en el proyecto. La siguiente tabla muestra un ejemplo de esto:

Título del documento: Documento de Visión – v2.0 al 15 de mayo de 2008.
Responsable del documento: Iván Garcerant.
Documentos de insumo: Términos de Referencia – v1.0 al 20 de enero de 2008.
Documentos derivados: Modelo de Casos de Uso y Especificación de Requisitos Suplementarios.

Tabla 1 – Ejemplo de Trazas de Documento

Lo ultimo que vale la pena comentar, es que las trazas son auditadas por el equipo de Control de Calidad[*] (Software Quality Control – SQC) quienes se guían por estas para comprobar el buen estado del proyecto, en tanto que el sistema de trazas es diseñado por el equipo de Aseguramiento de Calidad[*] (Software Quality Assurence – SQA) como parte del diseño del proceso de desarrollo.

Entonces una vez más como conclusión: Las trazas son dependencias entre los artefactos, que indican la forma en que la información fluye por ellos, desde los requisitos hasta el diseño y la implementación; en UML podemos indicar trazas por medio de dependencias estereotipadas en tanto que en los documentos podemos hacer un aparte o anexo con esta información.

Es todo por hoy.

, , , , , , , ,

3 comentarios

Plan de Finiquito del Proyecto

Como parte del llamado Plan de Desarrollo de Software, se incluye la planificación de las actividades y pasos a realizar para dar por concluido el proyecto. Algo que por puntual, es evidencia de cuan detallado puede llegar a ser la planificación y gestión de un proyecto de software.

Veamos: el Plan de Finiquito y Cierre del Proyecto es típico que solo tenga unos pocos párrafos, explicando lo siguiente:

  • Formalidades para dar el finiquito al proyecto. En otras palabras, que documento ha de estar firmado por que representante de las organizaciones cliente y de desarrollo.
  • Procedimientos de devolución de equipos y recursos asignados al proyecto, tales como computadoras, manuales, etc.
  • Propagar el fin de proyecto al fin de los contratos de arrendamiento de oficinas, fin de la relación con los profesionales contratados, etc.
  • Procedimiento administrativo en la organización cliente para concretar el pago del proyecto.
  • Re asignación de los profesionales que han participado en el proyecto, indicando con quien han de reportarse.
  • Cualquier otra consideración que se considere pertinente.

En resumen: este plan es de pocos párrafos de extensión, y se suele incluir como parte del Plan de Desarrollo de Software. Simple, rápido y fácil, pero detallado y un signo de estar haciendo las cosas correctamente al planificar los detalles del proyecto; incluyendo su final.

Nos estamos viendo.

, , , ,

Deja un comentario

Definimos UML como…

Imaginemos de momento, una reunión entre el cliente y los ingenieros responsables de una obra en construcción. Digamos un puente o un edificio alto, da igual. En esta escena, seguramente se discuten temas importantes: ¿Cuando estará terminada la obra? ¿Estará ajustada al costo? ¿Estamos atrasados? Digan de nuevo ¿como es que se va a hacer esto?

Los ingenieros civiles así como los arquitectos presentes, se apresuran a explicar al cliente el estado de la obra, presentando en todo momento lo muy bien ajustado que esta la construcción a la planificación y al plano del edificio.

Esto es, a pesar de tener algo muy concreto que mostrar (¡y ese algo es hecho de concreto!) los arquitectos intentan mantener la calma y la confianza del cliente demostrándole que la obra física esta en sincronía con un papel muy grande lleno de líneas y letras, a las que de cariño llaman el plano de la obra.

Curiosamente el cliente se muestra satisfecho, solicita unos pequeños cambios y se retira de la reunión renovando sus votos de confianza en el equipo constructor.

Ahora imaginemos una reunión entre este mismo cliente, buen hombre que esta ocupado en mil y un proyectos diferentes, y un equipo de desarrollo de software. En esta escena, seguramente también se discuten temas importantes: ¿Cuando estará terminado el sistema? ¿Estará ajustada al costo? ¿Estamos atrasados? Digan de nuevo ¿como es que se va a hacer esto?

Hay que ver que son las mismas preguntas… ¿no es razonable esperar la misma reacción de los ingenieros presentes? Ok, son ingenieros de software en esta ocasión, pero la verdad es que desde un punto de vista psicológico, nuestro cliente esta esperando lo mismo que lo tranquilizo en su primera reunión. Él quiere ver un plano.

UML notación gráfica utilizada para describir sistemas de software. En su sentido más amplio, puede ser utilizado para representar desde los requisitos iniciales, pasando por el detalle del diseño y así hasta llegar a los detalles de la instalación y uso del sistema desarrollado.

Naturalmente que tratándose de la profesión experta en hacer modelos de sistemas es obvio que el UML tenga cualidades similares a estos; es así que los elementos del lenguaje visual UML se encuentran definidos en forma tal que constituyen ellas mismas un entramado de partes y relaciones, es decir, un sistema.

Dicho sistema de definiciones, organizadas y sistematizadas, presentadas en gloriosos y detallados documentos de definición es el resultado del Grupo de Gestión de Objetos u OMG por sus siglas en inglés. Dicho grupo es el responsable no solo de la especificación de UML, sino de otras tecnologías clave en la industria como Corba.

La construcción del UML es un trabajo que solo puede ser entendida aplicando al lenguaje en si, los mismos principios que se aplican en el desarrollo de software de calidad. De acuerdo con la OMG, la organización modular de la definición garantiza el cumplimiento del principio de abierto cerrado o en otras palabras, que nuevas características, elementos de modelado e incluso nuevos lenguajes visuales completos, pueden ser definidos a partir de los elementos del UML, sin dañar el entendimiento de los elementos reutilizados y permitiendo la interoperabilidad de las herramientas así como de los conceptos integrados en los modelos.

El elemento más conocido del UML desde el punto de vista de los usuarios del mismo, es el diagrama; o presentación visual de elementos y relaciones en sintaxis UML; este elemento es equivalente a un plano individual del sistema. Existen gran variedad de diagramas dentro de UML por lo que estos a su vez, son objeto de clasificación, conociendo en forma inicial los diagramas que presentan información estructural o estática, por oposición a aquellos que presentan información dinámica o del comportamiento del sistema. Es decir, que con UML tendremos todas las vistas deseables para documentar nuestras ideas sobre el software o sistema cuyo modelo estemos construyendo.

A efectos de tener un ejemplo, he de decir que la inmensa mayoría de las ilustraciones de este blog son en realidad diagramas UML, creados en concordancia con las reglas del lenguaje con ayuda de software especial de dibujo. Así que si se ven algunos artículos tales como ejemplo de análisis de caso de uso, se tendrán un buen conjunto de ejemplos de diagramas bien construidos.

Más adelante voy a documentar cada uno de los tipos de diagramas, así como los mecanismos por medio de los cuales funcionan las definiciones de los mismos, con miras a presentar, no solo el modo en que el UML es utilizado directamente la construcción de vistas del sistema, sino también en como lo podemos extender y personalizar a fin de contar con una herramienta de modelado que sea mucho más que solo cajas y rayas.

, , , , , , , ,

14 comentarios