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.

Herramienta para prototipado de aplicaciones web, aquí hablaré de la versión v5.6.

• Herramienta de escritorio.
• Página de inicio aquí.
• Funcionalidades aquí.
  • Generación de documento de requisitos en Word a partir del modelo.
• Software de pago, versión de 30 días de prueba aquí.

Carencias

• Está pensado más para copiar y pegar que para reutilizar y parametrizar:
  • Falta de casos de uso globales comunes para toda la aplicación. Actualización: la versión 6 soporta casos globales y reutilizables.
  • Falta de evento onLoad para los paneles dinámicos para parametrizarse ellos mismos en lugar de tener que hacerlo en cada una de las páginas madre que les invocan.
  • Esto provoca que el desarrollo sea lento y tedioso, y los mantenimientos complejos y con altas posibilidades de bugs.
• La calidad del código generado es mejorable
  • No puedes utilizar hojas de estilo CSS.
  • No puedes automatizar las pruebas del código generado, ya que los elementos se generan con un id que cambia en cada versión.
    • Dificulta aún más los mantenimientos y desarrollos incrementales.
  • No puedes partir del código generado para construir las plantillas de la aplicación. Actualización: la versión 6 parece que soporta plantillas, pero no sé si se comportan como las layout de struts tiles y modificando la plantilla modificas todas las páginas, o si sólo sirven de apoyo para el desarrollo.
• La gestión de la memoria consumida es mejorable, cuando el prototipo empieza a crecer el manejo se vuelve exasperantemente lento.

Queremos desarrollar un sitio web. En este sitio web existirá una zona de administración, a la que únicamente accederán los administradores. Por tanto debemos implementar un mecanismos para controlar el acceso a esta zona. Para ello debemos implementar un código que cumpla los siguientes requisitos:

• Se accederá desde un enlace presente en la portada del sitio web.
• Se permitirá desconectarse de la administración (una vez identificado) desde un enlace desde la portada de la administración.
• Para identificarse se debe introducir un nombre de usuario y una contraseña válidos.
• Los nombres de usuario y sus contraseñas se almacenarán en código. Lo normal es que estuviesen almacenadas en una base de datos, pero utilizaremos JDBC más adelante.
• Si la identificación es correcta y tiene el privilegio de administrador, se redirigirá a la portada de la zona de administración, donde se mostrará un mensaje de bienvenida con su nombre.
• Si la identificación es correcta pero no posee el privilegio de administrador, se permitirá al usuario introducir nuevos datos y se le presentará un mensaje avisando de que no tiene privilegios.
• Si la identifiación no es correcta, se permitirá volver a introducir al usuario un nombre de red y una contraseña y se presentará un mensaje de identificación incorrecta.
• No hay límite de intentos incorrectos para cada usuario.

Podríamos implementar este control de acceso con la seguridad que nos proporciona TOMCAT. Pero en este caso lo implementaremos con Struts para tener un mayor control y flexibilidad.

Para los usuarios, pondremos los siguientes requisitos:

• Contendrán los siguientes datos de cada usuario:
  • Nombre, Apellido1 y Apellido2
  • Nombre de usuario (login)
  • Contrasenna
  • Roles
• Si entre los roles posee el rol “ADMINISTRADOR” podrá acceder al portal.

[tags]j2ee, struts[/tags]

Etapas 

La sincronización se dividirá en dos pasos :

1. Cruce de datos
2. Actualización de datos

Aún no se ha dedicido si serán clases java o servlets.

Entradas/Salidas

Entradas al cruce de datos: 

• Existen 4 fuentes de datos (2 de personal, 1 de régimen interno y 1 de sistemas). Estas fuentes de datos se pasarán a archivos csv (Comma Separated Values) para ser leídos por las clases de la sincronización.
• Un fichero csv que contiene los índices de cada persona en cada tabla (indices.csv).
• Será necesario un parámetro que represente el caracter que separa los valores de los archivos csv, típicamente ";".

• Para ayudar, se pasa el prefijo de los archivos de trazas

Salidas al cruce de datos:

• Un fichero csv con los resultados de los cruces de datos.
• El fichero csv que contiene los índices de cada persona en cada tabla (indices.csv).
• Un registro (log) de los cruces de datos. Es más útil que este fichero sea un csv indicando si se han encontrado los datos en cada fuente.
• Un registro (log) de las actualizaciones de los índices de cada persona en cada tabla (indices.csv).

Entradas a la actualización de datos :

• Ruta del fichero csv con los resultados generados en el cruce de datos.
• Será necesario un parámetro que represente el caracter que separa los valores de los archivos csv, típicamente ";".

Salidas a la actualización de datos :

• LDAP actualizado.
• Un registro (log) de acciones realizadas (altas/bajas/modificaciones).

Cruces de datos

Se realizarán dos cruces de datos:

1. Todos los usuarios de la fuente de Sistemas (que contiene todos los usuarios con acceso) con las demás fuentes.
2. Los usuarios de la fuente de Personal  que no se encuentren en la fuente de Sistemas (que contiene todos los usuarios sin acceso) con las demás fuentes.

Para ello se buscarán los usuarios en indices.csv.

• Si existe el índice
• si un usuario no se encuentra en una fuente de datos se actualiza indice.csv
• si un usuario que no se encontraba en indice.csv se encuentra buscando sin indice, se actualiza el indice.csv
• se forma los datos de usuarios.
• Si no existe el índice.
• Se cruzan los datos a buscando sin índice
• Se actualiza el fichero indices.csv

Actualización

Se recorre el fichero csv de actualización y se busca en el LDAP.

• Si se encuentra en el LDAP -> Es una modificación
• Si no se encuentra en el LDAP -> Es un alta

Se recorre el LDAP y se busca en el fichero csv

• Si no se encuentra es una baja lógica -> se modifica físicamente el campo es accesible
• Si se encuentra no se hacen nada