DBAccess en Ciberespacio Radio

Entrevista con Edgar Rincón. En su estilo incisivo hizo una entrevista bien amena y fresca.

Tips para construcción de diagramas de clases útiles y legibles

Escribo en este post uno de los temas más recurrentes y de más utilidad en clases, revisiones de pares, recomendaciones de diseño, revisiones de documentos de arquitectura y en general en cualquier momento donde aparezca un diagrama de clases.

Hago una recopilación de los tips y observaciones que surgen continuamente y que teniéndolos en cuenta se mejora significativamente la calidad y utilidad de los diagramas.

El error más común: Relaciones conceptuales

En muchos casos un modelo conceptual, que representa el espacio del problema, se utiliza como base para la identificación de clases. Las relaciones que se presentan en un modelo conceptual suelen ser acciones o interacciones de elementos en el mundo real. Por ejemplo en el modelo conceptual de un sistema de inscripciones de un ente educativo, seguramente consiguiremos una relación inscribe entre los conceptos de Estudiante y Materia.

Figura 1: Modelo Conceptual

En el modelamiento de un diagrama conceptual ésto es perfectamente válido. Ahora cuando se habla de relaciones entre clases, una relación inscribe entre las clases Estudiante y Materia tiene un significado bien específico y está relacionado directamente con la implementación.

Figura 2: Diagrama de Clases

La relación de la figura 2 establece que en la clase Materia existe un método llamado inscribe y que este método es invocado en algún momento por la clase Estudiante. Hay que estar claros con lo que se está expresando y hacerlo concientemente.

Si por ejemplo asumimos que un componente, capa de software o servicio es responsable de un contrato de registro de la inscripción de una materia y ofrece una operación o método con firma:
void inscribirMateria(Estudiante estudiante, Materia nuevaMateria)
throws InscripciónDuplicadaException
Este servicio en su implementación podría hacer una serie de validaciones y luego acceder a un repositorio y almacenar la formalización de la inscripción de la materia.
En este caso la clase Estudiante nunca invocaría un método inscribir de la clase Materia e inclusoeste método podría no existir, aunque sea cierta la relación conceptual entre ambas clases. En un diagrama de clases, de acuerdo a la implementación planteada, sería un error colocarla en un diagrama de clases.

Tipos de relaciones: estáticas vs. dinámicas

Las relaciones entre dos clases pueden ser clasificadas en dos tipos, estáticas y dinámicas.

Las relaciones estáticas son aquellas que definen estructuralmente a la clase, básicamente en los lenguaes OO utilizados actualmente se definen tres tipos; extensión o herencia, agregación y composición. No es el objeto de este artículo explicar estas relaciones, hay múltiples fuentes disponibles.

Las relaciones dinámicas son las que definen la interacción de la clase con otras, invocaciones que desde la clase se hace a métodos de otra clase. Un ejemplo de relación dinámica se define en la Figura 2.

El tip que se presenta a continuación se basa en esta definición teórica para hacer una recomendación concreta en la construcción de diagramas.

No llene el diagrama de clases con relaciones dinámicas descontextualizadas

Las relaciones dinámicas se dan en el contexto de la ejecución de una operación, servicio o contrato específico. Una clase que participa en la realización de múltiples operaciones, probablemente contará con múltiples invocaciones a otras clases, subconjuntos de todas estas relaciones (invocaciones) participan en la relización de una cada operación específica.

Si en un diagrama de clases, adicionalmente a las relaciones estáticas, colocamos todas las relaciones dinámicas que se dan entre las clases del diagrama (es decir, todas las relaciones por cada vez que una clase llama a un método de otra clase) entonces terminaremos con un diagrama sobrecargado, de aquellos que solemos llamar spaghetti diagram.

Figura 4: Espagueti inentendible... encontré un buen ejemplo buscando imágenes en la red.

Cuando se presenta un diagrama de clases, lo más recomendable es presentar la estructura utilizando sólo las relaciones estáticas. Las relaciones dinámicas recomiendo presentarlas en su debido contexto, por ejemplo utilizando un diagrama de secuencias o colaboración para cada operación o servicio. De esta forma se apreciará claramente la interacción entre las diferentes clases e incluso objetos, para lograr la realización de una operación.

Seguir esta recomendación mejora significativamente la utilidad de la documentación para el equipo que hará mantenimiento del sistema en construcción, disminuyendo así los costos de soporte y mantenimiento a futuro.

Re Re Re Re Re Reconversión Monetaria

La metodología para afrontar el impacto de la reconversión monetaria en las plataformas tecnológicas que definimos en la Unidad de Arquitectura e Innovación de DBAccess, ha sido mercadeada efectiva y masivamente por el equipo de la Unidad de Mercadeo. Numerosas notas de prensa, presentaciones y entrevistas has sido muestra de la acogida que ha recibido en el mercado. Yo por mi lado, de vocero del tema, repito una y otra vez como el conejito de las pilas...

Recopilación de enlaces y entrevistas.

Entrevista televisada para Alta Densidad - Globovisión.
La entrevista fue en un formato de preguntas y respuestas que después serán editadas. El fondo verde al mejor estilo de Matrix fue una nota divertida. Espero a que salga el programa en TV para ver qué fondo le colocan.
http://red-dbaccess.blogspot.com/2007/07/dbaccess-en-alta-densidad.html

DBAccess habla sobre los efectos de la reconversión monetaria sobre las plataformas TI en foro de CAVEDATOS 7/11/2007:

http://red-dbaccess.blogspot.com/2007/07/dbacces-en-foro-de-cavedatos-sobre.html
http://www.ciberespacio.com.ve/site/p_detalle_evento.asp?id_evento=7639&id_submodulo=24

Nuestra estrategia para la reconversión monetaria en ComputerWorld (Junio 2007): http://red-dbaccess.blogspot.com/2007/07/nuestra-estrategia-para-la-reconversin.html
Leer nota completa en ComputerWorld Venezuela (.pdf)

La conversión al bolívar fuerte tiene fuerte impacto en los sistemas informáticos:
http://enbytes.com/noticias/reconversionI.htm

Igual al anterior pero publicado por Conapri:
http://www.conapri.org/ArticleDetailIV.asp?CategoryId=14563&ArticleId=282506

CANTV.Net: DBAccess habla sobre los efectos de la reconversión monetaria:
http://www.cantv.net/ciencia/resena.asp?id=141181&cat=2&Fresena=TRUE

DBAccess en Alta Densidad - Radio. Entrevista por Carlos Monzón a ser transmitida en el Circuito X.






http://red-dbaccess.blogspot.com/2007/05/dbaccess-en-alta-densidad.html
Escuche la entrevista:

Póngase en los zapatos de los otros roles!

Es una práctica que viene con la experiencia y el conocimiento del proceso completo, la capacidad de ponerse con cierta frecuencia en el lugar de otros roles del equipo que ejecuta un proyecto de ingeniería de software.

Hago en este texto un análisis rol por rol, indicando el beneficio que puede traer ubicarse en la posición de otros.

Analista de Requerimientos

Es sumamente útil para el analista de requerimientos, al momento de especificar características del sistema o funcionalidades en forma de casos de uso, ubicarse en la posición del equipo de desarrollo y de los encargados del diseño de casos de prueba. Analizar su producto desde esta posición le permitirá evaluar si el nivel de especificidad es suficiente para que el requerimiento pase de forma fluida a las siguientes etapas del ciclo de desarrollo.

• Están claras las restricciones que impone el negocio?
• Los datos que se manejarán están totalmente claros? longitudes, alcance, etc.
• El perfil de los usuarios está claramente descrito?
• Los puntos de integración con otros sistemas fueron analizados y documentados?

Equipo de Desarrollo

Uno de los problemas más comunes en el área, es que un equipo de desarrollo encargado de mantenimiento consiga una implementación pobremente documentada, sin indicativos de los elementos relacionados con el mantenimiento de una funcionalidad en particular o las decisiones de diseño involucradas.
Un desarrollador que trabaja en la implementación de un caso de uso debe, como parte integral de su trabajo, ubicarse en la posición de un desarrollador que llega al proyecto en un futuro sin el contexto que él posee, y que deba incorporar un cambio de requerimiento en la funcionalidad en la que el trabaja.

• Cuáles son los elementos/componentes que participan en la realización de esa funcionalidad?
• Qué reglas o restricciones de negocio están involucradas?
• Está el código lo suficientemente claro y refactorizado para facilitar el proceso de lectura y comprensión?

Está ampliamente documentado los altos costos de mantenimiento en que se puede incurrir en caso de no contar con los insumos necesarios en esta etapa.

Arquitecto

Los arquitectos deben diseñar los lineamientos de construcción de un sistema teniendo en cuenta que su producto debe ser lo suficientemente claro y completo, para que diferentes equipos de desarrollo puedan producir un sistema implementado de la misma forma. El arquitecto debe ubicarse en el rol del desarrollador y tratar de implementar un caso de uso sobre esa arquitectura, con el objetivo de identificar los puntos que aún quedan abiertos y la conveniencia de las decisiones de diseño que se plasmaron en la arquitectura.

• La arquitectura habilita un desarrollo ágil?
• Está clara la distribución de las responsabilidades en los diferentes componentes?
• Están claros los lineamientos de manejo de errores?

En general, el colocarse en la posición de otro, permite evaluar el producto que se ha producido obviando el contexto o conocimiento que una persona tiene sobre ese producto, permitiendo evaluar objetivamente si se ha dejado la suficiente información documentada.

Práctica de Peer Reviews

Hay dos temas que motivan este escrito. El primero es la experiencia de haber pasado por varios peer reviews en los últimos días, donde me sentí en cada una de esas sesiones aplicando repetitivamente las mismas prácticas. Fueron efectivas y lo han sido desde hace algún tiempo, así que considero vale la pena identificar cuáles son y compartirlas. La segunda motivación nace de una pregunta que he realizado en varias oportunidades a mis alumnos de Ingeniería de Software de la USB; ¿si comparan el código que ustedes están produciendo actualmente con el de un equipo de desarrolladores con amplia experiencia produciendo software de calidad mundial, en qué se diferenciaría?. Creo que ambos temas están muy relacionados y son claves en la calidad técnica del software.

El ojo de un experto en su área de experticia, busca de forma natural las anomalías o carencias que pueda tener el producto en cuestión. ¿Cuáles son esas anomalías o carencias que se deben identificar en el código fuente y que deben saltar a la vista del ojo experto en una inspección de código?.

La revisión que suelo aplicar va en dos bloques. El primero relacionado con la correcta y clara definición de lineamientos de diseño y de arquitectura y por supuesto su cumplimiento. El segundo se enfoca en el cumplimiento de la funcionalidad establecida y la búsqueda de defectos.

Bloque de lineamientos de arquitectura

El diseño de la arquitectura de un sistema debe abarcar una serie de aspectos básicos que garanticen uniformidad en la implementación del sistema. Particularmente en las revisiones me fijo en los siguientes; Capas, Asignación de responsabilidades, Uso de patrones, Componentización de alto nivel, Manejo de excepciones y Generación de trazas para auditoría. Claro que hay otros, pero si se cumplen éstos seguramente tendremos una arquitectura bastante sólida.

Una secuencia de acciones para realizar la revisión en base a estos parámetros podría ser la siguiente:

• Buscar que en el documento de arquitectura estén claramente definidas las capas del sistema. Si la solución está compuesta por varios sistemas, aplica la secuencia a cada una.
• Debe establecerse para cada capa quiénes son los responsables en recibir las comunicaciones, en comunicarse con otras capas y cuál es el lenguaje que hablarán las capas entre si (tipos de datos simples, objetos de negocio, etc.).
• Las responsabilidades en cada nivel de la arquitectura lógica deben estar claras y ser consistentes. Quién valida parámetros de otra capa, quién crea objetos de negocio, quién interactúa con cada ente externo, quién interactúa con el repositorio, quién contiene la lógica de reglas de negocio, son algunas de las muchas preguntas que siempre es útil hacerse y cuyas respuestas deben estar claras.
• Qué patrones se están usando y por qué?. Qué piezas o componentes considera las más complejas? qué patrones usan éstas?, si no usan ninguno hay alguno que podría ayudar?.
• Siempre debemos poder mostrar una vista de componentes y debe estar claro cómo interactúan entre ellos, sus interfaces y responsabilidades.
• Debe en el documento de arquitectura o su equivalente estar un diagrama de clases de las excepciones a utilizar y estar definido cómo y cuándo se utilizarán, también debe estar definido de quién es la responsabilidad de capturarla en cada caso. Cuáles son posibles extender y cuáles no.
• Quién ha tenido la experiencia de tener que mantener un sistema en producción ha aprendido la utilidad de las trazas de auditoría de primera mano. Debe estar claro cuál es la estrategia a seguir en las trazas, en qué puntos deben generarse siempre, en cuáles es opcional, cuántos niveles se utilizarán y qué tipo de mensajes van en cada uno.
• Para validar posteriormente que todo lo anterior que está en la documentación se cumpla efectivamente en la implementación, se seleccionan un par de funcionalidades (casos de uso), y se revisan siguiendo su código fuente tal como lo haría durante su ejecución, desde las capas superiores a las inferiores.

Para todos los puntos anteriores las respuestas deben estar en la documentación, sino están y alguien debe explicarlo entonces está incompleta. Cada respuesta que alguien da debe anotarse y luego incorporarse al documento correspondiente. Es una buena forma de identificar los puntos de mejora de la documentación.

De contar con la disponibilidad de tiempo suficiente, podrían tomar en cuenta otros aspectos como Paquetes, Idioma del código fuente (es común y poco deseable el spanglish) y Uniformidad en los nombres.

Este primer bloque de prácticas se aplica cuando se realizan las primeras inspecciones de un proyecto. En sucesivas sesiones, cuando ya se ha garantizado que la arquitectura y los lineamientos de diseño están suficientemente maduros, la actividad puede enfocarse sólo en el segundo bloque.

Bloque de búsqueda de defectos

En el segundo bloque se revisa un conjunto de casos de uso o funcionalidades seleccionadas, el objetivo es verificar que la implementación efectivamente cumple con los requerimientos establecidos y tratar de identificar potenciales defectos.

La revisión al igual que en el bloque anterior es recomendable hacerla siguiendo el código fuente tal como se ejecutaría, línea a línea.

Durante estas revisiones tenga siempre en mente los lineamientos validados en el primer bloque, siempre es posible encontrar puntos donde no se cumple lo establecido y es pertinente alertar para que sea corregido.

Qué relación tiene lo anterior con la pregunta inicial sobre la diferencia del código fuente de un grupo de estudiantes con el de un equipo de desarrollo experto?, creo que los puntos del primer bloque son los principales diferenciales, ya que son continuamente reforzados por la experiencia.

Peer Reviews es todo un tema y existe amplia bibliografía al respecto, Peer Reviews in Software de Karl Wiegers es una muy buena opción para adquirir una base metodológica en el tema.

Entrevista sobre Reconversión Monetaria en Jazz 95.5 FM

Participación en el programa Tecnología hecha palabra, transmitido por la emisora Jazz 95.5 FM y moderado por Peter Cernik, para hablar de la estrategia que propone DBAccess como solución a las adecuaciones necesarias producto de la reconversión monetaria en Venezuela. Participamos Jesús Maceira y yo, el programa se efectuó el día 22/05/2007 a las 9:30 pm. El audio de la transmisión.

Artículo relacionado en el blog de DBAccess.