Figura 8: Extensión informal de UML — Tarjetas CRC para análisis guiados por la responsabilidad.
3.4.2. Diseño del sistema con Diagramas de Clase
Durante el diseño, el Diagrama de Clase se elabora para tener en cuenta los detalles concretos de la implementación del sistema.
3.4.2.1. Arquitecturas Multicapas
Una vez concienciados del diseño, estableceremos la arquitectura del sistema. Esto incluye establecer si será un sistema simple diseñado para correr en una sola máquina, un sistema "two-tiered" consistente en un cliente y un servidor, o un sistema "multi-tiered" con objetos interfaz de usuario separados de los objetos "business", separado de la base de datos, cada uno corriendo en plataformas distintas.
Una aproximación a dirigir el diagrama de clase para un sistema complejo es separar el diagrama en secciones que muestren la lógica de la aplicación, el diseño de la interfaz de usuario, y las clases implicadas con el almacenamiento de los datos. Esto se puede hacer físicamente segmentando el diagrama de clase, usando diagramas separados para cada sección, o simplemente añadiendo una propiedad a cada clase que "tracks" cada "tier" al cual pertenece.
3.4.2.2. Diseño de Componentes
Un componente es un grupo de objetos o componentes más pequeños que interaccionan entre ellos y se combinan para dar un servicio. Un componente es similar a una caja negra, en la cual los servicios del componente se especifican por su interface o interfaces, sin ofrecer conocimiento del diseño e implementación internas del componente. El desarrollo basado en componentes es el proceso de
ensamblar la combinación correcta de componentes en la configuración correcta para llevar acabo la funcionalidad deseada para un sistema. Los componenetes se representan en el diagrama de clases de UML especificando la interfaz de una clase o paquete. Hay dos notaciones para mostrar una interfaz – una es mostrar la interfaz como una "regular class symbol" con el estereotipo "interfz", con una lista de operaciones soportadas por esta interfaz, detalladas en el "operation department" (departamento de operación). "The alternate, shortcut notation" es mostrar la interfaz como un circulo pequeño junto con la clase con una línea sólida, con el nombre de la interfaz en el círculo.
El ejemplo de la Figura 9 muestra que la clase "Pasajero" ofrece la operación move(x coord, y coord) para su apariencia en un GUI, a través de su interfaz "Displayable". Ambas notaciones UML de interfaz, se muestran en la figura. Además, la clase Pasajero también ofrece una opción save(store at) a través de su interfaz Persistente. Una clase de o componente para conectar con una base de datos podría usar esta interfaz.
Figura 9: Diseño de Componentes: Especificando la Interfaz de la Clase
3.4.2.3. Análisis y diseño "Iterative"
El diagrama de clase se puede desarrollar en una "iterative fashion", a través de un ciclo repetido de análisis, diseño e implementación, y después vuelta al análisis, para empezar el ciclo de nuevo. Este proceso se suele llamar "round-trip engineering". El modelado de herramientas como System Architect 2001 puede facilitar este proceso permitiéndote implementar el diseño en un lenguaje como C++ o Java, y después traer de vuelta al código a al diagrama de clase, automáticamente actualizando la información contenida en el diagrama y en el "underlying repository".
Figura 10: Análisis, diseño y documentación "Iterative" con el Diagrama de Clase
Modelando el comportamiento de las Clases con Diagramas de Estado
Mientras los diagramas de interacción y colaboración modelan secuencias dinámicas de acción entre grupos de objetos en un sistema, el diagrama de estado se usa para modelar el comportamiento dinámico de un objeto en particular, o de una clase de objetos.
Un diagrama de estado se modela para todas las clases que se consideran con un comportamiento dinámico. En él, modelas la secuencia de estado que un objeto de la clase atraviesa durante su vida en respuesta a los estímulos recibidos, junto con sus propias respuestas y acciones.
Por ejemplo, un comportamiento de un objeto se modela en términos de en qué estado está inicialmente, y a qué estado cambia cuando recibe un evento en particular. También modelas qué acciones realiza un objeto en un estado en concreto.
Los estados representan las condiciones de objetos en ciertos puntos en el tiempo. Los eventos representan incidentes que hacen que los objetos pasen de un estado a otro. Las líneas de transición describen el movimiento desde un estado hasta otro. Cada línea de transición se nombre con el evento
que causa esta transición. Las acciones ocurren cuando un objeto llega a un estado.
Figura 11: Modelando Comportamiento Dinámico de un objeto "Vuelo" con un diagrama de estado
Diagramas de Actividad
El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado.
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos "bussiness" algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes.
3.6.1. Usando Diagramas de Actividad para modelar Casos de Uso
Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad.
3.6.2. Usando Diagramas de Actividad para modelar Clases
Cuando se modela el comportamiento de una clase, un diagrama de estado de UML se suel usar normalmente para modelar situaciones donde ocurren eventos asincrónicos. El diagrama de actividad se usa conado todos o la mayoría de los elementos representan el desarrollo de los pasos dados por las acciones generadas internamente. Deberías asignar actividades a las clases antes de terminar con el
diagrama de actividad.
Figura 12: Diagrama de Actividad
Modelando Componentes de Software
El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo las dependencias entre los componentes de software, los componentes de código binario, y los componentes ejecutables. En el Diagrama de Componentes modelas componentes del sistema, a veces agrupados por paquetes, y las dependencias que existen entre componentes (y paquetes de componentes).
Figura 13: Modelando componentes con el Diagrama de Componentes
Modelando la Distribución y la Implementación
Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama "deployment", empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente.
Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo "becomes" (se transforma)
Figura 14: Modelando la Distribución del Sistema con el Diagrama de Implementación
Diseño de Bases de Datos Relacionales — Una extensión informal de UML
El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos de almacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden ser implementadas directamente en una base de datos orientada a objetos. Aun así, en el entorno de desarrollo actual, la base de datos relacional es el método más usado para el almacenamiento de datos.
Es en el modelado de este área donde UML se queda corto. El diagrama de clase de UML se puede usar para modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semántica involucrada en el modelado relacional, mayoritariamente la noción de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar esta información, un Diagrama de Relación de Entidad (ER diagram) se recomienda como extensión a UML.
El Diagrama de Clase se puede usar para modelar el estructura lógica de la base de datos, independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos de clase representando columnas. Si una base de datos relacional es el método de implementación escogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relación de entidad lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entre entidades en un diagrama de relación de entidad (ER diagram).
Figura 15: Extensión de UML — Diseño de Bases de Datos Relacionales con el Diagrama de Relación de Entidad (ER Diagram)
Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de determinar cómo el modelo relacional encaja; y qué atributos son claves primarias, claves secundarias, y claves externas basadas en relaciones con otras entidades. La idea es constriur un modelo lógico que sea conforme a las reglas de normalización de datos.
Al implementar el diseño relacional, es una estrategia encaminada a hacer referencia al diagrama de relación de entidad lógico a un diagrama físico que represente el objetivo, el RDBMS. El diagrama físico puede ser denormalizado para lograr un diseño de base de datos que tiene tiempos eficientes de acceso a los datos. Las relaciones supersub entre entidades se resuelven por las estructuras de tablas actuales.
Además, el diagrama físico se usa para modelar propiedades específicas de cada fabricante para el RDBMS. Se crean varios diagramas físicos si hay varios RDBMSs siendo "deployed"; cada diagrama físco representa uno de los RDBMS que son nuestro objetivo.
Figura 16: Relaciones clave entre entidades en un Diagrama de Relación de Entidad
Uso de una herramienta de modelado
El intercambio de información de diseño e ideas usando la notación UML sería hecho en los medios que siempre han sido populares: pizarras, cuadernos y trozos de papel por nombrar algunos. Pero UML se sirve mejor por una herramienta de modelado, la cual puede ser usada para capturar, guardar, rechazar, integrar automáticamente información, y diseño de documentación.
Una característica que beneficia a los modeladores, UML también hace más fácil escoger una herramienta de modelado. Hace tiempo, el modelador primero tenía que seleccionar una notación de metodología, y después estaba limitado a seleccionar una herramienta que la soportara. Ahora con UML como estándar, la elección de notación ya se ha hecho para el modelador. Y con todas las herramientas de modelado soportando UML, el modelador puede seleccionar la herramienta basada en las áreas claves de funcionalidad soportadas que permiten resolver los problemas y documentar las soluciones.
Como una buena caja de herramientas, una buena herramienta de modelado ofrece todas las herramientas necesarias para conseguir hacer eficientemente varios trabajos, sin dejarte nunca sin la herramienta correcta. Dentro de la estructura de diseño de sistemas descrito en esta guía, esto incluye lo siguiente:
• Soporte para toda la notación y semántica de UML
• Soporte para una cantidad considerable de técnicas de modelado y diagramas para complementar UML – incluyendo tarjetas CRC, modelado de datos, diagramas de flujo, y diseño de pantallas de usuario. Posibilidad de reutilizar información obtenida por otras ténicas todavía usadas, como modelado tradicional de procesos.
• Facilitar la captura de información en un repositorio subyacente – permitiendo la reutilización entre diagramas.
• Posibilidad de personalizar las propiedades de definición de elementos subyacentes de modelos UML.
• Permitir a varios equipos de analistas trabajar en los mismos datos a la vez.
• Posibilidad de capturar los requisitos, asociarlos con elementos de modelado que los satisfagan y localizar cómo han sido satisfechos los requisitos en cada uno de los pasos del desarrollo.
• Posibilitar la creación de informes y documentación personalizados en tus diseños, y la salida de estos informes en varios formatos, incluyenod HTML para la distribución en la Internet o Intranet local.
• Posibilidad para generar y "reverse" código (por ejemplo C++, Java, etc) para facilitar el análisis y diseño "iterative", para volver a usar código o librerías de clase existentes, y para documentar el código.
Proceso de desarrollo
Aunque UML es bastante independiente del pro-ceso de desarrollo que se siga, los mismos creadores de UML han propuesto su propia metodología de desarrollo, denominada el Proceso Unificado de Desarrollo.
El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidos. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todos los esquemas de un sistema software. Pero, realmente, los aspectos que definen este Proceso Unificado son tres: es iterativo e incremental, dirigido por casos de uso y centrado en la arquitectura :
• Dirigido por casos de uso: Basándose en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que los llevan a cabo. Además, estos modelos se vali-dan para que sean conformes a los casos de uso. Finalmente, los casos de uso también sir-ven para realizar las pruebas sobre los componentes desarrollados.
• Centrado en la arquitectura: En la arquitectura de la construcción, antes de construir un edificio éste se contempla desde varios puntos de vista: estructura, conducciones eléctricas, fontanería, etc. Cada uno de estos aspectos está representado por un gráfico con su notación correspondiente. Siguiendo este ejemplo, el concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema.
• Iterativo e incremental: Todo sistema informático complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias fases. Actualmente se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina iteración en el proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Además, cada iteración parte de la anterior incrementado o revisando la funcionalidad implementada. Se suele denominar proceso. Ver figura 17
Figura 17: Proceso iterativo e incremental
Resumiendo, el Proceso Unificado es un modelo complejo con mucha terminología propia, pensado principalmente para el desarrollo de grandes proyectos. Es un proceso que puede adaptarse y extenderse en función de las necesidades de cada empresa.
Conclusiones
Es fácil predecir que UML será el lenguaje de modelado de software de uso universal. Las principales razones para ello son:
• En el desarrollo han participado investigadores de reconocido prestigio.
• Ha sido apoyado por prácticamente todas las empresas importantes de informática.
• Se ha aceptado como un estándar por la OMG.
• Prácticamente todas las herramientas CASE y de desarrollo la han adaptado como lenguaje de modelado.
En resumen, UML resuelve de forma bastante satisfactoria un viejo problema del desarrollo de software como es su modelado gráfico. Además, se ha llega-do a una solución unificada basada en lo mejor que había hasta el momento, lo cual lo hace todavía más excepcional.
Bibliografía
B. Vela, E. Marcos, Una extensión de UML para representar XML Schemas
Entendiendo UML: La guía del desarrollador, con una aplicación java basada en web, por Paul
Harmon y Mark Watson; Morgan Kauffman Publishers, Inc., 1998
(www.mkp.com/books_catalog/1-55860-465-0.asp).
¿Qué le falta a UML? un artículo por Scott Ambler, "Objet Magacine", Octubre de 1997, SIGS. Publications (www.sigs.com/omo/articles/ambler.html)
Especificación UML 1.1 (Centro de Recursos de UML en www.popkin.com)
Objetos, componentes y Estructuras con UML, The Catalysis Aproach, por Desmond F. D"Souza y Alan C. Wills, Addison Wesley Longman, 1998
Enrique Hernández Orallo, El Lenguaje, Unificado de Modelado (UML).
Autor:
Ing. Lizana Puelles Esther Yolanda
| Página siguiente |