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.

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

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

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.

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.

Plantillas: Documento de Arquitectura del Sistema

La mejor forma de documentar la arquitectura de un sistema intensivo en software es la combinar en un mismo documento, tanto los detalles del diseño en UML como los detalles relacionados con la implementación en código del proyecto. Aspectos tales como la vista del modelo de datos o el esquema de paquetes pertenecen al primer grupo, en tanto que el lugar donde se puede conseguir el código y la estructura de directorios que se genera con este, son puntos a tratar en el segundo bloque.

Por otra parte, es necesario enlazar con los requisitos, de ser posible con los casos de uso, ya que de esta forma se deja en claro que parte del sistema se ha cubierto con la arquitectura que se pretende documentar.

Y de primero claro, podemos discutir el posicionamiento de la arquitectura, quizás indicando los principios de diseño que guiaron el desarrollo.

Finalmente, adjunto la plantilla del Documento de Arquitectura del Sistema:

Arquitectura del Sistema(Plantilla)

Si tiene problemas con esta plantilla y quiere tener algunas sugerencias sobre características deseables en un documento de arquitectura del sistema, tengo un post sobre la lista de Michael Stal que le puede resultar útil.

El Ciclo de Vida: Fase de Elaboración

La fase de elaboración es la encargada de determinar la solución técnica del proyecto. Así como durante la fase de inicio se determino el qué, ahora es necesario el como. Es esta fase durante la cual elaboramos los requisitos al nivel del diseño y por tanto, nos pone en posición de saber si el proyecto es técnicamente viable así como conocer la tecnología que vamos a utilizar durante la construcción.

El foco de la fase de elaboración se encuentra en las disciplinas de Diseño y Análisis; ya que estas son las encargadas de dar con la solución técnica. Aunque también hay un importante papel para la Gerencia del Proyecto, dado que en la fase de Elaboración es el punto donde debemos haber disminuidos y controlados los riesgos principales que pudieran dar al traste con el proyecto.

Es también la Fase de Elaboración el punto de no retorno para el proyecto. Una vez que dejemos atrás a esta fase y entremos en la construcción, los gastos serán tan elevados que se tendrá que tener muy en claro el alcance de la apuesta económica; es mejor detener un proyecto aquí, cuando se ha ejecutado menos del 25% del presupuesto que más adelante, donde los gastos son mucho mayores.

Típicos objetivos para esta fase son:

• Documento de Arquitectura del Sistema revisado y aceptado.
• Prueba de Concepto exitosa de todas las tecnologías novedosas a utilizar.
• Prototipo de la Arquitectura del sistema.
• Plan de Riesgos con los riesgos principales identificados y controlados.

El objetivo central es solo uno: responder si el proyecto es técnicamente viable con la solución o diseño propuesto.

Entonces, ahora como para el glosario:

Fase de Elaboración: Establece el como del proyecto; es decir: determina la solución técnica del sistema y la demuestra a nivel de pruebas de concepto. La Fase de Elaboración también es el punto donde se deben de haber controlado los riesgos principales del proyecto.

Finalmente, en cuanto a su duración, considero como sano una fase de elaboración de dos o tres iteraciones. Esto debido a la necesidad de realizar y probar el diseño, lo que genera una carga de documentación y de programación sensiblemente mayores a las que teníamos durante la fase de concepción. Por otra parte, en un proyecto típico, el gasto realizado es de aproximadamente el 20% del total del costo del proyecto; por lo que la ejecución del presupuesto si contamos también a la fase de concepción rondará el 25%.

Control de Calidad: Revisión por pares

Dado que el modelo de calidad generalmente aplicado al software es de naturaleza cualitativa, nunca se va a estar objetivamente seguros de haber alcanzado la plena coincidencia entre los requisitos y lo creado, es decir, la calidad. De hecho, la naturaleza subjetiva del proceso de calidad del software es tan inherente a él, que la única sugerencia sistemática sobre como lograr esta comprobación es la llamada Revisión por pares.

La idea de la Revisión por pares es permitir que otros profesionales reconocidos, diferentes a los que han creado el sistema, juzguen y den su opinión sobre el diseño u otros aspectos del mismo. De este modo se puede obtener un nivel de verificación -subjetiva- al menos independiente del juicio del autor original; de manera de tener la posibilidad de asegurar al cliente, que lo que se ha hecho es reconociblemente adecuado para lo que nos ha pedido.

Naturalmente que una organización debe contar con al menos un tamaño mínimo para aplicar la Revisión por pares. No es valido que quien diseñe sea al mismo tiempo quien revise. Sin embargo no es necesario que esa un consultor externo al desarrollador. Se puede confiar sin problemas en la profesionalidad de los revisores.

Como en toda auditoria -y la revisión es una- el enfoque es encontrar defectos, no para señalar errores de los autores, sino para identificar oportunidades de mejorar. Nos conviene recordar esto, ya que algunos egos se pueden ver heridos durante una revisión rigurosa del diseño; y no es este el efecto que se busca. La idea es incorporar los beneficios de la critica constructiva y no la de señalar errores personales.

La mecánica de este proceso de revisión ha de consumir algunos días, ya que se deben enviar los diseños a evaluación, dando suficiente tiempo como para que sean analizados correctamente. Luego, en reunión con el equipo de diseño, los revisores pueden emitir sus opiniones y observaciones, dando la oportunidad de hablar sobre estas ideas entre todos los interesados. Además, espero sea obvio, solo es posible aplicar la revisión por pares en aquellos proyectos que estén correcta y suficientemente documentados.

El siguiente diagrama ilustra los detalles de la actividad:

Fig. 1 – Diagrama SPEM de la Actividad Revisión por Pares

En este diagrama se deja ver que quien revisa (Software Quality Control en la imagen) realiza sugerencias y emite objeciones sobre los artefactos puestos a revisión; comentarios estos que son expuestos al trabajador del proyecto relacionado con los mismos. Opcionalmente se puede informar al cliente y naturalmente, es posible emitir un informe con todo lo realizado.

La pareja del Análisis

Si hacemos una pequeña encuesta, veremos que mucha gente asocia parejas de palabras como en una relación izquierda/derecha, de manera que no comprende la una sin la otra. Esto le ocurre a la palabra análisis que hace pareja, en el imaginario popular, con síntesis.

Nosotros trabajamos en la industria del software, por lo que no asociamos la síntesis como la compañera del análisis. En su lugar, ponemos a diseño, una elección que puede llevar a más de uno a confundir el diseño con alguna actividad de síntesis.

Para evitar estos peligros, veremos qué entendemos por cada una de estas palabras, en un estilo digno del glosario.

Análisis. Actividad mental de ver al todo como una colección de partes.

Síntesis. Actividad mental de poner en un todo lo que se ha visto por separado.

Diseño. Actividad mental de disponer las cosas para que al desarrollarse, se alcance la situación deseada.

Espero quede claro, que la síntesis consiste en ver desde las partes, la posibilidad de un todo; en tanto que el diseño es la disposición de estructuras temporales que son necesarias para que un algo se desarrolle según nuestros deseos.

No niego que alguien pueda ver alguna relación entre síntesis y diseño, pero espero que quede claro que al menos, son cosas diferentes. La síntesis pone juntas las partes, en tanto que el diseño manipula las partes con una intención posterior.

Nos estamos viendo.

Disciplina de Diseño

El diseño es el acto de disponer las cosas, de manera que al estas desarrollarse se llegue a los resultados deseados. La intención del diseño es crear estructuras temporales o intermedias, que al paso del tiempo den lugar a la forma definitiva y deseada.

En Ingeniería del Software, llamamos Disciplina de Diseño a las actividades que determinan la disposición de las clases, archivos ejecutables, código, datos, etc. que forman la estructura estática del sistema, de manera tal -lo digo de nuevo- de permitir a la hora de la ejecución, que el sistema exhiba la funcionalidad requerida.

Dado que el Análisis pone en descubierto las instancias que al colaborar dan lugar a la funcionalidad, nosotros podemos definir sobre esta idea que el Diseño se encarga de encontrar una relación de clases -elementos estáticos- que al entrar en ejecución nos permite instanciar lo visto por el análisis.

Finalmente, en palabras técnicas, como para el Glosario:

Disciplina de Diseño. Es la encargada de realizar los Casos de Uso al nivel del Modelo de Diseño; a fin de establecer las estructuras intermedias que conforme a las restricciones de la tecnología utilizada, son necesarias para instanciar en tiempo de ejecución aquello que sea necesario para satisfacer el requisito.

La cual espero, sea una definición entendible a la luz de lo dicho primero.

Centrado en la Arquitectura

Un Proceso Definido es una construcción mental; que organiza un conjunto complejo de conceptos. No es de sorprender entonces que sea útil el construir este Proceso en torno a una serie de conceptos o principios, que hagan más fácil la comprensión del todo.

Uno de los principios claves del método definido al que llamamos UP, es la declaración que dice: Centrado en la Arquitectura. Es este uno de los tres principios rectores del método, por lo que no debemos menospreciar su importancia.

Entendemos por Arquitectura los elementos centrales del diseño de un sistema. Pueden ser las abstracciones comunes, los fundamentos en código o la tecnología central utilizada. Sea cual sea el caso, la arquitectura es esa parte del sistema que describe lo fundamental de este, y que por tanto, mantenemos esencialmente inalterada pese a las adiciones y modificaciones que tenga el software.

Dicho formalmente, como para el glosario:

Arquitectura del Software: conjunto de elementos esenciales del diseño, que sientan la estructura común a todo el sistema y determinan sus posibilidades técnicas con miras a satisfacer los requisitos con un mínimo de riesgo técnico y con un uso apropiado de los recursos disponibles.

Es durante la Fase de Elaboración que se desarrolla la arquitectura, no solo por medio del diseño en un UML, sino que también se prueba, se implanta y se documenta. De todo esto se encarga la llamada Disciplina de Diseño.

El método lucha en todo momento por establecer y mantener una arquitectura viable, por lo que la conservamos durante la fase de construcción. La idea de arquitectura es de hecho tan importante, que es posible incluso argumentar que el riesgo tecnológico queda disminuido gracias a que una buena arquitectura nos da bases para evitar muchos problemas e incluso, para hacer factible técnica y económicamente a un proyecto.

Notemos que la arquitectura es uno de los principales puntos a ser sometidos al proceso de Revisión por Pares, dado su rol central en la obtención de un software de calidad; no solo para el esquema tradicional de características de calidad, sino también para el enfoque de concordancia que manejo en el blog.

Finalmente recordemos que los otros dos principios básicos son Iterativo Incremental y Guiado por Riesgos y Requisitos.