Diagramas de secuencia y de colaboración

Estoy escribiendo sobre estos diagramas a pesar que son un tema bastante transitado dado que últimamente he recibido varias consultas sobre estos; y he observado que conceptualmente no se llegan a comprender para que sirven y eso lleva a que no se puedan aplicar correctamente.

Primero que nada hay que entender que son una forma más de comunicación en el marco de la definición de la arquitectura del proyecto y por lo tanto puede aplicar o no dependiendo del objetivo y las características del proyecto. En segundo lugar debemos tener en cuenta que son diagramas complementarios es decir no son excluyentes entre sí, de hecho tienen el mismo poder de expresión en cuanto a la comunicación de una idea.

Se dice que son diagramas dinámicos puesto que complementan a los diagramas de clases, componentes y paquetes en términos de ejecución de las instancias de las abstracciones diseñadas. El valor que agregan estos diagramas esta en que el arquitecto puede transmitir su idea de como deben implementarse los algoritmos que utilizan las transacciones.

A la pregunta, sobre si debo hacer un diagrama para cada proceso; mi respuesta es no necesariamente. La idea es que puedas tomar una muestra representativa de los procesos a desarrollar y a través de estos diagramas contarle a tus programadores cual es tu idea sobre el estilo y el uso de las abstracciones para que con ello se puedan guiar el desarrollo del resto de los procesos que no se han desarrollado. Como se trata de una herramienta de comunicación debes considerar el nivel de detalle necesario para contemplar todos los casos, recuerda que aquello que no pongas nadie lo podrá deducir.

El nivel de detalle que deben llevar dependerá no solo de la complejidad de los procesos sino también del tipo de recursos con los que cuentes; no es lo mismo diseñar para un rookie que para un experto.

En ambos tipos de diagramas lo que estamos mostrando son instancias de abstracciones, los mensajes que se envían entre sí y el orden en que lo hacen por eso se dice que tienen la misma capacidad de abstracción. Sin embargo los diagramas de interacción suelen ser mejores para procesos sincrónicos mientras que los de colaboración suelen serlo para procesos asincrónicos.

No hay una forma única de hacerlos, la efectividad que tengan dependerá del contexto. Tampoco son ya la herramienta de comunicación por excelencia pero suelen utilizarse aun en proyectos de gran porte.

Hay mucho para hablar sobre este tema, puesto que es muy amplio y no quiero hacer de este post algo exagerado, mi recomendación para encararlo es que habiendo analizado mis observaciones anteriores te los tomes como si estuvieras programando en "papel" y tus lineas de código en realidad fueran figuras. Esto no solo te ayudará a concentrarte en el diseño al máximo sino que te guiará en el nivel de detalle necesario. Y claro siempre puedes obtener feedback de tus diseños y así ir mejorando hasta encontrar tu estilo.

Un apunte sobre patrones de diseño

Durante el último examen puse un ejercicio de aplicación de patrones de diseño que me permitió descubrir que es mas difícil entender los contextos de aplicación de lo que yo pensaba. En este examen el ejercicio fue el siguiente: 

... se necesita un componente que permita acceder a documentos PDF en dos modalidades: una resumida que sirva como referencia al usuario para que pueda decidir cual documento abrir. Una vez que lo haya decidido, y ejecutado la acción de abrir documento, debe obtenerse el documento real. Proponga un esbozo de solución para el diseño del componente.

Esta claro (o al menos eso espero) que la respuesta es "necesitas un proxy" porque se trata de un recurso. Sin embargo recibí respuestas de toda índole, como por ejemplo:

• Composite, a lo cual digo NO porque es para modelar estructuras recursivas
• Template Method, a lo cual digo NO porque es para modelar algoritmos reutilizables
• Factory Method, a lo cual digo NO pues es para decidir que tipo de objeto crear
• Strategy, a lo cual digo NO pues es para decidir cual algoritmo utilizar dado el contexto
• Proxy,  a lo que digo SI pues es para modelar representantes de objetos costosos

No hay que olvidar que todos estos patrones tienen una implementación similar puesto que aprovechan las ventajas de la herencia y el polimorfismo para dar la solución al problema; pero esto no quiere decir que sean lo mismo.

Cuando te enfrentes a un problema de diseño de software recuerda, tener presente mis comentarios anteriores para que puedas utilizar las herramientas correctas en los momentos correctos y así utilizar al máximo la solución que te proponen.

Indices de rendimiento para gestión por valor ganado

Anteriormente hemos presentando la técnica de Valor Ganado para realizar el seguimiento de tus proyectos de forma empírica en términos financieros y de uso del calendario. Concomitantemente a ello existen una serie de indicadores que podemos utilizar para evaluar nuestra performance y así poder analizarnos y así (si corresponde) tomar acciones correctivas.

Considerando la nomenclatura presente en la imagen anterior respecto de los conceptos involucrados en la técnica. Los indices son

• CPI (Cost performance Index) es la relacion entre el trabajo realizado y el gasto que hemos hecho para poder realizarlo. De acuerdo con esto se define como EV/AC.
• SPI (Schedule performance Index) es la relación entre el trabajo realizado y el trabajo planificado por lo tanto se define como EV/PV.
• CV (Cost Variance) se trata de la diferencia entre el trabajo conseguido y el costo incurrido para conseguirlo. Por lo tanto se define como EV-AC
• SV (Schedule Variance) es la diferencia entre el trabajo conseguido y la planificación para el trabajo previsto por lo que se expresa como EV-PV

Lo interesante de estos indicadores es que si los combinas por pares (SPI con CPI y por otro lado SV y CV) y los presentas en un cuadrante puedes observar un modelo compuesto para tu proyecto. Como imaginarás la situación ideal es que SPI = CPI = 1 mientras que SV = CV = 0 lo que quiere decir que estas totalmente ontrack es decir ejecutando tu proyecto según lo previsto. Sin embargo puede ocurrir que: 

CV sea negativo: entonces los costos estarán por encima de lo previsto. CV sea positivo: entonces los costos estarán por debajo de lo previsto. SV sea negativo: tiempo invertido está por encima de lo previsto. SV sea positivo: tiempo invertido está por debajo de lo previsto. CPI menor a 1 entonces los costos estarán por encima de lo previsto. CPI sea mayor a 1 entonces los costos estarán por debajo de lo previsto. SPI  sea menor a 1 entonces el tiempo invertido estará por encima de lo previsto. SPI mayor a 1 entonces el tiempo invertido estará por debajo de lo previsto.

A partir de los criterios que te mencionaba antes es que terminas de armar tu cuadrante para analizar. Como vez en las imágenes lo pintado en verde estaría bien; mientras que lo que ves en rojo estaría mal y esto último significa que deberás de tomar acciones para corregir la situación y así volver el proyecto al curso.

Técnicas para el análisis causal

Durante el año 2012 me encontraba estudiando profundamente el estado del arte sobre el análisis causal, buscando una forma de mejorar el proceso. Uno de los primeros objetivos que fijé fue relevar cuales eran las técnicas que se estaban utilizando para desarrollar esta práctica. Lo que aquí les presento es parte de los hallazgos durante la revisión:

El diagrama de Ishikawa es la técnica más utilizada, la evidencia analizada muestra que los diagramas causa-efecto de Ishikawa (alias espina de pez) son la técnica más utilizada para la implementación de actividades de DCA en la industria del software.

Sin embargo encontré otras igual de interesantes y que puede decirse que no son de uso tradicional, sin embargo sí que vale la pena considerar:

Mapas Mentales (Mind Mapping) es una técnica desarrollada por Tony Buzan desarrollada para rastrear y registrar pensamientos. Debido a que el cerebro procesa información a alta velocidad es imposible documentar e incluso recordar todos los pensamientos e ideas que van surgiendo. Entonces ya que el ser humano habla en palabras y piensa en imágenes, esta técnica incorpora ambas en el proceso mientras intenta documentar todos los pensamientos que sea posible.

Pensamiento sistémico (Systemic thinking/system dynamics) fue desarrollada por Jay Forrester et. al. del MIT. Esta técnica ilustra las interrelaciones dentro de un sistema, basado en diferentes objetos que forman parte del sistema. Así pueden ser identificadas varias relaciones causa-efecto con el efecto de cada ciclo dentro del sistema. En el pensamiento sistémico cualquier elemento (variable) en una situación, se pueden trazar flechas (eslabones) que representan la influencia de un elemento sobre otro. A su vez estos revelan ciclos que se repiten una y otra vez, mostrando como varían las situaciones. Por lo tanto en el pensamiento sistémico, a diferencia de otras herramientas de diseño lineal se admiten ciclos. En el contexto de la ingeniería de software, esta técnica fue utilizada fue utilizada para explicar cómo los procesos de software funcionan.

Mapas Cognitivos (Cognitive Mapping) es una técnica fundada sobre la teoría de constructos personales de George Kelly. Esta técnica está basada en conocimiento causal. Su objetivo es la representación de conceptos y relaciones causales. La representación de esta técnica está dada por grafos. Los mapas cognitivos son en una forma un modelo grafico y cualitativo cuyo foco esta en las relaciones causales abstractas entre conceptos. Son utilizados como soporte a los procesos de adquisición de conocimiento y toma de decisiones.

Modelo de Ecuaciones Estructurales (SEM por las siglas en inglés para Structural Equation Model) es una técnica fundamentada sobre la teoría estadística. En esta técnica información de causa-efecto cualitativa es combinada con datos estadísticos para proveer de valoración cuantitativa de las relaciones causa-efecto entre las variables de interés. En el contexto de ingeniería de software, SEM propone un enfoque cuantitativo para predecir debilidades especificas de las organizaciones respecto del proceso de software basado en las relaciones causa-efecto entre áreas del proceso que pueden tener efecto sobre el resultado y las medidas resultantes en el proceso especifico de una organización de software.

Modelos Gráficos (Graphic Model) es una técnica fundada sobre la unión entre la teoría de probabilidad y la teoría de grafos. Así las relaciones causa-efecto dentro de un modelo causal son significativas estadísticamente cuando la técnica es utilizada bajo ciertas condiciones especificas. En el contexto de la ingeniería de software, los modelos gráficos son utilizados (como parte de SEM) para la predicción de debilidades especificas de los procesos de software de una organización basado en el estudio de las relaciones causa-efecto.

Modelo Causal Estructural (SCM por las siglas en inglés para Structural Causal Model) es una técnica creada por Judea Pearl y desarrollada para ser aplicada en ciencias cognitivas y ciencias sociales. La técnica combina muchas de las ventajas de los modelos causales tales como: SEM y modelos gráficos. En el contexto del software, SCM ha sido aplicado para el análisis de causa-efecto en proyectos de desarrollo de inteligencia artificial (AI).

Análisis de Causa Raíz (Causal Path Analysis) es una técnica desarrollada y descrita por Simon, Blalock et. al. se trata de una herramienta simple y muy poderosa basada en mapas cognitivos para explorar relaciones causa-efecto entre variables, utilizada en el contexto de ingeniería de software como parte del análisis de relaciones causa-efecto en proyectos de AI.

Análisis de Gráfico Radial (Radial Analysis Chart) esta técnica es en el contexto de ingeniería de software, una propuesta para extender los diagramas radiales (Radial Charts) para el análisis de defectos de forma de ser utilizadas para DCA, en donde cada banda radial representa un elemento al cual puede atribuirse un defecto (Henderson, 2008).

Modelo Basado en Reglas (Rule-based Models) se trata de una forma común de modelo computacional. Básicamente es un conjunto de clausulas denominadas reglas las cuales codifican conocimiento acerca de los fenómenos que están siendo modelados. En el contexto de ingeniería de software, esta técnica es aplicada como parte de un sistema de predicción de defectos multi-modelo.

Teoría Relacional para Mapas Causales (Relational Theory for Causal Maps) básicamente es un grafo dirigido que representa afirmaciones individuales sobre creencias respecto a su entorno. En el contexto de ingeniería de software, este tipo de enfoques es utilizado habitualmente en proyectos de AI y es aplicable únicamente en el caso de grafo sin ciclos.

Esto son solo parte de los hallazgos de la revisión, lo interesante de aplicar el método científico a una búsqueda es que no solo generas una evidencia que respalde los resultados sino que también obtienes un método que hace de la búsqueda un sistema.

Representación Informática del Conocimiento

Durante desarrollo de este artículo presentaremos diferentes aspectos relacionados con la fase de formalización y la representación de informática del conocimiento, basados en la visión de la ingeniería del conocimiento que nos presentan A. Gómez y colegas en su libro Ingeniería del conocimiento [1]. Hemos de iniciar nuestro análisis de estos tópicos, describiendo algunos términos importantes en relación con el objetivo de estudio.

Un modelo conceptual es según [1], una representación de los conocimientos del experto, externa al ordenador, en estructuras no computacionales. Mientras, que un modelo formal es de acuerdo con [1], una representación semi-computable de los conocimientos y conducta del experto.

De acuerdo con la visión de los autores [1], con la finalización de la etapa de conceptualización, termina el trabajo de modelado del problema desde el punto de vista del dominio y se pasa al modelado del problema desde el punto de vista del sistema, este último es el objetivo de la fase de formalización. En donde se han de transformar los modelos conceptuales obtenidos en nuevos modelos formales, utilizando para ello los formalismos de representación de los conocimientos.

A grandes rasgos de acuerdo con los autores [1],  el hecho de formalizar, implica el representar simbólicamente los conocimientos mediante alguno de los formalismos existentes, organizarlos de acuerdo con algún modelo de diseño y determinar los métodos de inferencia adecuados para manejar eficientemente dichos conocimientos. Con el objetivo de representar los conocimientos del experto en el ordenador [1], se han de utilizar aquellos formalismos o técnicas de presentación de los conocimientos.  Dado que son múltiples los formalismos que permiten representar los conocimientos de un dominio, con este artículo hemos de presentar algunos de los más relevantes según los autores.

Tipos de formalizmos

De acuerdo con los autores consultados [1] el rendimiento de un sistema basado en conocimiento, SBC de ahora en adelante, depende entre otras cosas del formalismo que se haya utilizados en la representación de los conocimientos, y de las técnicas empleadas para realizar inferencias. Dado que no existe una técnica de presentación universal que permita modelar todos los conocimientos de un problema previamente conceptualizados.

Una de los primeros tópicos a estudiar [1] es la capacidad de representación del formalismo que hemos de seleccionar en relación con los conocimientos, en este sentido los autores presentan una clasificación para los formalismos basada en la representación de: conceptos, relaciones o acciones, destacando entre ellos:

• a) Basados en conceptos: de acuerdo con los autores [1] estos, representan las principales clases y entidades del dominio, sus propiedades, y los posibles valores que puede tomar cada una. Como caso de estudio en este artículo analizaremos los Marcos o Frames.
• b) Basados en relaciones: lo cuales de acuerdo con los autores [1] centran su atención en las relaciones que aparecen entre los conceptos o entidades del dominio. De este grupo, en este artículo hemos de profundizar sobre las redes semánticas.
• c) Basados en acciones: De acuerdo con los autores [1], estos describen los conocimientos del dominio como un conjunto de acciones básicas. En este grupo aplicaremos como caso de estudio Guiones.

MARCOS

De acuerdo con lo establecido por los autores [1], el formalismo de Marcos, en inglés Frames, fue definido por Minsky como una estructura de datos para representar estereotipos. Básicamente, está formado por un nombre y un conjunto de propiedades.  Los conocimientos que allí se representan son conocimientos declarativos del dominio.

Los marcos [1] organizan los conocimientos del dominio en árboles, también llamados jerarquías, o en grafos, ambos construidos por especialización de conceptos generales en conceptos más específicos. 

Para representar los conocimientos [1], los conceptos que se deben utilizar son: marcos para representar conceptos, relaciones para expresar dependencias entre conceptos, propiedades para describir cada concepto, y facetas  para expresar de múltiples formas los valores con los que se puede rellenar cada propiedad.

Los conceptos [1], se representan a través de marcos clase y marcos instancia, donde el primero representa entidades genéricas y el segundo representa los elementos instancia de las anteriores entidades. 

Este formalismo [1] soporta también relaciones entre conceptos y las representa, precisamente, con relaciones entre marcos clase, entre marcos instancias y marcos clases, y entre marcos instancia. Permite entre estas, ciertas relaciones que son independientes del dominio de la aplicación y que se llaman relaciones estándar, también existen otras relaciones llamadas relaciones no estándar, para representar relaciones a medida entre conceptos de un dominio.

El formalismo de marcos [1], permite realizar importantes y poderosas inferencias utilizando los conocimientos almacenados. En concreto, las tres técnicas de inferencia que utilizan los marcos, de forma integrada son: equiparación, para clasificar entidades; herencia de propiedades para compartir propiedades entre marcos y, valores activos para representar la conducta del sistema y mantener la integridad de los datos almacenados.

En general, los SBC suelen representar los conocimientos estáticos del dominio en marcos, frente a redes semánticas ya que: permiten construir taxonomías de conceptos por especialización de conceptos generales en conceptos más específicos. En las bases de conocimientos formalizadas en marcos las propiedades se pueden definir de forma declarativa y procedimental. Los marcos permiten mantener internamente las restricciones, entre otras propiedades destacadas por los autores en [1].

REDES SEMÁNTICAS

De acuerdo con los autores en [1], las redes semánticas fueron definidas por Quillian. Una red semántica es un grafo orientado formado por nodos y por arcos unidireccionales. 

Como se expresaba previamente, en una red semántica [1], la información se representa, en un grafo orientado que esta formado por un conjunto de nodos y arcos unidireccionales, ambos etiquetados. Los nodos, representan conceptos e instancias de dichos conceptos y los arcos, que conectan nodos, relaciones binarias entre ellos. Por tanto, el significado de un concepto en la red dependerá de la forma en la que dicho concepto se relaciona con otros conceptos.

Los principales problemas de esta técnica [1], son la falta de una terminología adecuada, universalmente aceptada y de una semántica uniforme y precisa. Sin embargo, el diagramado en gráfico y su interpretación intuitiva las hace rápidamente compresibles y utilizadas al comenzar la formalización.

La representación de los conceptos [1], se modela mediante pares de atributo-valor. Los pares se representan, de la siguiente forma: el nodo origen es el objeto o concepto para el cual se definen los pares atributo-valor, los arcos que parten de dicho nodo son los atributos del par y los  nodos destino representan los valores de los atributos.

La representación de acciones [1], se realiza a través de la gramática de casos de Fillmore, las cuales se basan en que toda proposición, contenida en una sentencia, tiene una estructura profunda formada por un verbo, que es el elemento principal  y una o más frases nominales. Cada frase nominal se relaciona con el verbo mediante un conjunto de casos.  

Un sistema que utilice como formalismo de representación de conocimiento [1], estas redes, debe utilizar los conocimientos almacenados en la red para resolver los casos que se le planteen, de ahí que la eficacia del razonamiento en estas redes depende de los procedimientos que trabajan con la semántica de sus arcos. En este sentido las técnicas más empleadas son: equiparación y herencia de propiedades.

Se entiende de [1] que un fragmento de red se equipara con una red semántica, si el primer fragmento se puede asociar con un fragmento de la segunda. Mientras que la herencia de propiedades permite que nodos específicos accedan a propiedades definidas en otros nodos utilizando arcos de relación.

GUIONES

De acuerdo con los autores en [1], los guiones se utilizan para describir secuencias de sucesos estereotipados que tienen lugar en un dominio. Estos se ajustan bien para tratar situaciones dinámicas. 

Los guiones están compuestos de campos como los marcos, la diferencia está en su propósito pues mientras los marcos representan conceptos,  los guiones representan acciones en las que intervienen tales conceptos. Los componentes más comunes de los guiones son: 

• Cabecera: que explica el tipo de secuencia que representa.
• Condiciones de entrada: son aquellas condiciones que deben satisfacerse para que el guión sea instanciado.
• Condiciones de salida: conjunto de acciones ciertas una vez ejecutados los eventos descritos en el guión.
• Escenas: conforma una descripción de todos los eventos que ocurren en la situación descrita por el guión.

Si bien cualquiera de las técnicas que hemos evaluado en este artículo proponen unas interesantes capacidades de representación de conocimientos y facilidades de inferencia a partir de dicha representación, es importante conocer muy bien el objetivo de la representación antes de elegir la forma de representarlo. De acuerdo con los autores [1], la técnica de representación elegida para la mayoría de los SBC, por diferentes motivos y ventajas sobre, por ejemplo, las redes semánticas, son los Marcos. 

Referencias

[1] A. Gómez, N. Juristo, C. Montes y J. Pazos, Ingeniería del Conocimiento. España: Centro de Estudios Ramón Areces S. A., Tomás Bretón, 21, 28045, Madrid, 1997, cap. 6.

MVC - Model View Controller

Si bien el patron MVC es algo de lo que actualmente se oye hablar hasta en la fila del supermercado, no quise dejar pasar la oportunidad de escribir sobr él en este blog, enonces el objetivo de éste es recoger algunos aspectos que puedan servir de introducción (y base para profundizar la lectura) a conceptos relacionados con dicho patrón.

Introducción

Este patrón es categorizado por M. Fowler como uno de los patrones para diseño de presentaciones web.

El patrón MVC de acuerdo con la visión de M. Fowler [1], es uno de los más citados (y a la vez el más criticado) de entre los patrones más conocidos. Su comienzo se da a finales de los ‘70 como un framework desarrollado por Trygve Reenskaug para la plataforma Smalltalk. Desde entonces ha desempeñado un papel fundamental en la mayoría de los frameworks para IU y en las diferentes líneas de pensamiento acerca del diseño de UI.

Como funciona?

Este patrón considera tres diferentes roles. El modelo es un objeto que representa información acerca del dominio, es un objeto no visual que contiene toda la información y el comportamiento que es utilizado por la UI. En una visión del modelo puramente OO se trata de un objeto dentro de modelo de dominio.
La vista representa como se expone el modelo a través de la UI. Por lo tanto, si nuestro modelo es un objeto cliente, nuestra vista puede ser un cuadro completo de controles UI o estructuras HTML que presentan la información obtenida del modelo. La vita se responsabiliza únicamente de mostrar información, cualquier cambio a la información es capturada por una tercera parte del patrón MVC, el controlador (controller).
El controlador toma las entradas de usuario, manipula el modelo, y causa que la vista se actualice de forma adecuada. De esta manera, la UI resulta en una combinación estratégica de la vista y el controlador.
M. Fowler [1], expone que encuentra en el patrón MVC dos separaciones principales: una separación de la presentación y el modelo y otra entre el controlador y la vista. Además expone que la separación entre la presentación y el modelo es una heurística fundamental del buen diseño del Software.Un punto importante en esta separación es la dirección de las dependencias: la presentación depende del modelo pero el modelo no depende de la presentación. M. Fowler [1], de hecho recomienda que la gente que trabaja desarrollando el modelo debería ser completamente independiente de lo que aquellos que desarrollan la presentación están usando, con el principio en que ambas partes simplifiquen sus actividades, y faciliten el desarrollo de nuevas capas de presentación en el futuro. Además redunda en que los cambios a la capa de presentación puedan realizarse sin tener impacto en el modelo.

Este principio introduce además un tema en común. Con una interfaz que contemple varias ventanas, donde un programador realice un cambio en el modelo, este cambio impactara seguramente en varias ventanas, para soportar esta situación sin agregar dependencias innecesarias, seguramente las vistas deben comportarse como observadores del modelo (patrón Observer de Gang of Four).

La segunda división, la separación entre la vista y el controlador, puede verse un poco menos importante [1], en la práctica normalmente se tiene un controlador por cada vista o conjunto de vistas, y muchas veces se da que esta separación no existe. Debe evaluarse su implementación en aquellos sistemas donde la separación sea indispensable y muy útil.

A todo esto, hasta aquí hemos visto los principios del patrón, además podemos abstraer fácilmente donde estarían alojados las vistas y el modelo, pero ¿Dónde va el controlador? La visión más común lo sitúa en algún lugar entre el modelo y la vista.

Cuando utilizarlo?
M. Fowler [1], sitúa el valor del patrón MVC justamente en las separaciones comentadas previamente. Situando además a la separación entre la presentación y el modelo como uno de los principios de diseño de software más importantes, destacando que la única vez que no se debe seguir es en los sistemas en los que el modelo no tiene el control del comportamiento real. Recomienda que tan pronto como encontremos lógica no visual es que deberemos de aplicar la separación. Además destaca que la separación entre la vista y el controlador tiene menor importancia, recomendando que se haga únicamente cuando sea realmente necesario.

Con el objetivo de profundizar la lectura sobre este tema y comprender como este patrón es aplicado en arquitecturas de sistemas basados en plataformas Microsoft, simplemente recomendar la lectura de la Application Architecture Guide en su última release Beta 2.0.

Fuente: [1] M. Fowler y colegas, Patterns of Enterprise Application Architecture, Addison Wesley, November, 2002, ch. 14, pp. 330-331.