Modelado de Sistemas con UML

Introducción

En el presente módulo se permite entregar un material de apoyo que le permita al alumno poder definir diagramas propios como también poder entender el modelamiento de diagramas ya existentes, y finalmente se analiza los diagramas que componen UML y ofrece acercamientos a casos de uso guiados sobre cómo estos diagramas se usan para modelar sistemas, toda vez que el Lenguaje de Modelamiento Unificado (UML – Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.

El lenguaje UML

Cualquier rama de ingeniería o arquitectura ha encontrado útil desde hace mucho tiempo la representación de los diseños de forma gráfica. Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños de una forma más bien personal o con algún modelo gráfico. La falta de estandarización en la manera de representar gráficamente un modelo impedía que los diseños gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores.

Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creó el Lenguaje Unificado de Modelado (UML: Unified Modeling Lan-guage).

UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño.

El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con los diagramas de despliegue.

• MODELADO VISUAL

Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificación de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación gráfica. Esto se conoce como modelado visual.

El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. De la misma forma que para construir una choza no hace falta un modelo, cuando se intenta construir un sistema complejo como un rascacielos, es necesario abstraer la complejidad en modelos que el ser humano pueda entender.

UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los sistemas software como para la arquitectura hardware donde se ejecuten.

Otro objetivo de este modelado visual es que sea independiente del lenguaje de implementación, de tal forma que los diseños realizados usando UML se pueda implementar en cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados a objetos).

UML es además un método formal de modelado. Esto aporta las siguientes ventajas:

• Mayor rigor en la especificación.

• Permite realizar una verificación y validación del modelo realizado.

• Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y a la inversa (a partir del código fuente generar los modelos). Esto permite que el modelo y el código estén actualizados, con lo que siempre se puede mantener la visión en el diseño, de más alto nivel, de la estructura de un proyecto.

• HISTORIA DE UML

El lenguaje UML comenzó a gestarse en octubre de 1994 [1], cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software). El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Mode-lling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los "tres amigos". Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.

Esta primera versión se ofreció a un grupo de tra-bajo para convertirlo en 1997 en un estándar del OMG (Object Management Group http://www.omg.org). Este grupo, que gestiona estándares relacionados con la tecnología orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.), propuso una serie de modificaciones y una nueva versión de UML (la 1.1), que fue adoptada por el OMG como estándar en noviembre de 1997. Desde aquella versión han habido varias revisiones que gestiona la OMG Revision Task Force. La última versión aprobada es la 1.4. En estos momentos se está desarrollando una nueva versión en la que se incluirán cambios importantes (principalmente añadir nuevos diagramas) que conducirán a la versión 2.0 planificada para fines del 2002.

• ¿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 es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y una reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema.

Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo.

Las objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

• Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.

• Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.

Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseñados.

• Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura re-visión.

Aunque UML está pensado para modelar sistemas complejos con gran cantidad de software, el lenguaje es los suficientemente expresivo como para modelar sistemas que no son informáticos, como flujos de trabajo (workflow ) en una empresa, diseño de la estructura de una organización y por supuesto, en el diseño de hardware.

Un modelo UML está compuesto por tres clases de bloques de construcción:

• Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)

• Relaciones: relacionan los elementos entre sí.

• Diagramas: Son colecciones de elementos con sus relaciones.

• DIAGRAMAS UML

Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas 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.

Los diagramas más interesantes (y los más usados) son los de casos de uso, clases y secuencia, por lo que nos centraremos en éstos. Pare ello, se utilizará ejemplos de un sistema de venta de entradas de cine por Internet.

El diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. En la figura 3 se muestra un ejemplo de casos de uso, donde se muestran tres actores (los clientes, los taquilleros y los jefes de taquilla) y las operaciones que pueden realizar (sus roles).

El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste es el diagrama más común a la hora de describir el diseño de los sistemas orientados a objetos. En la figura 4 se muestran las clases globales, sus atributos y las relaciones de una posible solución al problema de la venta de entradas.

En el diagrama de secuencia se muestra la interacción de los objetos que componen un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 5 muestra la interacción de crear una nueva sala para un espectáculo.

El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el comportamiento dinámico del sistema están los de interacción, colaboración, estados y actividades. Los diagramas de componentes y despliegue están enfocados a la implementación del sistema.

Figura 3: Diagrama de casos de uso

Figura 4: Diagrama de clases

Figura 5: Diagrama de secuencia.

• UML ofrece notación y semántica estándar

UML preescribe una notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos. Previamente, un diseño orientado a objetos podría haber sido modelado con cualquiera de la docena de metodologías populares, causando a los revisores tener que aprender las semánticas y notaciones de la metodología empleada antes que intentar entender el diseño en sí. Ahora con UML, diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de los otros.

• 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 continú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ándose 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".

• XML Schemas en UML extendido

Un XML Schema es un documento que define el contenido y la estructura de un tipo de documento XML, es decir, describe los elementos y atributos que puede contener un documento y la forma en la que se pueden definir dentro de una estructura jerárquica de un documento válido.

Dado que XML Schema no tiene su propia notación gráfica se ha decidido utilizar UML. Sin embargo, este lenguaje no permite representar directamente estos esquemas, con lo que será necesario realizar una extensión al mismo.

UML ha sido diseñado para que pueda extenderse de una forma controlada, mediante sus propios mecanismos de extensión. Dichos mecanismos permiten crear nuevos bloques de construcción por medio de estereotipos, valores etiquetados y restricciones. Una extensión de UML debería contener : una breve descripción, la lista y descripción de los estereotipos, valores etiquetados y restricciones, y un conjunto de reglas que permitan determinar si un modelo está bien construido. La Tabla 1 resume la propuesta de extensión de UML para la representación de XML Schemas.

Tabla 1. Extensión de UML para representación gráfica de XML Schemas

Se ha presentado una extensión a UML para representar un esquema en XML Schema. Esta propuesta se enmarca dentro de MIDAS/DB, una metodología para la creación de bases de datos Web que propone utilizar UML como notación única para la definición de todo el sistema. Existen diferentes extensiones a UML para distintas técnicas de modelado Web, sin embargo, no son suficientes para representar todas las técnicas que se proponen en MIDAS/DB.

Para validar la extensión propuesta se han desarrollado distintos casos de prueba.

Además también se está realizando la implementación de una extensión a Rational Rose, que permitirá la representación en notación gráfica en UML de todo el sistema en todas las etapas de desarrollo de MIDAS/DB, así como la transformación semiautomática entre las distintas etapas. Actualmente, se está trabajando en la definición de otras extensiones a UML necesarias para poder respresentar todo el sistema con una única notación, y de guías de transformación para pasar de una etapa a la siguiente de forma sistemática.

Una perspectiva general de UML

• Una vuelta por un caso de uso

Una vez más, UML es una notación, no un método. No preescribe un proceso para modelar un sistema.

No obstante, como UML incluye los diagramas de casos de uso, se le considera estar dotado de una aproximación al diseño centrada en el problema con los casos de uso. El Diagrama de Caso de Uso nos da el punto de entrada para analizar los requisitos del sistema, y el problema que necesitamos solucionar.

La Figura 1 muestra un flujo general de cómo los diagramas de UML, con extensiones, interactuan en una aproximación al diseño con los casos de uso.

• Casos de Uso y Diagramas de Interacción

Un caso de uso se modela para todos los procesos que el sistema debe llevar a cabo. Los procesos se describen dentro de el caso de uso por una descripción textual o una secuencia de pasos ejecutados. Los Diagramas de Actividad se pueden usar también para modelar escenarios gráficamente. Una vez que el comportamiento del sistema está captado de esta manera, los casos de uso se examinan y amplian para mostrar qué objetos se interrelacionan para que ocurra este comportamiento. Los Diagramas de Colaboración y de Secuencia se usan para mostrar las relaciones entre los objetos.

• Clases y Diagramas de Implementación

Conforme se van encontrando los objetos, pueden ser agrupados por tipo y clasificados en un Diagrama de Clase. Es el diagrama de clase el que se convierte en el diagrama central del análisis del diseño orientado a objetos, y el que muestra la estructura estática del sistema. El diagrama de clase puede ser dividido en capas: aplicación, y datos, las cuales muestran las clases que intervienen con la interfaz de usuario, la lógica del software de la aplicación, y el almacenamiento de datos respectivamente. Los Diagramas de Componentes se usan para agrupar clases en componentes o módulos. La distribución general del hardware del sistema se modela usando el Diagrama de Implementación.

• Tarjetas CRC (CRC cards) – Una extensión informal de UML

Como una extensión informal a UML, la técnica de las tarjetas CRC se puede usar para guiar el sistema a través de análisis guiados por la responsabilidad. Las clases se examinan, se filtran y se refinan en base a sus responsabilidades con respecto al sistema, y las clases con las que necesitan colaborar para completar sus responsabilidades.

• Diagramas de Estado

El comportamiento en tiempo real de cada clase que tiene comportamiento dinámico y significativo, se modela usando un Diagrama de Estado. El diagrama de actividad puede ser usado también aquí, esta vez como una extensión del diagrama de estado, para mostrar los detalles de las acciones llevadas a cabo por los objetos en respuesta a eventos internos. El diagrama de actividad se puede usar también para representar gráficamente las acciones de métodos de clases.

Figura 1: Aproximación a un caso de uso guiado para el desarrollo orientado a objetos con UML, incluyendo las extensiones de tarjetas CRC y extensiones de modelado de datos.

• Implementando el diseño

La implementación del sistema trata de traducir información desde múltiples modelos UML en código y

estructura de bases de datos. Cuando se modela un sistema grande, es útil fragmentar el sistema en su capa "business" (incluyendo los objetos de la interfaz de usuario), su capa de aplicación (incluyendo los objetos de implementación), y su capa de datos (incluyendo la estructura de la base de datos y el acceso a objetos).

• Implementando la aplicación

El Diagrama de Clase se usa para generar una estructura base del código en el lenguaje escogido.

Información de los diagramas de interacción, estado, y actividad, puede ofrecer detalles de la parte procedimental del código de implementación.

• Implementando el diseño de Bases de Datos

La capa de datos del diagrama de clase se puede usar para implementar directamente un diseño orientado a objetos de una base de datos, o, como extensión de UML, puede ser referenciado en un diagrama de relación de entidad para más análisis de relaciones de entidad. Está en el diagrama de relación de entidad (ER diagram, entity relationship) el cual relaciona entre entidades que pueden ser modeladas basadas en atributos clave. El diagrama de relación de entidad lógico ofrece una base desde la cual construir un diagrama físico representando las tablas y relaciones actuales de la base de datos relacional.

• Probar teniendo en cuenta los requisitos

Los casos de uso se utilizan también para probar el sistema y ver si satisface los requisitos iniciales. Los pasos de los casos de uso van llevando a cabo para determinar si el sistema está satisfaciendo los requisitos del usuario.

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.

Figura 3: Modelado de Casos de Uso.

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 en forma de documentos de requisitos. Los casos de uso se utilizan para correlacionar cada escenario con los requisitos que completa. Si los requisitos no existen, modelar el sistema a través de los Casos de Uso, permite el descubrimiento de estos requisitos.

• Organización de Diagramas de Casos de Uso

Durante el análisis de negocio (business) del sistema, puedes desarrollar un modelo de caso de uso para este sistema, y construir paquetes para representar los varios dominios de negocio (business) del sistema.

Puedes descomponer cada paquete con un Diagrama de Caso de Uso que contenga los Casos de Uso de un dominio, con interacciones de actor.

• Un Caso de Uso para cada escenario

El objetivo es construir un Diagrama de Caso de Uso para cada tipo de escenario diferente en el sistema. Cada escenario muestra una secuencia diferente de interacciones entre actores y el sistema, sin condiciones "or".

• Modelar secuencias alternas a través de la relación "Extiende" (extends)

Típicamente, uno modela cada Caso de Uso con una secuencia normal de acciones. El usuario entonces considera condiciones "que si" para cada paso, y desarrolla Casos de Uso basados en estas secuencias alternas de eventos. Las secuencias alternas se modelan en casos de uso separados, los cuales están relacionados con el caso de uso original mediante una relación "Extiende" (extends). Las relaciones Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso de uso original.

En UML la relación de extensión es un elemento especial de modelado, por lo tanto la relación aparece explícitamente en las siguientes definiciones.

Definición 4: Extensión de Casos de Uso

Un Caso de Uso UC es la extensión de UC1 por UC2 a través de una relación "extend" ext; es decir, UC = UC1 ³ext UC2 si se cumple:

a- Aplicabilidad: El Caso de Uso UC1 es extendible por ext si se cumple la siguiente condición:

Para cada punto de extensión de ext debe existir una acción que coincida con él dentro de las secuencias de acciones del Caso de Uso:

« i OE ext. extensionPoint. $uo OE UC1.operation . $uotOE uo.actionSequence . i.location OE uot

b- UC1-Completitud: cada secuencia de acciones en UC1 es extendida en todas las formas posibles:

« o1 OE UC1.operation . $o OE UC.operation .

( o.name=o1.name Ÿ ("s1OEo1.actionSequence. extensions(s1,ext,UC2) Õ o.actionSequence ) )

c- UC1-Corrección: cada secuencia de acciones en UC es una extensión de alguna secuencia de acciones en UC1.

« oOEUC.operation .$o1OE UC1.operation . (o.name=o1.name Ÿ (« sOEo.actionSequence.

$s1OEo1.actionSequence. sOEextensions(s1,ext,UC2) ) )

Definición 5:

isExtensible: ActionSequence x Extend

El predicado es verdadero si la secuencia de acciones contiene algún punto de extensión de la relación extend y está definido de la siguiente forma:

« s:ActionSequence « ext:Extend .

isExtensible(s,ext) ´ $ iOEext.extensionPoint . i.locationOEs

Definición 6:

extensions: ActionSequence x Extend x UseCase -> Set(ActionSequence)

La función extensions(s,ext,uc) retorna el conjunto de todas las posibles extensiones de la secuencias dadas por la relación ext y el Caso de Uso uc. La función se define por casos de la siguiente forma:

Case 1: ÿ isExtensible(s,ext)

extensions(s,ext,uc)={s}

Case 2: isExtensible(s,ext)

extensions(s,ext,uc)={before(s,i.location); s2; after(s, i.location) /

iOEext.extensionPoint Ÿ i.locationOEs Ÿ s2OEuc.actionSequence }

Definición 7: UC extiende a UC1 si existe un Caso de Uso UC2 tal que UC es la extensión de UC1 por UC2 a través de una relación ext:

UC extendsext UC1 ´ $ UC2:UseCase . ( UC = UC1 ³ext UC2 )

• Eliminar el modelado redundante a través de la relación "Incluir"

(Include)

Para eliminar el modelado redundante de buena parte del comportamiento que aparezca en varios casos de uso, la parte del comportamiento puede ser modelada en un caso de uso separado que está relacionado con los otros casos de uso mediante la relación "Incluir" (Include). La relación Incluir (Include) se puede pensar como un caso de uso equivalente "of aggregation".

La relación Include

Una relación include entre dos Casos de Uso indica que el comportamiento definido en el Caso de Uso a adicionar, es incluído en un lugar dentro de la secuencia del comportamiento realizado por una instancia del Caso de Uso base. Cuando una instancia del Caso de Uso «llega al lugar» donde el comportamiento de otro Caso de Uso debe ser incluído, ejecuta todo el comportamiento descripto por el Caso de Uso incluído y luego continúa de acuerdo a su Caso de Uso original. El Caso de Uso incluído no depende del Caso de Uso base. En este sentido, el Caso de Uso incluído representa comportamiento encapsulado que puede ser reusado en varios Casos de Uso.

Definición 1: Inclusión de Casos de Uso

Un Caso de Uso UC es el resultado de incluir UC2 dentro de UC1; es decir UC = UC1 ³inc UC2 si se cumple lo siguiente:

a- Aplicabilidad: dentro de UC1 existe una llamada a UC2

$oOE UC1.operation . $utOE o.actionSequence . UC2.nameOEut

b- Completitud: UC contiene todas las posibles formas de incluir UC2 dentro de UC1

« o1OEUC1.operation . $oOE UC.operation . (o.name=o1.name Ÿ (« s1OEo1.actionSequence.

inclusions(s1,UC2) Õ o.actionSequence ) )

c- Corrección: todas las secuencias de acciones de UC provienen de incluir a UC2 dentro de alguna secuencia de acciones de UC1.

« oOEUC.operation . $o1OE UC1.operation . (o.name=o1.name Ÿ (« sOEo.actionSequence.

$s1OEo1.actionSequence. sOEinclusions(s1,UC2) ) )

Definición 2:

isIncluible: ActionSequence x UseCase

El predicado isIncluible(s,uc) es verdadero si la secuencia de acciones s contiene alguna invocación al Caso de Uso uc y está definido de la siguiente forma:

« s:ActionSequence « uc:UseCase . isIncluible(s,uc) ´ uc.name OEs

Definición 3:

inclusions: ActionSequence x UseCase -> Set(ActionSequence)

La función inclusions(s, uc) retorna el conjunto de todas las posibles inclusiones del Caso de Uso uc en la secuencia s y esta definida por casos, de la siguiente forma.

Case 1: ÿ isIncluible(s, uc) inclusions(s, uc)={s}

Case 2: isIncluible(s, uc) inclusions(s, uc)={ before(s,a);s2;after(s,a) / a=uc.name Ÿ s2OEuc.actionSequence }

Figura 4:: Relación caso de uso Extiende (extends) frente a relación de caso Usa (uses=Include).

• Ayuda en casos de uso probando el sistema frente a los requisitos

Los Casos de Uso también se utilizan para construir scripts de prueba que se usan a su vez para comprobar que la aplicación satisface los requisitos de negocio y de sistema.

Cuando has llegado al caso de uso del nivel más bajo, podrías crear un Diagrama de Secuencia para el Caso de Uso. Con los Diagramas de Secuencia y de Colaboración puedes modelar la implementación del escenario.

• Diagramas de Secuencia

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista "business" del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos.

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.

Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.

• Diagramas de Colaboración

El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y "time-out"), y la visibilidad de un objeto con respecto a los otros.

Figura 6:Diagrama de Colaboración para un grupo de Objetos

• Análisis y Diseño con el Diagrama de Clase

El Diagrama de Clase es el el diagrama principal de diseño y análisis para un sistema. En él, la estrucutra

de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante el

análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el

mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones.

3.4.1. Desarrollo de Diagramas de Clase durante el análisis

3.4.1.1. Aproximación a un Caso de Uso guiado

En una aproximación a un Caso de Uso guiado hacia el análisis orientado a objetos, el diagrama de clases se desarrolla a través de información obtenida en los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboración. Los objetos encontrados durante el análisis son modelados en términos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas.

Figura 7: Diagrama de Clase durante la fase de análisis

3.4.1.2. Extensión guiada por la responsabilidad

La técnica de la tarjeta CRC se usa a veces como una extensión a UML para análisis guiados por la responsabilidad. Las definiciones de clase son refinadas basándose en las responsabilidades de clase y en otras clases con las que colabora para completar sus responsabilidades.

Cada clase se representa en una tarjeta índice (index card), y los diseñadores establecen los papeles (roles) de las clases en el sistema para definir su trabajo, y con qué otras necesitan colaborar para completar sus responsabilidades. Esta información se pasa directamente a un diagrama de clase; las responsabilidades coinciden con los métodos de clase, las colaboraciones se traducen en asociaciones entre clases.