Lycka Bonita

UML (Unified Modeling Language, Lenguaje Unificado de Modelado) es un lenguaje visual extensible de modelado de sistemas orientado a objetos, de propósito amplio y genérico estandarizado por el Object Management Group (OMG).

Nace del intento de unificar los lenguajes de modelado visuales más extendidos en 1994 (Booch, OMT…). En 1996 OMG lanzó una RFP (Request for Proposal) aceptado en 1997, marcando el nacimiento de UML. Hoy es un estándar de facto abierto en la industria del software.

UML concibe el mundo como colecciones de objetos que interactúan, por eso resulta idóneo para utilizarse en desarrollo de software con lenguajes orientados a objetos. Se utiliza para especificar o describir sistemas, artefactos, métodos y procesos durante todo el ciclo de vida del sistema sin importar la implementación ni el proceso de desarrollo, incorporando las mejores prácticas de modelado para que puedan ser fácilmente legibles por personas e implementarse por las herramientas software de modelado.

Existen dos aspectos en un modelo UML que no están completos el uno sin el otro.

• Estructura estática, describe qué tipo de objetos conforman el sistema y cómo se relacionan.
• Comportamiento dinámico, describe los ciclos de vida de estos objetos y cómo interactúan entre sí para entregar la funcionalidad requerida.

Un modelo UML tiene al menos dos dimensiones:

• Textual, contiene las especificaciones de los diferentes elementos de modelado.
• Gráfica, muestra gráficamente el modelo textual utilizando diagramas e iconos, son simplemente vistas o proyecciones visuales de ese plano posterior semántico. Pueden existir elementos elididos (si no se muestran gráficamente), incompletos (pueden faltar en ambas dimensiones) e incoherentes (contradicciones entre los elementos).

UML se compone de 3 Bloques de Construcción.

• Elementos.
  • Estructurales. Son los nombres de un modelo UML, como una clase, interfaz, colaboración…
  • Comportamiento. Son los verbos de un modelo UML, como interacciones, actividades, máquinas de estado.
  • Agrupación. Paquetes que se utilizan para agrupar los elementos semánticamente en unidades cohesivas.
  • Anotación. Notas que se anexan al modelo para capturar información ad hoc.

• Relaciones, unen a los elementos entre sí especificando cómo dos o más elementos se relacionan semánticamente.
  • Dependencia. El elemento origen depende del elemento destino y se puede ver afectado por cambios en éste.
  • Asociación. La descripción de un conjunto de vínculos entre objetos.
  • Agregación. El elemento destino es una parte del elemento origen.
  • Composición. Una forma de agregación más fuerte, más restringida.
  • Contención. El elemento origen contiene el elemento destino.
  • Generalización. El elemento origen es una especialización del elemento destino más general y se puede sustituir por éste.
  • Implementación. El elemento origen garantiza llevar a cabo el contrato especificado por el elemento destino.
• Diagramas, nos muestran qué hará el sistema (diagramas a nivel de análisis) o cómo lo hará (diagramas a nivel de diseño).

UML utiliza 4 Mecanismos comunes para conseguir objetivos específicos:

• Especificaciones, descripciones textuales de la semántica de un elemento.
• Adornos, que se añaden a los elementos gráficos para hacer visibles aspectos de la especificación del elemento textual.
• Divisiones comunes.
  • Clasificador/instancia (abstracción/especificación). Comparten icono pero las instancias tienen el nombre subrayado. UML proporciona 33 clasificadores (actor, clase, componente, interfaz, caso de uso…)
  • Interfaz/implementación. Separando lo que se hace de cómo se hace, los contratos ocultan la complejidad.
• Mecanismos de extensión. UML no puede ser universal y satisfacer las necesidades presentes y futuras de todos los proyectos, por los que incorpora:
  • Restricciones, cadena de texto entre llaves que especifica cierta condición o regla sobre el elemento. UML define como una extensión estándar OCL (Object Constraint Language o Lenguaje de Restricción de Objetos).
  • Estereotipos, variaciones de un elemento de modelo existente con la misma forma pero con un propósito modificado, representado con el nombre del nuevo elemento entre cursores, <<…>>.
  • Valores etiquetados, son palabras claves que puede tener un valor anexado, al modo del valor de una propiedad.

Una funcionalidad de un aplicativo software describe un funcionamiento que debe cumplir dicho sistema, esto es define cuáles y cómo deben ser los datos de salida y el comportamiento del sistema dados unos datos de entrada.

Tradicionalmente las funcionalidades se catalogan en el documento de Especificación de Requisitos del Sistema (ERS) descritas como requisitos funcionales, que a su vez se desglosan en casos de uso que a su vez se mapean contra casos de prueba y finalmente podemos tracear su relación con el código y con suerte en algún test.

Siempre que se necesite una nueva funcionalidad, especialmente si se parte de un folio en blanco para describir el comportamiento que debe tener un sistema, existe cierto nivel de incertidumbre, por mucha experiencia que reúnan los participantes y aunque se parta de otro sistema o una versión anterior.

Para gestionar esta incertidumbre, se abren dos posibles caminos:

• Por un lado podemos parar el proyecto para refinar estas funcionalidades hasta rebajar el nivel de incertidumbre hasta cotas aceptables.

La investigación (otros productos, aspectos legales, otros puntos de vistas…), reflexión y la comunicación entre todos los participantes llevará tiempo pero sin duda despejará las dudas antes de continuar con el desarrollo. Es la visión tradicional en cascada de la industria del software.

• Por otro lado podemos arrancar para construir un sistema piloto, una maqueta que poder enseñar y con la que los usuarios puedan interactuar para despejar la incertidumbre con esta maqueta. Al construir un sistema con un alto grado de incertidumbre, sin conocer exactamente los requisitos, casos de uso y casos de prueba, tiene más sentido referirse a estos “inputs” con la terminología ágil, utilizando el término “Historia de Usuario“.

No hay nada como el visualizar e interactuar como un sistema para darnos cuenta de qué y cómo queríamos realmente que fuera el sistema. Es la visión moderna de la industria, la visión ágil basada en las nuevas metodologías de desarrollo ágiles. Una temprana entrega de un sistema que funciona nos permite aprender antes de la experiencia de su utilización, así como erradicar pronto errores de base que serían mucho más costosos de arrancar después.

No todo son ventajas. Al arrancar con un alto nivel de incertidumbre suele suponer entregar sistemas con pies de barro, es decir con arquitecturas difusamente definidas, escasamente documentadas, poco preparadas para la evolución y más difíciles de entender y utilizar. El mantenimiento suele encarecerse. Quién tiene tiempo para hacer una retrospectiva y una refactorización? Para qué si ya me has entregado algo que funciona? La labor comercial en este punto se complica notablemente, gestionar las expectativas es crucial. No se puede alcanzar la misma calidad sin retrospectivas y refactorizaciones, y es muy difícil de aceptar que resulte más cara una ampliación que el propio desarrollo.

Entonces, qué camino elegir?

Mi recomendación es tomar sabiamente lo mejor de ambos mundos.

En una primera etapa de conversaciones obtendremos normalmente una colección de historias de usuario que en esta etapa suelen ser muy difusas; pero si estamos sentados en la mesa es porque el cliente tiene una necesidad: tiene puntos muy claros que podemos plasmar en funcionalidades claras.

En este punto podemos construir un piloto partiendo sobre todo de certezas, de funcionalidades. De este modo tendremos una idea clara qué se precisa a grandes rasgos (una moto, un monopatín, un coche deportivo…) y podremos sentar unas bases que sin ser tan sólidas sí serán suficientemente sólidas.

Mientras el desarrollo ha arrancado, las conversaciones no han parado: al entregar el piloto ya habremos refinado más historias de usuario hasta convertirlas en funcionalidades claras, por lo cual el equipo de desarrollo tiene más material para seguir funcionando.

Al finalizar esta iteración, por un lado tendremos más historias de usuario refinadas en funcionalidades claras; por otro lado los usuarios nos pueden aportar un feedback de su interacción con el piloto, plasmado en más historias de usuarios y funcionalidades; finalmente el equipo de desarrollo habrá realizado una nueva entrega. No olvides incluir en cada iteración tiempo para que el equipo de desarrollo pueda aprender de sus experiencias (retrospectiva), corregir el rumbo y errores (testeo y refactorización), y formarse, investigar, ensayar… En caso contrario no dispondrás nunca de tiempo.

Y así podemos continuar iterando hasta convertir todas las historias de usuario, las originales y las nacidas de la experiencia real, en software que funciona. Contado así hasta parece fácil, y que cualquiera puede hacerlo

Cuál es el siguiente número de estas series ?

0 – 4 – 12 – 24 – 40 – ???

1/8 – 1/8 – 1/4 – 3/4 – 3 – ???

4 – 8 -15 – 16 – 23 – ???

Este tipo de series se reduce a averiguar qué tipo de regla se está aplicando encontrando la relación que existe entre estos números. En el fondo se trata de un buen ejercicio de lógica, aunque en este caso se reduzca únicamente a unas pocas posibilidades.

Curiosamente un día después de recibir la petición de ayuda para resolver un par de series me encuentro en la tesitura de diseñar un algoritmo típico en banca / seguros, es decir un montón de cosas simples con estado e interrelacionadas. Para diseñar un algoritmo el principio es el mismo : encontrar la relación entre unos datos para plasmar dicha relación en una implementación. 

Por cierto, has averiguado cuáles son los 3 números ocultos ? Has averiguado cuáles son las reglas que los unen ?

Bueno, pues ersta es mi interpretación genérica de qué es una persona. Para cada aplicación puede haber partes que varíen. Si tienes cualquier discrepancia no dudes en comentármela, excepto si eres JoseDa, claro.

Una persona es una clase que puede tener varios teléfonos de contacto, puede tener varias direcciones de contacto, y tiene unos datos personales. Únicamente un grupo de datos personales invariables ? No. La gente cambia de nombre, de sexo, de nacionalidad… 

La "foto" o ficha de una persona no es más que una asociación invariable entre una persona y un grupo de sus teléfonos, direcciones y datos personales.

Un usuario es una extensión de una persona, es decir, una persona que puede autenticarse en nuestro sistema mediante un nombre de usuario y una contraseña.

Con todo esto podemos definir el siguiente modelo de clases (utilizando violet)

Y es inmediato obtener el esquema de datos para nuestra base de datos (utilizando la nueva versión del DBDesigner 4.0, el MySQL WorkBench 5.0). En el modelo no he puesto los atributos de las clases, sólo las claves primarias.

Y también es entonces inmediato obtener las clases en Java que representen estos objetos. Lo dejo para la próxima entrega.

Antes que nada, es una entrada sobre Java, de mi trabajo, no de mis opiniones metafísicas.

Acabo de tener la oportunidad de hacerme esta pregunta profesionalmente, Qué es un persona en una aplicación web ? Y yo pensando que a estas alturas ya debería de estar más que contestada y clara porque todas y cada una de las aplciaciones web que construimos manejan los conceptos "Persona" y "Usuario".

Las aplicaciones web suelen estar asociadas a un negocio, así que se relaciona la persona o el usuario con los objetos de negocio de la propia aplicación : una póliza, una solicitud, una compra…

Pero las personas cambian con el tiempo, de dirección, de móvil, de nacionalidad, e incluso de sexo ! Por lo tanto debemos guardar la "foto" de la persona en el momento en el cursó cada póliza, solicitud o compra.

Así que os propongo este ejercicio, definid qué es una persona, un usuario y su relación. Una persona puede tener asociadas teléfonos y direcciones. Además debemos de ser capaces de guardar "fotos" de la persona en determinados instantes (por ejemplo cuando realiza una compra en nuestro sistema).

La semana que viene lo resuelvo, o al menos os doy mi solución .