Modelado de Sistemas com UML -...

24
Modelado de Sistemas com UML Popkin Software and Systems

Transcript of Modelado de Sistemas com UML -...

Page 1: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Modelado de Sistemas com UML

Popkin Software and Systems

Page 2: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Modelado de Sistemas com UMLpor Popkin Software and Systems

Page 3: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Tabla de contenidos1. Introducción ...........................................................................................................................................1

2. ¿Qué es UML?........................................................................................................................................2

2.1. UML ofrece notación y semántica estándar................................................................................22.2. UML no es un Método................................................................................................................32.3. Extensiones UML 1.1.................................................................................................................4

2.3.1. Esteroetipos....................................................................................................................42.3.2. Extensiones de Modelado de Negocio............................................................................42.3.3. Lenguaje restrictivo (constraint) de objetos (OCL)........................................................4

2.4. Más Extensiones.........................................................................................................................42.4.1. Análisis guiados por la responsabilidad con tarjetas CRC.............................................52.4.2. Modelo Relacional de datos...........................................................................................5

3. Una perspectiva general de UML.........................................................................................................6

3.1. Una vuelta por un caso de uso....................................................................................................63.2. Casos de Uso y Diagramas de Interacción..................................................................................63.3. Clases y Diagramas de Implementación.....................................................................................63.4. Tarjetas CRC (CRC cards) - Una extensión informal de UML..................................................63.5. Diagramas de Estado...................................................................................................................63.6. Implementando el diseño............................................................................................................73.7. Implementando la aplicación......................................................................................................73.8. Implementando el diseño de Bases de Datos..............................................................................73.9. Probar teniendo en cuenta los requisitos.....................................................................................7

4. Un estudio a fondo de UML..................................................................................................................8

4.1. Modelado de Casos de Uso.........................................................................................................84.1.1. Estudiar y descubrir los requisitos..................................................................................94.1.2. Organización de Diagramas de Casos de Uso................................................................94.1.3. Un Caso de Uso para cada escenario..............................................................................94.1.4. Modelar secuencias alternas a través de la relación "Extiende" (extends).....................94.1.5. Eliminar el modelado redundante a través de la relación "Usa" (uses)........................104.1.6. Ayuda en casos de uso probando el sistema frente a los requisitos..............................10

4.2. Diagramas de Secuencia...........................................................................................................104.3. Diagramas de Colaboración......................................................................................................114.4. Análisis y Diseño con el Diagrama de Clase............................................................................11

4.4.1. Desarrollo de Diagramas de Clase durante el análisis..................................................114.4.2. Diseño del sistema con Diagramas de Clase................................................................12

4.5. Modelando el comportamiento de las Clases con Diagramas de Estado..................................134.6. Diagramas de Actividad............................................................................................................14

4.6.1. Usando Diagramas de Actividad para modelar Casos de Uso.....................................144.6.2. Usando Diagramas de Actividad para modelar Clases.................................................14

4.7. Modelando Componentes de Software.....................................................................................154.8. Modelando la Distribución y la Implementación......................................................................154.9. Diseño de Bases de Datos Relacionales -- Una extensión informal de UML...........................15

5. Uso de una Herramienta de Modelado..............................................................................................17

5.1. System Architect 2001..............................................................................................................17

iii

Page 4: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

6. Sumario.................................................................................................................................................19

7. Referencias...........................................................................................................................................20

iv

Page 5: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 1. Introducción

Esta guía introduce el Lenguaje Unificado de Modelado (UML), versión 1.1. Analiza los diagramas quecomponen UML y ofrece acercamientos a casos de uso guiados sobre cómo estos diagramas se usan paramodelar sistemas. La guía también trata los mecanismos de extensibilidad de UML, los cuales permitenampliar su notación y su semántica. También sugiere la extensión de UML mediante dos técnicas noincorporadas: tarjetas CRC para análisis guiados por la responsabilidad, y diagramas de Entidad deRelación (ER) para modelar bases de datos relacionales.

1

Page 6: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 2. ¿Qué es UML?

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar paramodelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas ysímbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseñoorientado 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ñoorientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos desemántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a estapetición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seispromotores 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 OMGllama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar unaedición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.

2.1. 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 orientadoa objetos. Previamente, un diseño orientado a objetos podría haber sido modelado con cualquiera de ladocena de metodologías populares, causando a los revisores tener que aprender las semáticas ynotaciones de la metodología empleada antes que intentar entender el diseño en sí. Ahora con UML,

2

Page 7: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 2. ¿Qué es UML?

diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno losdiseños de los otros.

2.2. UML no es un Método

Aun así, UML no preescribe un proceso o método estándar para desarrollar un sistema. Hay variasmetodologí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étodosorientados 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 ySteven Mellor en dos libros de 1991, Ciclos de vida de Objetos, modelando el Mundo en Estados yCiclos de vida de Objetos, Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor countinúanactualizando su método continuamente (la actualización más reciente es el OOA96 report), yrecientemente 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 unmétodo de diseño orientado a objetos estándar. Combina OMT y Booch con tarjetas CRC y métodosformales. (www.hpl.hp.com/fusion/file/teameps.pdf)

• OMT: La Técnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicadaen el libro de gran influencia "Diseño y Modelado Orientado a Objetos" (Prentice Hall, 1991). Unmé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 Orientadoa Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design, WithApplications), detallan un método ofreciendo también diseño y análisis ’iterative’, centrándoso en ellado del diseño.

Además, muchas organizaciones han desarrollado sus propias metodologías internas, usando diferentesdiagramas y técnicas con orígenes varios. Ejemplos son el método Catalyst por Computer SciencesCorporation (CSC) o el Worlwide Solution Design and Delivery Method (WSDDM) por IBM. Estasmetodologí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 Casosde Uso y tarjetas CRC. La mayoría de estas organizaciones están adoptando e incorporando el UMLcomo 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 ejemplosimplemente 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 modelarsistemas de tiempo real, y el diagrama de implementación para modelar sistemas distribuidos. Aun así,

3

Page 8: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 2. ¿Qué es UML?

otros no estarán satisfechos con los diagramas ofrecidos por UML, y necesitarán extender UML conotros diagramas como modelos relacionales de datos y ’CRC cards’.

2.3. Extensiones UML 1.1

Los mecanismos de de extensibilidad incorporados permiten a UML ser una especie de especificaciónabierta que puede cubrir aspectos de modelado no especificados en el documento 1.1. Estos mecanismospermiten extender la notación y semática de UML.

2.3.1. Esteroetipos

Los estereotipos son el mecanismo de extensibilidad incorporado más utilizado dentro de UML. Unestereotipo respresenta una distinción de uso. Puede ser aplicado a cualquier elemento de modelado,incluyendo clases, paquetes, relaciones de herencia, etc. Por ejemplo, una clase con estereotipo ’actor’ esuna clase usada como un agente externo en el modelado de negocio. Una clase patrón es modelada comouna clase con estereotipo parametrizado, lo que significa que puede contener parámetros.

2.3.2. Extensiones de Modelado de Negocio

Un documento separado dentro de la especificación UML define clases y estereotipos de asociaciónespecíficos que extienden UML hasta cubrir conceptos de modelado de negocio. Esto incluye’stereotyping’ una clase como un actor, un trabajador (’both internal and case’), o una entidad, y’stereotyping’ una asociación como una comunicación simple, o una subcripción entre un origen y unobjetivo.

2.3.3. Lenguaje restrictivo (constraint) de objetos (OCL)

Una imagen puede describir muchas palabras. De igual modo, un modelo gráfico puede describir unacierta parte del comportamiento, después de la cual es necesario rellenar detalles adicionales conpalabras. Describiendo algo con palabras, sin embargo, casi siempre desemboca en ambiguedades; porejemplo, "¿que quería decir cuando escribió eso?". El Lenguaje Restrictivo (constraint) de Objetos(OCL) está incorporado en UML como un estándar para especificar detalles adicionales, o precisardetalles en la estrucutura de los modelos.

Desarrollado dentro de la IBM Insurace Division como un lenguaje de modelado de negocio, el OCL esun lenguaje formal diseñado para ser fácil de leer y de escribir. OCL es más funcional que el lenguajenatural, pero no tan preciso como un lenguaje de programación - no puede ser usado para escribir lógicasde lógica de programación o control de flujo. Puesto que OCL es un lenguaje para la expresión pura, susdeclaraciones están garantizadas de no tener efectos laterales - simplemente transportan un valor y nuncapueden cambiar el estado del sistema.

4

Page 9: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 2. ¿Qué es UML?

2.4. Más Extensiones

Dos áreas específicas que UML no cubre actualmente, ni con sus extensiones, son análisis guiados por laresponsabilidad y modelado de bases de datos relacionales. Esta guía introduce estas técnicas comoextensiones actuales del mundo real para UML que se deberían tener en cuenta.

2.4.1. Análisis guiados por la responsabilidad con tarjetas CRC

Una técnica muy usada para hacerse a la idea de cómo hay que pensar trantando con orientación aobjetos son los análisis guiados por la responsabilidad con las tarjetas CRC (CRC - Colaborador yResponsabilidad de Clase). Con esta técnica, las clases descubiertas durante el análisis pueden serfiltradas para determinar qué clases son realmente necesarias para el sistema.

2.4.2. Modelo Relacional de datos

Aunque las bases de datos orientadas a objetos se están volviendo más populares, en el entorno dedesarrollo actual, la base de datos relacional sigue siendo el método predominante para almacenar datos.Los diagramas de clases de UML se pueden usar para modelar la base de datos relacional en la que elsistema está basado, sin embargo, los diagramas tradicionales de modelado de datos capturan másinformación sobre la base de datos relacional y son más adecuados para modelarla. Esta guía trata el usode Diagramas de Relaciones de Entidad (ER) como una extensión importante de UML para el modeladode bases de datos relacionales.

5

Page 10: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 3. Una perspectiva general de UML

3.1. 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 unaaproximación al diseño centrada en el problema con los casos de uso. El Diagrama de Caso de Uso nosda 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 enuna aproximación al diseño con los casos de uso.

3.2. 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 sedescriben dentro de el caso de uso por una descripción textual o una secuencia de pasos ejecutados. LosDiagramas de Actividad se pueden usar también para modelar escenarios gráficamente. Una vez que elcomportamiento del sistema está captado de esta manera, los casos de uso se examinan y amplian paramostrar qué objetos se interrelacionan para que ocurra este comportamiento. Los Diagramas deColaboración y de Secuencia se usan para mostrar las relaciones entre los objetos.

3.3. Clases y Diagramas de Implementación

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

3.4. 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 através de análisis guiados por la responsabilidad. Las clases se examinan, se filtran y se refinan en base asus responsabilidades con respecto al sistema, y las clases con las que necesitan colaborar para completarsus responsabilidades.

6

Page 11: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 3. Una perspectiva general de UML

3.5. Diagramas de Estado

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

Figura 1

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.

3.6. Implementando el diseño

La implementación del sistema trata de traducir información desde múltiples modelos UML en código yestructura de bases de datos. Cuando se modela un sistema grande, es útil fragmentar el sistema en sucapa ’business’ (incluyendo los objetos de la interfaz de usuario), su capa de aplicación (incluyendo losobjetos de implementación), y su capa de datos (incluyendo la estrucutra de la base de datos y el acceso aobjetos).

3.7. 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 parteprocedimental del código de implementación.

3.8. Implementando el diseño de Bases de Datos

La capa de datos del diagrama de clase se puede usar para implementar direcatmente un diseño orientadoa objetos de una base de datos, o, como extensión de UML, puede ser referenciado en un diagrama derelació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 enatributos clave. El diagrama de relación de entidad lógico ofrece una base desde la cual construir undiagrama físico representando las tablas y relaciones actuales de la base de datos relacional.

3.9. 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. Lospasos de los casos de uso van llevando a cabo para determinar si el sistema está satisfacciendo losrequisitos del usuario.

7

Page 12: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

Las siguientes secciones presentan una vista más detallada al modelado con UML. Un sistema de reservade aerolíneas simple se va a usar para mostrar los diagramas y técnicas de modelado con UML. Secubren 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 tarjetasCRC

• 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 primeroen áreas manejables. Aunque estas áreas se llaman dominios, categorías o subsistemas, la idea es lamisma: 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 alos 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.

Figura 2

Figura 2: Organizando el sistema mediante el uso de paquetes

4.1. 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 losrequisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómoun sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmenteuna aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sinembargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casosde uso son generalmente el punto de partida del análisis orientado a objetos con UML.

8

Page 13: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

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

Figura 3

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 enmodo de texto o en un formato paso a paso. Cada caso de uso puede ser también definido por otraspropiedades, como las condiciones pre- y post- del escenario --- condiciones que existen antes de que elescenario comience, y condiciones que existen después de que el escenario se completa. Los Diagramasde Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. éstos sondescritos en una sección posterior de este documento.

4.1.1. 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. Lameta de capturar y comprobar los requisitos del usuario es asegurar que todos los requisitos soncompletados 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 deuso se utilizan para correlacionar cada escenario con los requisitos que completa. Si los requisitos noexisten, modelar el sistema a través de los Casos de Uso, permite el descubrimiento de estos requisitos.

4.1.2. 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 paraeste 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 deun dominio, con interacciones de actor.

4.1.3. 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, sincondiciones ’or’.

9

Page 14: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

4.1.4. 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 entoncesconsidera condiciones "que si" para cada paso, y desarrolla Casos de Uso basados en estas secuenciasalternas de eventos. Las secuencias alternas se modelan en casos de uso separados, los cuales estánrelacionados con el caso de uso original mediante una relación "Extiende" (extends). Las relaccionesExtiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso deuso extendido, hereda y modifica el comportamiento del caso de uso original.

4.1.5. Eliminar el modelado redundante a través de la relación "Usa"(uses)

Para eliminar el modelado redundante de buena parte del comportamiento que aparezca en varios casosde uso, la parte del comportamiento puede ser modelada en un caso de uso separado que está relacionadocon los otros casos de uso mediante la relación "Usa" (uses). La relación Usa (uses) se puede pensarcomo un caso de uso equivalente ’of aggregation’.

Figura 4

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

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

Los Casos de Uso también se utilizan para constriur scripts de prueba que se usan a su vez paracomprobar 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 elCaso de Uso. Con los Diagramas de Secuencia y de Colaboración puedes modelar la implementación delescenario.

4.2. Diagramas de Secuencia

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

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesariospara la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una

10

Page 15: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos sonnecesarios para que se puedan seguir los pasos.

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

Figura 5

Figura 5:: Diagrama de Secuencia para un escenario

Durante el análisis inicial, el modelador típicamente coloca el nombre ’business’ de un mensaje en lalínea del mensaje. Más tarde, durante el diseño, el nombre ’business’ es reemplazado con el nombre delmétodo que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a ladefinición de la case instanciada por el objeto en la recepción final del mensaje.

4.3. Diagramas de Colaboración

El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelarinteracciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en lasecuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra enestudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio deenlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlacemuestra 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

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

4.4. 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 estrucutrade clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante elanálisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa elmismo diagrama, y se modifica para satisfacer los detalles de las implementaciones.

11

Page 16: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

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

4.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 declases se desarrolla a través de información obtenida en los Casos de Uso, Diagramas de Secuencia yDiagramas de Colaboración. Los objetos encontrados durante el análisis son modelados en términos dela clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre lasclases instanciadas.

Figura 7

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

4.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 laresponsabilidad. Las definiciones de clase son refinadas basándose en las responsabilidades de clase y enotras 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 paracompletar sus responsabilidades. Esta información se pasa directamente a un diagrama de clase; lasresponsabilidades coinciden con los métodos de clase, las colaboraciones se traducen en asociacionesentre clases.

Figura 8

Figura 8: Extensión informal de UML -- Tarjetas CRC para análisis guiados por la responsabilidad.

4.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 laimplementación del sistema.

4.4.2.1. Arquitecturas Multicapas

Una vez concienciados del diseño, estableceremos la arquitectura del sistema. Esto incluye establecer siserá un sistema simple diseñado para correr en una sola máquina, un sistema ’two-tiered’ consistente enun cliente y un servidor, o un sistema ’multi-tiered’ con objetos interfaz de usuario separados de losobjetos ’business’, separado de la base de datos, cada uno corriendo en plataformas distintas.

12

Page 17: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

Una aproximación a dirigir el diagrama de clase para un sistema complejo es separar el diagrama enseccionesque muestren la lógica de la aplicación, el diseño de la interfaz de usuario, y las clasesimplicadas con el almacenamiento de los datos. Esto se puede hacer físicamente segmentando eldiagrama de clase, usando diagramas separados para cada sección, o simplemente añadiendo unapropiedad a cada clase que ’tracks’ cada ’tier’ al cual pertenece.

4.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 secombinan para dar un servicio. Un componente es similar a una caja negra, en la cual los servicios delcomponente se especifican por su interface o interfaces, sin ofrecer concimiento del diseño eimplementación internas del componente. El desarrollo basado en componentes es el proceso deensamblar la combinación correcta de componentes en la configuración correcta para llevar acabo lafuncionalidad deseada para un sistema. Los componenetes se representan en el diagrama de clases deUML 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 deoperaciones soportadas por esta interfaz, detalladas en el ’operation department’ (departamento deoperación). ’The alternate, shortcut notation’ es mostrar la interfaz como un circulo pequeño junto con laclase 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 desu interfaz Persistente. Una clase de o componente para conectar con una base de datos podría usar estainterfaz.

Figura 9

Figura 9: Diseño de Componentes: Especificando la Interfaz de la Clase

4.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 deanálisis, diseño e implementación, y después vuelta al análisis, para empezar el ciclo de nuevo. Esteproceso se suele llamar ’round-trip engineering’. El modelado de herramientas como System Architect2001 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óncontenida en el diagrama y en el ’underlying repository’.

Figura 10

Figura 10:Análisis, diseño y documentación ’Iterative’ con el Diagrama de Clase

13

Page 18: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

4.5. Modelando el comportamiento de las Clases con Diagramas deEstado

Mientras los diagramas de interacción y colaboración modelan secuencias dinámicas de acción entregrupos de objetos en un sistema, el diagrama de estado se usa para modelar el comportamiento dinámicode 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 comportamientodinámico. En él, modelas la secuencia de estado que un objeto de la clase atraviesa durante su vida enrespuesta 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 unobjeto en un estado en concreto.

Los estados representan las condiciones de objetos en ciertos puntos en el tiempo. Los eventosrepresentan icendentes que hacen que los objetos pasen de un estado a otro. Las líneas de transicióndescriben el movimiento desde un estado hasta otro. Cada línea de transición se nombre con el eventoque causa esta transición. Las acciones ocurren cuando un objeto llega a un estado.

Figura 11

Figura 11:Modelando Comportamiento Dinámico de un objeto ’Vuelo’ con un diagrama de estado

4.6. Diagramas de Actividad

El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar elcomportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, ouna clase, o un método complicado.

Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas deactividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usandiagramas de actividad para modelar procesos ’bussiness’ algunos de los cuales pueden actuar enparalelo, y para modelar varios hilos en los programas concurrentes.

4.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 casode uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad.

14

Page 19: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

4.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 usarnormalmente para modelar situaciones donde ocurren eventos asincrónicos. El diagrama de actividad seusa conado todos o la mayoría de los elementos representan el desarrollo de los pasos dados por lasacciones generadas internamente. Deberías asignar actividades a las clases antes de terminar con eldiagrama de actividad.

Figura 12

Figura 12:Diagrama de Actividad

4.7. Modelando Componentes de Software

El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo lasdependencias entre los componentes de software, los componentes de código binario, y los componentesejecutables. En el Diagrama de Componentes modelas componentes del sistema, a veces agrupados porpaquetes, y las dependencias que existen entre componentes (y paquetes de componentes).

Figura 13

Figura 13:Modelando componentes con el Diagrama de Componentes

4.8. Modelando la Distribución y la Implementación

Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesadoen tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos desoftware que viven en ellos. En el diagrama ’deployment’, empiezas modelando nodos físicos y lasasociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias decomponentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contieneel componente.

Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidadesen tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o detiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos quemigran de componente a componente usando una relación de dependencia con el estereotipo ’becomes’(se transforma)

Figura 14

Figura 14:Modelando la Distribución del Sistema con el Diagrama de Implementación

15

Page 20: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 4. Un estudio a fondo de UML

4.9. Diseño de Bases de Datos Relacionales -- Una extensióninformal de UML

El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos dealmacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden serimplementadas directamente en una base de datos orientada a objetos. Aun así, en el entorno dedesarrollo 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 usarpara modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semánticainvolucrada en en el modelado relacional, mayoritariamente la noción de atributos clave que relacionanentre 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 atributosde clase representando columnas. Si una base de datos relacional es el método de implementaciónescogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relación de entidadlógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y asus atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relacionesentre entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entreentidades en un diagrama de relación de entidad (ER diagram).

Figura 15

Figura 15:Extensión de UML -- Diseño de Bases de Datos Relacionales con el Diagrama de Relaciónde Entidad (ER Diagram)

Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de determinar cómoel modelo relacional encaja; y qué atributos son claves primarias, claves secundarias, y claves externasbasadas en relaciones con otras entidades. La idea es constriur un modelo lógico que sea conforme a lasreglas de normalización de datos.

Al implementar el diseño relacional, es una estrategia encaminada a hacer referencia al diagrama derelación de entidad lógico a un diagrama físico que represente el objetivo, el RDBMS. El diagrama físicopuede ser denormalizado para lograr un diseño de base de datos que tiene tiempos eficientes de acceso alos datos. Las relaciones super-sub 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 elRDBMS. Se crean varios diagramas físicos si hay varios RDBMSs siendo ’deployed’; cada diagramafísco representa uno de los RDBMS que son nuestro objetivo.

Figura 16

Figura 16:Relaciones clave entre entidades en un Diagrama de Relación de Entidad

16

Page 21: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 5. Uso de una Herramienta deModelado

El intercambio de información de diseño e ideas usando la notación UML sería hecho en los medios quesiempre han sido populares: pizarras, cuadernos y trozos de papel por nombrar algunos. Pero UML sesirve 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 unaherramienta de modelado. Hace tiempo, el modelador primero tenía que selecionar una notación demetodología, y después estaba limitado a seleccionar una herramienta que la soportara. Ahora con UMLcomo estándar, la elección de notación ya se ha hecho para el modelador. Y con todas las herramientasde modelado soportando UML, el modelador puede seleccionar la herramienta basada en las áreas clavesde 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 herramientasnecesarias para conseguir hacer eficientemente varios trabajos, sin dejarte nunca sin la herramientacorrecta. 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 complementarUML - incluyendo tarjetas CRC, modelado de datos, diagramas de flujo, y diseño de pantallas deusuario. Posibilidad de reutilizar información obtenida por otras ténicas todavía usadas, comomodelado tradicional de procesos.

• Facilitar la captura de información en un repositorio subyacente - permitiendo la reutilización entrediagramas.

• 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 ylocalizar 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 estosinformes 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 ydiseño ’iterative’, para volver a usar código o librerías de clase existentes, y para documentar elcódigo.

17

Page 22: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 5. Uso de una Herramienta de Modelado

5.1. System Architect 2001

Popkin software ofrece soporte para modelar sistemas con UML en System Architect 2001. Ofrece todaslas características descritar arriba para permitir el modelado eficiente de sistemas. Para más informaciónen los distintos productos de Popkin Software, visite www.popkin.com

18

Page 23: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 6. Sumario

UML 1.1 es un buen comienzo - ofrece a los arquitectos de sistemas una notación estándar para modelarsistemas. Ahora, igual que los arquitectos leen los planos, un modelador de objetos puede cogercualquier diseño y entender qué se está capturando. UML también es bueno para la comunidad delmodelado - en vez de gastar tiempo acordando cómo expresar la información que se captura, losmodeladores puden resolver el problema a mano, lo cual es diseñar el sistema.

Sin embargo, aunque UML se presta a una aproximación a los Casos de Uso guiados, UML no respondea la pregunta de cómo construir un sistema. Esta elección de qué metodología, o proceso usar tdoavíaqueda abierta para que el modelador lo decida o dé con él.

Desde un punto de vista notacional, UML 1.1 no es todavía la solución completa; pero se espera queUML continúe evolucionando con el tiempo. Mientras tanto, los modeladores usarán UML cono unabase, extendiéndolo mediante una combinación de otras técnicas, como los análisis guiados por laresponsabilidad y el modelado relacional de datos, para modelar el mundo real.

19

Page 24: Modelado de Sistemas com UML - moodle2.unid.edu.mxmoodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/sistemas_uml…Un Caso de Uso para cada escenario ... Analiza los diagramas que

Capítulo 7. Referencias

• Entendiendo UML: La guía del desarrollador, con una aplicación java basada en web, por PaulHarmon 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, SIGSPublications (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 yAlan C. Wills, Addison Wesley Longman, 1998.

20