Metodologia UML

¿Qué es UML?

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

• Diagramas de Casos de Uso para modelar los procesos ’business’.

• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

• Diagramas de Colaboración para modelar interacciones entre objetos.

• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.

• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.

• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.

• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.

• Diagramas de Componentes para modelar componentes.

• Diagramas de Implementación para modelar la distribución del sistema.

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos.

Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.

En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.

UML no es un Método

Aun así, UML no preescribe un proceso o método estándar para desarrollar un sistema. Hay varias metodologías existentes; entre las más populares se incluyen las siguientes:

• Catalysis: Un método orientado a objetos que fusiona mucho del trabajo reciente en métodos orientados a objetos, y además ofrece técnicas específicas para modelar componentes distribuidos.

• Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por Ivar Jacobson.

• Shlaer/Mellor: El método para diseñar sistemas de tiempo real, puesto en marcha por Sally Shlaer y

Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos, modelando el Mundo en Estados y

Ciclos de vida de Objetos, Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor countinúan

actualizando su método continuamente (la actualización más reciente es el OOA96 report), y recientemente publicaron una guía sobre cómo usar la notación UML con Shlaer/Mellor.

• Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un método de diseño orientado a objetos estándar. Combina OMT y Booch con tarjetas CRC y métodos formales. (www.hpl.hp.com/fusion/file/teameps.pdf)

• OMT: La Técnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicada en el libro de gran influencia "Diseño y Modelado Orientado a Objetos" (Prentice Hall, 1991). Un método que propone análisis y diseño ’iterative’, más centrado en el lado del análisis.

• Booch: Parecido al OMT, y también muy popular, la primera y segunda edición de "Diseño Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design, With

Applications), detallan un método ofreciendo también diseño y análisis ’iterative’, centrándoso en el lado del diseño.

Además, muchas organizaciones han desarrollado sus propias metodologías internas, usando diferentes diagramas y técnicas con orígenes varios. Ejemplos son el método Catalyst por Computer Sciences

Corporation (CSC) o el Worlwide Solution Design and Delivery Method (WSDDM) por IBM. Estas metodologías difieren, pero generalmente combinan análisis de flujo de trabajo, captura de los requisitos, y modelado de negocio con modelado de datos, con modelado de objetos usando varias notaciones

(OMT, Booch, etc), y algunas veces incluyendo técnicas adicionales de modelado de objetos como Casos de Uso y tarjetas CRC. La mayoría de estas organizaciones están adoptando e incorporando el UML como la notación orientada a objetos de sus metodologías.

Algunos modeladores usarán un subconjunto de UML para modelar ’what they’re after’, por ejemplo simplemente el diagrama de clases, o solo los diagramas de clases y de secuencia con Casos de Uso.

Otros usarán una suite más completa, incluyendo los diagramas de estado y actividad para modelar sistemas de tiempo real, y el diagrama de implementación para modelar sistemas distribuidos. Aun así, otros no estarán satisfechos con los diagramas ofrecidos por UML, y necesitarán extender UML con otros diagramas como modelos relacionales de datos y ’CRC cards’.

Un estudio a fondo de UML

Las siguientes secciones presentan una vista más detallada al modelado con UML. Un sistema de reserva

de aerolíneas simple se va a usar para mostrar los diagramas y técnicas de modelado con UML. Se cubren los siguientes puntos:

• Organizando tu sistema con paquetes

• Modelando con Casos de Uso, y usándolos para averiguar los requisitos del sistema

• Modelando con Diagramas de Secuencia y Colaboración

• Analizando y diseñando con el Diagrama de Clase, y extendiendo UML con la técnica de las tarjetas

CRC

• Modelando comportamiento con Diagramas de Actividad y de Estado

• Modelando componentes de software, distribución e implementación

• Extendiendo UML con el diseño de Bases de Datos relacionales

Una de las tareas clave para modelar un sistema de sofware de grandes dimensiones es dividirlo primero

en áreas manejables. Aunque estas áreas se llaman dominios, categorías o subsistemas, la idea es la misma: dividir el sistema en áreas que tengan competencias parecidas.

UML introduce la noción de un paquete como el ítem universal para agrupar elementos, permitiendo a los modeladores subdividir y categorizar sistemas. Los paquetes pueden ser usados en cualquier nivel, desde el nivel más alto, donde son usados para subdividir el sistema en dominios, hasta el nivel más bajo, donde son usados para agrupar casos de uso individuales, clases, o componentes.

Modelado de Casos de Uso

El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmente una aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis orientado a objetos con UML.

El modelo de casos de uso consiste en actores y casos de uso. Los actores representan usuarios y otros sistemas que interaccionan con el sistema. Se dibujan como "muñecos" de palo. Actualmente representan el tipo de usuario, no una instancia de usuario. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo desde un actor. Se dibujan como elipses.

Cada caso de uso se documenta por una descripción del escenario. La descripción puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso puede ser también definido por otras propiedades, como las condiciones pre- y post- del escenario --- condiciones que existen antes de que el escenario comience, y condiciones que existen después de que el escenario se completa. Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. éstos son descritos en una sección posterior de este documento.

Estudiar y descubrir los requisitos

El objetivo final en cualquier diseño de software es satisfacer los requisitos del usuario para el sistema.

Estos requisitos pueden ser requisitos de software, requisitos de productos, o requisitos de pruebas. La meta de capturar y comprobar los requisitos del usuario es asegurar que todos los requisitos son completados por el diseño, y que el diseño es acorde con los requisitos especificados.

Muchas veces los requisitos del sistema ya existen

...