Diagramas de Secuencia

Los Diagramas de Secuencia muestran cómo las instancias se intercambian mensajes a lo largo del tiempo en un escenario determinado. El tiempo viene representado por la bajada que se realiza a lo largo de la líneas de vida, el eje vertical, y el paso de mensajes se representa en el eje horizontal. Obviamente los mensajes nunca pueden darse hacia detrás, por lo que no veremos líneas de mensaje ascendentes.

En la parte superior del diagrama se colocan los objetos que intervienen en la escena, la notación suele bien colocar simplemente el nombre de la clase que representa a la instancia o bien el nombre del objeto seguido de su clase utilizando dos puntos para separalos. Por ejemplo <<usuario:Espectador>> indica que el nombre (la variable de nombre) "usuario" es una instancia de la clase Espectador.

La línea de vida discontinua implica que o bien aún el objeto no ha sido instanciado o bien se encuentra latente. Los objetos cobran vida al reaccionar a mensajes recibidos, aunque en el diagrama de ejemplo no se muestran, existen dos mensajes típicos create y destroy, que levantan una instacia de un objeto o la destruyen. Algunos diagramatizadores permiten indicar cuándo un objeto ha sido destruído cerrando su línea de vida con una X.

Como ejemplo ampliado, añado a continuación otro diagrama de secuencia. Cuando un diagrama se vuelve tan extenso es conveniente plantearse el dividirlo en varios.

Herramientas de Metrica

Checkstyle: 
 Comprueba normas de estilo a lo largo del código JAVA de un proyecto. Entre otras, comprueba:

• Que los artefactos contengan comentarios JAVADOC.
• Convenciones de nombrado.
• Límites de longitud en líneas y parámetros.
• La presencia de cabeceras.

Destacan también las posibilidades de detección de secciones de código duplicadas y medidas de complejidad.

PMD:
Un analizador de código JAVA utilizado para detectar errores comunes, código muerto, sentencias demasiado complejas, medidas de complejidad ciclomática y código duplicado, así como detección de patrones de código simplificable, substituíble o mejorable.

Findbugs:
Un analizador estático de bytecodes que detecta bugs potenciales.

Clover:
Una herramienta de cobertura de código. Una gran ventaja que aporta es que permite filtrar los tests de manera que solo se lanzan aquellos que implican código modificado desde la última ejecución.

Sonar:
Plataforma online de presentación de métricas de calidad del software. Se basa en las herramientas citadas anteriormente. Genera multitud de informes.

Los Principios de Código

Eliminación de redundancias. DRY/DIE: 
 DRY:  Don't Repeat Yourself
 DIE: Duplication Is Evil.

Una unidad de conocimiento debe tener una única representación dentro de un sistema. Cuando se cumple correctamente la modificación de un elemento no implica un cambio en elementos que no están relacionados con él. Como todo en este mundo debe interpretarse dentro del marco del sentido común, existen autores que se oponen al DRY absoluto dado que sugieren que la repetición añade más verbalidad al código, por ejemplo en los tests la repetición permite que el código sea más semejante a un guión.  En general DRY/DIE a nivel de algoritmos y lógica de estados es absolutamente recomendable, tal cual ocurre en una redacción en lenguaje no automático.

Principios SOLID:
Un objetivo principal de agilidad a nivel de código es generar código legible, extensible y fácil de mantener. Deteminar qué es buen código no es tarea simple y se han desarrollado varias técnicas para determinar su calidad, entre ellas los criterios SOLID son muy conocidos. Veamos en qué consisten:

S: (SRP) Principio de Única Responsabilidad.
O: (OCP) Principio de Apertura/Cierre.
L: (LSP) Principio de Substitución de Liskov.
I: (ISP) Principio de Segregación de Interfaz.
D: (DIP) Principio de Inversión de Dependencia.



S: (SRP) Principio de Única Responsabilidad.
Una entidad en un sistema debe ocuparse de una y solo una responsabilidad, de lo contrario debe plantearse la división en varias entidades. En principio esto aumenta el bajo acoplamiento y aumenta la cohesión dado que el reparto de responsabilidades es una buena técnica de dispersión y concentración de código.
 
O: (OCP) Principio de Apertura/Cierre.
 En general es deseable que una entidad pueda extenderse de manera que acepte nuevas variantes de comportamiento o estructura sin necesidad de modificar el código original. Estar "cerrado" para la modificación y "abierto" a la extensión implica que el código no está sujeto a modificaciones que pongan en riesgo sistemas que lo usan actualmente. Es un principio básico de la reutilización.


L: (LSP) Principio de Substitución de Liskov.
 Un principio bastante teórico:
   Sea p(x) una propiedad probable de los objetos x de tipo T. Entonces p(x) debe ser probable para los objetos y de tipo S, siendo S un subtipo de T.

Ahí queda eso... simplemente el principio viene a indicarnos que en una jerarquía de objetos bien diseñada siempre podremos substituir los objetos del tipo superior por una de sus herencias. Como un ejemplo básico si tenemos un sistema que funciona con objetos del tipo Animal ese sistema debería aceptar directamente trabajar con objetos del tipo Pollo o Perro. Conseguir esto no es tarea fácil y mucho menos garantizarlo, en principio es necesario fijar que los métodos de las clases heredadas sean iguales en argumentos y en tipo de retorno y no lanzar excepciones nuevas o distintas (los lenguajes actuales fuerzan a ello, el principio se enunció en 1987 y estamos en el año 2011). El contrato que siguen los subtipos debe también cumplir que las precondiciones no sean más fuertes que las de la clase que heredan, las postcondiciones no ser más débiles y que se respeten las invariantes, lo cual es absolutamente lógico ¿qué no lo es?

I: (ISP) Principio de Segregación de Interfaz.
 Una interfaz debe mantenerse pequeña, es más fácil cumplir contratos pequeños que contratos enormes, por tanto una interfaz grande debe segregarse en variar interfaces más pequeñas. Esto permite que los objetos que se comunican con un sistema lo hagan mediante una interfaz reducida que aclara cuál es su rol, un cliente no debe estar forzado a depender de métodos que no va a utilizar.


D: (DIP) Principio de Inversión de Dependencia y Métodos de Inversión de Control.

• Los módulos de niveles superiores no deben depender de los módulos de niveles inferiores. Ambos deben depender de abstracciones.
• Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

Vaya, vaya... bocadillo de caballa. Para el que recuerde la frase popularizada por Bruce Lee, ¡gran maestro del Kung Fu!, "Be water my friend", los maestros de código en su iluminanción suelen decir: "Mantente abstracto". Gran concepto que va mucho más allá del código y probablemente del Kung Fu, si es que eso es posible.

Un módulo (superior) no debe depender directamente de otro (inferior), de lo contrario la reusabilidad del módulo (superior) se verá muy afectada. Aunque parezca lo contrario solucionar esto no suele ser complicado, si trabajoso, un módulo debe depender de una interfaz abstracta, si otro módulo quiere comunicarse con aquel debe cumplir o acomodarse a la interfaz sugerida.  
 --------------------------- 

Principio de Simplicidad (KISS):

Tal como le indicaba el detective Rick al pianista en la película Casablanca: "Tócala otra vez Sam", el principio KISS viene a decir: "Keep it Simple Sam", variantes posteriores de este enunciado llevaron a versiones algo más agresivas como "Keep It Simple, Stupid" que en mi criterio deben evitarse en toda alegación de mejora de un diseño realizado, no llame estúpidos a sus compañeros a no ser que tenga absoluta certeza de ello, y si es así, tampoco es recomendable. Otra opción es eliminar la coma, con lo que la interpretación conveniente sería: Mantenlo estúpidamente simple, mucho más socialmente correcta, dónde va a parar.

Como otros muchos principios fácil es decirlo pero no hacerlo:

"Un objetivo del diseño de un sistema es que sea lo más simple posible, evitando toda complejidad innecesaria".

Diagramas de Actividades

Según la Vigésima segunda edición del Diccionario de la Lengua Española , la Real Academia Española nos indica:
 actividad.

(Del lat. activĭtas, -ātis).

1. f. Facultad de obrar.

2. f. Diligencia, eficacia.

3. f. Prontitud en el obrar.

4. f. Conjunto de operaciones o tareas propias de una persona o entidad. U. m. en pl.

5. f. Fís. En una cantidad dada de una sustancia radiactiva, número de átomos que se desintegran por unidad de tiempo.

Nos quedaremos con la cuarta definición, descartando , más que nada por eficacia y no por dejar de ser interesantes, las demás versiones, incluída la referente a la desintegración nuclear, más propia de un tratado de Ciencias Físicas o una película de La Guerra fría que de un escrito sobre UML. Por tanto, sea para nosotros de importancia la definición, y teniendo en cuenta que las personas no dejan de ser entidades (¿acaso existe algo con nombre conocido que no lo sea?):

Actividad: Conjunto de operaciones o tareas propias de una entidad. 

Me adelanto a las dudas que se podrían darse posteriormente de no aclarar la diferencia de conceptos entre las palabras "actividad" y "tarea". Siguiendo el mismo procedimiento anterior llegamos a la definición:

 

Tarea: Trabajo que debe hacerse en tiempo limitado.

Incidamos en que una actividad es un conjunto de tareas. La diferencia límite la pondrá el sentido común y el hecho de que una tarea es un proceso de naturaleza atómica, permítanme la gracia, sin actividad radioactiva. En el caso de haber desglosado demasiado las actividades en tareas muy probablemente sean más idóneos diagramas de estados y secuencias.

 Elementos comunes en los diagramas de Actividad:

Pista de nado (Swimlanes): Las actividades son llevadas a cabo por varias entidades que colaboran entre sí. Un Diagrama de Actividad puede dividirse en varias particiones que recogen las actividades propias de cada una de las entidades. En la cabecera del rectángulo asociado a la pista de nado se coloca el nombre de la entidad.

Estados de Inicio y Fin: representados por redondeles negros (Inicio) o bien redondeles negros con un borde blanco (Fin) representan el puntos de partida y finalizaciones de los flujos de ejecución.

Actividades: Representadas por rectángulos de esquinas redondeadas con un nombre representativo colocado en su centro.

Puntos de toma de Decisión: Su símbolo es el rombo, dependiendo de la decisión tomada, normalmente representada mediante una restricción sobre la línea de flujo, se seguirá una u otra rama durante el flujo de ejecución.

Transiciones de Ejecución de Flujo en Paralelo (Fork) y Sincronizaciones (Join): Los diagramas de actividad permiten reflejar qué actividades pueden hacerse en paralelo. Una vez realizadas se sincronizan en el punto de unión.


El diagrama siguiente contiene ejemplos de cada uno de los elementos descritos, puebe a describir con sus propias palabras el comportamiento del sistema descrito en base a las actividades mostradas.

A continuación, otro ejemplo de diagrama de actividad, trate de determinar qué representa.

El Lenguaje de Modelado Unificado UML

A la hora de evaluar cualquier nueva herramienta para determinar su incorporación a los métodos de producción es conveniente aclarar cuestiones sobre su utilidad y, por supuesto, para qué no sirve, dónde resulta inútil, en otras palabras, aclarar cuestiones de alcance.

El Lenguaje Unificado de Modelado es útil en todas las áreas de un proyecto donde sea necesario especificar, visualizar, construir o documentar elementos o "artefactos".

Tal como se trató anteriormente, UML aporta planos y mapas sumamente convenientes en multitud de campos, tanto directamente relacionados con la Ingeniería del Software como no, teniendo éxito también en el área de Modelos de Negocio.

El Lenguaje Unificado de Modelado facilita el estudio de los sistemas. 

Los Diagramas del UML 2.0 Se clasifican en tres clases, Comportamiento, Interacción y Estructura: 

Diagramas de Comportamiento:

 Permiten exhibir comportamientos de un sistema.

•  Diagrama de Actividad: Muestra los procesos de alto nivel de la organización. Incluye flujo de
  datos, o un modelo de la lógica compleja dentro del sistema.
• Diagrama de Caso de Uso: Exhibe los casos de utilización, actores y sus interrelaciones.
• Diagrama de Estado: Describe los estados que pueden tener un objeto o interacción, así como las transiciones entre dichos estados. 

Diagramas de Interacción:

Es un subconjunto de los diagramas de comportamiento. Enfatizan las interacciones entre los objetos.

• Diagrama de Secuencia Modela la secuencia lógica, a través del tiempo, de los mensajes entre las instancias.  
•  Diagrama de Comunicación/Colaboración:
  muestra las interrelaciones, y el flujo de
  mensajes entre los objetos. 
• Diagrama de Interacción: (Vista General) Variante del diagrama de actividad que permite mostrar el flujo de control dentro de un
  sistema. 
• Diagrama de Tiempos: Muestra el 
  cambio en el estado de un objeto
  en el tiempo, en respuesta a
  eventos externos.

Diagramas de Estructura:

Muestran los elementos de una especificación que sean independientes del  tiempo. Incluyen clase, estructura de componentes, componente, despliegue, objeto y diagramas de paquetes. 

  Diagrama de Clases: Exhibe una colección de elementos del modelo estático, tales como

• clases y tipos, sus contenidos y sus relaciones.
• Diagrama de Despliegue: Muestra la realización de la arquitectura del sistema. 
•  Diagrama de Paquetes: Describe cómo los elementos del modelo se organizan en paquetes,
  así como las dependencias entre esos paquetes.
•  Diagrama de componentes Muestra los componentes de una aplicación, sistema o empresa. 

Los Diagramas por Su Importancia:

 

Programación eXtrema y El Agilismo

En esencia la programación extrema consiste en un conjunto de técnicas que han demostrado tener éxito en muchos proyectos y por tanto muy recomendables en conjunto. El empuje actual de los seguidores del agilismo añade un factor importante, la alta motivación de los programadores, variable principal directamente relacionada con el rendimiento de los equipos. En la práctica, XP se divide en varios niveles:

• A nivel de Desarrollo de Código:
• Desarrollo Dirigido por Pruebas (TDD: Test Driven Design), el diseño emerge de forma natural cuando se anteponen las pruebas a la codificación.
• Diseño Simple: Evitar el sobrediseño aumenta la calidad del software.
• Programación con Copiloto: El código se lleva a cabo conjuntamente con un compañero con el que se comparte la tarea de codificación actuando como supervisor y con el que se intercambia el puesto en turnos cortos en intervalos menores a una hora. El compañero también rota entre los equipos de desarrolladores disponibles, es una técnica de maximización de la calidad del código en términos de legibilidad y simpleza.
• Refactorización: Diversas técnicas de remodelización del código que mejoran su calidad sin alterar su función.   
• A nivel de Integración:
• La Integración Continua permite garantizar que los distintos módulos se puedan combinar generando un ejecutable común.  
• Se programa en base a un vocabulario proveniente de una metáfora, la similitud entre el dominio a implementar y el dominio conocido por el equipo facilita las tareas.
• Pertenencia Colectiva: todo el código está disponible para todo el equipo.
• Camino Sostenible: El menor tamaño de las entregas intermedias, de menor tamaño, permiten que las estimaciones tracen una ruta sin demasiados altibajos.
• Utilización de Estándares de Código: Se establece cómo, dónde y de qué manera se colocará el código escrito.



• A nivel de Planificación del Proyecto:
• El cliente comprueba las entregas mediante Pruebas de Cliente, diseñadas y documentadas.
• La organización se organiza de forma horizontal como un equipo completo bien comunicado.
• Se involucra a todo el equipo en las estimaciones y decisiones de planificación a modo de Juego de Planificación.
• Las entregas se realizan contínuamente y son pequeñas.

La buena comunicación y la documentación eficiente se establecen como bases de la programación extrema, lógicamente UML tiene mucha cabida en este aspecto y es ampliamente utilizado en proyectos XP. 

El Proceso Unificado

Curioso mundo éste de la informática, recuerdo cuando Compaq compró la Digital, desapareciendo los sistemas Alfa, para luego ser comprada por HP, la empresa con las siglas peor escogidas de la historia.

La absorción de pequeñas empresas con éxito por otras de enorme tamaño es algo del día a día y lo mismo ocurrió con Rational, padres del Proceso Unificado de Rational (RUP) , que una vez absorvidos por IBM  pasó a llamarse Proceso Unificado (UP).

En 1995 Grady Booch, Jim Rumbaugh y Ivar Jacobson, ambos en plantilla de Rational Software, decidieron unificar tres técnicas dedicadas a modelizar objetos, la Técnica de Modelado de Objetos (OMT), la metodología de diagramas utilizados por Booch, y la Ingeniería Orientada a Objetos (OOSE). Ese fue el origen de UML.


La relación entre UML y el RUP era tan fuerte que durante años estuvo sujeta a la confusión de muchos; hablar de UML, una técnica de diagramatización, parecía forzosamente unida al RUP, una metodología.

Básicamente el UP descompone un proyecto en múltiples fases que se tratan individualmente como un proyecto separado llevado a cabo por iteración contínua y que al terminar genera salidas intermedias, denominadas artefactos y normalmente documentales que se utilizan como entradas de la fase siguiente. UML se utiliza a mansalva tanto internamente como en las interfases a modo de artefactos.

Las fases de UP pueden inicialmente recordarnos al ciclo de vida tradicional de la cascada del salmón, donde cada subfase se realiza como un proceso iterativo, que nos puede recordar también al ciclo de vida de la espiral de Boehm, el solapamiento sabernos a Shasimi... A menudo las ideas nuevas no son más que las antiguas, unidas, cambiadas de sitio y renombradas. La siguiente imágen se hizo muy conocida en el mundillo de la ingeniería del software y muchas interpretada erróneamente al pie de la letra.

Cualquier otra metodología existente puede adoptar los diagramas UML en sus distintas fases aportando, entre otras muchas, la ventaja de unificar la represantación de los sistemas arquitectónicamente orientados a objetos. Esto viene a aportar a la ingeniería del software algo común en todas las ingenierías conocidas, los planos de sus sistemas.