UML v1

Análisis y Diseño de
Sistemas Orientado a
Objetos
Versión 5.1
Libro 1
Análisis y Diseño de
Sistemas Orientado a
Objetos
Código de Curso: CY450
Versión 5.1
Guía del Estudiante
Libro 1: Análisis y
Diseño de Sistemas
Orientado a Objetos
IBM IT Education Services
Worldwide Certified Material
Información de la Publicación
Esta publicación ha sido producida usando Microsoft Word 2000 y Microsoft PowerPoint
2000 para Windows.
Marcas Registradas
IBM ® es una marca registrada por International Business Machines Corporation.
Otras compañías, productos, y nombre de servicios pueden ser marcas registradas o
marcas de servicios de otros.
Marcas Registradas de otras compañías según se muestra
Windows
Microsoft Corporation
Red Hat Linux
Red Hat
Edición Diciembre 2007
La información contenida en este documento no ha sido sometida a ninguna prueba
formal de IBM y está distribuida en base a “como está” sin ninguna garantía expresa o
implícita. El uso de esta información o la implementación de cualquiera de estas
técnicas es responsabilidad del cliente y depende de la habilidad del cliente evaluar e
integrarlas dentro del entorno operacional del cliente. Aun cuando cada punto puede
haber sido revisado por IBM en su exactitud y para una situación específica, no hay
garantía de que los mismos resultados o similares, funcionarán en otra parte. Los
clientes que intenten adaptar estas técnicas a sus propios entornos, lo hacen bajo su
propio riesgo.
Copyright International Business Machines Corporation, 2007. Todos los
derechos reservados.
Este documento no puede ser reproducido total o parcialmente sin previo permiso
escrito de IBM.
.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Contenido
Descripción del Curso........................................................................................1
Descripción de Unidades ...................................................................................3
Volumen 1: Modelado Básico ............................................................................6
Unidad 1: Introducción a UML ...........................................................................7
1. La Necesidad del Análisis y Diseño Orientado a Objetos (OOAD)
8
2. Fundamentos de la Orientación a Objetos
12
3. Importancia del Modelado
19
4. UML
19
5. El Modelo UML
19
Resumen
19
Unidad 1: Examen de Autoevaluación
19
Respuestas a la Unidad 1: Examen de Autoevaluación
19
Unidad 2: Modelado del Comportamiento con Casos de Uso ......................19
1. Introducción
19
2. Importancia de los Casos de Uso
19
3. Casos de Uso
19
4. Análisis de un Caso de Uso
19
5. Diagrama de Caso de Uso
19
6. Diagramas de Actividad
19
7. Caso de Estudio
19
Resumen
19
Unidad 2: Examen de Autoevaluación
19
Respuestas de la Unidad 2: Examen de Autoevaluación
19
Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso.........19
1. Ejercicio de Laboratorio
19
Unidad 4: Modelado Estructural Básico .........................................................19
1. Modelado Estructural
19
2. Diagramas de Clase
19
3. Relaciones entre Clases
19
4. Mecanismos Comunes
19
5. Caso de Estudio
19
Resumen
19
i
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Unidad 4: Examen de Autoevaluación
19
Respuestas de la Unidad 4: Examen de Autoevaluación
19
Volumen 2: Modelado Avanzado .....................................................................19
Unidad 1: Modelado Estructural Avanzado ....................................................19
1. Introducción
19
2. Clasificadores
19
3. Elementos Abstractos
19
4. Multiplicidad
19
5. Clases Plantillas (Template)
19
6. Estereotipos para Clases
19
7. Relaciones
19
8. Interfaces y Realización
19
9. Roles
19
10. Paquetes
19
11. Instancias
19
12. Diagramas de Objetos
19
13. Caso de Estudio
19
14. Algunas Recomendaciones
19
Resumen
19
Unidad 1: Examen de Autoevaluación
19
Respuestas de la Unidad 1: Examen de Autoevaluación
19
Unidad 2: Laboratorio de Modelado Estructural Avanzado ..........................19
Ejercicio de Laboratorio
19
Unidad 3: Modelado de interacción.................................................................19
1. Introducción
19
2. Interacción
19
3. Colaboración
19
4. Diagramas de Interacción
19
5. Manejar Tiempo y Espacio
19
6. Cómo Crear un Diagrama de Colaboración
19
Resumen
19
Unidad 3: Examen de Autoevaluación
19
Respuestas a Unidad 3: Examen de Autoevaluación
19
Unidad 4: Lab. de Modelado de Interacción ...................................................19
ii
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Ejercicio de Laboratorio
19
Unidad 5: Modelado de Comportamiento Avanzado .....................................19
1. Introducción
19
2. Máquinas de Estado
19
3. Eventos
19
4. Subestado
19
5. Diagramas de Estado
19
6. Clases Activas
19
7. Caso de Estudio: Trabajar con Diagramas de Estado
19
8. Algunas Recomendaciones
19
Resumen
19
Unidad 5: Examen de Autoevaluación
19
Respuestas a la Unidad 2: Examen de Autoevaluación
19
Unidad 6: Modelado Arquitectónico................................................................19
1. Introducción
19
2. Componentes
19
3. Diagrama de Componentes
19
4. Colaboraciones
19
5. Patrones
19
6. Diagrama de Despliegue
19
7. Caso de estudio Componentes y Despliegue
19
Resumen
19
Unidad 6: Examen de Autoevaluación
19
Respuestas a Unidad 4: Examen de Autoevaluación
19
iii
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Descripción del Curso
Nombre del Curso
Análisis y Diseño de Sistemas Orientado a Objetos.
Duración
La duración de este curso es de 40 horas académicas.
Propósito
El propósito de este curso es obtener conocimientos y destrezas en el manejo de los
Principios de la Orientación a Objeto y en el Lenguaje Unificado de Modelado UML
(Unified Modeling Language), considerado como un estándar de la industria del
software para apoyar el análisis y diseño de sistemas orientados a objetos (OOAD). El
uso del Lenguaje Unificado de Modelado UML permite al desarrollador de sistemas
especificar, visualizar, construir y documentar los artefactos de sistemas de software
orientados a objetos, utilizando un formato visual de modelado con sus tres elementos
importantes a saber: los bloques de construcción (que incluyen mas de nueve
diagramas), las reglas que ayudan a juntar esos bloques de construcción y algunos
mecanismos de extensión.
Audiencia
Estudiantes, profesionales y desarrolladores que desean conocer acerca de Análisis y
Diseño de Sistemas Orientado a Objetos.
Prerrequisitos
•
Introducción a las computadoras personales y a Windows XP.
•
Fundamentos a la programación Orientada a Objetos.
Objetivos del Curso
Al final de este curso Ud. será capaz de:
•
Describir la necesidad del estudio del Análisis y Diseño Orientado a Objetos.
•
Conocer los conceptos básicos del paradigma orientado a objetos.
•
Describir la importancia del modelado UML.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Descripción del Curso 1
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
•
Describir el uso y funcionamiento de los diagramas UML en el aspecto
estructural.
•
Describir el uso y funcionamiento de los diagramas UML en el aspecto de
comportamiento.
•
Conocer las diferencias entre la especificación UML 1.x y la especificación UML
2.0.
•
Describir el uso y funcionamiento de los diagramas de la especificación UML 2.0
en el aspecto estructural y de comportamiento.
•
Aprender a manejar herramientas de modelado.
Agenda
Cada unidad del curso tiene una duración de 2 a 3 horas académicas.
Unidad 1:Programación en C – Los Primeros Pasos
Volumen 1: Fundamentos de C
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos en parte
o en su totalidad sin el previo permiso escrito de IBM.
2
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Descripción de Unidades
Volumen 1: Modelado Básico
Unidad 1: Introducción a UML
Esta unidad comienza dando la motivación para el estudio del Análisis y el Diseño
Orientado a Objetos. Ayuda a entender los diversos principios de orientado a objetos y
proporciona una introducción al Lenguaje Unificado de Modelado (UML).
Unidad 2: Modelado del Comportamiento con Casos de Uso
Esta unidad da inicio al Lenguaje de Modelado Unificado (UML), comenzando con el
Diagrama de Casos de Uso, el cual es el diagrama que permite modelar un sistema de
la forma como lo entendería el usuario. Este tipo de diagramas es muy usado en el
transcurso del levantamiento de información, debido a que el usuario puede tener una
mejor visión del sistema sin entrar en profundidad de programación.
Unidad 3: Laboratorio de Modelado del Comportamiento con Casos de
Uso
Esta unidad pretende poner en práctica los conocimientos adquiridos en la unidad
anterior, utilizando un ejercicio práctico de laboratorio.
Unidad 4: Modelado Estructural Básico
En esta unidad se discute uno de los diagramas más importantes de UML como lo es el
Diagrama de Clases. Conceptos como Clases, Objetos, herencia, polimorfismo,
relaciones entre clases y objetos, estereotipos, entre otros, que permiten mostrar una
cara estática del sistema.
Volumen 2: Modelado Avanzado
Unidad 1: Modelado Estructural Avanzado
Esta unidad se refiere a los diferentes tipos de clasificadores, además de proporcionar
mayor información sobre interfaces, tipos y paquetes. Discute diagramas e instancias de
objetos. Ayuda al estudiante a aprender cómo construir diagramas de objetos.
Unidad 2: Laboratorio de Modelado Estructural
Esta unidad de Laboratorio se construye sobre la base de las unidades anteriores en el
modelado estructural y ayuda a aprender a crear clases abstractas a partir de un
documento de requerimientos dado. Proporciona una forma de desarrollar la habilidad
de derivar diagramas de clase y diagramas de objetos en diferentes escenarios.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Descripción de Unidades 3
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Unidad 3: Modelado de Interacción
Esta unidad proporciona detalles de dos de los diagramas más importantes para
modelar la dinámica de un sistema, estos diagramas son: Diagramas de secuencia y
diagramas de colaboración. Los diagramas de interacción describen el modo en que los
grupos de objetos colaboran para realizar un trabajo y la subclasificación (Diagramas de
secuencia y colaboración) permite ver esa colaboración de dos maneras distintas pero
compatibles.
Unidad 4: Laboratorio de Modelado de Interacción
Esta unidad de Laboratorio se construye sobre la base de la unidad anterior en el
modelado de interacción y ayuda a aprender a crear Diagramas de secuencia y
colaboración a partir de un documento de requerimientos dado.
Unidad 5: Modelado de Comportamiento Avanzado
Esta unidad proporciona detalles de algunos de los aspectos avanzados de modelado
de comportamiento. Discute los eventos y señales, máquinas de estado y métodos de
construcción de diagramas de mapa de estado con cierto detalle. Una enumeración
breve de las diferencias y similitudes entre procesos e hilos se proporciona como una
base conceptual.
Unidad 6: Modelado Arquitectónico
Con la complejidad creciente de sistemas de software, la importancia del modelado
arquitectural está siendo enfatizada tanto en la industria y como en el entorno
académico. Esta unidad enfatiza los componentes, el despliegue y las colaboraciones.
Proporciona detalles de diagramas de componente y diagramas de despliegue.
Volumen 3: Introducción a UML 2.0 y a Herramientas de Modelado
Unidad 1: Introducción a UML 2.0 (Diagramas Estructurales)
Esta unidad proporciona una introducción a la nueva versión de UML llamada UML 2.0.
Explica los cambios más relevantes entre esta nueva versión y las versiones anteriores
de UML. También, se enumeran las diferencias entre los diagramas estructurales del las
versiones 1.X y la versión 2.0. Se explican de forma básica los nuevos diagramas de la
nueva especificación.
Unidad 2: Introducción a UML 2.0 (Diagramas de Comportamiento)
En esta unidad se explican de manera básica los diagramas de comportamiento de la
nueva versión de UML, tales como: Diagramas de Casos de Uso, Diagramas de
Actividad, Diagramas de interacción, Diagramas de Máquinas de Estado, así como
también se detallan los nuevos diagramas incluidos en la versión 2.0 de UML.
Unidad 1:Programación en C – Los Primeros Pasos
Volumen 1: Fundamentos de C
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos en parte
o en su totalidad sin el previo permiso escrito de IBM.
4
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Apéndice A: Manejo de la Herramienta EclipseUML Free Edition
Esta unidad proporciona una introducción a la herramienta EclipseUML Free Edition, el
cual es un plugin para ser instalado en la Plataforma Eclipse. Aquí se explica cómo
crear nuevo proyecto en eclipse, como crear paquetes, instalación en windows y linux,
como crear un diagrama UML y la barra de herramientas de cada tipo de diagrama,
proporcionándole al estudiante las prácticas necesarias para el manejo de herramientas
de modelado.
Apéndice B: Manejo de la Herramienta Rational Software Modeler
Esta unidad proporciona una introducción a la herramienta Rational Software Modeler,
la cual es la herramienta por excelencia de IBM para modelado con UML. Aquí, se
explican cómo crear diagramas, exportar a imagen, crear proyectos, ingeniería hacia
delante y reversa, entre otras características, proporcionado al estudiante prácticas para
realizar modelos UML en esta herramienta.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Descripción de Unidades 5
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Volumen 1: Modelado Básico
Unidad 1:Programación en C – Los Primeros Pasos
Volumen 1: Fundamentos de C
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos en parte
o en su totalidad sin el previo permiso escrito de IBM.
6
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML
Objetivos de Aprendizaje
Al final de esta unidad, usted será capaz de:
•
Describir la necesidad del Análisis y Diseño Orientado a Objetos (Object
Oriented Analysis and Design - OOAD).
•
Explicar los principios de la orientación a objetos.
•
Describir el trabajo del Lenguaje Unificado de Modelado (Unified Modeling
Language - UML).
•
Describir la importancia del modelado en UML.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 7
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. La Necesidad del Análisis y Diseño Orientado a
Objetos (OOAD)
El desarrollo de aplicaciones de software es fundamentalmente un proceso complejo,
por lo que, entender, diseñar, desarrollar y desplegar grandes sistemas de software son
los retos que enfrenta la industria de software en la actualidad. El proceso del ciclo de
vida involucra las siguientes etapas:
•
Entender los requerimientos.
•
Analizar los requerimientos.
•
Diseñar el sistema de software.
•
Implementar el sistema de software.
•
Probar el sistema de software.
•
Realizar mantenimiento del sistema de software.
Al completar cada una de las etapas, se crean uno o más documentos (reportes o
código). Estos documentos son llamados productos de trabajo y permiten comprender el
sistema en cada etapa.
Después de la primera etapa, de entender los requerimientos, se crea un producto de
trabajo llamado entendimiento preliminar de requerimientos. Muchos analistas no ven
esta etapa de modo diferente a la segunda etapa de análisis de los requerimientos y las
fusionan en una. Sin embargo, el entender los requerimientos juega un rol importante en
el desarrollo de software de hoy día debido a que los dominios de aplicaciones de
software son cada vez más variados y complejos. La etapa de analizar los
requerimientos da origen a un producto de trabajo llamado especificación de
requerimientos de software.
El producto de trabajo de la tercera etapa, correspondiente a diseñar el sistema, es el
documento de diseño. En la etapa de implementación, el sistema resulta en la creación
de manuales de diversos tipos, tales como: el manual de usuario, manual administrativo
y otros. En algunos casos, cualquier tipo de código que se use en la parte inicial de la
implementación es también documentado.
La fase de prueba crea productos de trabajo en las siguientes áreas:
•
Metodologías de prueba.
•
Planes y casos de pruebas utilizados.
•
Resultados obtenidos de la prueba del sistema.
Aunque cada etapa resulta en un producto de trabajo útil, se está conciente de los
diferentes problemas que los analistas y desarrolladores de software deben confrontar.
Los requerimientos son poco claros y volátiles por naturaleza. Un requerimiento
ignorado o dejado de lado tiene un efecto cascada en todo el proceso de desarrollo del
sistema. Entender un sistema grande y complejo es en sí una tarea difícil. El análisis y
diseño de sistemas complejos es un proceso difícil que demanda tiempo. Las
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 8
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
metodologías de análisis y diseño estructurado usadas anteriormente, intentaron
proporcionar soluciones y eran exitosas en muchas situaciones. Sin embargo, el mundo
real es complejo, y con el creciente uso de computadoras en todos los aspectos de la
vida, el manejo de aplicaciones complejas del mundo real es cada vez más desafiante.
OOAD tiene la capacidad inherente para ocuparse de los diferentes aspectos de
sistemas de software complejos. Mientras la metodología de análisis y diseño
estructurado construye un sistema usando funciones, la orientación a objetos construye
sistemas usando objetos. Estos objetos tienen una correspondencia directa con los
objetos del mundo real. Las entidades del mundo real son simples de entender. Por lo
tanto, no es una tarea muy difícil transferir conocimiento del mundo real al dominio del
software, usando la orientación a objetos.
Para mostrar la importancia de OOAD, se muestra una narración de la construcción del
buque de guerra Vasa, más conocida como la Tragedia de Vasa.
El Rey Gustav de Suecia, quien obtuvo grandes victorias en las Guerras Bálticas,
anhelaba poseer el mejor buque insignia en toda Europa. Él quería un barco que fuese
el orgullo de la Marina Sueca. El Rey designó a Hendrick Hybertzoon, un experto
constructor de barcos de Holanda, para que construyera el buque insignia, y le dio
instrucciones preliminares. Pronto, Hybertzoon pudo construir un modelo a escala del
buque insignia propuesto. El Rey Gustav estaba feliz con el prototipo y ordenó a
Hybertzoon para que procediera con la construcción del verdadero barco. Un bosque
entero de robles fue dado al experto constructor de barcos para obtener madera para
este prestigioso proyecto.
Ni el Rey Gustav ni sus consejeros, incluyendo el Almirante de la Marina Sueca,
proporcionaron a Hybertzoon alguna especificación escrita. Hybertzoon decidió que el
barco debía tener una longitud de 108 pies y ordenó que se cortara la madera del
bosque de robles de acuerdo a eso. La construcción estaba progresando hasta que un
día el Rey vino a inspeccionar. Él consideró que la longitud del barco debía
incrementarse en otros 35 pies. Después de todo, iba a ser el orgullo de la Marina
Sueca, pero Hybertzoon ya había cortado la madera y había terminado de construir la
quilla del barco. La quilla debía ser extendida con una longitud adicional de madera de
modo que la longitud pudiera incrementarse a 120 pies.
El Rey Gustav se enteró durante sus vacaciones de verano que el Rey de Dinamarca
también estaba construyendo un buque insignia. También se enteró que el barco Danés
iba a tener tres cubiertas de cañones mientras que su barco ¡tenía sólo dos! El ego del
Rey Gustav no pudo soportar esto. Él ordenó que se instalara en su buque insignia otra
cubierta de cañones con 50 cañones de bronce (cada uno pesando más de una
tonelada). También ordenó que su barco fuera completado antes de la fecha estimada
original. El dinero no iba a ser un obstáculo para este proyecto. Hybertzoon no era
capaz de convencer al Rey de que no era posible hacer cambios estructurales
importantes después de que la quilla había sido colocada y se había hecho el
entarimado. Hybertzoon aceptó las demandas imposibles del Rey, pero murió antes de
completar la tarea, quizás debido al stress. La tarea de completar el proyecto fue dada a
su hermano, Arent Hybertzoon de Groote, a pesar de su relativa inexperiencia.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 9
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
A principio del Siglo 17, los constructores de barcos estaban aún por empezar a utilizar
métodos analíticos para construir barcos. Ellos solamente hacían suposiciones bien
fundamentadas acerca de las especificaciones del barco y aprendían a través del
proceso de ensayo y error. Las especificaciones eran secretos celosamente guardados
y no estaban sujetas a revisiones abiertas. El peso de las armas (unas 50 toneladas
extra) no figuró en los cálculos para el buque insignia Sueco. Tampoco otros ítems
como un horno de cocina que se añadiría al peso total. El constructor del barco creyó
que el entarimado adicional en los lados y un lastre adicional de 130 toneladas se
encargarían del asunto. El entarimado fue completado, pero el constructor del barco se
dio cuenta entonces que no había espacio bajo la cubierta para otras 130 toneladas de
roca para proporcionar lastre. Este aspecto fue ignorado completamente.
Después de que el buque insignia real estuvo al fin listo, la Marina Sueca probó el barco
haciendo que 30 marinos corrieran a lo largo del barco. El barco casi se inclinó hacia un
lado en una ocasión, pero nadie supo cómo resolver el problema de estabilidad. El
barco fue declarado probado y listo para zarpar, dado que el tiempo estipulado y la
paciencia del Rey se estaban agotando. El barco fue bautizado como Vasa y fue
lanzado del puerto de Estocolmo en Agosto de 1628. Difícilmente, el barco había
navegado apenas unos cuantos kilómetros cuando una pequeña ráfaga de viento
sacudió la vela mayor. El orgullo de la Marina Sueca se volcó y se hundió
inmediatamente.
Se pueden aprender algunas lecciones de la tragedia de Vasa. Éstas son:
•
La construcción de barcos era un trabajo artesanal. Se practicaba con poco
énfasis en algún método científico o de ingeniería.
•
El Rey no dio especificaciones por escrito. Todos los requerimientos del barco
fueron recogidos verbalmente.
•
No se aplicaron métodos de diseño. La tarea de construir un buque de guerra
estaba basada en unos cuantos bosquejos y modelos.
•
Los resultados o consecuencias de cambiar los requerimientos en las diferentes
etapas de la construcción del barco no se conocían.
•
La prueba no se condujo científicamente y cualquier indicación de algún
problema no fue tomada en cuenta.
•
Todos los pedidos y demandas del cliente fueron aceptados sin analizar si era
posible incorporarlos.
Cada punto mencionado anteriormente tiene relación con lo que sucede típicamente en
un esfuerzo de desarrollo de software. La construcción de barcos era una tarea grande
y compleja. Los sistemas complejos del mundo real requieren además que el desarrollo
de sistemas sea dirigido de la manera correcta. Con la llegada del análisis y diseño
estructurado de sistemas de software, se proporcionó un enfoque de ingeniería para el
desarrollo de sistemas de software. Para la mayoría de los puntos cubiertos
anteriormente, la metodología de análisis y diseño estructurado se ocupó de ellos. Sin
embargo, la metodología no proporcionó una solución para hacer corresponder
directamente los objetos del mundo real en el dominio de software. La orientación a
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 10
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
objetos ofrece una solución que ayuda a los desarrolladores a hacer corresponder el
mundo real tan cerca como sea posible al dominio de la solución. Existen muchas
metodologías que permiten soluciones para problemas complejos. A continuación, se
discutirán brevemente las diversas metodologías disponibles y luego se estudiará en
detalle la orientación a objetos.
•
Orientada a Aspectos: La Programación Orientada a Aspectos (POA) permite a
los desarrolladores escribir, ver y editar un aspecto diseminado por todo el
sistema como una entidad por separado, de una manera inteligente, eficiente e
intuitiva. Un aspecto se define como una propiedad que afecta el rendimiento
(performance) o la semántica de los componentes en forma sistemática
(Ejemplo: sincronización, manejo de memoria, distribución, etc.). La POA es una
nueva metodología de programación que implica separar la funcionalidad básica
de los aspectos y los aspectos entre sí. Esta separación se realiza a través de
mecanismos que permitan la abstracción y la composición de los mismos, a fin
de poder implementar todos los requerimientos del sistema.
•
Literal: Esta metodología combina un lenguaje de programación y uno de
documentación. Donald Knuth es el inventor de la programación literal. El
propósito de esta metodología es mejorar la capacidad para la documentación
del lenguaje de programación nativo. Un programa es tratado típicamente como
una “pieza de literatura”. También puede verse en el modo hipertexto.
•
Estructurada: Esta metodología es la más usada y la mayoría está familiarizada
con ella. Lenguajes como BASIC, Pascal, COBOL y C son algunos de los
ejemplos que pueden ser usados para programar usando esta metodología. La
programación estructurada permite organizar programas en una jerarquía de
módulos. Cada módulo tiene un solo punto de entrada y, a menudo, un solo
punto de salida.
•
Orientada a Objetos: Esta metodología se basa en modelar el mundo real y ha
ganado importancia significativa en los últimos tiempos. En la orientación a
objetos se trabaja con objetos en el sistema que interactúan unos con otros a
través de mensajes. La orientación a objetos proporciona los recursos para
ocuparse de los objetos de un sistema complejo. El análisis y diseño de un
sistema desde una perspectiva orientada a objetos forma el núcleo de este
curso. Se aprenderá todo acerca de la orientación a objetos a medida que se
avance en el curso.
•
Patrones: De acuerdo con Dirk Riehle y Heinz Zullighoven, “un patrón es la
abstracción de una forma concreta, la cual reaparece frecuentemente en
contextos específicos no arbitrarios”. Dr. Christopher Alexander, un arquitecto,
concibió el concepto de patrones en el planeamiento urbano y arquitectura de
construcciones. La aplicación de patrones para el desarrollo de software está
inspirada por su trabajo. Simplemente los patrones son soluciones probadas
para problemas frecuentes dentro de un cierto contexto. De acuerdo con
Alexander, “cada patrón es una regla de tres partes, la cual expresa una relación
entre un cierto contexto, un problema y una solución”.
Cualquiera de las metodologías mencionadas anteriormente para desarrollar un
sistema, seguirá el proceso del ciclo de vida de desarrollo de software.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 11
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Indiferentemente de la metodología subyacente, el entender los requerimientos,
analizarlos, diseñar el sistema, implementarlo y probarlo son etapas esenciales de un
proceso de construcción de sistema. Por lo tanto, cada metodología requerirá un
traductor de requerimientos, un analista de requerimientos, un analista de sistemas, un
diseñador de sistemas, un programador y un probador, para llevar a cabo las diferentes
etapas del proceso de construcción de sistemas.
2. Fundamentos de la Orientación a Objetos
Antes de continuar y aprender acerca del Lenguaje de Modelado Unificado (UML), se
discutirán brevemente los principios de la orientación a objetos.
2.1 Modelado del Mundo Real
El creciente poder de la computación y la tecnología ha dado lugar a muchos esfuerzos
de desarrollo de sistemas grandes y complejos. El modelado del mundo real forma la
base para la orientación a objetos y ayuda a los analistas de sistemas a entender mejor
el sistema.
A continuación se presentan los requerimientos recopilados para automatizar el pago de
cuentas a través de la Internet.
Se requiere que el cliente llene un formulario de aplicación para permitir el pago de
cuentas a través de los servicios ofrecidos por BillPaymentJunction, Inc.
En el paradigma de análisis y diseño estructurado, el escenario anterior se pensaría de
forma lógica en términos de las funciones llenarFormularioAplicación() y pagarFactura().
El paradigma de análisis y diseño estructurado no está basado en modelar el mundo
real. En la orientación a objetos, se intentará modelar el mundo real y los objetos del
mundo real. Se aprecia que el mundo real tiene clientes, formularios de aplicación,
facturas, pagos de cuentas y servicios. Entre éstos, se pueden clasificar algunos de
ellos como acciones (pagos de cuentas y servicios) y otros como entidades (clientes,
formularios de aplicación, facturas). Primero se modelan estas entidades del mundo real
y luego se asocian las acciones identificadas como las funciones o responsabilidades
de estas entidades.
2.2 Tipos de Dato Abstracto
En la orientación a objetos, el modelado de la vida real resulta en tipos de dato
abstracto. Un tipo de dato abstracto es un modelo matemático. Las operaciones son
definidas en el modelo para permitir la aplicación del tipo de dato en un entorno de
programación. Algunos se refieren a la programación orientada a objetos como
programación de los tipos de dato abstracto. Las entidades Cliente y Formulario
Aplicación del ejemplo presentado en la sección anterior son tipos de dato abstracto.
En la orientación a objetos, se trabaja principalmente con datos. Por tanto, las
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 12
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
operaciones son definidas sobre esos datos. Cada dato que se vuelve parte de un
sistema orientado a objetos es, en esencia, un tipo de dato abstracto.
2.3 Abstracción de Datos
La abstracción de datos es fundamental para el pensamiento orientado a objetos. La
abstracción permite a una persona concentrarse en los aspectos esenciales del
problema a la mano, mientras ignora detalles que tienden a distraer. El mundo real es
complejo y presenta demasiados elementos que deben manejarse simultáneamente. Se
necesita superar la complejidad para poder resolver los problemas. La abstracción es
una manera conveniente de manejar la complejidad. El Institute of Electrical and
Electronics Engineers’ Inc. - IEEE define la abstracción como “una visión del problema
que extrae la información esencial relevante a un propósito particular e ignora el resto
de la información“.
Dicho simplemente, la abstracción es eliminar lo innecesario. Por ejemplo, un libro en
una biblioteca puede ser visto de modo diferente que un libro en una editorial. En una
biblioteca, el libro puede verse que tiene un título, nombre de la editorial, fecha de
publicación, número de edición, precio y autor. El mismo libro, desde el punto de vista
de la editorial, puede verse que tiene un título, número de páginas, área impresa del
libro y muchas otras cosas relacionadas a la publicación del libro. De modo similar, en
una aplicación, la abstracción de una entidad se basa en su necesidad y relevancia en
la aplicación.
2.4 Encapsulamiento
La esencia del encapsulamiento recae en que cuando un objeto trae consigo su
funcionalidad, esta última se oculta. Con el encapsulamiento de los datos se consigue
que las personas que utilicen un objeto sólo tengan que comprender su interfaz,
olvidándose de cómo está implementada, y en definitiva, reduciendo la complejidad de
utilización.
La utilidad del encapsulamiento se ve en la reducción de la complejidad, esto es debido
a que las Clases se comportan como cajas negras donde sólo se conoce el
comportamiento pero no los detalles internos, y esto es conveniente porque solo
interesa conocer qué hace la Clase, pero no como lo hace.
Tomemos un ejemplo de un telecajero, se puede ir a un telecajero a retirar dinero,
consultar saldo y realizar transferencias. Estas son funcionalidades que se les
proporcionan a los usuarios, pero no es posible conocer como estas funcionalidades
están implementadas y los usuarios no están preocupados por conocerlas.
En la orientación a objetos, el encapsulamiento ayuda a mantener juntos los elementos
de datos, así como las funciones y procedimientos que operan sobre ellos.
En el paradigma procedimental, los datos y operaciones se mantienen separados, tal
como se muestra en la Figura 1.1.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 13
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
DATOS /
CARACTERÍSTICAS
Guía del Estudiante
OPERACIONES
Figura 1.1: Datos y Operaciones en el Paradigma Procedimental
En el paradigma orientado a objetos, los datos y las operaciones están juntos dentro de
una cápsula, tal como se muestra en la Figura 1.2.
OPERACIONES
DATOS/CARACTERISTICAS
Figura 1.2: Datos y Operaciones en el Paradigma Orientado a Objetos
2.5 Ocultamiento de la Información
El encapsulamiento conlleva al ocultamiento de la información, esto es, tanto los datos
como la implementación de las operaciones de un objeto son ocultados al usuario. Por
lo general, la mayoría de las personas que ve televisión no sabe o no se preocupa de la
complejidad electrónica que hay detrás de la pantalla, ni de todas las operaciones que
tienen que ocurrir para mostrar una imagen en la pantalla. La televisión hace lo que
tiene que hacer sin mostrarnos el proceso necesario para ello, esto es, ocultamiento de
la información. Al tener encapsulado juntos los datos miembros y las diferentes
operaciones, el usuario debe saber cómo acceder a las operaciones para trabajar con
los datos.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 14
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
2.6 Clase
Las clases son tipos de datos definidos por el usuario. Las clases, en la tecnología
orientada a objetos, representan la mayor parte de las veces a las entidades del mundo
real, excepto para unos pocos conceptos abstractos. Dado el dominio de un problema,
el dominio de la solución en la tecnología orientada a objetos, contendrá clases que son
identificadas como entidades en el dominio del problema.
Se presenta el ejemplo de un sistema bancario para entender esto. Los bancos
permiten a los clientes operar con diferentes tipos de cuentas, como ahorro, corriente y
depósito de plazo fijo. Los clientes usan formularios de depósito para depositar dinero y
usan formularios de retiro para retirar dinero del banco. La transferencia de fondos de
una cuenta a otra, dentro del mismo banco se puede hacer usando un formulario
especialmente diseñado para este propósito. La perspectiva dada aquí es desde el
punto de vista del cliente del banco. Internamente, el banco tendrá muchos otros
formularios adicionales para acometer estas tareas. A partir de esta corta descripción,
se pueden representar algunas de las siguientes entidades del mundo real y sus
correspondencias a clases en el mundo orientado a objetos. Esto es ilustrado en la
Figura 1.3.
Mundo Real
Mundo Orientado a Objetos
Cliente
CuentaAhorros
Cliente del
Banco
Cuenta de
Ahorros
CuentaCorriente
PlanillaDepositos
Cuenta
Corriente
Depósitos
Figura 1.3: Correspondencia de Entidades del Mundo Real a Clases en el Escenario
Bancario
2.7 Objeto
En términos sencillos, un objeto es una instancia de una clase. Los objetos interactúan
con otros para proporcionar una solución a un problema. Se asumirá por ejemplo que se
tiene definida una clase Pila. Este tipo de dato definido por el usuario puede ser usado
sólo cuando se crean instancias del tipo de dato. Por lo tanto, se puede crear miPila,
tuPila y suPila como instancias de la clase Pila. Es el objeto quien ocupa
memoria en una computadora.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 15
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Un objeto promete cumplir el contrato prometido por su clase. Cada objeto puede
definirse en términos del comportamiento que muestra o se espera que muestre. Un
objeto carro se define por su comportamiento como, “moverse”, “acelerar”, “llevar
personas”, “detenerse” o “voltear”. Basado en su comportamiento, es fácil caracterizar
un carro como estar en movimiento o estático. El objeto carro puede poseer otras
propiedades físicas como modelo, año de fabricación, tamaño de tanque de
combustible, número de llantas, características de seguridad y número de registro.
Se puede decir que un objeto tiene lo siguiente:
•
Estado, en un instante dado en el tiempo:
El estado de un objeto son las propiedades y los valores que toman estas
propiedades en un instante en el tiempo. En un ejemplo de pila, el objeto
miPila de la clase Pila puede tener dos propiedades estáticas,
elemento_pila y tope_de_pila. Los valores que tienen son dinámicos por
naturaleza, dado que pueden cambiar con el paso del tiempo. Un objeto conoce
su estado en cualquier instante de tiempo. En la orientación a objetos, un objeto
conoce acerca de sí mismo y revela su estado a través de su interfaz.
•
Identidad, que es única entre objetos de la misma clase:
La identidad de un objeto se refiere a la manera única en que el objeto es
conocido, referido y distinguido de todos los objetos en el sistema. Los objetos
suPila y miPila se identifican como objetos diferentes en el sistema, dado
que poseen su espacio en memoria y un estado.
•
Comportamiento, que son usualmente los datos y funciones de dicha clase:
El comportamiento consiste de responsabilidades que promete llevar a cabo el
objeto. Es la manera en que un objeto reacciona a los mensajes que recibe (de
otros objetos). Las operaciones push (agregar) y pop (extraer) definidas en la
clase Pila son dos de los comportamientos presentados por la clase.
Una clase es un marco de trabajo (framework). Los objetos son manifestaciones
concretas de este marco de trabajo. Una definición de clase debe existir para que los
objetos sean creados y para interactuar unos con otros. Es a través de la interacción de
objetos que funciona el sistema completo orientado a objetos.
2.8 Interfaz e Implementación
Cuando la complejidad de una entidad en el mundo real llega a ser muy grande, se
precisa ocultar al usuario algunos de los detalles menos necesarios acerca de esa
entidad. Usualmente, cada entidad tiene dos aspectos:
•
Interfaz.
•
Implementación.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 16
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Una interfaz es la forma en la cual se presenta la clase al mundo real. Una
implementación es el método que se sigue para hacer que el objeto de la clase realice
sus responsabilidades.
Considere el siguiente ejemplo para entender la distinción entre interfaz e
implementación:
El aire acondicionado de un automóvil es una interfaz con métodos definidos como:
Distribuir el aire(), enfriar el aire(), entre otros, pero cada automóvil implementa estos
métodos según sus características, por ejemplo la distribución de aire de una camioneta
Pick-up no puede ser la misma que la de una camioneta VAN, ya que esta última
necesita más salidas de aire en su interior para que el enfriamiento sea uniforme.
En el ejemplo anterior, se ha visto de qué modo las actividades del mundo real se basan
en interfaces e implementaciones. La mayoría de las actividades que se realizan se
basan en el conocimiento del comportamiento proporcionado por la entidad en la que
uno se interesa. Como usuario de un servicio, uno está interesado en lo que la entidad
proporciona y no en cómo la entidad satisface el requerimiento. El “qué” describe la
interfaz de la entidad y el “cómo” proporciona la implementación de la entidad. Esta
distinción es crucial para el desarrollo orientado a objetos.
2.9 Métodos
En la mayoría de los lenguajes orientados a objetos, las operaciones que puede realizar
un cliente sobre un objeto se declaran como métodos. Los métodos son una parte de la
declaración de la clase. C++ usa el término función miembro y Java usa el término
métodos para denotar el mismo concepto. Se usarán estos términos de modo indistinto.
Los métodos son los algoritmos usados por la clase para implementar la tarea
prometida por la interfaz. Por lo tanto, en el ejemplo de la pila, la tarea o responsabilidad
de agregar un elemento a la pila (push) se denomina un método.
2.10
Mensajes
Los objetos se comunican unos con otros a través de mensajes. Un mensaje es un
pedido a un objeto para que realice una tarea a través de un método apropiado. Es el
mecanismo usado por un objeto para hacer que otro objeto lleve a cabo una tarea. El
objeto iniciador conoce la interfaz del objeto sobre el cual esta acción es iniciada. El
objeto receptor satisface el requerimiento del objeto iniciador aceptándolo e
implementando la tarea.
Un buen ejemplo de la vida real podría ser un televisor y su control remoto, cuando
usted desea ver un programa en especial, busca el control remoto y presiona el botón
de encendido. En ese momento el control remoto le envía literalmente al televisor un
mensaje para que se encienda. El televisor recibe el mensaje, lo identifica como una
petición y la realiza.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 17
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Un mensaje puede cambiar el estado del objeto receptor. Un mensaje puede tener cero
o más argumentos explícitos. En este contexto, el objeto receptor es un argumento
implícito que siempre está presente. El mensaje retorna un valor de cierto tipo,
posiblemente void, al emisor del mensaje. Típicamente, un mensaje contiene lo
siguiente:
•
El nombre del objeto que va a recibir el mensaje.
•
El nombre del mensaje.
•
Argumentos que son pasados al objeto receptor. Esto es opcional. También se
pueden pasar los mismos objetos como argumentos.
2.11
Herencia
Herencia, quiere decir que la clase X comparte la estructura y comportamiento de la
clase Y. En este contexto, la clase Y se denomina la superclase y la clase X se
denomina la subclase. A veces se referirá a la clase Y como el padre y la clase X como
su hija.
La Figura 1.4 describe la herencia entre las entidades Vehículo y Carro.
SuperClase
SubClase
Vehículo
Carro
Figura 1.4: Herencia entre Vehículo y Carro
La subclase no sólo necesita heredar la estructura y comportamiento tal como se
encuentran en la superclase. Puede, y a veces lo hace, redefinir el comportamiento
proporcionado por el padre. De modo alternativo, la subclase puede también aumentar
los servicios proporcionados por la superclase. La superclase se denomina también la
clase base, mientras que la subclase es también referida como la clase derivada.
Ahora, ¿Por qué una clase debe heredar la estructura y comportamiento de otra clase?
La superclase publica algunas características que son más generales por naturaleza.
Las subclases pueden especializarse en estas características al heredar la clase
original y redefinir aquellas características. Por lo tanto, la herencia se refiere a una
relación de generalización-especialización entre clases.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 18
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Por ejemplo, animal es una categoría general de donde se deriva un caballo. La idea es
modelar el hecho de que un caballo “es un” animal. De modo similar, el hecho de que
un águila sea un tipo de ave puede lograrse al heredar el águila de un ave. La idea es
muy simple. Piense en un águila. ¿Qué imagen se obtiene inmediatamente? Se obtiene
la imagen de una criatura que tiene alas y tiene la habilidad de volar. El hecho de que el
águila tenga alas y pueda volar es fundamental para cualquier ave. El comportamiento
general de “volar” está encapsulado en un ave lo cual es verdadero para cualquiera que
“es un” ave. De modo similar, la estructura de un ave, que tiene alas, también está
encapsulada en el ave. Ahora, corre por cuenta del águila especializarse bajo esta
estructura y comportamiento, dado que tiene su propia manera de volar o mantener sus
alas. Por lo tanto, se puede decir que un águila “es un” ave.
El mundo real también tiene algunas excepciones. Mientras casi todas las aves tienen la
habilidad de volar, algunas aves como el avestruz no pueden volar. La especialización
puede ocuparse también de tales excepciones.
La jerarquía de herencia especifica la relación “es un” entre la subclase y la superclase.
Es también posible que una subclase sea una superclase de otra clase. El ejemplo en la
Figura 1.5 resalta esto.
Persona
Estudiante
Estudiante
Graduado
Empleado
Estudiante de
Extensión
Profesor
Profesor
Contratado
Staff
Administrativo
Profesor
Temporal
Figura 1.5: Jerarquía de Herencia
La Figura 1.5 describe una jerarquía de herencia la cual establece que cada subclase
“es un” tipo de su superclase. Se presentan los siguientes ejemplos:
•
Empleado “es una” Persona.
•
Staff Administrativo “es un” Empleado.
Algunos ejemplos de una jerarquía “es un” se listan a continuación:
•
Búsqueda binaria “es un” tipo de algoritmo de búsqueda.
•
Estudiante “es una” persona.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 19
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
•
Rosa “es una” flor.
•
Animal “es un” ser vivo.
•
Humano “es un” mamífero.
•
Carro “es un” tipo de vehículo.
•
Pantalón “es un” tipo de prenda de vestir.
•
Lapicero “es un” tipo de instrumento de escritura.
Guía del Estudiante
Los objetos que son diseñados cuidadosamente para ser muy generales pueden ser
reutilizados en muchas circunstancias, ahorrando mucho esfuerzo en futuros problemas
de programación. La herencia que se ha visto hasta ahora es conocida como herencia
simple.
Es también posible para una subclase heredar de dos superclases. En esa situación, la
herencia se conoce como herencia múltiple. Los animales anfibios, como la rana y la
tortuga, son ejemplos de esto. Se muestra un ejemplo en la Figura 1.6.
Animal
Animal
Acuático
Animal
Terrestre
Animal
Anfibio
Figura 1.6: Herencia Múltiple
Sin embargo, la herencia múltiple puede crear problemas. Tanto “Animal Terrestre”
como “Animal Acuático”, por ejemplo, pueden definir un método llamado “método de
respiración”. Evidentemente, “Animal Terrestre” respira a través de la nariz, mientras
que “Animal Acuático” respira a través de agallas. Ahora, con herencia múltiple, ¿Cuál
de los “métodos de respiración” hereda “Animal de anfibio”?. Esto se conoce como el
“problema del diamante”. La jerarquía mostrada en la Figura 1.6 describe un problema
de diamante.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 20
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Cabe destacar que no todos los lenguajes de programación implementan la herencia
múltiple. C++ usa la palabra reservada virtual durante la herencia para indicar que sólo
una copia del método es derivada en la subclase. En el caso de Java no proporciona
dicha capacidad.
2.12
Agregación
Se estudió que la herencia proporciona una jerarquía de generalización-especialización.
Es también posible que una entidad contenga otra entidad. Asuma que se tienen cuatro
entidades, Carro, Puerta, Asiento y Capó. Se puede afirmar que la entidad “Carro”
contiene Puertas, Asientos y un Capó. Se está enfatizando la relación de contenedor
cuando se asevera de esta manera. Esto es conocido como una relación “tiene un”
entre entidades. Presentado de otra manera, se puede decir, “Un Carro tiene Puertas,
Asientos y un Capó”, tal como se muestra en la Figura 1.7.
Carro
Puerta
Asiento
Capó
Figura 1.7: Relación “Tiene un” (‘has a’)
La figura anterior describe la relación “tiene un” entre Carro y las otras entidades.
Denota que la entidad Carro tiene Puertas, Asientos y un Capó. La relación “tiene un” es
conocida también como la relación contenedora.
A veces, se tiende a confundir la relación contenedora entre dos entidades. Se
entenderá esto con un ejemplo. Considere las dos entidades, Persona y Bebida. En
español, se dice, “Persona tiene una Bebida”, pero esto no significa que la entidad
Persona contiene la entidad Bebida. Lo que se quiere decir con contenedora es que la
entidad contenida es parte de la entidad contenedora. Esa aseveración no es verdadera
con respecto a Persona y Bebida. Ellas existen separadamente y la entidad Persona
sólo es capaz de beber la Bebida, no de contener la entidad Bebida.
Es también incorrecto indicar, “Lapicero tiene un Color”. Color es un atributo de un
Lapicero, no una entidad. Las características de cualquier entidad serán indicadas en
español como “la entidad tiene características”. Por eso las propiedades no califican
para que se les llamen entidades. Las jerarquías “es un” y “tiene un” son sólo entre dos
entidades.
Algunos ejemplos de una relación “tiene un” se listan a continuación:
•
Libro “tiene” Párrafos.
•
Párrafo “tiene” Palabras.
•
Sistema de Computadora “tiene un” Teclado.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 21
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
•
Aves “tienen” Alas.
•
Edificio “tiene” Cuartos.
Guía del Estudiante
Entender la distinción entre la relación “es un” y “tiene un” es muy importante en el
desarrollo de sistemas orientados a objetos.
2.13
Polimorfismo
Polimorfismo significa la posibilidad de hacer que una operación exhiba diferente
comportamiento en instancias diferentes. El comportamiento depende de los tipos de
datos usados en diferentes operaciones. Por ejemplo, las fechas se pueden crear de
algunas de las siguientes maneras:
•
Usando tres enteros distintos, día, mes y año (15, 8, 1947).
•
Usando una cadena (“15/08/1947”), de donde se pueden extraer las tres partes.
•
Usando un entero largo (“19471508”), de donde se pueden extraer las tres
partes.
En los paradigmas de programación tradicional, se debe proporcionar diferentes
nombres para las tres funcionalidades. Se les puede llamar fechaEnteros,
fechaString y fechaLarga. Sin embargo, mediante el concepto de polimorfismo, se
puede proporcionar sólo un nombre fecha y proporcionar tres diferentes
funcionalidades. La correspondencia entre la llamada actual y la implementación de la
funcionalidad dependerá de los argumentos pasados con la llamada. Polimorfismo
significa “un nombre, múltiples funcionalidades”.
2.14
Tipo
Un tipo (type) es un estereotipo de una clase. Un estereotipo permite al diseñador crear
nuevos bloques de construcción extendiendo bloques existentes. Se usa el tipo para
especificar un dominio de objetos y sus operaciones. Las implementaciones de estas
operaciones no están incluidas en el tipo. Se usa el tipo cuando se desea modelar el
significado de una abstracción y la adherencia de la abstracción a una interfaz.
Típicamente los tipos se usan para representar estructuras de datos. Por ejemplo, una
entidad estudiante se puede diseñar con una interfaz, mientras que la estructura de
datos que representa los detalles de un estudiante, como la estructura de datos lista, se
puede diseñar como un tipo.
2.15
Rol
Cada entidad tiene un cierto comportamiento asociado a ella. Un rol describe el
comportamiento de una entidad. Por ejemplo, una persona puede jugar diferentes roles
como profesora, hermana, hija, madre o pintora. Cuando un objeto juega un rol,
presenta un determinado comportamiento al mundo exterior, dependiendo del rol que
juega el objeto en ese momento.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 22
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
2.16
Análisis y Diseño de Sistemas Orientado a Objetos
Paquete
Un paquete es un mecanismo para agrupar elementos. Normalmente, los elementos
cohesivos son organizados en un paquete. Los elementos que se hacen referencia aquí
son elementos de modelo de alto nivel, a saber, clases y sus relaciones. Esto es similar
al concepto de módulos, donde los elementos de la función son agrupados.
A continuación se discutirá la importancia del modelado.
3. Importancia del Modelado
Un modelo es una representación de la realidad. Grady Booch, James Rumbaugh e Ivar
Jacobson definen un modelo como una simplificación de la realidad. Un modelo
proporciona el diseño de un sistema. Usando un modelo, se puede hacer lo siguiente:
•
Visualizar un sistema.
•
Especificar la estructura y comportamiento de un sistema.
•
Crear plantillas para construir el sistema.
•
Documentar las decisiones hechas a lo largo del sistema.
Nota: No es suficiente un solo modelo para entender y representar un sistema.
Modelar sistemas de software es tan importante como modelar un edificio antes de su
construcción. Un lenguaje de modelado consiste típicamente de elementos del modelo,
notaciones y directivas. Para ocuparse de los sistemas complejos, es esencial la
visualización. La visualización del sistema se convierte a un formato entendible por los
desarrolladores usando una técnica de Modelado. UML es un lenguaje de modelado
visual que ayuda a construir sistemas grandes y complejos orientados a objetos y
basados en componentes.
A continuación se aprenderá acerca de UML.
4. UML
UML es un lenguaje usado para especificar, visualizar, construir y documentar las
diversas piezas de sistemas de software y también para modelado de negocios y otros
sistemas que no sean software. El uso de UML en el desarrollo de sistemas orientados
a objetos ganó importancia cuando los tres autores de esta metodología, Grady Booch,
James Rumbaugh e Ivar Jacobson, llegaron juntos a Rational Software Corporation.
Estos autores presentaron un lenguaje de modelado visual que puede considerarse
como un estándar para el desarrollo de sistemas Orientados a Objetos. UML fue
desarrollado en Rational Software Corporation, con contribuciones de otros
metodologístas, líderes, vendedores de software y muchos usuarios. Hoy día, UML es
considerado el estándar de la industria para el desarrollo de sistemas de software
orientados a objetos.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 23
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Antes de UML, existieron tres metodologías populares de desarrollo de sistemas
Orientados a Objetos, cada cual un invento de los tres autores anteriores. La
metodología de Grady Booch fue llamada Boochgrams. La técnica de James Rumbaugh
era conocida como Técnica de Modelado de Objetos (Object Modeling Technique OMT) y el método de Ivar Jacobson fue llamado Ingeniería de Software Orientado a
Objetos (Object-Oriented Software Engineering - OOSE).
UML proporciona un lenguaje de modelado de aplicaciones para lo siguiente:
•
Modelado de proceso de negocios con casos de uso.
•
Modelado de clases y objetos.
•
Modelado de componentes.
•
Modelado de distribución e implementación (deployment).
5. El Modelo UML
Para entender UML en su totalidad, se deben aprender tres importantes elementos. Son
estos:
•
Bloques de construcción de UML.
•
Reglas que ayuden a agrupar los bloques de construcción.
•
Mecanismos comunes aplicados en el proceso de uso del lenguaje de
modelado.
La estructura de los bloques de construcción de UML se describe en la Figura 1.8.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 24
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Figura 1.8: Estructura de Bloques de Construcción de UML
A continuación se discute cada elemento, relación y diagrama.
5.1 Bloques de Construcción
Los bloques de construcción de UML se clasifican en tres amplios conceptos:
•
Elementos del modelo.
•
Relaciones.
•
Diagramas.
5.2 Elementos del Modelo
Existen cuatro tipos de elementos del modelo.
•
Elementos Estructurales: Los elementos estructurales son entidades estáticas.
No revelan un comportamiento dinámico. Forman los nombres para el modelo
UML. Representan ya sea un elemento físico o uno conceptual. Existen siete
tipos de elementos de modelo estructural. Éstos son:
- Clase: Representa un dominio de objetos que comparten los mismos atributos,
operaciones y relaciones.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 25
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
- Interfaz: Es un conjunto de operaciones que revela los servicios ofrecidos por
una clase o componente.
- Caso de Uso: Es una descripción de un conjunto de acciones que realiza un
sistema con respecto a un actor particular interesado en el sistema. Un actor
es una entidad que interactúa con algún aspecto del sistema. Una definición
formal de caso de uso será proporcionada en el Volumen 2, Unidad 1 –
Modelado Básico del Comportamiento.
- Colaboración: Es la realización de un caso de uso.
- Clase Activa: Es una clase cuyos objetos pueden poseer uno o más procesos.
Tales objetos pueden iniciar una actividad de control.
- Componente: Es la parte reemplazable de un sistema. Tal reemplazo es
posible sólo si el componente se ajusta al contrato proporcionado por la
interfaz.
- Nodo: Es un recurso que puede ser computado y por lo tanto, existe en tiempo
de ejecución. Es un elemento estructural físico.
•
Elementos de Comportamiento: Los elementos que representan el modelo
dinámico se denominan elementos de comportamiento. Se tienen dos elementos
de comportamiento: Interacción y Máquina de Estado. Las interacciones son
mensajes que son pasados entre objetos para permitirles interactuar unos con
otros para acometer una tarea particular. Una máquina de estado describe los
diferentes estados que atraviesa un objeto en respuesta a eventos.
•
Elementos de Agrupación: Partes del modelo UML que representan aspectos
organizacionales son llamados elementos de agrupación. El paquete es el único
elemento de agrupación. Un paquete se usa para organizar elementos
cohesivos en grupos.
•
Elementos de Anotación: Estos elementos se usan para describir las partes de
UML. Se tiene un elemento de anotación llamado “nota”, que se usa para
documentar restricciones y comentarios asociados con los elementos.
5.3 Relaciones
UML proporciona cuatro tipos de relaciones:
•
Dependencia: Es una relación semántica entre dos elementos. Un cambio en
un elemento puede causar un cambio en el elemento dependiente.
•
Asociación: Es una relación estructural. Es el enlace entre dos o más objetos
en el sistema. Es a través de la asociación que los objetos interactúan unos con
otros para cumplir tareas específicas.
•
Generalización: Es la relación de generalización / especialización. El objeto
especializado, el hijo, hereda los atributos, operaciones, relaciones y semántica
de la clase generalizada, el padre.
•
Realización: Esta relación existe entre las interfaces y las clases o
componentes que realizan las interfaces. También existe entre casos de uso y
las colaboraciones que realizan los casos de uso. La relación de realización
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 26
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
describe la relación semántica. Se aprenderá posteriormente más acerca de la
relación de realización.
5.4 Diagramas
Un diagrama es una representación gráfica. Cada diagrama de UML proporciona una
vista diferente del sistema. UML proporciona nueve tipos de diagramas. Son estos:
•
Diagrama de Clases: Muestra un conjunto de clases, interfaces, colaboraciones
y sus relaciones.
•
Diagrama de Objetos: Muestra un conjunto de objetos y sus relaciones.
•
Diagrama de Casos de Uso: Muestra casos de uso, actores y sus relaciones.
Ésta es una perspectiva importante para entender un sistema.
•
Diagrama de Secuencias: Muestra el ordenamiento en el tiempo de los
mensajes. También muestra el enfoque de control de cada objeto que participa
en un escenario.
•
Diagrama de Colaboración: Muestra la organización estructural de objetos que
interactúan unos con otros.
•
Diagrama de Estados: Se usa para representar máquinas de estado. Consiste
de estados, transiciones, eventos y acciones.
•
Diagrama de Actividad: Muestra el flujo de una actividad a otra en el sistema.
Éste es un tipo único de diagrama de estados.
•
Diagrama de Componentes: Muestra la organización y dependencias entre un
conjunto de componentes en el sistema.
•
Diagrama de Distribución e Implementación (Deployment): Muestra los
nodos y los componentes que residen en ellos.
5.5 Reglas
Las reglas ayudan a los bloques de construcción de UML a especificar un modelo bien
formado. Un modelo está bien formado si es auto-consistente y sincroniza con todos los
otros modelos relacionados. UML incluye reglas semánticas para:
•
Nombre: Se usa para identificar elementos del modelo, relaciones y diagramas.
•
Visibilidad: Especifica la manera en que los nombres pueden ser vistos y
usados por los clasificadores.
•
Ámbito: Es el contexto en el cual los nombres residen.
•
Ejecución: Es la manera en que el modelo dinámico se simula.
•
Integridad: Específica cómo los elementos del modelo se relacionan unos con
otros.
5.6 Mecanismos Comunes
Los mecanismos se usan a lo largo de UML para simplificar el proceso de construcción
del modelo. Existen cuatro tipos de mecanismos, éstos son:
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 27
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
•
Especificación: Es el mecanismo que proporciona la descripción de la sintaxis y
semántica de los bloques de construcción de UML. La representación gráfica
simplemente proyecta partes relevantes del modelo en consideración, y por lo
tanto revela un aspecto específico del sistema.
•
Adornos: Los adornos son simples decoraciones que ayudan a entender el rol
del elemento del modelo en el sistema. Un elemento del modelo se representa
por un componente visual en UML, el cual es el símbolo básico para ese
elemento del modelo. Los adornos se usan para agregar más detalles al
elemento del modelo.
•
División Común: La construcción de sistemas orientados a objetos conlleva a
dividir el mundo real en diferentes segmentos. Una división se relaciona a:
- Clases e instancias de clases.
- Casos de uso e instancias de casos de uso.
- Componentes e instancias de componentes.
Otra división se relaciona a la separación entre interfaz e implementación. Las
implementaciones realizan el contrato especificado por la interfaz.
Otra división ocurre entre los casos de uso y colaboraciones, donde las
colaboraciones son realizaciones concretas de casos de uso.
•
Mecanismos de Extensibilidad: UML proporciona tres tipos de mecanismos
extensibles. Éstos son:
- Estereotipos.
- Valores etiquetados (Tagged values).
- Restricciones.
Un estereotipo permite al diseñador crear nuevos bloques de construcción extendiendo
bloques existentes. Los valores marcados se usan para crear información nueva en la
especificación de un elemento del modelo. Una restricción se usa para crear nuevas
reglas al extender aquellas existentes. Habiendo discutido brevemente el modelo UML,
se aprenderá acerca de los tres tipos de modelado que ofrece UML. Éstos son:
•
Modelado estructural.
•
Modelado de comportamiento.
•
Modelado arquitectónico.
En los siguientes volúmenes se estudiarán cada uno de ellos a profundidad.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 28
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Resumen
Ahora que ha completado esta unidad, usted debe ser capaz de:
•
Describir la necesidad del Análisis y Diseño Orientado a Objetos (Object
Oriented Analysis and Design - OOAD).
•
Explicar los principios de la orientación a objetos.
•
Describir el trabajo del Lenguaje Unificado de Modelado (Unified Modeling
Language - UML).
•
Describir la importancia del modelado en UML.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 29
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Unidad 1: Examen de Autoevaluación
1) ¿Cuál(es) fase(s) del esfuerzo de la construcción del barco (en la Tragedia de
Vasa) puede relacionarse al esfuerzo del desarrollo de software?
a) Requerimientos
b) Diseño
c) Prueba
d) Todas las anteriores
2) ¿Cuál de los siguientes conceptos se relaciona a “eliminar lo innecesario”?
a) Encapsulamiento
b) Ocultamiento de información
c) Abstracción
d) Ninguna de las anteriores
3) ¿Cuál de los siguientes no es un bloque de construcción de UML?
a) Elementos del modelo
b) Relaciones
c) Diagramas
d) Adornos
4) UML fue la primera metodología inventada para desarrollar sistemas orientados a
objetos
a) Verdadero
b) Falso
5) ¿Cuáles de las siguientes afirmaciones son correctas?
a) La esencia del encapsulamiento recae en que cuando un objeto trae consigo
su funcionalidad, esta última se oculta.
b) Los objetos interactúan con otros para proporcionar una solución a un
problema.
c) Una interfaz es el método que se sigue para hacer que el objeto de la clase
realice sus responsabilidades.
d) Las operaciones que puede realizar un cliente sobre un objeto se declaran
como atributos.
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 30
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
6) ¿Cuál de las siguientes relaciones enfatiza una relación de “uso” (“using”)?
a) Asociación
b) Agregación
c) Generalización
d) Dependencia
7) Animal mamífero, es una categoría general de donde se deriva un caballo. ¿Qué
tipo de relación existe entre animal y caballo?
a) Asociación
b) Agregación
c) Generalización
d) Dependencia
8) La relación “tiene un” es conocida también como la relación asociativa
a) Verdadero
b) Falso
9) Permite a una persona concentrarse en los aspectos esenciales del problema a la
mano, mientras ignora detalles que tienden a distraer
a) Encapsulamiento
b) Rol
c) Tipo
d) Abstracción
10) ¿Cuáles de las siguientes afirmaciones son correctas?
a) La jerarquía de herencia permite que la subclase herede los miembros de
datos y operaciones.
b) Polimorfismo significa la capacidad para hacer que una operación exhiba el
mismo comportamiento en diferentes instancias.
c) “El encapsulamiento es un mecanismo para agrupar los datos y los métodos
de las clases”.
d) Ninguna de las anteriores.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Introducción a UML 31
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Respuestas a la Unidad 1: Examen de Autoevaluación
1) d
2) c
3) d
4) b
5) a y b
6) d
7) c
8) b
9) d
10) a y c
Unidad 1: Introducción a UML
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos 32
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento
con Casos de Uso
Objetivos de Aprendizaje
Al final de esta unidad, usted será capaz de:
•
Definir la importancia de los casos de uso.
•
Definir cada uno de los elementos involucrados en un diagrama de casos de
uso.
•
Describir el análisis para un caso de uso.
•
Describir la importancia y los elementos de los diagramas de actividad.
•
Elaborar un diagrama de casos de uso.
•
Elaborar diagramas de actividad.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
33
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. Introducción
Cuando se comienza el desarrollo de un sistema es de crucial importancia comprender
el punto de vista del usuario. Comprender tal punto de vista es clave para generar
sistemas que sean tanto útiles como funcionales, es decir, que cumplan con los
requerimientos y sean sencillos de trabajar.
El modelado, desde el punto de vista del usuario, es llamado Casos de Uso. En esta
unidad se comprenderá todo lo relacionado con los casos de uso, su importancia y su
función, además de los diagramas de actividad que describen cada caso de uso del
sistema.
2. Importancia de los Casos de Uso
El caso de uso es una excelente herramienta para que los usuarios describan el sistema
desde sus propios puntos de vista.
La idea es involucrar a los usuarios en las etapas iniciales del análisis y diseño del
sistema. Esto aumentará las probabilidades de que el sistema sea de mayor provecho
para las personas que lo utilizan, en vez de ser un sistema computacional
incomprensible para los usuarios finales.
3. Casos de Uso
Un caso de uso es una interacción entre un usuario u otra entidad y el sistema que es
diseñado. Un caso de uso es una descripción de un conjunto de acciones que realiza un
sistema con respecto a un actor particular interesado en el sistema. Formulado por Ivar
Jacobson, los casos de uso se popularizaron en la mayoría de sistemas orientados a
objetos. El usuario o la entidad que tiene interés en el sistema que se está diseñando es
llamado actor. En otras palabras, un actor es una entidad que interactúa con el sistema.
Un caso de uso involucra interacciones entre diversos actores y el sistema. El actor
puede ser otro sistema o subsistema. El actor representa el rol que cumplen los
usuarios mientras interactúan con el sistema.
Los casos de uso son útiles por varias razones ya que ayudan a hacer lo siguiente:
•
Descubrir requerimientos.
•
Capturar la necesidad del usuario al enfocarse en la tarea que el usuario
necesita realizar con el sistema.
•
Formular planes de prueba del sistema.
•
Controlar el desarrollo iterativo.
A continuación se muestran algunos casos de uso típicos:
•
Generar número identificación.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
34
Guía del Estudiante
•
Imprimir reporte.
•
Ver estadísticas.
•
Asignar curso.
•
Crear documento.
•
Publicar libro.
Análisis y Diseño de Sistemas Orientado a Objetos
Se observa de lo anterior que todos los casos de uso son una combinación de un verbo
y un sustantivo. Al listar los casos de uso, se observa esencialmente el sistema desde el
punto de vista del actor. En consecuencia, cada caso de uso o conjunto de casos de
uso tiene sentido sólo en el contexto de un actor.
Para los casos de uso anteriores, se pueden identificar los siguientes actores:
•
Gerente de Registro.
•
Oficinista del Banco.
•
Responsable de actualizar Inventario.
•
Adjudicador de cursos.
•
Autor.
•
Editor libros.
Los actores no son las abstracciones del sistema. Ellos representan los usuarios
externos que pueden usar el sistema que se está diseñando.
Cada caso de uso tiene un nombre; puede ser un nombre simple o un nombre de ruta.
El nombre de ruta puede tener el nombre del paquete en donde se ubica el caso de uso.
En UML, un caso de uso se dibuja como una elipse con el nombre dentro de la elipse,
tal como se muestra en la Figura 2.1.
Nombre simple
Validar curso
Nombre de ruta
DetalladorCurso::
Validar curso
Figura 2.1: Casos de Uso: Usando Nombres Simples y Nombres de Ruta
Los actores que participan en el sistema pueden ser heredados de un actor existente.
Un ejemplo se muestra en la Figura 2.2.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
35
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 2.2: Ejemplo de Herencia en Actores
3.1 Colaboraciones
Un caso de uso captura el comportamiento deseado del sistema. Esto no especifica de
qué modo será llevado a cabo el comportamiento. Pero eventualmente, cada caso de
uso tiene que ser implementado, creando una sociedad de clases y otros elementos que
ayuden a implementar el comportamiento del caso de uso. Por ejemplo, la sociedad de
clases necesarias para implementar el caso de uso Asignar Curso consiste de
GerenteRegistro, Curso, Disciplina, Estudiante y Visualizador.
La colaboración se usa en UML para representar una sociedad de elementos, tanto
estáticos como dinámicos, que ayuden a implementar el comportamiento de un caso de
uso, esto es, un caso de uso es realizado por una colaboración.
La colaboración de un caso de uso se representa como una elipse punteada, y la
realización del caso de uso se describe como una línea punteada con la flecha
apuntando hacia el caso de uso que realiza, tal como se ilustra en la Figura 2.3.
Asignar
cursos
Administrar
cursos
Figura 2.3: Representación de una Realización de Caso de Uso por Colaboración
3.2 Flujo de Eventos
Un caso de uso se usa para ilustrar lo que hace un sistema; sin embargo, un caso de
uso no especifica el modo en que el sistema lo implementa.
La descripción de un flujo de eventos describe el comportamiento de un caso de uso. El
flujo de eventos se puede mostrar usando cualquiera de los siguientes métodos:
•
Texto estructurado informal.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
36
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
Texto estructurado con precondiciones y postcondiciones.
•
Seudocódigo.
En cualquiera de los métodos anteriores, puede describirse el flujo principal de eventos
así como el flujo excepcional o alternativo.
Un ejemplo de flujo de eventos que usa texto informal se da a continuación. Esto es
para un caso de uso llamado Asignar Curso y el actor involucrado es el Gerente
de Registro, quien es responsable de la asignación de cursos.
Caso de uso: Asignar Curso
El flujo principal de eventos para el caso de uso Asignar Curso será el siguiente:
•
El sistema indica al Gerente de Registro para ingresar el código de
disciplina del curso, para el cual tiene que hacerse la asignación.
•
El Gerente de Registro ingresa el código de disciplina a través del teclado.
•
El sistema verifica la validez del código de disciplina.
•
Luego el sistema indica al Gerente de Registro para ingresar si los cursos
van a ser asignados a un solo estudiante, a un grupo de estudiantes o a todos
los estudiantes.
•
El Gerente de Registro elige una de las tres opciones.
•
El sistema muestra los cursos disponibles para el semestre actual para la
asignación.
•
El Gerente de Registro elige los cursos a ser asignados.
•
El sistema muestra los detalles al Gerente de Registro y espera una
confirmación.
•
El Gerente de Registro confirma la asignación.
•
El sistema genera una entrada en el registro del estudiante para el semestre
actual acerca de los cursos que han sido asignados para el estudiante.
•
El Gerente de Registro sale del sistema.
El flujo excepcional de eventos para el caso de uso Asignar Curso será el siguiente:
•
El Gerente de Registro puede cancelar la operación en cualquier momento.
No se realiza cambio alguno al registro del estudiante.
•
El Gerente de Registro puede ingresar el código de disciplina cualquier
número de veces. En tanto no presione el botón OK, puede limpiar y reingresar el
código de disciplina.
•
El sistema indica al Gerente de Registro para ingresar nuevamente el
código de disciplina si el código de disciplina no es válido.
El flujo de eventos anterior es para uno de los casos de uso. Cada caso de uso puede
ser asociado con una descripción de flujo de eventos, de un modo similar.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
37
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
En la Figura 2.4, se muestra un formato para el flujo de eventos del tipo Texto
estructurado con precondiciones y postcondiciones, cabe destacar que no es un modelo
único, sino una referencia.
Figura 2.4: Formato para Flujo de Eventos de Tipo Texto Estructurado
3.3 Escenarios
Un escenario es una instancia de un caso de uso. Normalmente existe una expansión
de un caso de uso a un escenario. Un solo caso de uso puede resultar en varios
escenarios. Para la mayoría de casos de uso, se pueden tener escenarios primarios y
secundarios. Los escenarios primarios definen las secuencias esenciales y los
secundarios definen las secuencias alternativas. Por ejemplo, el caso de uso Generar
lista de estudiantes graduados puede tener variantes como generar listas
basado en ciertas entradas que son diferentes para estudiantes universitarios, de
postgrado y de investigación. Estas variantes pueden ser modeladas como secuencias
alternas.
3.4 Relaciones
Se pueden usar tres tipos de relaciones con casos de uso. Éstas son:
•
Generalization (generalización): En la herencia de los casos de uso, el
caso de uso secundario hereda las acciones y significado del primario, además
agrega sus propias acciones. Tal como se muestra en la Figura 2.5.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
38
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Validar
curso
Validar
curso
Pregrado
Validar
curso
Postgrado
Figura 2.5: Relación de Generalización
•
La figura anterior indica que los casos de uso Validar curso Pregrado y
Validar curso Postgrado heredan de un caso de uso más generalizado,
Validar curso. El caso de uso hijo hereda el comportamiento y significado
del caso de uso padre. Así como es posible con clases, un caso de uso hijo
puede ser sustituido donde sea que aparezca el caso de uso padre. La
representación de la generalización es una flecha vacía que apunta del caso de
uso hijo al caso de uso padre
•
Include (inclusión): Los casos de uso pueden incluir otros casos de uso.
Cuando existen secuencias de pasos en común es importante crear un nuevo
caso de uso que agrupe esas secuencias, luego existirán casos de usos que
incluirán al nuevo creado, de manera de simplificar el diagrama. Es importante
destacar que los casos de uso que se incluyen nunca aparecerán solo,
simplemente funcionan como parte de un caso de uso que lo incluya. El
estereotipo <<include>> se usa para denotar la relación include. La
representación en UML es una flecha abierta punteada que sale desde el caso
de uso base y apunta al caso de uso que se quiere incluir. Un ejemplo puede
verse en la Figura 2.6.
•
Extend (extensión): Los casos de uso pueden extenderse de otros casos de
uso. La relación extend indica que el comportamiento del caso de uso base es
extendido o ampliado por otro caso de uso (caso de uso que extiende), en la
ubicación especificada por el punto de extensión. El caso de uso base puede
existir por sí mismo. Los puntos de extensión pueden ser mencionados dentro
del caso de uso base, además los puntos de extensión son puntos donde el
comportamiento del caso de uso extendido aparece. Estos casos de uso puede
tener uno o más puntos de extensión. Todos los puntos de extensión tienen
nombre. La representación en UML es una flecha abierta punteada que sale del
caso de uso que extiende y apunta al caso de uso base. Un ejemplo puede
verse en la Figura 2.6.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
39
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 2.6: Relaciones include y extend
En la Figura 2.6, el caso de uso Generar tarjeta registro incluye explícitamente
el comportamiento de los casos de uso Validar curso y Validar estudiante.
Validar curso y Validar estudiante no pueden existir por sí mismos, sin ser
incluidos por un caso de uso.
También, se muestra que el caso de uso Ver status estudiante extiende el
comportamiento del caso de uso Chequear cuenta de estudiante. El punto de
extensión es validar cuenta. El flujo será el siguiente:
•
Ingresar para ver el estado de la cuenta del estudiante.
•
Seleccionar estudiante a visualizar.
•
Validar cuenta.
•
Mostrar detalles de la cuenta del estudiante.
En el punto de extensión, el comportamiento del caso de uso extendido Ver status
cuenta de estudiante será efectuado y luego el flujo dentro del caso de uso base
se reanuda.
4. Análisis de un Caso de Uso
Para el análisis de los casos de uso de un sistema se debe seguir las siguientes
recomendaciones:
•
Entrevistas con los clientes, esto le dará una idea del área en que se estará
trabajando, la cual da el fundamento para entrevistar a los usuarios.
•
Entrevistar a los usuarios, ellos deben indicar todo lo que ellos deben hacer con
el sistema a diseñar. Lo que los usuarios indiquen conformaran los candidatos
para los casos de uso.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
40
Guía del Estudiante
•
Análisis y Diseño de Sistemas Orientado a Objetos
Describir brevemente los casos de usos candidatos y realizar una lista de los
posibles actores que van a interactuar con ellos.
5. Diagrama de Caso de Uso
Un diagrama de caso de uso describe un conjunto de caso de uso, actores y sus
relaciones. Un diagrama de caso de uso consiste de:
•
Un conjunto de casos de uso.
•
Actores.
•
Asociaciones de comunicación entre actores y casos de uso.
•
Relaciones entre casos de uso.
Figura 2.7: Un Diagrama de Caso de Uso con Tres Actores y Cinco Casos de Uso
La Figura 2.7, ilustra un diagrama de caso de uso que consiste de tres actores y cinco
casos de uso. Los tres actores tienen una asociación con el caso de uso Verificar
horario. El actor Manejador Horario interactúa con el sistema a través del caso
de uso Generar horario, el cual incluye el caso de uso Validar curso.
Se discutió anteriormente que los casos de uso son útiles para modelar los
requerimientos de un sistema. A continuación se muestra un conjunto de
recomendaciones para entender cómo este modelado es posible usando los casos de
uso:
•
Establecer el contexto del sistema identificando los actores participantes en el
sistema.
•
Identificar el comportamiento que cada actor espera del sistema.
•
Utiliza el estereotipo <<System>> cuando los actores no sean humanos.
•
Especificar estos comportamientos como casos de uso.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
41
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
•
El comportamiento común puede ser dividido en nuevos casos de uso, de modo
que puedan ser incluidos por otros casos de uso.
•
El comportamiento variante del sistema debe ser dividido en nuevos casos de
uso que extiendan el flujo principal.
•
Los extends debe ser aplicados moderadamente en los diagramas.
•
Dibujar el diagrama de caso de uso que describe el conjunto de casos de uso,
actores y sus relaciones.
6. Diagramas de Actividad
Los diagramas de actividad muestran el flujo desde una actividad hacia otra actividad en
el sistema. Las actividades son elementos no atómicos, dentro de una máquina de
estados. Las máquinas de estado modelan el comportamiento de un objeto individual.
Las máquinas de estado se discuten más adelante. Cada actividad resulta en una
acción. Una acción puede resultar en un cambio de estado del objeto, una llamada a
otro objeto o un valor que es devuelto al llamador. Los diagramas de interacción y
actividad son similares. La diferencia radica en el hecho de que los diagramas de
interacción representan objetos que pasan mensajes entre ellos, mientras que los
diagramas de actividad representan las operaciones que ejecutan los objetos. La
diferencia es sutil, pero presenta diferentes vistas a los usuarios.
Un diagrama de actividad consiste de objetos, estados de acción, estados de actividad y
transiciones.
6.1 Estados de Acción y Actividad
Los estados de acción son definidos usando tres términos, a saber:
•
Ejecutable.
•
Atómico.
•
Cálculo.
Algunos ejemplos se muestran a continuación:
•
Invocar una operación sobre otro objeto.
•
Enviar una señal a otro objeto.
•
Crear un nuevo objeto.
•
Destruir un objeto existente.
•
Especificar una expresión simple.
Todos los ejemplos anteriores significan estados de acción que son atómicos (no es
posible una descomposición posterior) por naturaleza. Por lo tanto, un estado de acción
es referido como un “cálculo atómico ejecutable”. Un estado de acción puede ser una
acción simple o una expresión.
La Figura 2.8 ilustra estados de acción.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
42
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Figura 2.8: Estados de Acción
El estado de acción Activar Bandera no puede ser más descompuesto. En la Figura
2.8, se muestra una acción simple y una expresión.
Los estados de actividad denotan algunas actividades a ser realizadas. Un ejemplo es
la invocación de una función o un procedimiento. Los estados de actividad toman una
cantidad de tiempo razonable para completarse. Pueden o no ser atómicos. Los estados
de actividad pueden ser divididos posteriormente en estados de acción. Un estado de
acción es un estado de actividad, el cual es atómico o no puede ser más dividido. Los
estados de actividad y acción se denotan gráficamente en forma de pastilla.
Figura 2.9: Dos Estados de Actividad
La Figura 2.9, muestra dos estados de actividad. Cada uno tiene una acción asociada a
él. Uno tiene una acción de salida llamada noid mientras que el otro tiene una acción
de entrada llamada obtenerAño. Al final del primer estado de actividad, se obtiene un
noid. En la otra representación, el punto de entrada, obtenerAño es requerido. Se
observa que los estados de actividad son representados como operaciones, las que a
su vez pueden tener otros estados de actividad o estados de acción. Por ejemplo, el
estado de actividad Procesar noid puede incluir el estado de actividad Generar
noid, el cual a su vez puede incluir el estado de acción Encontrar disciplina y
otro estado de actividad Generar numero secuencia.
6.2 Transiciones
Tal como se mencionó anteriormente, los diagramas de actividad muestran el flujo de
una actividad a otra en el sistema. Cuando un estado de acción o actividad completa su
trabajo, el flujo de control debe ser pasado al siguiente estado de actividad o acción en
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
43
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
el diagrama. Se usan transiciones para mostrar el cambio de una actividad o acción a
otra en el sistema.
Las transiciones se muestran usando una línea dirigida con la punta de la flecha
apuntando hacia el siguiente estado o actividad. Para describir el flujo completo, se
muestra típicamente un estado inicial y uno final. La Figura 2.10, muestra el modo en
que las transiciones se representan en UML. El estado inicial indica el inicio de la
actividad. El resto de las acciones se mueven de un estado de acción a otro estado de
acción o estado de actividad. Finalmente, se muestra el final de un conjunto de
actividades con la ayuda del estado final.
Figura 2.10: Transiciones en UML
6.3 Condición de Guardia
Algunas veces las transiciones deberían ser ejecutadas solo cuando ciertas cosas han
ocurrido. Una condición de guardia puede ser asignada a una transición para restringir
su ejecución; es decir, si la condición de guardia no se cumple, la actividad siguiente a
la transición no se ejecuta. En la Figura 2.11, se muestra un ejemplo de condición de
guardia.
Figura 2.11: Condiciones de guardia en UML
6.4 Decisión o Bifurcación
Aunque existe un flujo de control de una actividad a otra, no siempre es puramente
secuencial. Se puede encontrar ramificación, bifurcación y unión de acciones. La
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
44
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
bifurcación es similar a una construcción if ... then ... else. Cuando se
muestra la bifurcación en diagramas de actividad, se indica la condición bajo la cual
tuvo lugar la transición. La bifurcación se denota con un diamante.
La Figura 2.12, muestra el modo en que es representada la bifurcación.
Figura 2.12: Representación de Bifurcación
El Revisar estado estudiante engloba un estado de actividad. Puede contener
otros estados de actividad y/o estados de acción. Cuando un estudiante se gradúa, el
registro de estudiante debe tener activada la bandera graduado. Un estudiante debe
haber pasado todos los cursos para poder graduarse. Si el estudiante no ha podido
aprobar siquiera un solo curso, entonces la bandera asesoría es activada. La Figura
2.12 muestra esta bifurcación, con la condición apropiada mostrada como una etiqueta
junto con la transición bifurcada (condición de guardia). Es importante destacar que se
pueden tener más de dos condiciones en una bifurcación, como se muestra en la Figura
2.13.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
45
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 2.13: Bifurcación con más de dos Condiciones
6.5 Punto de Fusión
Es el lugar donde dos rutas alternativas se unen y continúan juntas, esto es muy usado
cuando en algún momento 2 rutas o ramas de un diagrama realizan la misma secuencia
de pasos, para no repetir esos pasos, se utiliza el punto de fusión. El punto de fusión se
denota con un diamante, como se muestra en la Figura 2.14.
Figura 2.14: Notación para el Punto de Fusión
6.6 Concurrencia
Imagine una situación donde se deben manejar flujos concurrentes, es decir, manejar
más de un flujo al mismo tiempo. UML usa la ramificación (forking) y unión (joining) para
manejar un flujo concurrente.
Para mostrar la ramificación y unión de flujos de control, se usa una barra de
sincronización, la cual es una línea gruesa horizontal. Una bifurcación o ramificación
(fork) representa la separación de un flujo de control en dos o más transiciones
salientes, la simbología es mostrada en la Figura 2.15.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
46
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Figura 2.15: Notación para la Ramificación (fork)
Una unión (join) representa la unión de dos o más transiciones entrantes, la simbología
es mostrada la Figura 2.16.
Figura 2.16: Notación para la Unión (join)
Las transiciones salientes, como resultado de una bifurcación, representan flujos
concurrentes de control. Para poder mostrar correctamente el flujo de actividades, se
debe asegurar el balance de bifurcaciones y uniones. El balance es asegurado al
igualar el número de flujos que abandonan una bifurcación con el número de flujos que
ingresan a una unión.
La Figura 2.17 muestra un ejemplo de bifurcación y unión de transiciones con tres flujos
concurrentes, los cuales se bifurcan desde el estado de actividad Crear noid(). Los
tres flujos de control se encuentran donde la variable noid es creada. El control es
entonces pasado al siguiente estado de acción donde el noid es asignado.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
47
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Encontrar
disciplina
Noid=año+ disciplina+sno
Figura 2.17: Ejemplo de Bifurcación y Unión de Transiciones
6.7 Un Ejemplo de Diagrama de Actividad
La Figura 2.18 es un ejemplo de un diagrama de actividad completo. Incluye todos los
conceptos que se han aprendido: estados de acción, estados de actividad, transiciones,
ramificación, bifurcación y unión.
Cuando las actividades son modeladas, existen objetos que serán asociados al flujo de
control. Se puede describir el flujo de objetos en un diagrama de actividad.
En la Figura 2.18, se muestra un objeto s que es una instancia de la clase
Estudiante, cuyo estado es cambiado cuando se asigna un noid. Muchos objetos se
pueden mostrar en un diagrama de actividad.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
48
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Encontrar disciplina
Noid=año+disciplina+sno
Figura 2.18: Diagrama de Actividad
6.8 Indicaciones
Cuando se realiza una secuencia de actividades, es posible utilizar indicaciones para
enviar y recibir señales traducidas como eventos, dichas señales provocarán que se
ejecute una actividad.
El símbolo utilizado para enviar una señal es un pentágono convexo, y el utilizado para
recibir una señal es un pentágono cóncavo. Se puede ver un ejemplo en la Figura 2.19.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
49
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
:
Figura 2.19: Envió y Recepción de Señales
Como se observa en la Figura 2.19, la impresión se ejecuta gracias a que el procesador
de texto transmite una señal (evento) a la impresora, la cual recibe y realiza la
impresión, además se coloca el objeto Impresora para denotar que cambia de estado.
6.9 Carriles
Cuando se modelan los flujos de trabajo del negocio, se puede categorizar el diagrama
de actividad en grupos. Cada grupo representa típicamente la parte de la organización
que es responsable de esas actividades. En UML estos grupos son referidos como
carriles (swimlanes). Los carriles son descritos con una línea vertical, la cual separa
cada grupo.
En un diagrama de actividad cada carril tiene un nombre. Dado que un carril representa
un conjunto de actividades, una o más clases pueden representar cada carril en el
sistema. Cada actividad debe pertenecer a un solo carril. Una transición de una
actividad a otra puede hacerse desde un carril hacia otro, haciendo que las transiciones
atraviesen los carriles.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
50
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
La Figura 2.20 muestra un diagrama de actividad dividido en carriles.
Figura 2.20: Un Diagrama de Actividad Dividido en Carriles
Se observa que existen transiciones de un carril a otro. Los nombres que se asocian a
un carril representan clases y también pueden representar actores del sistema que son
los responsables de llevar a cabo las actividades que están en su carril.
Los diagramas de actividad se usan para modelar los aspectos dinámicos de un
sistema. Esto puede hacerse ya sea modelando un flujo de trabajo o modelando una
operación. Al modelar un flujo de trabajo, el enfoque está en actividades en el sistema y
la manera en que los actores del sistema colaboran con el sistema. El modelado de una
operación involucra entender los detalles computacionales de la operación.
Se puede asociar a cada diagrama de actividad un nombre. Empezando con el flujo de
trabajo principal, se puede continuar lentamente con la identificación de la ramificación,
concurrencia, bifurcación y unión.
7. Caso de Estudio
El caso de estudio planteado a continuación permitirá diseñar los distintos diagramas
que implementa la metodología UML; para comenzar se diseñarán el diagrama de caso
de uso y de actividad, y a lo largo del curso se diseñarán los diagramas restantes
utilizando el mismo caso de estudio.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
51
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
El enunciado se ambienta en la idea de que se han realizado entrevistas con el cliente y
los usuarios del sistema, lo cual se aprende en cursos anteriores.
Se desea diseñar un sistema computarizado para automatizar un club de video, el cual
debe tener las siguientes características:
•
El sistema debe llevar el control de afiliación y retiro de clientes.
•
Para llenar la ficha del cliente es necesario los siguientes datos:
- Nombre completo.
- Cédula.
- Dirección.
- Teléfono.
•
Como requerimiento de inscripción la persona debe de ser mayor de 18 años.
•
El cliente puede afiliarse por medio del sitio web y cancelar con su tarjeta de
crédito.
•
El sistema debe permitir alquilar, reservar, devolver y comprar películas.
•
El cliente puede devolver la película por el buzón de devolución el cual
automáticamente realiza el registro.
•
Debe permitir a los clientes consultar las películas disponibles por medio de
terminales remotos instalados en la tienda.
•
Para alquilar una película el operador del sistema introduce la cédula del cliente,
luego introduce el código de la película a ser alquilada, si la cédula del cliente no
aparece en el sistema, la transacción no procede.
•
Las reservaciones son realizadas por la página web del video club.
•
La duración de la reservación es de 24 horas, al cumplirse el lapso, la
reservación es cancelada automáticamente y la película estaría disponible en la
existencia.
•
El sistema gestiona el pago de la película por adelantado con tarjeta de crédito,
emitiendo una factura.
•
El alquiler de las películas tiene una duración de 2 días hábiles, los días
adicionales son cobrados como días de mora.
•
Para alquilar y reservar una película es necesario ser cliente del video club.
•
El sistema debe llevar el inventario de las películas del video.
•
El club de video ya dispone un sistema contable automatizado que se comunica
con el sistema planteado.
Cabe destacar que no se diseñará un diagrama de actividad por cada caso de uso, solo
los necesarios para entender la metodología, los diagramas restantes quedan para
prácticas del lector.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
52
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
7.1 Identificar los Actores del Sistema
Los actores principales para el sistema del video club son:
•
Cliente: Es la persona que compra, alquila, consulta, reserva películas en el
video club. Además, maneja el sistema directamente cuando reserva por Internet
y consulta películas en los terminales remotos.
•
Empleado: Es la persona que maneja el sistema directamente en el video club.
•
Banco: Representa a la entidad externa con la que el sistema debe contactar
para admitir y realizar los pagos con tarjetas de los clientes.
•
Sistema contable: Representa sistema externo con el cual se comunica el
sistema de video club para todos los movimientos administrativos.
•
Buzón: Representa la máquina automatizada que se conecta con el sistema
para registrar las películas devueltas.
7.2 Identificar los Casos de Uso Principales
Los casos de uso para el sistema de video club son:
•
Alquilar película: Permite al empleado registrar en el sistema las películas que
los clientes desean alquilar, verificando el cliente y el código de la película a
alquilar.
•
Devolver película: El empleado utiliza este caso de uso para registrar la entrega
de una película vencida, integrándola nuevamente en la existencia.
•
Consultar película: El cliente utiliza este caso de uso cuando quiere consultar la
existencia de una película en especial.
•
Reservar película: El cliente utiliza este caso de uso cuando desea realizar
reservaciones de películas por Internet.
•
Afiliar cliente: El operador utiliza este caso de uso cuando afilia a un cliente en el
video club.
•
Desafiliar cliente: El empleado utiliza este caso de uso cuando retira a un cliente
del video club.
•
Comprar películas: El empleado utiliza este caso de uso cuando registra la venta
de una película en el sistema.
•
Consultar clientes: Es un caso de uso genérico utilizado por los casos de usos
alquilar película, afiliar cliente y desafiliar cliente.
•
Gestionar cobro: Se encarga de gestionar el cobro a los clientes ya sea en
efectivo o por medio de tarjeta de crédito, lo cual interactúa con el Banco.
•
Administrar inventario de películas: Se encarga de llevar el control de la
existencia de las películas, así como alimentar al sistema de contabilidad de club
de video.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
53
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
7.3 Describir el Modelo de Casos de Uso
Se describirá el modelo de casos de uso para observar las relaciones entre los actores
y los diferentes casos de uso identificados en el sistema.
Figura 2.21: Diagrama de casos de uso para el Video Club
Se puede observar en la Figura 2.21 que el caso de uso Consultar cliente es incluido
por los casos de uso Alquilar película, Desafiliar cliente y Afiliar cliente. La razón por la
cual esto ocurre, es debido a que Consultar cliente es un modulo obligatorio para los
casos de usos mencionados, además no tiene funcionalidad independiente.
7.4 Flujo de Eventos
En este punto se muestra el flujo de eventos del caso de uso Alquilar película con un
formato del tipo texto estructurado, tomando en cuenta los flujos excepcionales (ver la
Tabla 1).
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
54
Guía del Estudiante
Nombre C.U:
Actores:
Descripción:
Casos de Uso
Relacionados:
Análisis y Diseño de Sistemas Orientado a Objetos
Alquilar película
Id C.U
Empleado
Permite que el cliente alquile una película
Consultar película, Consultar cliente
CU-001
Datos de la película
Registro de la película actualizado y
y del cliente
Salidas: registro del cliente actualizado
Curso Típico
Acción del Actor
Respuesta del Sistema
1.- El empleado introduce en el sistema la
cédula del cliente.
2.- El sistema verifica que el cliente este afiliado.
3.- El empleado introduce el código de la
película que el cliente escogió.
4.- El sistema verifica que la película exista o que
esté disponible.
5.- El sistema muestra los datos de la película.
6.- El sistema solicita la verificación de la película
7.-El empleado realiza la confirmación.
8.- El sistema muestra el monto a cancelar.
9.- El sistema pide los datos de la tarjeta de
crédito.
10.-El empleado introduce los datos de la
tarjeta.
11.- El sistema verifica con el banco la validez de
la tarjeta de crédito.
12.- El sistema muestra mensaje de transacción
exitosa.
13.- El sistema actualiza el inventario de películas
14.- El sistema actualiza la BD del sistema
contable.
15.-El sistema genera un recibo de pago al
cliente.
Curso Excepcional # 1: El cliente no aparece en el sistema
En el paso 1 del flujo típico, el empleado introduce una cédula
Precondición:
Acción del Actor
Respuesta del Sistema
1.- Falla la búsqueda del cliente.
2.- El sistema muestra un mensaje, indicando que
el usuario no está afiliado.
3.- El caso de uso continúa en el paso 1 del
flujo principal.
Curso Excepcional # 2: La película esta alquilada
En el paso 3 del flujo típico, el empleado introduce el código de
la película.
Precondición:
Acción del Actor
Respuesta del Sistema
1.- El sistema encuentra que la película no está
disponible.
Entradas:
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
55
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
2.- El sistema muestra en pantalla un mensaje,
indicando que la película no está disponible.
3.- El caso de uso continúa en el paso 3 del
flujo del flujo típico.
Curso Excepcional # 3: Tarjeta de crédito inválida
En el paso 11 del flujo típico, el sistema verifica la validez de la
tarjeta de crédito.
Precondición:
1.- Falla la transacción con el sistema bancario.
2.- El sistema muestra un mensaje de error
donde indica que la tarjeta es inválida.
3.- El caso de uso continúa en el paso 10 del
flujo típico.
Tabla 1: Curso Típico y Excepcional del Caso de Uso Alquilar Película
Cabe destacar que los cursos excepcionales desarrollados no son los únicos que
pueden conseguirse en este caso de uso, también existen otros como Cancelar la
operación, entre otros, los cuales se dejan de práctica al lector.
7.5 Diagrama de Actividad para el Caso de Uso
En este punto se realiza el diagrama de actividad del caso de uso Alquilar Película,
tomando en cuenta el flujo de evento típico y los flujos de eventos excepcionales
descritos anteriormente. El diagrama puede verse en la Figura 2.22.
En la Figura 2.22 puede observarse que cada flujo esta marcado por una línea con una
flecha de dirección que termina cuando termina el flujo. A continuación se describen los
diferentes flujos:
•
El flujo marcado como 1 (uno), indica el escenario exitoso, donde el cliente está
afiliado, la película que seleccionó está disponible y la tarjeta de crédito es
válida, lo cual produce una transacción exitosa.
•
El flujo marcado como 2 (dos), indica un escenario de excepción, donde el
cliente no aparece en el sistema (no esta afiliado). El sistema muestra un
mensaje de error indicando que el usuario no está afiliado, generando
automáticamente un ciclo, donde el sistema vuelve a pedir que se introduzca la
cédula.
•
El flujo marcado como 3 (tres), indica también un escenario de excepción, donde
la película no está disponible. El sistema muestra un mensaje de error indicando
que la película no está disponible, en este caso también se genera un ciclo, en el
cual el sistema vuelve a pedir que se introduzca el código de la película.
•
El flujo marcado como 4 (cuatro), es un escenario de excepción, donde cliente
no confirma el alquiler de la película, El sistema muestra un mensaje de
operación cancelada y termina el flujo.
•
El flujo marcado como 5 (cinco), es un escenario de excepción, donde el sistema
bancario reporta la tarjeta de crédito como tarjeta invalida, por lo tanto el sistema
muestra un mensaje de error, generando un ciclo, donde se vuelve a pedir los
datos de la tarjeta de crédito.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
56
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
2
3
1
4
5
Figura 2.22: Diagrama de Actividad para el Caso de Uso Alquilar Película
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
57
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Resumen
Ahora, que ha completado esta unidad, usted debe ser capaz de:
•
Definir la importancia de los casos de uso.
•
Definir cada uno de los elementos involucrados en un diagrama de casos de
uso.
•
Describir el análisis para un caso de uso.
•
Describir la importancia y los elementos de los diagramas de actividad.
•
Elaborar un diagrama de casos de uso.
•
Elaborar diagramas de actividad.
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
58
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Examen de Autoevaluación
1) Un diagrama de actividad es una interacción entre un usuario u otra entidad y el
sistema que es diseñado.
a) Verdadero
b) Falso
2) De las siguientes afirmaciones, seleccione las respuestas correctas:
a) El caso de uso es una excelente herramienta para que los usuarios describan
el sistema desde sus propios puntos de vista.
b) El nombre de un caso de uso es una combinación de un adjetivo y un
sustantivo.
c) En un diagrama de caso de uso, los actores que participan en el sistema
pueden ser heredados de un actor existente.
d) Un caso de uso se representa gráficamente con un círculo, con el nombre
dentro del círculo.
3) Una colaboración, es una sociedad de clases, que se utiliza para implementar un
caso de uso
a) Verdadero
b) Falso
4) ¿Cuáles de los siguientes métodos son utilizados para describir el flujo de eventos
de un caso de uso?
a) Texto estructurado informal
b) Texto estructurado con precondiciones y postcondiciones
c) Seudocódigo
d) Solo a y b
5) ¿Cuáles de las siguientes son relaciones entre casos de uso?
a) Asociación
b) Generalización
c) Inclusión
d) Agregación
6) La relación de inclusión quiere decir que un caso de uso incluye implícitamente a
otro caso de uso.
a) Verdadero
b) Falso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
59
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
7) De las siguientes afirmaciones seleccione las respuestas correctas:
a) Un estado de acción es un elemento no atómico.
b) Una condición de guardia puede ser asignada a una transición para restringir
su ejecución.
c) Un diagrama de actividad consiste de objetos, estados de acción, estados de
actividad y transiciones.
d) En los diagramas de actividad la bifurcación se denota gráficamente como un
diamante.
8) Las transiciones se muestran usando una línea punteada dirigida con la punta de
la flecha apuntando hacia el siguiente estado o actividad.
a) Verdadero
b) Falso
9) Es el lugar donde dos rutas alternativas se unen y continúan juntas.
a) Unión
b) Fusión
c) Concurrencia
d) Bifurcación
10) El símbolo utilizado para enviar una señal es un pentágono cóncavo y el utilizado
para recibir una señal es un pentágono convexo.
a) Verdadero
b) Falso
Unidad 2: Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
60
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Respuestas de la Unidad 2: Examen de Autoevaluación
1) b
2) a y c
3) a
4) a, b y c
5) b y c
6) b
7) b, c y d
8) b
9) b
10) b
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
61
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Lab. de Modelado del
Comportamiento con Casos de Uso
Objetivos del Laboratorio
•
Identificar requerimientos del sistema usando Casos de Usos.
•
Describir los escenarios y flujos de eventos de los Casos de Usos.
•
Elaborar Diagrama de Casos de Usos.
•
Elaborar Diagramas de actividades.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
63
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. Ejercicio de Laboratorio
Se describe un sistema ATM para un e-Bank (Banco electrónico).
El e-Bank lanzó sus operaciones en Venezuela, con su casa matriz en Caracas, en
2002. Dentro de un periodo corto de tres años, construyó una red de 275 sucursales por
toda Venezuela. Quizás deba su éxito al excelente servicio al cliente y a la banca por
Internet para clientes individuales y corporativos. Aunque tiene un sistema ATM
existente en todas sus sucursales, el banco desea diseñar e implementar un nuevo
sistema ATM basado en las últimas tecnologías. La necesidad es tener un sistema de
software orientado a objetos para el ATM, que resulte en una estructura sencilla con
componentes reutilizables que sean fáciles de extender y mantener.
A continuación se presenta la descripción de los requerimientos claves del sistema ATM
para el e-Bank:
•
Existen dos tipos principales de clientes del banco: Individuales y corporativos.
•
Uno de los requerimientos importantes del sistema es permitir al cliente
depositar una cantidad y/o retirar una cantidad de una cuenta en los centros
ATM. Los centros ATM tienen un quiosco con capacidades de pantalla de
contacto.
•
El cliente debe tener la capacidad de revisar cada transacción realizada contra
una cuenta. Algunas de las transacciones registradas incluyen lo siguiente:
- Fecha.
- Hora.
- Tipo de transacción (o tipo de transacción).
- Cantidad.
- Balance de Cuenta.
•
Un cliente individual puede operar tres tipos de cuentas:
- Una cuenta de ahorros.
- Una cuenta de depósito fijo.
- Una cuenta de depósito recurrente.
•
Un cliente corporativo sólo puede operar un tipo de cuenta, llamada cuenta
corriente.
•
Los clientes pueden acceder a sus cuentas en el ATM insertando una tarjeta
ATM, dicha tarjeta es proporcionada al cliente junto con un código (PIN) que
tendrá que ser insertado después que se inserta la tarjeta. El código (PIN) está
compuesto de 4 dígitos decimales del 0 al 9.
•
Se supone que una sola tarjeta ATM proporciona acceso a todas las cuentas del
cliente.
•
Un cliente puede hacer depósitos en cualquiera de los tipos de cuenta.
Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
64
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
El retiro de dinero es permitido en la cuenta de ahorros sólo si existe un balance
positivo.
•
El retiro de efectivo directamente desde la cuenta de depósito fijo o la de
depósito recurrente no está permitido.
•
El retiro de efectivo desde la cuenta corriente está permitido incluso si no existe
un balance positivo.
•
La magnitud de sobregiro permitido se fija al momento de abrir la cuenta
corriente y puede ser modificado sólo por las autoridades del banco y no a
través del ATM.
•
Mientras el retiro no está permitido directamente desde la cuenta de depósito fijo
o recurrente, se puede transferir una cantidad de dinero desde estas cuentas
hacia una cuenta de ahorros. Sin embargo, dichas transferencias implican un
pago por transacción del 7% y las cantidades transferidas no pueden exceder
del 75% que se tiene en la cuenta origen.
Se requiere realizar las siguientes tareas:
•
Identificar los actores principales del sistema.
•
Identificar los casos de usos más relevantes en el sistema, indicando relaciones
extensión e inclusión.
•
Dibujar el diagrama de casos de usos.
•
Realizar el flujo de eventos para el caso de uso más relevante en el sistema,
tomando en cuenta los cursos típicos y excepcionales.
•
Realizar el diagrama de actividad del caso de uso más relevante en el sistema.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
65
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
Objetivos de Aprendizaje
Al final de esta unidad, usted será capaz de:
•
Describir el modelado estructural del UML en forma básica.
•
Describir clases y sus relaciones.
•
Conocer los mecanismos comunes que pueden ser aplicados a las clases.
•
Elaborar Diagrama de Clases.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
67
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. Modelado Estructural
El modelo estructural es el modelo UML básico. Estructura significa constitución. El
Modelado estructural de UML especifica cómo está constituido el sistema completo. El
modelado revela las partes concretas del sistema completo. Simplemente, el modelado
estructural se ocupa de las clases (abstracciones) y objetos (realizaciones concretas de
las abstracciones).
Se verán dos diagramas bajo el modelado estructural. Éstos son:
•
Diagramas de clase.
•
Diagramas de objetos.
Se aprenderá acerca de diagramas de clase y las relaciones entre clases, comenzando
la discusión con los diagramas de clase.
2. Diagramas de Clase
Una clase es el marco de trabajo para un conjunto de objetos, que comparten los
mismos atributos, operaciones, relaciones y semánticas. En UML, una clase se
representa gráficamente con un rectángulo. A continuación se aprenderá acerca de los
nombres de clase.
2.1 Nombre de Clase
Cada clase tiene un nombre. Un nombre puede ser simple, en donde sólo el nombre de
la clase se especifica. La otra forma de nombrar una clase es especificando el nombre
de ruta, la cual contiene también el nombre del paquete. Es importante destacar que las
clases deben comenzar con letra mayúscula, si el nombre está compuesto por dos
palabras, las mismas deben ser unidas comenzando cada una en mayúscula. La Figura
1.9 muestra la notación más simple de representar una clase en UML.
Empleado
Estudiante
Vehículo
FormularioDeRegistro
Figura 4.1: Método Simple de Representar una Clase
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
68
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
La Figura 4.2 muestra el modo en que se usan los nombres de ruta cuando se nombran
clases.
DetalleEmpleado::Empleado
Universidad::DetalleEstudiante::
Estudiante
Fabricante::Vehículo
Biblioteca::DetalleMiembro::
FormularioDeRegistro
Figure 4.2: Uso de Nombres de Rutas
El signo :: se usa como el símbolo de separación. La última parte del nombre de ruta es
el nombre de la clase (en el extremo de la derecha) y hacia el extremo contrario
(izquierdo) es el nombre del paquete. Como una práctica estándar, la primera letra de
un paquete y de un nombre de clase está en mayúsculas. A continuación se aprenderá
acerca de los atributos de la clase.
2.2 Atributos de Clase
Un atributo es una propiedad de una clase y tiene un nombre. Los atributos de una
clase caracterizan la clase. Los atributos especifican un rango de valores que los
objetos de la clase pueden tomar. Los atributos de una clase describen las propiedades
esenciales de la clase, y pueden ser especificados dentro del rectángulo ubicado debajo
del nombre de la clase, tal como se muestra en la Figura 4.3.
Nombre de
clase
Empleado
empleadoId
empleadoNombre
fechaDeNacimiento
salario
departmento
Atributos
Figura 4.3: Atributos de una Clase
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
69
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Los nombres de atributos que constan de una sola palabra comienzan con letra
minúscula. Sí el nombre del atributo esta formado por más de una palabra, cada palabra
siguiente comenzará con una letra mayúscula, a excepción de la primera palabra que
comenzará en minúscula, tal como en nombreEmpleado. Esto se hace para mejorar la
legibilidad. Es posible además especificar el tipo de dato al que pertenece el atributo,
así como también un valor por defecto, tal como se muestra en la Figura 4.4.
Nombre de
Clase
Empleado
empleadoId : Integer
empleadoNombre : String
fechaDeNacimiento : DOB
salario : Float = 0.0
departmento : String
Atributos
Figura 4.4: Atributos de una Clase con sus Valores por Defecto
El atributo salario se establece con un valor por defecto de 0.0. Separando el atributo y
la clase con dos puntos (:) muestra la clase a la cual pertenece el atributo.
Ahora se discutirán las operaciones de una clase.
La sintaxis de un atributo en UML, de forma completa, se muestra a continuación:
[visibilidad] nombre [multiplicidad] [: tipo ] [= valor inicial]
[{propiedad de la cadena}]
Algunos ejemplos de cómo se pueden especificar atributos en UML:
númeroIdentidad
Sólo el nombre del atributo
+ númeroIdentidad
Visibilidad y nombre del atributo
- númeroIdentidad = 10
Visibilidad, nombre y valor inicial
númeroIdentidad: Integer
Nombre y tipo
númeroIdentidad {frozen}
Nombre y propiedad
Se puede mencionar cualquiera de las tres propiedades, changeable, addOnly y
frozen. La propiedad changeable (cambiable) indica que el valor del atributo
puede ser fácilmente alterado. Esta es la propiedad por defecto.
La propiedad addOnly (solo adicionar) se usa cuando la multiplicidad es mayor
que uno, y puede ser completada con valores extra, pero una vez creada no puede ser
retirada o cambiada.
Cuando se usa la propiedad frozen (congelado), el valor de los atributos no puede
ser alterado después de que el atributo ha sido inicializado.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
70
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
2.3 Operaciones de una Clase
Las operaciones son las funcionalidades o comportamiento que una clase ofrece, por
ejemplo una clase llamada Carro puede realizar diferentes operaciones tales como:
Acelerar(), Frenar(), cruzar(), entre otros.
En UML, las operaciones se especifican en un rectángulo ubicado debajo de la lista de
atributos. Esto se ilustra en la Figura 4.5.
Nombre de
Clase
Empleado
empleadoId : Integer
empleadoNombre : String
...
Atributos
colocarDetalleEmpleado()
obtenerDetalleEmpleado()
colocarSalario(salario : Float)
obtenerSalario() : Float
Operaciones
Figura 4.5: Atributos y Operaciones de una Clase
En la Figura 4.5, se ilustra cómo se especifican las operaciones como parte de la clase.
Se puede especificar el parámetro tomado por una operación junto con su tipo de dato,
indicándolo entre los paréntesis que preceden al nombre de la operación, como en
colocarSalario(salario:Float). También se puede especificar el tipo de retorno
de una función, como en obtenerSalario().
La elipsis (...) o puntos suspensivos bajo la sección de atributos de la clase en la Figura
4.5, indica que tal vez existan más atributos para esta clase. Una clase juega un rol
particular en cada vista del sistema. Se pueden revelar sólo aquellos atributos y
operaciones para la clase que son aplicables para esa vista.
La sintaxis de las operaciones en UML, de forma completa, se muestra a continuación:
[visibilidad] nombre [(lista de parámetros)]
[: tipo del retorno] [{propiedad de la cadena}]
Algunos ejemplos de cómo se pueden usar las operaciones se muestran a continuación:
definirEmpleado()
sólo nombre de la operación
+ definirEmpleado ()
visibilidad y nombre
- definirEmpleado (e : Empleado)visibilidad, nombre y parámetro
obtenerEmpleado() : Empleado
nombre y tipo de retorno
obtenerEmpleado () {isQuery}
nombre y propiedad
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
71
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Existen cuatro tipos de propiedades de cadenas para las operaciones. Estas son:
•
isQuery (es consulta): Cuando se ejecuta esta operación, el sistema no
se modifica. Generalmente, la operación no tiene repercusiones.
•
Sequential (secuencial): Los que invocan la operación deben asegurar
que hay un sólo flujo del objeto (o sólo una llamada a una instancia) en un
instante en el tiempo. Si hay más, la semántica y la integridad no son
garantizadas por la operación.
•
Guarded (garantizada): Múltiples llamadas desde hilos concurrentes
pueden ocurrir simultáneamente para una instancia (sobre la operación
guarded), pero solo a una se le es permitido ejecutarse. Las otras son
bloqueadas hasta que la primera operación es completada. La semántica y la
integridad son garantizadas por la operación guarded.
•
Concurrent (concurrente): Cuando existen muchos flujos de control, se
garantiza la semántica e integridad del objeto tratando la operación como
atómica, o en otras palabras, múltiples flujos de control pueden ocurrir
simultáneamente para un objeto en operaciones concurrentes.
Las propiedades sequential, guarded y concurrent son relevantes para aplicar a objetos
activos, procesos o hilos.
Se puede agregar información adicional a la lista de parámetros, usando la siguiente
sintaxis:
[dirección] nombre : tipo [=valor por defecto]
La dirección puede ser in para parámetros de entrada, out para parámetros de
salida e inout para un parámetro que ingresa y puede ser modificado. El parámetro in
no puede ser modificado, mientras que el parámetro out puede ser modificado por la
operación. También se puede especificar un valor inicial al atributo. A continuación un
ejemplo:
definirEmpleado(in e : Empleado)
InicializarId (in IDNo : Integer = 100)
2.4 Estereotipo
Cada conjunto de atributos u operaciones puede ser categorizado y un nombre puede
proporcionarse para este grupo. Esto se denomina un estereotipo. Los estereotipos
ayudan a agrupar operaciones o atributos similares. También ayudan a una mejor
organización de atributos y operaciones cuando se especifican como parte de la clase.
La Figura 4.6 brinda un ejemplo de cómo usar los estereotipos. Típicamente, los
estereotipos son encerrados dentro de << >>.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
72
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Nombre de Clase
Empleado
<< detalles básicos >>
empleadoId : Integer
empleadoNombre : String
fechaDeNacimiento : DOB
<< detalles empleo >>
salario : Float = 0
Atributos
Estereotipo
<< operaciones de colocar >>
colocarDetallesEmpleado()
colocarSalario(salario : Float)
<< operaciones de recuperar >>
obtenerDetalleEmpleado()
Operaciones
Figura 4.6: Uso de Estereotipos
En la figura anterior, se tienen unos cuantos estereotipos, son estos: detalles
básicos, detalles empleo, operaciones de colocar y operaciones de
recuperar. Los atributos y operaciones que siguen un estereotipo pertenecen a
aquella categoría especificada por el estereotipo.
Ahora se examinarán las responsabilidades de una clase.
2.5 Responsabilidades de una Clase
¿Existe alguna diferencia entre una operación y una responsabilidad? Las operaciones
son las implementaciones de los servicios proporcionados por la clase. Por otro lado,
las responsabilidades son aquellas que una clase establece y que es capaz de realizar.
Las responsabilidades son obligaciones a ser cumplidas por una clase. Por ejemplo, la
clase Empleado es responsable de conocer el nombre del empleado o su edad. Las
responsabilidades se muestran en forma textual, en simple español.
La Figura 4.7 ilustra el modo en que las responsabilidades de una clase se muestran
dentro de la especificación de una clase.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
73
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Nombre de
Clase
Empleado
Responsabilidades
-- Mantener los detalles
del empleado
-- Determinar la edad
del empleado
Responsabilidades
-- Capaz de establecer
los detalles del
empleado
Figura 4.7: Responsabilidades de una Clase
2.6 Ámbito y Visibilidad
Hay dos tipos de ámbito para los atributos y operaciones de las clases, estos son, clase
e instancia.
•
Ámbito de clase: Indica que el atributo o la operación están disponibles a través
del nombre de la clase. No hay necesidad de tener un objeto que accede al
atributo u operación. El ámbito de clase se representa subrayando el atributo.
•
Ámbito de instancia: Indica que cada instancia del clasificador tiene su propia
copia del atributo u operación. El ámbito de instancia es el ámbito por defecto.
Los atributos y operaciones de una clase pueden o no ser usados por otras clases. La
visibilidad refiere al alcance de acceso permitido para un miembro de una clase.
•
Pública (Public): Denota que los atributos y operaciones son visibles a otros
clasificadores, de modo que cualquier otro clasificador podrá utilizarlos. Un signo
+ al lado del atributo o la operación denota visibilidad public.
•
Protegida (Protected): Cualquier subclase o descendiente de un clasificador
puede usar el atributo o la operación de una súper clase. El símbolo # se usa
para denotar miembros protected de una subclase.
•
Privada (Private): Sólo las instancias de un clasificador pueden usar los
atributos y operaciones que tienen visibilidad private, esto es, el atributo o la
operación sólo se puede utilizar dentro de la clase que lo contiene. Un signo –
denota visibilidad private.
•
Paquete (Package): Denota que los atributos y operaciones son visibles a
clasificadores que se encuentran dentro del mismo paquete. El símbolo ~ se
utiliza para indicar este tipo de visibilidad. Esta visibilidad es válida en la
especificación 2.0 de UML.
La Figura 4.8 muestra un ejemplo que ilustra ámbito y visibilidad.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
74
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Empleado
-cuentaEmpleado
# empleadoId
# empleadoNombre
+ colocarEmpleadoId()
+ colocarEmpleadoNombre()
+ obtenerEmpleadoId()
+ obtenerEmpleadoNombre ()
+ obtenerCuentaEmpleado()
...
Figura 4.8: Ilustración de Ámbito y Visibilidad
3. Relaciones entre Clases
Las relaciones conectan dos o más cosas. En la orientación a objetos, se hablan de
tales conexiones entre dos o más clases. Los cuatro tipos de relaciones entre clases
son las siguientes:
•
Dependencia.
•
Generalización.
•
Asociación.
•
Agregación.
Cada una de estos tipos de relaciones tiene una notación específica en UML. A
continuación se discute la relación de dependencia.
3.1 Relación de Dependencia
La relación de dependencia es la relación de “utiliza”. Esto quiere decir que un elemento
usa otro elemento para que se realice una tarea. Un cambio en el elemento que se está
usando afecta al elemento que lo usa. Lo inverso no necesariamente es cierto. Por
ejemplo, una relación de dependencia ocurre cuando un objeto es pasado como un
parámetro en una operación de una clase. La operación puede usar el objeto a través
de sus interfaces conocidas. Si la interfaz cambia, afecta al objeto que está usando el
otro objeto. En UML, una línea punteada dirigida denota una relación de dependencia.
Una dependencia puede tener nombre. Pero normalmente no se le pone nombre a
menos que se tenga un modelo que tenga muchas dependencias y exista la necesidad
de distinguirlas entre ellas.
La Figura 4.9 muestra cómo se usa una relación de dependencia en UML.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
75
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
GeneradorNomina
DatosNomina
actualizarDataEmpleado()
generarNomina()
DatosNomina
obtenerDataEmpleado()
añadirDataEmpleado()
GerenadorNomina
Figura 4.9: Relación de Dependencia
En la Figura 4.9, la dirección de la cabeza de la flecha es hacia la clase de la cual se
depende. La clase GeneradorNomina es dependiente de la clase DatosNomina. Para
que se genere la nómina, la clase GeneradorNomina requiere datos de la clase
DatosNomina. Un cambio en la interfaz de DatosNomina afectará a
GeneradorNomina. A continuación, se aprenderá acerca de la relación de
generalización.
3.2 Relación de Herencia o Generalización
La generalización consiste de la relación entre una clase principal (superclase) y la
subclase. La superclase representa un concepto general mientras que la subclase
representa un concepto más específico. Esta relación es llamada también una relación
“es un tipo de” (“is a kind of”). Ejemplos de esta relación son:
•
Rosa es un tipo de flor.
•
Quick sort es un tipo de algoritmo de ordenamiento.
•
Lapicero es un tipo de instrumento de escritura.
•
Windows 2000 es un tipo de sistema operativo.
En una relación de generalización, la entidad hija puede aparecer donde sea que
aparezca la entidad padre, pero lo inverso no es válido. Se alcanza el polimorfismo con
la generalización cuando una entidad hija sobrescribe una operación que es definida en
la entidad padre. En UML se denota la relación de generalización con una línea sólida
dirigida. La Figura 4.10 es una representación esquemática de tal relación.
Empleado
Gerente
IngSoftware
GerenteProducción
Staff
GerenteVentas
Figura 4.10: Relación de Generalización
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
76
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
La clase Gerente es una subclase de Empleado, y es también la superclase para las
clases GerenteVentas y GerenteProducción. A continuación se discute la relación
de asociación.
3.3 Relación de Asociación
La relación de asociación es una relación simple. Conecta dos clases, denotando la
relación estructural entre ellas. En una asociación, es posible navegar entre las clases
que participan en la relación. También puede existir una asociación de una clase a sí
misma. La notación UML para una asociación es una línea sólida que conecta las dos
clases que participan en la relación de asociación.
Una relación de asociación puede tener un nombre que indica la asociación entre las
dos clases, en este caso debe colocársele justo sobre la línea sólida que define la
asociación. Cuando una clase participa en una relación de asociación, juega un rol
específico en esa relación. Los roles pueden ser especificados para cada clase que
participa en la relación.
La Figura 4.11 describe una relación de asociación, mostrando el nombre de asociación
y los roles que cumplen las clases en esa relación.
Trabaja Para
Compañía
Gerente
Empleado
Empleador
Figura 4.11: Relación de Asociación
El nombre de la asociación es Trabaja Para y los roles son Empleado y
Empleador. Agregar estos adornos a la relación de asociación mejora el significado de
las clases que participan en la relación.
3.3.1
Multiplicidad
También se puede mostrar cuántos objetos pueden ser conectados para una instancia
de una relación de asociación. Esto se llama la multiplicidad del rol de una asociación.
Una asociación tiene dos extremos, en cada extremo se puede especificar un número
que indica el número de objetos a ser creados para esa asociación. Vea la Figura 4.12.
VehiculoCuatroRuedas
1
4
Puertas
Figura 4.12: Multiplicidad del Rol de una Asociación
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
77
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
En la figura anterior, se muestra que para cada instancia de VehiculoCuatroRuedas
existen cuatro instancias de Puertas.
También se puede especificar:
0..1 para cero o uno, también se puede definir como “ninguno o uno”.
0..* para cero o más.
1..* para uno o más.
3..5 para el rango 3, 4 ó 5.
Adicionalmente, se puede tener conjuntos de multiplicidad, por ejemplo, {7, 8, 12}.
3.3.2
Asociación Calificada
Cuando un objeto de una clase tiene que seleccionar un objeto de otra clase para
cumplir con un papel especial en la asociación, la primera clase debe valerse de un
atributo en específico para localizar al objeto adecuado. Este atributo debe ser un
identificador único. Esto es llamado asociaciones calificadas, por ejemplo cuando una
persona reserva por teléfono entradas para ir al cine, el recepcionista le entrega un
número de reservación único (localizador) de las entradas, si en algún momento se
desea saber el estado de la reservación o se va a comprar las entradas al cine, se debe
entregar el número de la reservación para realizar la operación. La Figura 4.13 muestra
la representación gráfica del ejemplo anterior.
RecepcionistaCine
NumeroReservacion
1
localiza 1..*
Reservacion
Figura 4.13: Asociación Calificada
3.3.3
Clase Asociación
Una clase asociación modela atributos y operaciones de una asociación, la clase
asociación se crea de la misma manera que una clase estándar, la conexión se realiza
mediante una línea discontinua entre la asociación de dos clases relacionadas.
La clase asociación puede tener asociaciones con otras clases. En la Figura 4.14, se
muestra una clase asociación Contrato para la asociación “trabaja para” entre la clase
Empleado y la clase Compañía. Esta misma clase Contrato se asocia con la Clase
Gerente.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
78
Guía del Estudiante
Empleado
Análisis y Diseño de Sistemas Orientado a Objetos
trabaja para
Compañia
Contrato
Gerente
aprobado por
Figura 4.14: Clase Asociación
3.4 Relación de Agregación
También se puede especificar una relación de agregación al extender la relación básica
de asociación. Se conoce como una relación todo-parte (whole-part). La clase en un
extremo de la relación contendrá las clases en el otro extremo de la relación. La relación
todo-parte significa la relación “es parte de” o “tiene un”. Algunos ejemplos de una
relación de agregación son los siguientes:
•
Un cuarto tiene una puerta.
•
Edificio tiene cuartos.
•
Vehículo tiene un motor.
•
Compañía tiene departamentos.
•
Libro tiene capítulos.
Existen dos formas de agregación:
•
Agregación simple.
•
Composición.
Una agregación establece una relación del tipo “tiene un” entre dos clases. En una
agregación simple, el tiempo de vida del todo y las partes no están enlazados. Por otro
lado, en la composición, si están enlazados. Si el todo deja de existir, las partes
automáticamente dejan de existir.
La Figura 4.15 muestra una agregación simple. Esta relación se muestra usando un
diamante sin rellenar. El diamante se ubica cerca de la clase que forma el todo en la
relación. Puerta y Asiento existen como entidades incluso si la clase
VehiculoCuatroruedas deja de existir. Ellas están disponibles para su uso con otros
vehículos similares.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
79
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
VehiculoCuatroRuedas
Puerta
Asiento
Figura 4.15: Agregación Simple
La Figura 4.16 describe la composición y la multiplicidad.
Edificio
nombreEdificio
numeroDePisos
colocarNombre()
colocarNumeroDePisos()
...
1
4..6
Habitación
Piso
numeroPisos
numeroDeHabitaciones
1
obtenerNumeroPiso()
obtenerNumeroDeHabit()
12
numeroHabitación
lugarHabitación
obtenerNumeroHabit()
obtenerLugarHabit()
...
Figura 4.16: Composición y Multiplicidad
Edificio tiene una relación de composición con Piso, y Piso a su vez tiene una
relación de composición con Habitación.
En la primera instancia, Edificio es el todo y Piso es la parte. En la segunda
instancia, Piso es el todo y Habitación es la parte. Esta relación se muestra como un
diamante negro ó relleno, que se coloca cerca de la clase que representa el todo en la
relación.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
80
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
También se muestra la multiplicidad del rol de la agregación. Un edificio puede tener 4,
5 ó 6 pisos mientras que cada piso tiene 12 habitaciones.
Antes de ver un ejemplo para ilustrar cómo se dibujan los diagramas de clase usando la
notación UML, se discutirá brevemente algunos adornos usados comúnmente en
diagramas de clase.
4. Mecanismos Comunes
Se aprendió que los mecanismos comunes, tal como los adornos, mejoran el
entendimiento del sistema.
A continuación se listan algunos de esos mecanismos comunes:
•
Nota: Una nota permite especificar comentarios acerca de un aspecto particular
de un modelo. Una nota se muestra gráficamente como un rectángulo con una
esquina doblada. También contiene comentarios textuales o gráficos. Vea la
Figura 4.17.
Los comentarios
van aquí
Figura 4.17: Especificación de Comentarios en UML
•
Valor Etiquetado (Value tagged): Los valores etiquetados permiten crear
nueva información en la especificación de un elemento. Se representa como una
cadena colocada entre un par de llaves {...}. Los valores etiquetados se colocan
debajo de un elemento.
•
Estereotipo: Los estereotipos permiten crear nuevos tipos de bloques de
construcción que son específicos al sistema que está siendo analizado. Estos
bloques de construcción son similares a los existentes. Los estereotipos están
encerrados dentro de << >> y son ubicados encima del elemento al cual se
refieren.
•
Restricción: Las restricciones ayudan a agregar nuevas reglas o a modificar
aquellas existentes. Éstas son de nuevo encerradas entre llaves y se ubican en
proximidad al elemento asociado.
•
Compartimentos Extra: Pueden ser agregados a una notación de clase para
proporcionar mayor significado a la existencia de la clase en el modelo.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
81
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
La Figura 4.18 ilustra los mecanismos comunes discutidos anteriormente.
La clase que
maneja todas las
operaciones de
nómina de la
compañía.
<< Subsistema Nómina >>
GerenteNómina
{version = 1.3}
revisarFecha()
activarProcesoNómina()
...
{Corre sólo el último
día de cada mes}
GeneradorNómina
{autor = jerry}
InformacionNómina
generarNómina()
Se conecta
a Oracle 8i
el cual es
residente
en el
servidor
King.
ConectorBaseDatos
{version = 2.0}
{autor = donald}
{fecha = 03/03/2001}
traerDataEmpleado()
traerDeducciones()
traerIngreso()
Excepciones
noHayEmpleado
accesoIncorrectoBaseDatos
...
Figura 4.18: Ilustración de los Mecanismos Comunes
En la Figura 4.18, se han incluido los siguientes mecanismos comunes:
•
Dos notas, una adjunta a GerenteNomina y otra a ConectorBaseDatos.
•
Valores etiquetados para las clases GerenteNomina, GeneradorNomina y
ConectorBaseDatos. Los valores son especificados como una cadena encerrada
dentro de { } justo debajo del nombre de la clase. Note que los valores
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
82
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
etiquetados son útiles para especificar el número de versión, nombre de autor y
la fecha en que se escribió el programa.
•
Restricción para GerenteNomina, colocada fuera de dicha clase, para indicar
que las operaciones de esta clase corren sólo en el último día del mes. Ésta es
la única restricción que se ha agregado a esta figura.
•
Se ha agregado un compartimiento extra llamado Excepciones, en la clase
ConectorBaseDatos. Este da la lista de excepciones lanzadas por esta clase.
También se pueden agregar compartimentos sin nombre dentro de una clase.
5. Caso de Estudio
Hasta aquí se ha aprendido acerca de clases, sus relaciones, adornos y mecanismos
comunes. Siguiendo con la resolución del caso de estudio planteado en la unidad 2,
ahora se aprenderá a construir un diagrama de clases. Un diagrama de clases describe
gráficamente un conjunto de clases, interfaces, colaboraciones y las relaciones entre
ellas.
Se coloca nuevamente el problema para mayor comprensión del mismo.
Se desea diseñar un sistema computarizado para automatizar un club de video, el cual
debe tener las siguientes características:
•
El sistema debe llevar el control de afiliación y retiro de clientes.
•
Al momento de la afiliación por Internet el sistema muestra un contrato, el cual
debe ser aceptado por el cliente para ser afiliado.
•
Para llenar la ficha del cliente es necesario los siguientes datos:
- Nombre completo.
- Cédula.
- Dirección.
•
Como requerimiento de inscripción la persona debe de ser mayor de 18 años.
•
El cliente puede afiliarse por medio del sitio web y cancelar con su tarjeta de
crédito.
•
El sistema debe permitir alquilar, reservar, devolver y comprar películas.
•
El cliente puede devolver la película por el buzón de devolución el cual
automáticamente realiza el registro.
•
Debe permitir a los clientes consultar las películas disponibles por medio de
terminales remotos instalados en la tienda.
•
Para alquilar una película el operador del sistema introduce la cédula del cliente,
luego introduce el código de la película a ser alquilada, si la cédula del cliente no
aparece en el sistema, la transacción no procede.
•
Las reservaciones son realizadas por la página Web del club de video.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
83
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
•
La duración de la reservación es de 24 horas, al cumplirse el lapso, la
reservación es cancelada automáticamente y la película estaría disponible en la
existencia.
•
El sistema gestiona el pago de la película por adelantado con tarjeta de crédito,
emitiendo una factura.
•
El alquiler de las películas tiene una duración de 2 días hábiles, los días
adicionales son cobrados como días de mora.
•
Para alquilar y reservar una película es necesario ser cliente del video club.
•
El sistema debe llevar el inventario de las películas del video.
El club de video ya dispone un sistema contable automatizado que se comunica con el
sistema planteado.
5.1 Identificar las Clases
•
En la Figura 4.19, se muestran Las clases
descripción del problema:
que son identificadas en la
Figura 4.19: Clases Identificadas
Para el diagrama final varias de estas clases no serán tomadas en cuenta, esto nos dice
que no todas las clases que se identifican a primera vista son todas las clases que
finalmente quedaran para el diagrama.
Cabe destacar que la abstracción de las clases realizadas, puede variar según la
capacidad de análisis de la persona encargada de realizar el modelo. Por lo tanto varias
personas pueden tener diferentes diagramas de clase del mismo problema.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
84
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
5.2 Identificar Propiedades y Métodos
En la Figura 4.20, se muestra las propiedades y los métodos principales extraídos de la
descripción de problemas, acompañado de sus respectivas visibilidades.
Los diagramas brindan la primera vista de la arquitectura del sistema, desde el punto de
vista de abstracciones del mundo real. Se usará el mismo ejemplo en otras unidades
para obtener las otras vistas del sistema.
C
Figura 4.20: Identificación de Propiedades y Métodos con Visibilidad
5.3 Identificar Relaciones
En la Figura 4.21, se observan las diferentes relaciones identificadas en el problema.
•
Asociación: Como se puede observar en la Figura 4.21, la asociación es la
relación más utilizada comúnmente. Se describe a continuación cada una de las
relaciones:
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
85
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Un cliente realizar distintas operaciones con películas, esto implica una relación de
asociación entre la clase Cliente y la clase Película
Figura 4.21: Diagrama de Clases
El cliente realiza los pagos de las películas, lo cual genera una relación de asociación
entre la clase Cliente y la clase Pagos.
La relación de asociación entre la clase Empleado y la Película, permite el registro del
empleado con la transacción de la película.
•
La clase Inventario tiene una relación de asociación con la clase Película, debido
a que el inventario contiene la cantidad de películas que hay en el stock de la
tienda de video.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
86
Guía del Estudiante
•
Análisis y Diseño de Sistemas Orientado a Objetos
Dependencia: La clase Factura depende de la clase Cliente, si cambian los
datos del cliente la factura es afectada directamente. También existe una
relación entre la clase Factura y la clase Pagos, la cual permite que en la factura
se imprima la forma de pago de la película.
Además de observar las relaciones, observe las clases que fueron descartadas del
análisis preliminar en los puntos anteriores, queda de parte del lector analizar el por
que fueron descartadas esas clases.
5.4 Algunas Recomendaciones
Se debe notar que cada clase que se modela debe corresponder a alguna entidad
tangible de una abstracción conceptual en el mundo real. Lo siguiente debe tenerse en
cuenta para lograr una clase bien estructurada:
•
La clase debe proporcionar una abstracción clara de algo desde el dominio del
problema o desde el dominio de la solución. Usualmente puede ser parte del
vocabulario del dominio del problema o del dominio de la solución.
•
La clase tiene un pequeño conjunto de responsabilidades bien definidas y las
lleva a cabo de una buena forma.
•
La clase proporciona una clara separación de la especificación y la
implementación.
•
La clase es fácilmente entendible.
•
La clase es simple.
Cuando se dibuja la clase en UML, es una buena idea seguir los consejos que se dan a
continuación:
•
Limitar la presentación de todas las propiedades de la clase siendo considerada
a niveles aceptables. Se debe mostrar sólo aquellas propiedades de la clase que
son importantes para entender la naturaleza de la abstracción en su contexto.
•
Si se tiene una larga lista de atributos, trate de agruparlos de acuerdo con
alguna categoría.
•
Si cierto conjunto de clases está relacionado, muéstrelos en el mismo diagrama.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
87
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Resumen
Ahora que ha completado esta unidad, usted debe ser capaz de:
•
Describir el modelado estructural del UML en forma básica.
•
Describir clases y sus relaciones.
•
Conocer los mecanismos comunes que pueden ser aplicados a las clases.
•
Elaborar Diagrama de Clases.
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
88
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Examen de Autoevaluación
1) ¿Cuál de las siguientes es una relación simple, que conecta dos clases, denotando
la relación estructural entre ellas?
a) Realización
b) Generalización
c) Agregación
d) Asociación
2) Dentro de una clase, los estereotipos ayudan a agrupar atributos y operaciones.
a) Verdadero
b) Falso
3) Las operaciones y responsabilidades de una clase son las mismas.
a) Verdadero
b) Falso
4) ¿Cuál de los siguientes ayuda a agregar nuevas reglas a aquellas existentes?
a) Estereotipos
b) Notas
c) Restricciones
d) Ninguno de los anteriores
5) En UML, una línea punteada dirigida denota una relación de:
a) Generalización
b) Dependencia
c) Asociación
d) Ninguna de las anteriores
6) En una agregación simple, el tiempo de vida del todo y las partes están enlazadas.
a) Verdadero
b) Falso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
89
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
7) Especifican un rango de valores que los objetos de la clase pueden tomar.
a) Operaciones
b) Atributos
c) Responsabilidades
d) Restricciones
8) ¿Cuáles de las siguientes multiplicidades son correctas?
a) 0..1 para cero o uno
b) 0..* para cero o más
c) 1..* para uno o más
d) 3..5 para el rango 3 , 4 ó 5
9) ¿Una asociación calificada se realiza cuando un objeto de una clase debe valerse
de un atributo en específico para localizar al objeto adecuado?
a) Verdadero
b) Falso
10) Indique cuáles de los siguientes nombres de clases son válidos:
a) DetalleEmpleado::Empleado
b) Empleado
c) Automóvil
d) Biblioteca::DetalleMiembro:: FormularioDeRegistro
Unidad 4: Modelado Estructural Básico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
90
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Respuestas de la Unidad 4: Examen de Autoevaluación
1) d
2) a
3) b
4) c
5) b
6) b
7) b
8) a, b, c y d
9) a
10) a, c y d
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
91
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Volumen 2: Modelado Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Modelado Estructural Básico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin el previo permiso escrito de IBM.
93
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural
Avanzado
Objetivos de Aprendizaje
Al final de esta unidad, usted será capaz de:
•
Describir los tipos de clasificadores.
•
Explicar acerca de las interfaces, roles, tipos y paquetes.
•
Describir instancias y diagramas de objetos.
•
Construir diagramas de objetos.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
95
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. Introducción
En la Unidad 4 – Modelado Estructural Básico del Volumen 1, se explicaron los
conceptos básicos de la orientación a objetos, modelado de ideas y diagramas de clase.
Esta unidad, se ocupa de las características avanzadas del modelado estructural del
UML.
2. Clasificadores
Los clasificadores son bloques de construcción de UML. Son elementos del modelo,
que pueden tener instancias. UML utiliza clasificadores para describir las características
estructurales y de comportamiento del sistema. Las clases son tipos de clasificadores.
Ahora se va a considerar un ejemplo de clases en un sistema. En una aplicación
bancaria, se tienen abstracciones que modelan clientes, planillas de depósitos o
cuentas. Estas abstracciones son la esencia del modelo. Se crean instancias de los
elementos del modelo anterior, que interactúan entre sí para realizar una tarea en
particular. Se sabe que cada una de las instancias de un clasificador, la clase en este
ejemplo, comparte características idénticas. Los atributos de la clase forman las
características estructurales de un clasificador mientras las operaciones de la clase
forman las características de comportamiento.
Los demás clasificadores se muestran a continuación:
•
Interfaz: La interfaz describe los servicios proporcionados por una clase o un
componente.
•
Componente: Los componentes son las partes físicas de un sistema, que son
reemplazables. Ellos se adhieren a la interfaz y proporcionan la realización de un
conjunto de interfaces.
•
Nodo: Un nodo es un elemento físico que predomina en tiempo de ejecución.
Representa un recurso computacional. Los nodos generalmente tienen memoria
y capacidad de procesamiento.
•
Caso de Uso: La cadena de acciones realizadas por un sistema es descrita por
un caso de uso. Los resultados producidos por las acciones son de valor para un
actor particular del sistema.
•
Subsistema: Un subsistema es una agrupación de elementos del modelo.
•
Tipo de datos: Un tipo de dato puede ser primitivo o enumerado.
•
Señal: Una señal significa el estímulo asincrónico comunicado entre instancias.
La única excepción a la regla acerca de los clasificadores que tienen características
estructurales y de comportamiento es la interfaz. Las interfaces podrían no tener
atributos. La Figura 1.1 proporciona las notaciones UML para todos los clasificadores.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
96
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Interfaz
Clase
Empleado
empleadoId
empleadoNombre
setEmployeeName()
setEmployeeID()
...
Componente
Caso de Uso
parser.dll
GenerarPago
Subsistema
Nodo
Servidor
Base de
Datos
<<Subsistema
Manejador de
Datos>>
Subsistema
Administrador de
Transacciones
Tipo de Dato
Señal
<<tipo>>
color
{valores son azul,
verde, amarillo, rojo}
<<estado>
Impresora Encendida
Figura 1.1: Notaciones UML para Clasificadores
3. Elementos Abstractos
Existen en un modelo algunas clases, cuyas instancias no pueden ser creadas. Dichas
clases se denominan clases abstractas. Generalmente, las clases abstractas contienen
una o más operaciones que no son implementadas. Dichas operaciones se dejan
abiertas para que las implementen las clases que heredan de una clase abstracta. Las
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
97
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
operaciones que no son implementadas, pero proporcionan sólo una interfaz, se
denominan operaciones abstractas. Estas operaciones deben ser implementadas en
algún nivel de la jerarquía de herencia. Las operaciones de una clase abstracta pueden
ser de tres tipos. Estos son:
•
Operaciones abstractas: Deben ser implementadas por una subclase o clase
hija.
•
Operaciones de polimorfismo: Estas operaciones pueden ser sobrescritas en
una subclase. El comportamiento de la superclase o clase padre es sobrescrito
en la subclase.
•
Operaciones de hoja: Estas operaciones no son ni abstractas ni polimórficas.
Se implementan en la clase abstracta, que puede ser heredada por la subclase,
dependiendo de su visibilidad. Una operación de hoja es una operación
concreta.
En UML, las clases abstractas y las operaciones abstractas se describen usando letra
cursiva o itálica. Las operaciones de hoja se indican como {leaf}. Las operaciones
desprovistas de adornos son operaciones polimórficas, esto quiere decir que pueden
ser reescritas por las subclases. Una clase que no tiene padre puede ser adornada con
{root}. Una clase que no puede tener más hijos está adornada con {leaf}.
Usuario
{root}
# cedula
Operación
Abstracta
Operación
Polimórfica
incluir()
actualizarDatos()
...
Empleado
{leaf}
Cliente
{leaf}
# id_empleado
# id_cliente
incluir()
retirarEmpleado
actualizarDatos()
...
Incluir()
RetirarCliente()
actualizarDatos()
Figura 1.2: Ejemplo de Elementos Abstractos, Raíz (root), leaf y Polimórficos
La Figura 1.2 muestra una porción del diagrama de clases del caso de estudio anterior
agregándole algunas operaciones, donde se puede notar que la clase Usuario es una
clase abstracta, que también es la raíz y la clase base de la jerarquía de herencia. Las
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
98
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
clases Empleado y Cliente son hijos de la clase abstracta Usuario, las cuales no
pueden tener más hijos. Con respecto a las operaciones se tiene:
•
incluir(): Indicado en cursiva representa una operación abstracta, la cual es
implementada en las clases Empleado y Cliente.
•
actualizarDatos(): Es una operación polimórfica. Las clases hijas pueden
sobrescribirla, tal como lo hacen las clases Empleado y Cliente.
4. Multiplicidad
La multiplicidad se usa para permitir al diseñador especificar el número de objetos que
pueden ser creados para una clase. Generalmente, una clase puede tener cualquier
número de objetos. Pero en ciertas situaciones, se podría querer indicar el número
exacto de objetos para una clase. El número se muestra dentro de la notación de clase
para indicar el número de objetos para una clase.
En el caso de un atributo, como se vio anteriormente, se puede especificar el número de
objetos después del nombre del atributo. Adicionalmente, se puede diseñar una clase
que tenga sólo un objeto. Dichas clases se denominan clases singleton. Un ejemplo de
una clase singleton es cualquier generador o clase monitor, donde sólo se necesita una
instancia que puede ser usada por los demás objetos.
La Figura 1.3 ilustra la multiplicidad.
Empleado
Libro
1..3
100..*
Cliente
1..*
Biblioteca
1
libros[100..*]:Libro
Figura 1.3: Ilustración de Multiplicidad
Para una clase, se especifica la multiplicidad en el extremo derecho contra el nombre de
la clase. Las instancias de atributos se muestran al lado del nombre del atributo dentro
de los corchetes. La Figura 1.3 describe lo siguiente:
•
De una a tres instancias de la clase Empleado
•
100 ó más instancias de la clase Libro
•
Una o más instancias de la clase Cliente
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
99
Análisis y Diseño de Sistemas Orientado a Objetos
•
Guía del Estudiante
Exactamente una instancia de la clase Biblioteca, pero contiene 100 o más
instancias de la clase Libro
5. Clases Plantillas (Template)
Un template o plantilla constituye un elemento parametrizado que permite definir una
familia de clases, las cuales comparten la misma definición.
Por ejemplo, si se define una clase plantilla (template) Pila, el tipo de elemento que
almacena la pila no es conocido al momento de definir la clase template. La clase
template pila entonces representa una familia de clases pilas, tal como, pila de
enteros, pila libro, pila de flotante o pila empleado. El proceso de crear una
clase fuera de una clase template se denomina enlace (binding). El tipo de los
elementos es pasado como un parámetro a la clase template.
Durante el enlace (binding), los elementos formales son asociados a los elementos
reales. La clase, enlazada (bind) fuera de una clase template es una clase concreta y
puede ser subclase.
Es importante destacar que no es posible añadir características a las clases enlazadas,
todas estas deben estar especificadas en la plantilla.
Los templates o plantillas son soportadas en C++ y Ada, por otra parte Java planea
introducirlo en JDK 1.5. La Figura 1.4 ilustra la notación UML para un template y su
correspondiente clase concreta.
Type
Pila
+ push (in elem:Type) : Type
+ pop (inout elem:Type) : Type
+ esVacia () : Boolean
...
<<bind>>
(Libro)
PilaLibro
<<bind>>
(Integer)
PilaInteger
Figura 1.4: Notación UML para un Template y su Correspondiente Clase Concreta
En la Figura 1.4, Pila es una clase template que está representada por el parámetro
dentro de un rectángulo punteado. Ambas operaciones push y pop muestran que los
argumentos que toman son del tipo parametrizado Type. Las clases concretas se
representan como clases normales especificando una relación a la clase template. La
relación no describe una relación de generalización. Junto a la flecha dirigida, se
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
100
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
proporciona el tipo real que está asociado a los formales. El estereotipo <<bind>>
indica la asociación de clases template con las clases concretas.
6. Estereotipos para Clases
Estos estereotipos son una manera de especificar cómo una clase es utilizada en el
diseño. Un estereotipo de clase no es parte del nombre de la clase y no genera código
en la clase. Entre ellos se tienen:
•
Entity: Solo tiene conocimiento sobre sí mismo y sus relaciones inmediatas,
este conocimiento limitado lo hace altamente reutilizable. Una clase entidad
modela la información de larga vida y su comportamiento asociado. Cada clase
con el estereotipo <<entity>> representa un recurso en el mundo real y no un
recurso del software y debe preservar su propia integridad sin importar donde o
cuando se utiliza. Un ejemplo claro se puede observar en el caso de estudio del
club de video. En él, la clase Película puede tener el estereotipo <<entity>>,
debido a que no importa en que tienda de video se utilice, siempre un objeto
instanciado por la clase Película tendrá características en común, tales como
género, título, entre otras. Ver Figura 1.5.
<<entity>>
Pelicula
- id_pelicula
+ alquilarPelicula()
+ comprarPelicula()
...
Figura 1.5: Ejemplo de estereotipo <<entity>>
•
Control: Una clase con un estereotipo del <<control>>, no posee casi
ninguna información sobre sí mismo. Representa un comportamiento, más que
un recurso. Este tipo de clase se refiere más a dirigir el comportamiento de otros
objetos y no tiene casi ningún comportamiento propio. Por ejemplo, en el caso
de estudio de la tienda de video, se podría tener una clase llamada Gestor, la
cual tendría operaciones como alquilar película, reservar película, afiliar cliente,
devolver película y estaría relacionada con clases como Película, Cliente,
Factura. Ver Figura 1.6.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
101
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
<<control>>
Gestor
+ devolverPelicula()
+ afiliarEmpleado()
+ generarFactura()
...
Figura 1.6: Ejemplo de estereotipo <<control>>
Existen 4 formas de representar gráficamente los estereotipos <<entity>> y <<control>>,
las cuales se muestran en la Figura 1.7.
Película
Película
Película
Película
Gestor
Gestor
Gestor
Gestor
Figura 1.7: Ejemplo de estereotipo <<control>>
•
utility: Son aquellas clases cuyas operaciones y atributos tienen ámbito de
clase. Esto es para permitir que los demás objetos del sistema accedan a las
operaciones y atributos directamente con el nombre de la clase, sin crear
instancias de la clase. El principal uso de esta clase utility, es llevar a cabo
funcionalidades comunes a través de un sistema. Por ejemplo, una clase
Calculo, puede proporcionar funciones matemáticas básicas, en cualquier
parte del sistema sin necesidad de crear un objeto para utilizarlas. Ver la Figura
1.8.
<<utility>>
Calculo
+ sumar(): float
+ restar(): float
+ multiplicar(): float
...
Figura 1.8: Ejemplo de Estereotipo <<utility>>
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
102
Guía del Estudiante
•
Análisis y Diseño de Sistemas Orientado a Objetos
Enumeration: Son tipos de datos definidos por el usuario, que definen las
constantes de un sistema. Una clase enumeración define un conjunto de valores
literales, usados generalmente para validación. En la Figura 1.9 se tiene una
clase CategoriaPelicula, la cual define ciertos literales que no pueden ser
cambiados.
<<enumeration>>
CategoriaPelicula
infantil
terror
drama
aventura
Figura 1.9: Ejemplo de Estereotipo <<enumeration>>
7. Relaciones
Se ha comprendido los diferentes tipos de relaciones que permiten los sistemas
orientados a objetos. En esta sección se explican los conceptos avanzados de las tres
relaciones que se aprendieron en la Unidad 2 – Modelado Estructural Básico del
Volumen 1.
7.1 Relación de Dependencia
La relación de dependencia especifica un cambio en el elemento del modelo que afecta
al elemento dependiente del modelo. Aunque las dependencias se pueden crear tal
cual, es decir sin ningún estereotipo, UML permite dar más significado a las
dependencias, es decir concretar más, mediante el uso de estereotipos.
7.1.1
Estereotipos que se Aplican a Relaciones de Dependencia entre clases
Hay cinco estereotipos en esta categoría:
•
Bind: Se usa en enlace del template o plantilla. La fuente enlaza al template
destino junto con los parámetros reales. Se ha visto un ejemplo del estereotipo
bind en la Figura 1.4.
•
Derive: Se usa entre dos atributos o entre dos asociaciones. La fuente se
calcula en base a un valor en el destino. La Figura 1.10 muestra que el atributo
añosEnServicio deriva del atributo fechaDeInicio, que es una instancia de
la clase Fecha. Así añosEnServicio para un empleado puede ser calculado
en base a la fecha actual y la fecha de inicio.
•
Friend: Se usa normalmente para permitir a las demás clases acceder a los
miembros de una clase. Proporciona al clasificador origen visibilidad especial en
los atributos y operaciones del clasificador destino. La Figura 1.10 muestra que
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
103
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
la clase GeneradorPerfilEmpleado es friend de Empleado. Esto permite
a la clase GeneradorPerfilEmpleado ver los atributos y operaciones private
de la clase Empleado.
•
Refine: Se utiliza para indicar que una clase es la misma que otra, pero más
refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
•
Use: Se usa cuando se debe describir una relación semántica entre dos
elementos. La semántica del elemento origen depende de la semántica de la
parte pública del elemento destino. Se aplica cuando se requiere marcar
explícitamente una relación de dependencia.
La Figura 1.10 ilustra un ejemplo de algunos de los estereotipos mencionados
anteriormente.
Empleado
<<derive>>
empleadoID
empleadoNombre
fechaDeInicio:Date
empleadoDireccion
añosEnServicio
...
<<friend>>
GeneradorPerfilEmpleado
empleadoPerfil[1..*]: Perfil
Figura 1.10: Ejemplo de Algunos Estereotipos
Existen otros estereotipos para la relación de dependencia pero están ligados a otros
diagramas por lo cual se explican más adelante.
7.2 Relación de Generalización
La Figura 1.11 muestra cómo la herencia múltiple se representa gráficamente en UML.
GerenteProyecto es un IngenieroSoftwareSenior y un Gerente. Los objetos
de GerenteProyecto heredan atributos y operaciones de estas superclases. La
Figura 1.11 muestra herencias simples y múltiples.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
104
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Empleado
Gerente
GerenteProducción
IngenieroSoftwareSenior
GerenteVentas
PersonalOficina
GerenteProyecto
Figura 1.11: Herencias Simples y Múltiples
7.2.1
Estereotipo para la Relación de Generalización
El estereotipo asociado con la generalización es la implementación. El estereotipo de
implementación se usa cuando se debe modelar herencia privada. C++ soporta
herencia privada. Este estereotipo declara que el hijo hereda el comportamiento del
padre pero no hace público el comportamiento. También declara que no soporta
interfaces padre.
7.2.2
Restricciones en Relaciones de Generalización
Para una relación de generalización, existen cuatro restricciones que son:
•
Complete: Sugiere que el número de hijos requeridos por el modelo debe ser
especificado. No se permiten hijos adicionales.
•
Incomplete: Es lo contrario a la restricción anterior. Se permiten hijos
adicionales. Es útil para mostrar que la especificación completa de la jerarquía
de herencia no se realiza.
•
Disjoint: Especifica que los objetos del padre no pueden contener más de un
hijo como tipo. Esto se aplica en el contexto de herencia múltiple.
•
Overlapping: Permite más de un hijo en tiempo de ejecución. Esto también se
aplica en el contexto de herencia múltiple.
Las últimas dos restricciones se usan para distinguir entre clasificación estática y
dinámica. La restricción disjoint permite clasificación estática, mientras que el
overlapping permite clasificación dinámica. La clasificación dinámica ocurre cuando un
objeto cambia su tipo en tiempo de ejecución. Por defecto, para una generalización
simple las restricciones son {incomplete,disjoint}. En la Figura 1.12 se muestra un
ejemplo de alguna de estas restricciones.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
105
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Usuario
{incomplete, disjoint}
Cliente
Empleado
Figura 1.12: Restricciones de la Relación de Generalización
7.3 Relación de Asociación
Esta relación se usa para mostrar que están conectados dos elementos del modelo. Los
tres adornos para esta relación son: nombre, rol, multiplicidad para cada uno de los
extremos de la asociación.
Ahora se presentarán otras dos propiedades importantes de una relación de asociación:
•
Navegación: Generalmente, una línea sólida entre las dos clases que están en
asociación denota una relación de asociación. También se puede mostrar la
dirección de la asociación colocando una cabeza de flecha en la línea. Se
muestra la dirección de la asociación entre GerenteDeRegistro y
TarjetaDeRegistro en la Figura 1.13. A menos que se especifique una
dirección de la línea, la navegación es bidireccional.
GerenteResgitro
TarjetaRegistro
1..
generarRegistroTarjeta
generarRegistroTarjeta()
crearPlantillaTarjeta()
Figura 1.13: Dirección de la Asociación
•
Visibilidad: Se pueden usar los símbolos asociados con la visibilidad public,
protected y private para mostrar si una clase en una asociación es visible a otras
clases o no. Se usan los símbolos +, # y – fuera del objeto, cerca de la clase que
necesita ser visible. La visibilidad private indica que las clases fuera de la
asociación no pueden tener acceso al objeto al final de la asociación que
describe la visibilidad. La visibilidad protected permite que las clases sean
visibles a los hijos de las clases en el otro extremo. Si no se menciona la
visibilidad, entonces se considera visibilidad public.
La Figura 1.14 muestra la visibilidad protected. Una juega el rol de un solicitante
y la otra el rol de un generador.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
106
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
GerenteRegistro
TarjetaRegistro
# Generador
generarRegistroTarjeta
generarRegistroTarje
ta()
crearPlantillaTarjet
Solicitante
Figura 1.14: Visibilidad Protected
7.3.1
Restricciones en Relaciones de Asociación
Son limitaciones hechas en un elemento del modelo que permiten asegurar su
integridad a lo largo de la vida del sistema. Para una relación de asociación existen
restricciones tales como:
•
Ordenación (Ordered): Indica que el conjunto de objetos asociados, representa
un conjunto ordenado, siguiendo una secuencia. Por ejemplo, en el club de
video un empleado atiende a un cliente, pero cada cliente debe ser atendido en
el orden que llegan, esto permite que el empleado atienda los requerimientos del
cliente en turno. Observe el ejemplo en la Figura 1.15.
atiende
Empleado
Cliente
{ordered}
Figura 1.15: Restricción Ordered
•
OR Exclusivo (Exclusive OR): Esto permite que las instancias de una clase
deben participar en una sola a la vez. Por ejemplo en una asociación entre una
clase Administrador de eventos y una clase eventos, el administrador de eventos
podría realizar una auditoria a un evento o también podría realizar supervisiones
al evento, pero no los dos roles al mismo tiempo. Observe la Figura 1.16.
Supervisa
Evento
AdministradorEvento
{xor}
Audita
Figura 1.16: Restricción XOR
•
Subconjunto (subset): Indica que una colección esta incluida en otra colección.
Por ejemplo en una escuela en la mayoría de los casos los representantes de
los alumnos también son sus padres.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
107
Análisis y Diseño de Sistemas Orientado a Objetos
7.3.2
Guía del Estudiante
Asociación Reflexiva
Es una clase que tiene una asociación con ella misma. Esto ocurre cuando una clase
tiene objetos que juegan diferentes roles. En importante que los roles estén bien
definidos para que se entienda con claridad la relación. Por ejemplo, en la Figura 1.17,
la clase Persona muestra la relación que existe entre padres y sus hijos, una o
muchas personas tienen cero o dos padres y entre cero y muchos hijos.
Persona
Padres
0..2
Hijos
*
Figura 1.17: Asociación Reflexiva
8. Interfaces y Realización
Una interfaz es el conjunto de operaciones que una clase o un componente especifica
como su servicio. Se pueden tener interfaces subsistemas. El nombre de la interfaz
puede ser un nombre simple o un nombre de ruta, además es importante resaltar que
las interfaces no tienen atributos solo operaciones que serán implementadas por una o
varias clases.
UML representa las interfaces de dos maneras, como una clase con el estereotipo
<<interface>> o utilizando círculos pequeños conectados con una línea con el elemento
que provee los servicios descritos por la interfaz. Observe un ejemplo de interface en la
Figura 1.18.
<<inteface>>
IFigureAgent
interfaz
Clase
dibujar()
mover()
redimensionar()
...
Figura 1.18: Formas de Representar una Interfaz
En UML, se puede proporcionar más información a una interfaz para hacerla fácilmente
comprensible.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
108
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
Se pueden adjuntar precondiciones o post condiciones para cada operación. Las
precondiciones son aquellas que deben ser satisfechas cuando la operación es
invocada. Las post condiciones son las que deben ser satisfechas al final de la
operación.
•
Las Interfaces pueden estar asociadas con máquinas de estado.
•
Las colaboraciones pueden ser adjuntadas a una interfaz.
8.1 Realización
Esta es una relación semántica entre dos clasificadores. La notación utilizada es una
línea punteada con una punta de flecha en forma de triángulo sin rellenar apuntando
hacia el clasificador que especifica el contrato.
La relación de realización tiene algunos ingredientes de relaciones de dependencia y
generalización, además se usa en el contexto de interfaces y colaboraciones.
Semánticamente, es correcto decir “una clase o un componente es la realización de una
interfaz”. Las clases implementan interfaces y de aquí el término realización es usado
en lugar de generalización. En el caso de generalización, se enfatiza una relación
padre/hijo. No hay tal relación enfatizada en una relación de realización. También es
muy usual ver realizaciones en casos de uso, las cuales son llamadas colaboraciones.
La Figura 1.18a muestra un ejemplo de una relación de realización.
Las Figuras 1.19a y 1.19b representan la realización de una interfaz por una clase. En
la Figura 1.18a, la interfaz revela algunas de las operaciones. Por tanto, se describe la
interfaz usando la estructura de clase con el estereotipo <<interface>> en una línea
anterior el nombre de la interfaz. En la segunda Figura 1.19b, se usa el ícono de interfaz
y se observa que la clase ObjetoDocumento es la realización de la interfaz
IAgenteFigura.
La Figura 1.19c representa la realización de un caso de uso a través de una
colaboración.
Las formas usadas para la realización de las Figuras 1.19a y 1.19c se denominan
formas canónicas y la usada en la Figura 1.19b se refiere a la forma abreviada (elided
form).
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
109
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
<<inteface>>
IAgenteFigura
dibujar()
mover()
redimensionar()
...
ObjetoDocumento
Figura 1.19a: Interfaz Usando la Estructura de Clase con el Estereotipo <<interface>>
ObjetoDocumento
IAgenteFigura
Figura 1.19b: Realización de la Clase ObjetoDocumento desde la interfaz IAgenteFigura
GenerarReporte
Generación
Figura 1.19c: Realización de Colaboración de un Caso de Uso
9. Roles
Una clase puede llevar a cabo más de una interfaz. Una instancia de la clase soporta el
contrato especificado en todas las interfases que sus clases se han comprometido. Pero
en un determinado contexto o escenario, la instancia podría revelar sólo algunas de las
interfaces. En ese caso, la interfaz representa un rol que juega el objeto. Un rol es una
forma por la cual una abstracción se presenta al mundo.
La Figura 1.20 muestra cómo se describen los roles para una interfaz. El
ObjetoDocumento tiene dos interfaces, IFigureAgent y IDocumentoAgent. En el
contexto dado de la participación del ObjetoDocumento con un EditorTexto, el rol
de la interfaz está siendo descrito en el terminal del ObjetoDocumento. El rol de la
interfaz está en la forma de un Documento.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
110
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Figura
IFigureAgent
ObjetoDocumento
Documento
IDocumentoAgent
Figura 1.20: Descripción de Roles para una Interfaz
10. Paquetes
Un paquete es un mecanismo para agrupar elementos. Los paquetes organizan
modelos de la misma manera que los directorios organizan y almacenan archivos. Cada
paquete tiene un nombre, que es un nombre simple o un nombre de ruta. Los nombres
de ruta tienen otros nombres de paquete en los que el paquete especificado está
encapsulado. Los paquetes, como las clases pueden ser adornados con valores
etiquetados o tener compartimientos adicionales para exponer otros detalles. La Figura
1.21 muestra dos paquetes, uno con un nombre simple y otro con un nombre de ruta.
Uno tiene valores etiquetados indicando el autor. ENomina es el paquete que encierra
a Nomina.
Nómina
ENomina:: Nómina
{author:jerry}
Figura 1.21: Paquetes con un Nombre Simple y un Nombre de Ruta
También se puede revelar las clases o componentes dentro del paquete, junto con su
visibilidad. Esto se puede hacer de dos formas:
•
Anidamiento textual.
•
Anidamiento gráfico.
La Figura 1.22 ilustra esto. Las clases mostradas dentro del paquete son elementos que
son apropiados por el paquete. GeneradorNomina y GeneradorPago son clases
públicas, mientras que ConectorBaseDatos es una clase privada. Esta clase puede
ser usada por todas las clases dentro de este paquete, pero no por uno fuera del
paquete Nomina.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
111
Análisis y Diseño de Sistemas Orientado a Objetos
Nómina
+GeneradorNómina
+GeneradorPago
-ConectorBaseDatos
Guía del Estudiante
Nómina
+GeneradorNómina
+ GeneradorPago
- ConectorBaseDatos
Anidamiento Textual
Anidamiento Gráfico
Figura 1.22: Anidamiento Textual y Anidamiento Gráfico
10.1
Estereotipos de Paquetes
UML proporciona cuatro estereotipos para paquetes:
•
Facade: Esto permite especificar que un paquete es una vista a algún otro
paquete.
•
Framework: Se usa cuando un paquete principalmente sólo contiene patrones.
•
Sub-system: Este estereotipo se usa para mostrar que un paquete puede
representar un modelo independiente de un sistema.
•
System: Se usa para mostrar que un sólo paquete representa el sistema
completo.
La Figura 1.23, muestra como se representa gráficamente los estereotipos de paquetes.
<<System>>
TiendaVideo
<<System>>
TiendaVideo
Figura 1.23: Anidamiento textual y Anidamiento Gráfico
10.2
Relación de Dependencia con Paquetes
Existen estereotipos que permiten clarificar la dependencia entre paquetes, entre ellos
se tienen:
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
112
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
Import: Una clase contenida dentro de un paquete puede también aparecer en
otro paquete en la forma de un elemento importado, por medio de una relación
de dependencia entre paquetes. Es necesario resaltar que no todas las clases
dentro de un paquete son visibles por otros paquetes. La dependencia de
importación se utiliza para agregar nombres al espacio de nombres del paquete
del cliente como sinónimos de los caminos completos.
•
Access: La dependencia de acceso indica que el contenido del paquete del
proveedor puede aparecer en referencias efectuadas por los elementos del
paquete cliente. Este estereotipo no crea las referencias automáticamente,
simplemente concede permiso para establecer referencias.
La Figura 1.24 muestra un ejemplo de esta relación y estereotipos.
A
B
<<import>>
<<access>>
C
Figura 1.24: Ejemplo de estereotipos con relación de dependencia
En la Figura 1.24, el paquete A agrega el contenido público del paquete B al espacio de
nombres del paquete A. El paquete B puede ver todo el contenido público del paquete
C, sin añadirlo a su espacio de nombre, por lo cual para hacer una referencia a un
elemento público del paquete C, se necesita colocar todo el nombre de ruta.
10.3
Herencia entre Paquetes
Los paquetes pueden heredar de un paquete existente. Ellos siguen los mismos
principios que las clases.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
113
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
GUI
+ Ventana
+
WebGUI
+ Marco
+ GUI:Ventana
ApliGUI
+ Marco
+ GUI:Ventana
Figura 1.25: Ejemplo de Generalización de Paquetes
11. Instancias
Las clases son abstracciones del mundo real. Los objetos son instancias de una clase.
Una instancia es la manifestación concreta de una abstracción. En un sistema orientado
a objetos, las instancias forman el núcleo del sistema. Las interacciones se llevan a
cabo entre las instancias. En UML, una instancia es descrita justo como una clase, con
el nombre subrayado.
11.1
Nombres de Instancia
Cada objeto tiene un nombre. Puede ser uno de los siguientes:
•
Instancia nombrada: Una instancia proporciona explícitamente un nombre. En
algunos casos, se puede especificar el nombre de la instancia y en otros el
nombre de la instancia junto con el nombre de clase.
•
Instancia anónima: No hay un nombre explícito para un objeto. Sólo se da el
nombre de la clase o paquete junto con el nombre de la clase.
•
Instancia huérfana: Una instancia huérfana es aquella cuya abstracción no es
conocida. Es útil en situaciones en que los objetos se cargan dinámicamente en
memoria. Al momento del diseño, la abstracción podría no ser conocida. Si
después se descubre la abstracción a la que corresponde esta instancia, se le
puede cambiar a una instancia nombrada.
También se puede mostrar una colección de objetos llamados multiobjetos.
La Figura 1.26 muestra ejemplos de las instancias nombradas y anónimas.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
114
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
esteEmpleado
Instancia nombrada, sin especificar el
nombre de la clase
esteEmpleado: Empleado
Instancia nombrada con el nombre de
clase dado
Instancia sin nombrar, sólo nombre de clase
dado
:Empleado
:EmpleadoData ::Empleado
Instancia sin nombre pero, tanto el paquete
como la clase son especificados
Multiobjeto, colección de objetos
anónimos
:Empleado
Figura 1.26: Ejemplos de Instancias Nombradas y Anónimas
11.2
Operaciones de Instancias
El objeto puede trabajar con todas las operaciones definidas como parte de su clase. Si
el objeto es parte de una jerarquía de herencias, la operación puede o no ser invocada
como una operación polimórfica.
11.3
Estado de un Objeto
Cada objeto tiene un estado. El estado de un objeto es una de las posibles condiciones
bajo las que el objeto puede existir. El estado de un objeto cambia con el tiempo y está
definido por un conjunto de propiedades (atributos), por los valores de esas propiedades
y por las relaciones que dicho objeto puede tener con otros objetos.
Por ejemplo, el estado del objeto esteEmpleado de la clase Empleado incluye la
propiedad estática empleadoNombre y el valor actual jerry. Usando la notación UML,
se pueden especificar los atributos y sus valores.
11.4
Objetos Activos
Los objetos activos son aquellos que tienen su propio flujo de control. Los hilos y
procesos son ejemplos de objetos activos. Un objeto activo está descrito en la misma
forma en que está un objeto, pero con el contorno del rectángulo oscuro.
La Figura 1.27 muestra los atributos de un objeto y los objetos activos.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
115
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
esteEmpleado
empleadoNombre="Scooby"
empleadoEdad=28
Instancia con valores de atributo
Instancia con un estado explícito
esteEmpleado
[En Prueba]
Objeto activo
t : EmpleadoHilo
Figura 1.27: Los Atributos de un Objeto y los Objetos Activos
11.4.1 Estereotipos de Objetos
Una instancia estereotipo se puede ilustrar en UML usando el estereotipo
<<exception>>. Cabe destacar que no hay estereotipos de objetos específicos.
Los estereotipos que aparecen en los objetos son los mismos que aparecen en las
clases. Ver Figura 1.28.
<<exception>>
Instancia estereotipada
e: Empleado
Figura 1.28: Instancia Estereotipo
Existen otros estereotipos que pueden ser usados con instancias pero junto con una
relación de dependencia. Entre ellos se tienen:
•
instanceOf: Este estereotipo se usa para especificar las instancias de un
clasificador. El objeto origen es una instancia del clasificador destino. Se usa
cuando en un diagrama de clases, se necesita mostrar la relación entre una
clase y un objeto.
•
Instantiate: Este estereotipo establece que la fuente crea instancias del destino.
11.4.2 Restricciones
Las instancias sólo tienen una restricción, referida como transient. Una restricción
transient especifica que la instancia debe ser creada durante la ejecución de una
interacción cerrada. Dichos objetos son destruidos después de que la ejecución se
completa.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
116
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
12. Diagramas de Objetos
Un diagrama de objeto ilustra un conjunto de objetos y sus relaciones para un contexto
o escenario dado. Contiene objetos y enlaces. Un enlace es una conexión semántica
entre objetos. También es una instancia de una asociación. Un enlace se muestra como
una línea. Generalmente, un diagrama de objeto es una instancia de un diagrama de
clases para un contexto dado.
La Figura 1.29 muestra un ejemplo de un diagrama de objetos extraído del diagrama de
clases de la tienda de video.
:usuario
miCliente: Cliente
miEmpleado: Empleado
realiza
opera con
opera con
miPago:Pagos
realiza
mipelicula: Pelicula
mireservacion: Reservacion
Figura 1.29: Ejemplo de un Diagrama de Objetos
El correspondiente diagrama de clases para el diagrama de objetos anterior representa
una relación de generalización entre Usuario/Cliente y Usuario/Empleado.
También muestra una relación de asociación entre Cliente/Pagos,
Cliente/Reservación, Cliente/Pelicula y Empleado/Pelicula.
13. Caso de Estudio
La Figura 1.30 muestra las reglas con respecto a los clientes y las reservaciones de la
tienda de video, también como la relación y la multiplicidad que existen entre ellos. Un
cliente puede tener cero o más reservaciones y cada reservación es realizada
únicamente por un cliente específico.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
117
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
El diagrama de clase define los atributos que deben ser usados para definir cada tipo de
objeto y el comportamiento que cada tipo de objeto debe soportar.
<<entity>>
Cliente
<<entity>>
Reservacion
Id_reservacion
Id_cliente
1
Fecha_afiliación
realiza
0..*
Fecha_reservacion
nombre
InscribirCliente()
RetirarCliente()
realizarReservacion()
eliminarReservacion()
Figura 1.30: Ejemplo de un Diagrama de Clases
El diagrama de objeto de la Figura 1.31, muestra que el objeto manuel de tipo Cliente
ha realizado dos reservaciones. Note que los objetos no tienen los compartimientos de
las operaciones, que son necesarias para las clases. Los objetos definen los atributos
debido a que cada objeto posee diferentes valores de atributos definidos por la clase,
pero no contiene operaciones porque ellas no tienen múltiples interpretaciones o
valores. Esto quiere decir, que todos los objetos derivados de la misma clase contienen
las mismas operaciones.
Es importante destacar que aunque todos los atributos de los objetos de la Figura 1.31
tienen valores, no necesariamente es una regla, también los atributos pueden estar en
blanco o pueden ser nulos, todo depende de la definición del atributo en la clase.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
118
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
<<entity>>
R001M: Reservacion
<<entity>>
Manuel: Cliente
id_reservacion=R001M
Fecha_reservacion=26/07/20
05
nombre= Manuel
id_cliente=001
Fecha_afiliacion=26/07/2
005
<<entity>>
R002M: Reservacion
id_reservacion=R002M
Fecha_reservacion=27/07/20
05
Figura 1.31: Ejemplo de un Diagrama de Objetos
14. Algunas Recomendaciones
En el contexto del modelado de relaciones, se pueden considerar las siguientes pautas:
•
Restringir el uso de dependencias sólo a aquellas relaciones que no son
estructurales.
•
Hacer uso de la relación de generalización sólo si se encuentra una relación ‘es
un’ (herencia).
•
Evitar herencias múltiples. Usar agregación en su lugar.
•
El árbol de herencia no debe ser demasiado profundo (es buena idea tener
menos de 5 niveles).
•
El árbol de herencia no debe ser demasiado ancho.
•
Si se tiene un árbol de herencia demasiado ancho, buscar la posibilidad de
identificar clases abstractas.
•
Las asociaciones deben ser usadas sólo donde hay relaciones estructurales
entre objetos.
•
Mantener un diagrama UML simple. Esto permitirá no tener demasiadas líneas
que crucen y lo hagan difícil de leer y comprender.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
119
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Resumen
Ahora que ha completado esta unidad, debe ser capaz de:
•
Describir los tipos de clasificadores.
•
Explicar las interfaces, roles, tipos y paquetes.
•
Describir instancias y diagramas de objetos.
•
Construir diagramas de objetos.
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
120
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Examen de Autoevaluación
1) ¿Cuál de las siguientes declaraciones es falsa?
a) Un clasificador es un bloque de construcción general de UML.
b) Los clasificadores son aquellos que pueden tener instancias.
c) Un clasificador es otro nombre para una clase.
d) Los clasificadores tienen características estructurales y de comportamiento.
2) El ámbito de clase para las operaciones declara que las operaciones pueden ser
invocadas usando sólo el nombre de la clase.
a) Verdadero
b) Falso
3) Algunos de los estereotipos de clases son, seleccione los correctos.
a) Facade
b) Utility
c) Control
d) Bind
4) ¿Cuál de los siguientes son restricciones para una asociación?
a) Complete
b) Ordered
c) Disjoint
d) Or exclusive
5) ¿Cuáles de las siguientes pueden ser operaciones de una clase abstracta?
a) Una operación abstracta.
b) Una operación de hoja.
c) Una operación de polimorfismo.
d) Ninguna de las anteriores.
6) La multiplicidad no puede ser mostrada para los atributos de una clase.
a) Verdadero
b) Falso
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
121
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
7) ¿Cuál de los siguientes utiliza el estereotipo <<bind>> ?
a) Clases
b) Clases abstractas
c) Clases template
d) Súper clases
8) ¿Cuál de los siguientes utiliza un estereotipo import?
a) Objetos
b) Interfaces
c) Clases
d) Paquetes
9) La realización de los casos de uso no puede ser vista como colaboraciones.
a) Verdadero
b) Falso
10) Los diagramas de objetos son instancias de los diagramas de clases para un
contexto dado.
a) Verdadero
b) Falso
Unidad 1: Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
122
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Respuestas de la Unidad 1: Examen de Autoevaluación
1) c
2) a
3) b y c
4) b, d
5) a, b y c
6) b
7) c
8) d
9) b
10) a
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 1: Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
123
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Laboratorio de Modelado
Estructural Avanzado
Objetivos de Aprendizaje
Al final de esta unidad, debería estar en capacidad de:
•
Identificar las clases de un determinado documento de requerimientos.
•
Dibujar diagramas de clase.
•
Dibujar diagramas de objeto para diferentes escenarios.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Laboratorio de Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
125
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Ejercicio de Laboratorio
Se describe un sistema ATM para un e-Bank (Banco electrónico).
El e-Bank lanzó sus operaciones en Venezuela, con su casa matriz en Caracas, en
2002. Dentro de un periodo corto de tres años, construyó una red de 275 sucursales por
toda Venezuela. Quizás deba su éxito al excelente servicio al cliente y a la banca por
Internet para clientes individuales y corporativos. Aunque tiene un sistema ATM
existente en todas sus sucursales, el banco desea diseñar e implementar un nuevo
sistema ATM basado en las últimas tecnologías. La necesidad es tener un sistema de
software orientado a objetos para el ATM, que resulte en una estructura sencilla con
componentes reutilizables que sean fáciles de extender y mantener.
A continuación se presenta la descripción de los requerimientos claves del sistema ATM
para el e-Bank:
•
Existen dos tipos principales de clientes del banco: Individuales y corporativos.
•
Uno de los requerimientos importantes del sistema es permitir al cliente
depositar una cantidad y/o retirar una cantidad de una cuenta en los centros
ATM. Los centros ATM tienen un quiosco con capacidades de pantalla de
contacto.
•
El cliente debe tener la capacidad de revisar cada transacción realizada contra
una cuenta. Algunas de las transacciones registradas incluyen lo siguiente:
- Fecha.
- Hora.
- Tipo de transacción (o tipo de transacción).
- Cantidad.
- Balance de Cuenta.
•
Un cliente individual puede operar tres tipos de cuentas:
- Una cuenta de ahorros.
- Una cuenta de depósito fijo.
- Una cuenta de depósito recurrente.
•
Un cliente corporativo sólo puede operar un tipo de cuenta, llamada cuenta
corriente.
•
Los clientes pueden acceder a sus cuentas en el ATM insertando una tarjeta
ATM, dicha tarjeta es proporcionada al cliente junto con un código (PIN) que
tendrá que ser insertado después que se inserta la tarjeta. El código (PIN) está
compuesto de 4 dígitos decimales del 0 al 9.
•
Se supone que una sola tarjeta ATM proporciona acceso a todas las cuentas del
cliente.
•
Un cliente puede hacer depósitos en cualquiera de los tipos de cuenta.
Unidad 2: Laboratorio de Modelado Estructural Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
126
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
El retiro de dinero es permitido en la cuenta de ahorros sólo si existe un balance
positivo.
•
El retiro de efectivo directamente desde la cuenta de depósito fijo o la de
depósito recurrente no está permitido.
•
El retiro de efectivo desde la cuenta corriente está permitido incluso si no existe
un balance positivo.
•
La magnitud de sobregiro permitido se fija al momento de abrir la cuenta
corriente y puede ser modificado sólo por las autoridades del banco y no a
través del ATM.
•
Mientras el retiro no está permitido directamente desde la cuenta de depósito fijo
o recurrente, se puede transferir una cantidad de dinero desde estas cuentas
hacia una cuenta de ahorros. Sin embargo, dichas transferencias implican un
pago por transacción del 7% y las cantidades transferidas no pueden exceder
del 75% que se tiene en la cuenta origen.
Se requiere realizar las siguientes tareas:
1) Identificar los paquetes en los cuales serán ubicadas las clases identificadas en el
volumen anterior. Mostrar la visibilidad apropiada.
2) Mostrar una realización de interfaz.
3) Dibujar el diagrama de objetos para cualquier instancia del diagrama de clases.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 2: Laboratorio de Modelado Estructural Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
127
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
Objetivos de Aprendizaje
Al final de esta unidad, debería estar en capacidad de:
•
Definir colaboraciones.
•
Definir interacciones.
•
Elaborar Diagramas de secuencias.
•
Elaborar Diagramas de colaboración.
•
Describir pasos para realizar diagramas de colaboración.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
129
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. Introducción
La vista de interacción describe secuencias de intercambios de mensajes entre los roles
que implementan el comportamiento de un sistema.
Esta visión proporciona una vista integral del comportamiento del sistema, es decir,
muestra el flujo de control a través de muchos objetos. La vista de interacción se exhibe
en dos diagramas centrados en distintos aspectos pero complementarios: centrados en
los objetos individuales y centrados en objetos cooperantes. A continuación se explican
2 conceptos importantes para entender estos diagramas.
2. Interacción
Es el conjunto de mensajes intercambiados por los roles del clasificador a través de los
roles de asociación. Un mensaje es una comunicación unidireccional entre dos objetos,
un flujo de objeto con la información de un remitente a un receptor. Un mensaje puede
tener parámetros que transporten valores entre objetos. Un mensaje puede ser una
señal (comunicación explícita entre objetos, con nombre y asíncrona) o una llamada (la
invocación síncrona de una operación con un mecanismo para el control, que retorna
posteriormente al remitente).
3. Colaboración
Es una descripción de una colección de objetos que interactúan para implementar un
cierto comportamiento dentro de un contexto. Describe una sociedad de objetos
cooperantes unidos para realizar un cierto propósito. Una colaboración contiene ranuras
que son rellenadas por los objetos y enlaces en tiempo de ejecución. Una ranura de
colaboración se llama Rol porque describe el propósito de un objeto o un enlace dentro
de la colaboración. Conociendo estos conceptos, se puede aprender sobre estos
diagramas.
4. Diagramas de Interacción
Los diagramas de interacción describen el modo en que grupos de objetos colaboran
para realizar un trabajo. Ellos capturan el comportamiento de un solo caso de uso,
mostrando el patrón de interacción entre los objetos. Por lo tanto, un diagrama de
interacción consiste de:
•
Conjunto de objetos.
•
Relaciones o enlaces entre objetos.
•
Mensajes entre objetos.
Existen dos tipos de diagramas de interacción. Éstos son:
•
Diagramas de Secuencia: Describen el comportamiento del sistema
enfatizando el orden ó secuencia en el tiempo de los mensajes. El orden ó
Unidad 3: Modelado de interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
130
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
secuencia en el tiempo se representa gráficamente como una tabla, donde los
objetos se disponen en lo alto del eje X, y los mensajes en orden de acuerdo al
tiempo, a lo largo del eje Y.
•
Diagramas de Colaboración: Representan colaboraciones que enfatizan la
organización estructural de los objetos que pasan mensajes entre ellos mismos.
La notación para un diagrama de colaboración es un conjunto de arcos y
vértices.
Ambos diagramas consisten típicamente de objetos, enlaces y mensajes. Los
diagramas de secuencia describen el tiempo de vida de un objeto y el enfoque de
control. Los diagramas de colaboración incluyen una ruta y diversos números de
secuencia. Estas dos características subrayan la diferencia entre estos diagramas.
Los diagramas de secuencia y colaboración son como dos caras de la misma moneda.
De hecho son considerados semánticamente equivalentes, esto significa que
representan la misma información, dado que son creados a partir del mismo conjunto de
datos. Así un diagrama puede ser convertido en otro y viceversa. No se perderán datos
durante el proceso de conversión. Sin embargo, de modo explícito, dan a conocer
diferentes vistas del mismo sistema.
Los diagramas de secuencia tienen varias características importantes que son
necesarias para este modelado, las cuales se denotan a continuación.
4.1 Diagrama de Secuencia
Todo el comportamiento en el sistema orientado a objeto es realizado por los objetos,
no por las clases.
Los objetos trabajan juntos para realizar tareas comunicándose el uno con el otro. El
examinar cómo los objetos trabajan bajo circunstancias específicas, revela la naturaleza
exacta de la comunicación. Por lo tanto, los diagramas de secuencia modelan al nivel
de objetos más que al nivel de clases. El diagrama de secuencia utiliza dos elementos
fundamentales los cuales se muestran a continuación.
4.1.1 Línea de Vida del Objeto
La notación de la línea de vida de un objeto es una combinación de un objeto con una
línea de tiempo, la cual es una línea discontinua que sale de la base del objeto. El largo
de dicha línea representa el tiempo que el objeto interactúa en el escenario.
El tope del diagrama es la localización por defecto de los objetos en un diagrama de
secuencia, si los objetos están en el tope del diagrama significa que el objeto existe con
anterioridad en el escenario, pero si el objeto es dibujado niveles más abajo, esto
significa que el objeto es creado durante el escenario. En la Figura 3.1 se muestra un
ejemplo de líneas de vida de un objeto.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
131
Análisis y Diseño de Sistemas Orientado a Objetos
:Cliente
:Cliente
:Reservación
Guía del Estudiante
:Empleado
Figura 3.1: Tres Objetos con Líneas de Vida
4.1.2 Mensajes
Un mensaje es la definición para la comunicación entre objetos, estos mensajes pueden
invocar una operación, enviar una señal, causar una creación o destrucción de un
objeto. Los mensajes se representan con una flecha, pero según el tipo de mensaje el
tipo de flecha puede cambiar. La cola de la flecha representa al remitente del mensaje y
la cabeza representa el receptor del mensaje. En la Figura 3.2 se muestra un ejemplo
de envío de mensajes simple con objetos.
Figura 3.2: Mensajes en Diagramas de Secuencia
El diagrama de secuencia de la Figura 3.2 describe los mensajes en orden creciente del
tiempo.
Por
lo
tanto,
el
mensaje
que
invoca
al
método
cunsultar_Pelicula(id_pelicula) es invocado mucho antes que el mensaje
obtenerPelicula(). También puede observarse en la Figura 3.2 que el objeto de la
clase ConectorBaseDato es creado en el ámbito del diagrama de secuencia, este tipo
de objeto se denomina objeto transitorio (transient objects), son denotados por la
restricción {transient}. Dicho objeto luego de ser utilizado se destruye. La barra
vertical muestra el enfoque de control. Es el período de tiempo durante el cual un objeto
está realizando una acción. También es importante nombrar que las flechas punteadas
Unidad 3: Modelado de interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
132
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
que aparecen en la Figura 3.2, las cuales representan las respuestas de los mensajes
enviados.
Existen diferentes tipos de mensajes entre ellos se tienen:
•
Simples: Es la transferencia de control de un objeto a otro. Los mensajes
enviados en la Figura 3.2 son mensajes simples y las flechas punteadas
representan el retorno o la respuesta.
•
Síncronos: El objeto remitente pasa un mensaje y espera a que el receptor
acepte la llamada. El receptor despacha la operación y envía un valor de retorno
al remitente. Observe la Figura 3.3.
Figura 3.3: Mensajes Síncronos en Diagramas de Secuencia
•
Asíncronos: El objeto remitente envía una señal y continúa con sus tareas
independientes. El receptor recibe la señal, la procesa y luego de la finalización de la tarea, continúa con sus tareas independientes. El remitente no espera a
que el receptor complete la tarea. Los dos objetos no están sincronizados en
este tipo de comunicación. La Figura 3.4 ilustra el paso asíncrono de mensajes.
Figura 3.4: Mensajes Asincrónico en Diagramas de Secuencia
•
Reflexivos: En los mensajes reflexivos, el remitente y el receptor son el mismo
objeto. Por ejemplo, en la Figura 3.2 el objeto de la clase Película luego de
recibir la lista de películas, envía un mensaje invocando al método
llenarPelicula(). Este último, se encarga de crear la lista en el objeto para luego
seleccionar a través del Id, la película requerida por el objeto de la clase Cliente.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
133
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
4.1.3 Comentarios
En algunos casos es importante proporcionar alguna explicación sobre lo que sucede
en el diagrama o en los elementos dentro del diagrama. Para realizar esto la
especificación UML se vale del mecanismo común como las notas. Estas notas pueden
ser colocadas en cualquier parte del diagrama o pueden ser unidas a los elementos por
medio de una línea punteada. Como se muestra en la Figura 3.5.
Figura 3.5: Comentarios en Diagramas de Secuencia
4.1.4 Iteración
Una iteración significa que uno o más mensajes son ejecutados en secuencia más de
una vez. La iteración se denota usando un asterisco (*) y una condición para controlar el
número de iteraciones. Por ejemplo, un caso de uso adicional para la tienda de video es
Consultar Inventario, el cual tiene como una de sus responsabilidades mostrar por
pantalla las películas en existencia según sus géneros entre otras cosas. El diagrama
de secuencia para este caso de uso utilizaría una iteración para recuperar de la base de
datos las películas según un filtro de búsqueda. Observe este ejemplo en la Figura 3.6.
Figura 3.6: Iteraciones en Diagrama de Secuencia
Unidad 3: Modelado de interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
134
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
4.2 Diagramas de Colaboración
Los diagramas de colaboración brindan una orientación visual acerca del flujo, en el
contexto de la organización estructural de objetos que interactúan unos con otros. Dado
que no existe un ordenamiento en el tiempo de los mensajes, se proporciona a los
mensajes un número de secuencia y así se mantiene una correspondencia uno a uno
entre los dos diagramas. La ventaja de un diagrama de colaboración es que puede
ayudar a validar las asociaciones entre las clases o a descubrir nuevas.
La Figura 3.7 ilustra un diagrama de colaboración.
Figura 3.7: Diagrama de colaboración
La Figura 3.7 muestra otra vista de lo que fue presentado en el diagrama de secuencia
de la Figura 3.2.
4.3 Iteraciones en Diagramas de Colaboración
Normalmente, los diagramas de colaboración se usan para modelar el flujo secuencial.
Sin embargo, se pueden modelar flujos más complejos que involucren iteración y
bifurcación.
En el caso de la iteración, el número de secuencia tiene como prefijo la expresión de
iteración [m: = 1 to 100], o simplemente *, para indicar que el mensaje es llamado
varias veces.
En el caso de la bifurcación, una condición como [a > b] es puesta como prefijo al
número de secuencia. Las rutas de la rama llevan el mismo número de secuencia pero
la condición asociada a ellas no debe solaparse. UML no formula estándar alguno para
las expresiones usadas en ambos casos. Puede ser usado cualquier seudo código
acordado.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
135
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
La Figura 3.8 ilustra la iteración y bifurcación en diagramas de colaboración. Dado que
el número de secuencia aparece dos veces, aunque se sabe que existe una rama en
esa etapa. El objeto :GerenteRegistro invoca a graduaEstudiante() 400 veces,
lo cual se indica como una iteración.
GerenteRegistro
[id:=1 to 499]
1: graduaEstudiante()
Graduador
3: estudianteNoGraduado()
2: modificaEstadoEstudiante()
[no aprobado]
[aprobado]
ManejadorExepcion
ConectorBaseDato
Figura 3.8: Iteración y Bifurcación en Diagrama de Colaboración
5. Manejar Tiempo y Espacio
El tiempo y espacio se modelan típicamente para sistemas de tiempo real y distribuido.
Un sistema en tiempo real requiere que las operaciones se lleven a cabo en un tiempo
preciso. La operación puede tener que terminar dentro de un tiempo estipulado. Algunos
ejemplos de sistemas en tiempo real son Controlador de Vuelos, Monitor de
Salud y Controlador de Cruceros.
Un sistema distribuido es aquél en donde los componentes se distribuyen a lo largo de
diferentes nodos. Los nodos pueden ser diferentes computadoras ubicadas físicamente
aparte unas de otras, o pueden estar en la misma computadora usando diferentes
procesadores.
La especificación del tiempo es importante para sistemas en tiempo real y la ubicación
para sistemas distribuidos.
Los términos asociados al tiempo y espacio son:
•
Marca de Tiempo: Es el tiempo en el que registra la ocurrencia de un evento.
Un ejemplo es s : obtenerEstudiantes(), donde s es la marca de tiempo. Es decir,
obtenerEstudiante() ocurrió en el instante s.
Unidad 3: Modelado de interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
136
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
Restricción de Tiempo: Se refiere a un valor absoluto o relativo del tiempo, que
se debe cumplir. En UML, la restricción de tiempo se denota por una cadena
encerrada entre llaves. Un ejemplo es {TiempoDeEspera <= 10 ns}.
•
Ubicación: Es el lugar donde reside el componente. En UML, éste es un valor
denotado por una cadena encerrada entre llaves. Un ejemplo es {location =
ServidorPrincipal}.
2: asignarId()
GerenteEstudiante
{Location= Servidor
Principal}
1: generarId()
Ge nerado rId
3: modi ficarDatosEst udia nte()
ConectorBaseDatos
{tiem po e jecuc ión < 10 ns }
{Location= servidor
Base de datos}
EnrutadorDatos
4: haltOperacio nes()
Figura 3.9: Representación de Tiempo y Espacio
6. Cómo Crear un Diagrama de Colaboración
Para una mejor comprensión de este diagrama se pueden seguir los siguientes pasos:
•
Colocar los objetos que participaran en el diagrama.
•
Dibujar los enlaces entre los objetos utilizando el diagrama de clases como guía.
•
Agregar un mensaje con una flecha paralela, en el enlace entre dos objetos.
•
Enumere el mensaje en el orden de ejecución.
•
Repita los pasos 3 y 4 hasta que este modelado todo el escenario.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
137
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Resumen
Ahora que ha completado esta unidad, usted debe ser capaz de:
•
Definir colaboraciones.
•
Definir interacciones.
•
Describir diagramas de secuencias.
•
Describir diagramas de colaboración.
•
Describir pasos para realizar diagramas de colaboración.
Unidad 3: Modelado de interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
138
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Examen de Autoevaluación
1) ¿Cuál de las siguientes es una instancia de asociación?
a) Interacción
b) Enlace
c) Actividad
d) Relación
2) ¿Cuál de los siguientes introduce un ordenamiento dinámico de mensajes pasados
entre dos o más objetos?
a) Interacciones
b) Actividades
c) Clases
d) Carriles
3) ¿Cuáles son estereotipos asociados a los enlaces?
a) new
b) transient
c) destroy
d) Ninguna de las anteriores
4) Los diagramas de colaboración muestran los mensajes en orden ascendente en el
tiempo.
a) Verdadero
b) Falso
5) Los diagramas de interacción comprenden de: Seleccione los que apliquen
a) Conjunto de objetos.
b) Relaciones o enlaces entre objetos.
c) Mensajes entre objetos.
d) Generalizaciones.
6) Los términos asociados al tiempo y espacio son: Seleccione los que apliquen
a) Marca de tiempo
b) Expresión de tiempo
c) Ubicación
d) Restricción de espacio
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
139
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
7) Un diagrama de colaboración puede ser convertido en un diagrama de secuencia.
a) Verdadero
b) Falso
8) Algunas de las semejanzas entre el diagrama de secuencia y de colaboración son:
Seleccione las que apliquen.
a) Ambos diagramas consisten típicamente de objetos, enlaces y mensajes.
b) Los diagramas de secuencia y colaboración describen el tiempo de vida de un
objeto y el enfoque de control.
c) Estos diagramas son creados a través del mismo conjunto de datos.
d) Los diagramas de secuencia y colaboración no tienen semejanza alguna
9) El tipo de mensaje donde el objeto remitente pasa un mensaje y espera a que el
receptor acepte la llamada se llama:
a) Mensaje Simple
b) Mensaje asincrónico
c) Mensaje síncrono
d) Mensaje reflexivo
10) La iteración se denota usando un numeral (#) y una condición para controlar el
número de iteraciones.
a) Verdadero
b) Falso
Unidad 3: Modelado de interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
140
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Respuestas a Unidad 3: Examen de Autoevaluación
1) b
2) a
3) b y c
4) b
5) a, b y c
6) a, b y c
7) a
8) a y c
9) c
10) b
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 3: Modelado de interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
141
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Lab. de Modelado de
Interacción
Objetivos de Aprendizaje
Al final de esta unidad, usted será capaz de:
•
Diseñar diagramas de secuencia.
•
Diseñar diagramas de colaboración.
•
Aplicar los conceptos aprendidos en la unidad anterior.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Lab. de Modelado de Interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
143
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Ejercicio de Laboratorio
Se describe un sistema ATM para un e-Bank (Banco electrónico).
El e-Bank lanzó sus operaciones en Venezuela, con su casa matriz en Caracas en el
año 2002. Dentro de un periodo corto de tres años, construyó una red de 275
sucursales por toda Venezuela. Quizás deba su éxito al excelente servicio al cliente y a
la banca por Internet para clientes individuales y corporativos. Aunque tiene un sistema
ATM existente en todas sus sucursales, el banco desea diseñar e implementar un
nuevo sistema ATM basado en las últimas tecnologías. La necesidad es tener un
sistema de software orientado a objetos para el ATM, que resulte en una estructura
sencilla con componentes reutilizables que sean fáciles de extender y mantener.
A continuación se presenta la descripción de los requerimientos claves del sistema ATM
para el e-Bank:
•
Existen dos tipos principales de clientes del banco: Individuales y corporativos.
•
Uno de los requerimientos importantes del sistema es permitir al cliente
depositar una cantidad y/o retirar una cantidad de una cuenta en los centros
ATM. Los centros ATM tienen un quiosco con capacidades de pantalla de
contacto.
•
El cliente debe tener la capacidad de revisar cada transacción realizada contra
una cuenta. Algunas de las transacciones registradas incluyen lo siguiente:
- Fecha.
- Hora.
- Tipo de transacción (o tipo de transacción).
- Cantidad.
- Balance de Cuenta.
•
Un cliente individual puede operar tres tipos de cuentas:
- Una cuenta de ahorros.
- Una cuenta de depósito fijo.
- Una cuenta de depósito recurrente.
•
Un cliente corporativo sólo puede operar un tipo de cuenta, llamada cuenta
corriente.
•
Los clientes pueden acceder a sus cuentas en el ATM insertando una tarjeta
ATM, dicha tarjeta es proporcionada al cliente junto con un código (PIN) que
tendrá que ser insertado después que se inserta la tarjeta. El código (PIN) está
compuesto de 4 dígitos decimales del 0 al 9.
•
Se supone que una sola tarjeta ATM proporciona acceso a todas las cuentas del
cliente.
•
Un cliente puede hacer depósitos en cualquiera de los tipos de cuenta.
Unidad 4: Lab. de Modelado de Interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
144
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
El retiro de dinero es permitido en la cuenta de ahorros sólo si existe un balance
positivo.
•
El retiro de efectivo directamente desde la cuenta de depósito fijo o la de
depósito recurrente no está permitido.
•
El retiro de efectivo desde la cuenta corriente está permitido incluso si no existe
un balance positivo.
•
La magnitud de sobregiro permitido se fija al momento de abrir la cuenta
corriente y puede ser modificado sólo por las autoridades del banco y no a
través del ATM.
•
Mientras el retiro no está permitido directamente desde la cuenta de depósito fijo
o recurrente, se puede transferir una cantidad de dinero desde estas cuentas
hacia una cuenta de ahorros. Sin embargo, dichas transferencias implican un
pago por transacción del 7% y las cantidades transferidas no pueden exceder
del 75% que se tiene en la cuenta origen.
Se requiere realizar las siguientes tareas:
1) Realizar un diagrama de secuencia y colaboración para retirar efectivo de la
cuenta corriente.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 4: Lab. de Modelado de Interacción
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
145
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento
Avanzado
Objetivos de Aprendizaje
Al final de esta unidad, usted será capaz de:
•
Discutir qué son los eventos y las señales.
•
Definir máquinas de estado.
•
Discutir y construir diagramas de estado.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
147
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. Introducción
En las unidades anteriores, se aprendió acerca de la necesidad y el uso de cinco
diagramas, a saber: diagramas de clase, diagramas de objetos, diagramas de casos de
uso, diagramas de interacción y diagramas de actividad. En esta unidad, se aprenderá
otro diagrama – el diagrama de estados – el cual permite realizar un Modelado de
Comportamiento.
2. Máquinas de Estado
En la dinámica de análisis y diseño orientado a objetos, los objetos son típicamente
modelados mostrando los diversos estados por los que atraviesa durante su tiempo de
vida. Esto proporciona otra vista de los objetos en el sistema. Mientras sean empleadas
las interacciones para modelar el comportamiento de un conjunto de objetos, se utilizan
máquinas de estado para modelar y entender el comportamiento de un objeto individual.
Cada objeto tiene un tiempo de vida, por lo cual empieza su existencia en algún punto
en el tiempo y deja de existir en otro punto en el tiempo. Durante su existencia, puede
sufrir varios cambios. Los eventos causan cambios en el estado de un objeto basado en
la ocurrencia de eventos. Un objeto puede atravesar una serie de estados durante su
tiempo de vida y las máquinas de estado ayudan a modelar estos cambios de una
manera simple.
Las máquinas de estado representan un conjunto de estados que atraviesa un objeto
durante su tiempo de vida. También incluyen la reacción del objeto ante un evento.
Las máquinas de estado se pueden usar para modelar el comportamiento de una
instancia de una clase o un caso de uso. A veces, las máquinas de estado se usan para
modelar el sistema completo.
Las máquinas de estado pueden ser visualizadas de dos maneras, según se menciona
a continuación:
•
Usando Diagramas de Actividad: En este caso, el flujo de control se enfatiza
de una actividad a otra.
•
Usando Diagramas de Estado: Estos diagramas muestran los diversos estados
que atraviesa el objeto durante su tiempo de vida junto con las transiciones entre
estos estados.
Antes de continuar y aprender a construir un diagrama de estados, es necesario
entender algunas terminologías asociadas a las máquinas de estado.
2.1 Estados
Un estado es un conjunto de valores que almacena un elemento en un punto en el
tiempo. Un objeto, durante su tiempo de vida, puede realizar una de las siguientes
tareas:
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
148
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
Satisfacer una condición.
•
Realizar una actividad específica.
•
Esperar que ocurra un evento.
Cuando el objeto está llevando a cabo una de las tareas anteriores, se dice que el
objeto está en ese estado. Por ejemplo, un objeto en el estado Inactivo espera que
un evento ocurra, o un objeto en el estado Validando está realizando una actividad.
Un estado de un objeto tiene varias partes, estas son:
•
Nombre: Cada estado tiene un nombre asociado a él. Si no se ha proporcionado
un nombre, es un estado anónimo.
•
Acciones de Entrada: Se puede especificar una acción cuando un objeto está
entrando a un estado. Por ejemplo, se puede fijar la acción colocarAlarma() al
entrar a un estado.
•
Acciones de Salida: También se puede especificar una acción cuando un
objeto sale de un estado. Por ejemplo, se puede fijar la acción
desactivarAlarma() al salir de un estado.
•
Transiciones Externas: Se refiere a las transiciones que suceden entre estados
distintos de un mismo estado. Se ejecuta una acción y se genera un cambio de
estado.
•
Transiciones Internas: Son transiciones que suceden internamente entre
subestados de un mismo estado. Se ejecuta una acción pero no se genera un
cambio de estado.
•
Subestados: Se pueden tener estados anidados dentro de otros estados. Estos
estados anidados pueden ser subestados secuenciales o concurrentes.
•
Eventos Diferidos: Un objeto puede diferir el manejo de eventos a otro estado.
Un estado se representa como una caja redondeada con el nombre del estado en su
interior, la cual puede tener uno o dos compartimientos. En el primer compartimiento se
coloca el nombre del estado. El segundo compartimiento es opcional, en él se colocan
acciones de entrada, acciones de salida y acciones internas. En la Figura 4.1 se
muestra la representación gráfica de los estados.
Figura 4.1: Representación Gráfica de los Estados
UML define dos tipos especiales de estados:
•
Estado Inicial: Representa el inicio del diagrama. El estado inicial se representa
gráficamente con un punto sólido junto con una flecha que apunta al primer
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
149
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
estado del diagrama, tal como se muestra a la izquierda de la Figura 4.2. El
estado inicial identifica el estado en el cual un objeto es creado.
•
Estado Final: Representa la culminación del diagrama de estados. El estado
final es una subclase de estado, razón por la cual toma todas las características
de un estado con la excepción que no puede salir ninguna transición de él. El
estado final se representa gráficamente como un ojo de buey (un punto dentro
de un círculo), tal como se muestra a la derecha de la Figura 4.2.
Figura 4.2: Representación Gráfica de Estado Inicial y Final
Es importante señalar que tanto el estado inicial como el final se denominan
seudoestados, ya que no cumplen con todas las características de un estado simple.
3. Eventos
Un evento es un suceso o hecho en el sistema que causa una transición de estado. Un
evento posee tiempo y espacio asociados a él. La Figura 4.3 es una ilustración de un
evento simple.
Figura 4.3: Evento Simple
La figura anterior describe dos estados: Inactivo y Activo. La transición del estado
Activo al estado Inactivo se debe al evento llamado Colgar. La mayoría de los
eventos resultan en una acción. En la Figura 4.3, el evento Colgar resulta en la acción
liberarConexion().
Los eventos pueden ser de dos tipos:
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
150
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
Eventos Externos: Los eventos que ocurren entre los actores y el sistema se
denominan eventos externos. La inserción de una tarjeta en un sistema
automatizado es un ejemplo de un evento externo.
•
Eventos Internos: Los eventos que suceden entre objetos que residen en el
sistema son referidos como eventos internos. Una excepción de desbordamiento
de punto flotante es un ejemplo de un evento interno.
Un evento es análogo a los mensajes en un diagrama de secuencia. Existen cuatro
tipos de eventos que pueden ser modelados en UML: señales, eventos de llamada,
eventos de tiempo y eventos de cambio.
3.1 Señales
Las señales se refieren a la comunicación asíncrona entre objetos. Las señales no
devuelven valores a los que envían la señal. Las señales son siempre enviadas de un
objeto a otro, nunca son invocadas. Normalmente en un sistema se espera que los
objetos actúen y reaccionen al evento. De igual manera, las señales se usan para
manejar eventos excepcionales. Por lo tanto, una señal es un evento que es lanzado
asincrónicamente por un objeto y es capturado por otro objeto en el sistema. Esta
comunicación asíncrona entre objetos es referida como excepción, en los lenguajes de
programación modernos. Las excepciones son el tipo más común de señales que se
modelan en un sistema.
La Figura 4.4 muestra el modo en que las señales se representan en UML. Se muestra
que la señal ConexionFallida es lanzada asincrónicamente por la operación
obtenerConexion() del ConectorBaseDatos cuando existe una falla en la
conexión a la base de datos. Se usa el estereotipo <<send>> para indicar que se envía
una señal.
ConectorBaseDato
<<send>>
ObtenerConexion()
obtenerPelicula()
ObtenerPeliculA()
ObtenerListaPelicula()
ObtenerListaPelicula()
<<señal>>
ConexionFallida
nombreBd
Figura 4.4: Representación de Señales en UML
Típicamente, las excepciones son modeladas usando señales. La Figura 4.5 muestra un
ejemplo del modo en que pueden ser modeladas.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
151
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 4.5: Excepciones Modeladas con Señales usando Estereotipo <<exception>>
La señal es una clase estereotipada o que tiene un estereotipo. Los parámetros
enviados junto con la señal sirven de atributos de la señal. En el ejemplo anterior de la
Figura. 4.4, nombrebd es el parámetro.
Las señales también tienen relaciones de generalización. La Figura 4.6 ilustra la
jerarquía de señales.
Figura 4.6: Jerarquía de Señales
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
152
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
La
señal
FallaTeclado
es
una
especialización
de
la
señal
FallaDispositivoEntrada, la cual a su vez es una especialización de la señal
FallaHardware. En la Figura 4.6, se intenta modelar los eventos asíncronos para un
sistema de computadora.
Una señal puede ser enviada como una acción de una transición de estado en una
máquina de estado. También puede ser un mensaje enviado desde un objeto hacia otro
en una interacción. Las señales pueden ser enviadas dentro de una operación durante
su ejecución.
3.2 Eventos de Llamada
La emisión de operaciones se llama eventos de llamada. El despacho de la operación
resulta en una transición de estado a diferencia de las señales que son asíncronas, por
lo general, los eventos de llamada son típicamente síncronos. Un objeto invoca una
operación sobre otro objeto que tiene un estado, así el objeto receptor completa la
operación y cambia a un nuevo estado, después del cual el control es regresado al
emisor. El emisor espera hasta que el receptor finalice la operación.
La Figura 4.7 muestra un ejemplo de un evento de llamada.
Figura 4.7: Evento de Llamada
La Figura 4.7 describe una transición de estado de Inactivo a Procesando. El
objeto estaba en el estado Inactivo cuando recibió el mensaje
validarIdSeguridad. Al completar la validación, el objeto cambia al estado
Procesando.
3.3 Eventos de Tiempo
Los eventos de tiempo se usan en casos donde el paso del tiempo tiene que ser
registrado. En UML, los eventos de tiempo son modelados usando la palabra reservada
after, seguida por la expresión que caracteriza el tiempo. Por ejemplo, after (4
segundos) o after (2 horas) son formas válidas en las que pueden especificarse
los eventos de tiempo. Aquí, el evento en sí mismo es el paso del tiempo. La Figura 4.8
ilustra los eventos de tiempo.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
153
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Inactivo
Figura 4.8: Evento de Tiempo
La Figura 4.8 ilustra una funcionalidad simple de un salva pantalla. La expresión indica
que si el usuario no presiona alguna tecla del teclado en 5 minutos, el estado del salva
pantalla es cambiado a activo. Luego, si el usuario presiona alguna tecla, el salva
pantalla vuelve al estado en reposo.
A menos que se indique, el tiempo de inicio para verificar una expresión que sigue a un
after es el momento cuando se ingresó al estado actual.
3.4 Eventos de Cambio
En UML, un cambio de estado o el cumplimiento de una condición se puede representar
usando eventos de cambio. La palabra reservada usada para describir eventos de
cambio es when, seguida de una expresión condicional. El evento de cambio ocurre
cuando la condición en la expresión condicional cambia de falso a verdadero. Algunos
ejemplos del modelado de eventos de cambio son when (inventario < 1000) y
when (tiempo = 20:00 horas). El evento de cambio puede ocurrir cuando el
inventario cae debajo del valor 1000. El evento ocurre cuando la condición es
cambiada de falso a verdadero.
La Figura 4.9 demuestra un evento de cambio.
Figura 4.9: Evento de Cambio
La Figura 4.9 ilustra el modo en que una alarma para una reunión se fija en 'encendido',
cuando la hora es 12:00 pm.
3.5 Transiciones
Se define como la respuesta de un objeto, que se encuentra en un estado, a la
ocurrencia de un evento. Dos estados se relacionan a través de una transición. Cuando
un objeto se mueve de un estado a otro, el movimiento se muestra usando una
transición. Bajo la ocurrencia de un evento, el objeto ingresa al siguiente estado en la
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
154
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
relación. La ocurrencia del evento resulta en alguna acción especificada. Una transición
puede tener múltiples fuentes y múltiples destinos.
Un estado puede transitar a sí mismo. Esto es referido como autotransición. En la
autotransición, el objeto abandona el estado debido a la ocurrencia de un evento,
maneja el evento, ejecuta una acción y reingresa al mismo estado. Un ejemplo de
autotransición puede verse en la Figura 4.10.
Figura 4.10: Autotransición
En la Figura 4.10, se muestra el modo en que un teléfono realiza el discado de un
número telefónico. Cada vez que se presiona un dígito numérico se activa un evento
que va asociado a la acción AñadirDigito() que almacena el número para luego
validarlo y conectar la llamada. Cada vez que es presionado un número, el objeto
abandona el estado Marcando para ejecutar una acción y luego regresar al mismo.
Número válido es una restricción que debe cumplirse para ir al estado En línea.
Existen cinco partes en una transición. Éstas son:
•
Estado Fuente: Un estado fuente es aquel que es afectado por la transición.
Antes de la transición, el objeto está activo en el estado fuente.
•
Estado Destino: Se alcanza este estado después de completar la transición. El
objeto ahora está activo en ese estado.
•
Acción: Es la computación atómica que puede afectar el objeto al que
pertenece la máquina de estado. La acción puede afectar otros objetos
indirectamente, si están visibles para ese objeto.
•
Evento Activador: El evento activador dispara la transición que permite
moverse al siguiente estado. Debe cumplirse la condición de guarda.
•
Condición de Guarda: Hay una evaluación de una expresión Booleana cuando
ocurre el activador de eventos. Si la evaluación de la expresión resulta
verdadero, la transición se dispara, de lo contrario no se dispara.
Antes de ver cómo son modelados los subestados en UML, se verán brevemente las
características avanzadas asociadas a estados y transiciones. Vea la Figura 4.11.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
155
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 4.11: El Estado Procesando de un Objeto
La Figura 3.11 describe el estado Procesando de un objeto. A continuación se
discuten cinco características asociadas a estados y transiciones:
•
Acción de Entrada (Entry): Las acciones de entrada pueden no tener
condiciones de guarda, sin embargo pueden tener parámetros. Los parámetros
pueden representar los argumentos que recibe la máquina de estado durante el
proceso de creación del objeto. Al entrar en este estado, el objeto siempre activa
la alarma. Esto sucede cuando un objeto ingresa a ese estado. Es posible que
existan múltiples flujos de eventos concurrentes desde múltiples estados.
•
Acción de Salida (Exit): Pueden existir múltiples transiciones desde el estado
Procesando del objeto. Al abandonar ese estado, la alarma siempre es
desactivada, sin tomar en cuenta el estado en que pueda entrar después de salir
ese estado. Las acciones de salida pueden no tener argumentos o condiciones
de guarda.
•
Transiciones Internas: Las transiciones internas se usan para manejar eventos
dentro del estado. Son diferentes de las autotransiciones. Las transiciones
internas no ejecutan las acciones de entrada y salida dado que los eventos se
manejan sin abandonar el estado.
•
Actividades: Típicamente, para un objeto en un estado particular se dice que
está Inactivo hasta que ocurra un evento. Sin embargo, el objeto puede realizar
cierto trabajo hasta que un evento ocurra aunque la secuencia de acciones que
está realizando el objeto será interrumpida cuando ocurra el evento.
En la Figura 4.11 se usa la transición especial do para indicar que el objeto está
realizando una secuencia de acciones, por ejemplo, accion1() y accion2(). El
trabajo realizado por el objeto mientras está en el estado Procesando se divide en
acciones separadas. Una acción no se puede interrumpir, pero una secuencia de
acciones puede ser interrumpida por un evento. Entre accion1() y accion2(), un
evento puede ser manejado por el objeto. Esto puede llevar a una transición a otro
estado fuera de este estado. En este caso, accion2() puede no ser llevada a cabo.
•
Eventos Diferidos: Se usa para diferir el manejo de un evento a otro estado en
el cual pueda estar el objeto, en algún otro momento. Esto significa solamente
que el evento no es manejado inmediatamente.
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
156
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
4. Subestado
Un estado puede tener estados anidados, llamados subestados. Un estado puede o no
tener subestados. Un estado con subestados es llamado estado compuesto, mientras
que uno sin subestados es llamado estado simple. Los estados compuestos pueden
tener subestados secuenciales o concurrentes. Pueden existir varios niveles de
subestados en un estado particular.
4.1 Subestados Secuenciales
Los subestados secuenciales son referidos también como subestados disjuntos.
La Figura 4.12 brinda un ejemplo de un estado con subestados secuenciales.
Figura 4.12: Estado con Subestados Secuenciales
La figura anterior muestra que un objeto está en el estado Inactivo cuando ocurre un
evento presionarTecla(). El objeto transita al estado Activo. Permanece en este
estado hasta que ocurra el evento Termino. El objeto entonces regresa al estado
Inactivo.
En el estado Activo, se encuentran tres subestados: Validando, Procesando y
Mostrando. Ellos representan un flujo de control secuencial. El estado compuesto tiene
una acción de entrada activar(). El estado Procesando bien puede ser el estado
mostrado en la Figura 4.11. Por lo tanto, se puede ver que las máquinas de estado
pueden ser muy complejas.
•
Cuando un objeto está en un estado compuesto, se dice que está a la vez en
alguno de los subestados. Un estado fuente puede transitar hacia el estado
compuesto o directamente hacia algún subestado específico del estado
compuesto.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
157
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
4.2 Subestados Concurrentes
Los subestados concurrentes permiten especificar dos o más estados que se ejecutan
en paralelo. La Figura 4.13 muestra un ejemplo de un estado con subestados
concurrentes.
Figura 4.13: Un Estado con Subestados Concurrentes
Se nota en la figura anterior que un objeto, el cual está en el estado Mantenimiento,
ingresa concurrentemente a los dos subestados anidados. El control es pasado al
estado inicial de ambos estados concurrentemente. Dentro de los subestados
concurrentes, los subestados son secuenciales por naturaleza.
En este caso, cuando una transición va a un estado compuesto, se divide entre los
subestados concurrentes; es decir, el control fluye hacia todos los subestados
concurrentes. Esto es equivalente a una ramificación. Cuando una transición abandona
un estado compuesto, las actividades en cada subestado concurrente deben ser
completadas antes de que el objeto abandone el estado compuesto. Esto es
equivalente a una unión.
Los subestados concurrentes pueden no tener estados inicial, final o historial. Sin
embargo, el subestado secuencial dentro de un subestado concurrente puede incluir
estas características. Esto se describe en la Figura 4.13. Los dos subestados
concurrentes son subestados secuenciales anidados. Por lo tanto, tienen sus estados
inicial y final correspondientes.
Los estados concurrentes son también llamados subestados ortogonales.
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
158
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
4.3 Historial de Estados
A veces es útil y necesario mantener el último subestado activo antes de salir por
transición del estado compuesto. Cuando el objeto reingresa al estado compuesto, se
reanuda el trabajo en ese último subestado activo, saltando los subestados anteriores.
Esto contribuye a mantener el historial dentro del estado compuesto.
Para mantener el historial, cuando el objeto abandona un subestado, se puede fijar una
variable del estado compuesto con un valor, este valor puede ser verificado al
reingresar en el estado compuesto usando una condición. Basado en la condición, el
estado inicial transitará hacia cada subestado verificando el valor de la variable. De esta
manera, el último subestado activo puede ser recordado por el estado compuesto y el
subestado apropiado puede ser ubicado por la fuente. Esto es incómodo, dado que
cada subestado necesita mantener una acción de salida. Al reingresar al estado
compuesto, se realiza una verificación para encontrar la transición hacia el estado
correcto.
UML proporciona una manera más simple en donde un historial del estado puede ser
modelado. No hay necesidad de mantener acciones de salida con este método. En vez
de ello, se usa el símbolo H dentro de un círculo para indicar que el estado compuesto
mantiene un historial. La transición desde fuera del estado compuesto es dirigida hacia
la H y luego el control pasa al subestado secuencial (el estado inicial, la primera vez), y
en posteriores transiciones, al último subestado activo.
Se mantiene el historial mientras los eventos que ocurran causen una transición en
medio del flujo de control secuencial. Una vez que la transición dentro de los
subestados anidados alcance al estado final, se pierden los detalles del historial. Vea la
Figura 4.14.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
159
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 4.14: Máquina de Estado Compleja
La Figura 4.14 es una máquina de estado razonablemente compleja. El estado
compuesto Reportando representa un historial profundo. Éste recuerda el historial del
estado anidado más interno, el cual es Conectando. El subestado anidado Generando
muestra un historial superficial y mantiene el historial sólo para los subestados dentro
de su espacio circundante.
El evento activarReporte() causa una transición del estado Esperando al estado
Reportando. Éste estado contiene subestados.
UML diferencia entre historial superficial y profundo. El historial superficial es descrito
con una H dentro de un círculo y un historial profundo es descrito con una H* dentro de
un círculo. El historial superficial mantiene el historial del subestado anidado inmediato.
El historial profundo mantiene el historial hasta el subestado anidado más interior de
cualquier profundidad.
La Figura 4.14 muestra un ejemplo de historial superficial y profundo. Los estados del
historial se pueden usar sólo con los subestados secuenciales Generando, Validando
e Imprimiendo. El subestado Generando tiene dos subestados Conectando y
Calculando. El subestado Conectando de nuevo es un estado compuesto, con
Esperando y Recibiendo como sus subestados. La Figura 4.14 no menciona los
eventos dentro de los subestados, dado que su enfoque se encuentra en el
mantenimiento del historial de los estados.
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
160
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
5. Diagramas de Estado
Un diagrama de estados muestra la secuencia de estados por la que atraviesa un objeto
durante su tiempo de vida, en respuesta a los estímulos y mensajes exteriores. Un
diagrama de estados se representa gráficamente como vértices y arcos. El nombre UML
designado para la máquina de estado conceptual es Diagrama de Estados. Consiste de
estados - simples y compuestos, eventos, acciones y transiciones.
Algunos objetos son manejados por eventos. Tales objetos permanecen inactivos hasta
que un evento es activado. Este comportamiento de espera por un estímulo externo,
para causar que un objeto actúe se llama comportamiento establecido por eventos. Los
diagramas de estado se usan para modelar dicho comportamiento en el sistema. Estos
comportamientos pueden ser modelados para clases, interfaces, componentes y nodos
de un sistema. También se puede usar un diagrama de estados para modelar un
escenario con ayuda de casos de uso.
La Figura 4.15 muestra un ejemplo de una máquina de estados para un objeto
DetectorDeHumo, el cual comienza en el estado Inicializando la alarma, luego
pasa al estado Inactivo esperando un evento para que la alarma se active. Cuando
se ejecute el evento activarAlarma() el objeto pasa al estado Activo, el mismo tiene
subestados secuenciales que verifican la señal de activación realizan una llamada a una
central de bomberos y descuelgan la llamada.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
161
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 4.15: Una Máquina de Estados para un Objeto DetectorDeHumo
6. Clases Activas
Una clase es referida como clase activa cuando es capaz de iniciar una actividad de
control. Una instancia de una clase activa es un objeto activo. Típicamente, un objeto
activo es un proceso o un hilo, dado que es capaz de iniciar una actividad de control.
Un proceso puede ejecutarse concurrentemente con otros procesos. Cada proceso
tiene su propio espacio de dirección y es llamado componente pesado. Un proceso es
conocido por el sistema operativo. Por otro parte, un hilo es un componente ligero que
puede ejecutarse concurrentemente con otros hilos dentro del mismo proceso. Los hilos
dentro de un proceso comparten el mismo espacio de dirección. Los hilos pueden ser
conocidos para el sistema operativo, pero típicamente residen dentro de un componente
pesado. Los procesos e hilos traen con ellos el concepto de concurrencia. Por lo tanto,
los objetos activos pasan mensajes a otros objetos activos al incorporar semántica de
concurrencia. Esto ayuda a la sincronización de las interacciones entre flujos
independientes.
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
162
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Una clase activa es descrita gráficamente en la Figura 4.16. El borde exterior del
rectángulo es más grueso. Una clase activa es como una clase normal con atributos,
operaciones y compartimentos adicionales. Los objetos activos reciben señales, las
cuales se listan en un compartimiento llamado Señales.
La Figura 4.16 muestra las diversas partes de una clase activa. Las clases estáticas no
reciben señales y por lo tanto no tienen un compartimiento llamado Señales. Se ve
que la clase ConectorBaseDatos recibe dos señales.
Figura 4.16: Clase Activa
Para modelar un proceso o hilo en UML, se usan clases activas. Cada flujo de control
independiente, dentro de una aplicación, se representa como un proceso o como un hilo
y se le asigna un nombre único.
En UML, process y thread son los dos estereotipos estándar definidos para clases
activas. En un sistema, se pueden encontrar tanto objetos activos como pasivos. Un
objeto activo puede interactuar con un objeto pasivo y viceversa.
Existen cuatro maneras en las que las interacciones pueden ocurrir entre un objeto
activo y uno pasivo. Se discuten brevemente a continuación:
1) Pasar un mensaje desde un objeto pasivo hacia otro objeto pasivo.
En un solo flujo de control, el paso de un mensaje es una llamada a una operación
desde un objeto hacia otro objeto. La Figura 4.17 muestra este tipo de paso de
mensaje.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
163
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 4.17: Paso de Mensaje entre Objetos Pasivos
2) Pasar un mensaje desde un objeto activo hacia otro objeto activo
La comunicación interprocesos ocurre cuando dos objetos activos se involucran en una
comunicación. Existen dos maneras en las que ocurre la comunicación interprocesos:
•
Un objeto activo invoca una operación sobre otro objeto activo sincrónicamente.
El objeto llamador pasa un mensaje y espera a que el receptor acepte la
llamada. El receptor despacha la operación y envía un valor de retorno al
llamador. El llamador y el receptor continúan con sus tareas independientes. Por
la duración de la operación, los dos objetos son sincronizados. La Figura 4.18
muestra un ejemplo de paso síncrono de mensajes.
Figura 4.18: Paso Síncrono de Mensajes
•
Un objeto activo invoca una operación sobre otro objeto activo
asincrónicamente. El objeto llamador envía una señal y continúa con sus tareas
independientes. El receptor recibe la señal, la procesa y luego de la finalización
de la tarea, continúa con sus tareas independientes. El llamador no espera a que
el receptor complete la tarea. Los dos objetos no están sincronizados en este
tipo de comunicación. La Figura 4.19 ilustra el paso asíncrono de mensajes.
Figura 4.19: Paso Asíncrono de Mensajes
Note la diferencia entre los símbolos usados en las Figuras 4.18 y 4.19 para el paso
síncrono y asíncrono de mensajes. En el primer caso, el objeto de
:ConectorBaseDatos espera hasta que el objeto :EnrutadorDatos encuentre una
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
164
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
nueva ruta. Esto puede ocurrir cuando existe una saturación de la red. En el segundo
caso, el objeto :EnrutadorDatos pasa un mensaje asíncrono haltOperations() y
luego continúa con su tarea independiente. La finalización de la tarea
haltOperations() no afecta las tareas independientes de :EnrutadorDatos.
3) Pasar un mensaje desde un objeto pasivo hacia un objeto activo
Algún flujo de control inicia desde un objeto activo. Esto permite que el objeto pasivo
invoque una operación sobre el objeto activo. La misma semántica es aplicada en el
caso de un objeto pasivo que pasa un mensaje a otro objeto pasivo. La Figura 4.20
describe un simple paso de mensajes entre un objeto pasivo y un objeto activo.
Figura 4.20: Paso de Mensajes entre un Objeto Pasivo y un Objeto Activo
4) Pasar un mensaje desde un objeto activo hacia un objeto pasivo
El paso de mensajes de un objeto activo a un objeto pasivo es similar a una simple
invocación de una operación. Sin embargo, se tiene que ver el tema de la sincronización
cuando más de un objeto activo pasa un flujo de control al mismo tiempo a un solo
objeto pasivo. La Figura 4.21 muestra el modo en que más de un objeto activo pasa
mensajes a un objeto pasivo.
Figura 4.21: Paso de Mensajes desde Múltiples Objetos Activos hacia un Objeto Pasivo
En la figura anterior, dos instancias de la clase Parser están enviando mensajes al
objeto :AcumuladorDatos.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
165
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
7. Caso de Estudio: Trabajar con Diagramas de Estado
Para el caso de estudio de la tienda de video, a continuación se muestra el diagrama de
estados para un objeto Película. La Figura 4.22 muestra los diversos estados en que
estará el objeto durante su tiempo de vida. Se parte de la premisa que la película existe
en Stock, estando en ese estado la película puede ser Alquilada, Comprada o
Reservada. Note que para que ocurra una transición al estado Alquilada, es necesario
que el cliente que desea alquilar la película este afiliado, igual pasa cuando ocurre una
transición del estado Reservada al estado Alquilada si la reservación tiene menos de 24
horas ocurre la transición y si es mayor de 24 horas la reservación es rechazada
(eventos de cambio). En el caso del estado Comprada no existe ninguna restricción
asociada al evento ComprarPelicula().
Figura 4.22: Los Diversos Estados del Objeto y sus Transiciones
Otro caso que puede ser presentado es el diagrama de estado de un objeto cliente,
desde la perspectiva de alquilar y devolver película. Ver Figura 4.23
En esta figura se muestran 2 estados en la que un objeto cliente puede estar cuando
alquila y devuelve películas, estos son: SinPelicula y ConPelicula.
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
166
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Figura 4.23 Los Diversos Estados del Objeto y sus Transiciones
En la Figura 4.23, se puede observar que un cliente está en estado SinPelícula
cuando no realiza ningún alquiler, al activarse el evento AlquilerPelicula()ocurre
una transición al estado ConPelicula, el cual tiene 2 transiciones reflexivas. La
transición reflexiva de la izquierda se realiza cuando se activa el evento
DevolverPelícula(), tomando en cuenta que el cliente tiene más de una película
alquilada. La transición reflexiva de la derecha se realiza cuando se activa el evento
AlquilarPelicula() y el cliente ya tiene películas alquiladas. El objeto pasa de
nuevo al estado SinPelicula cuando se activa el evento DevolverPelicula(),
tomando en cuenta que el cliente solo le queda una película alquilada.
8. Algunas Recomendaciones
Las siguientes, son algunas recomendaciones en el contexto de manejo de eventos:
•
Puede construirse una jerarquía de señales; esto le permitirá sacar provecho de
las propiedades comunes de algunas señales relacionadas.
•
Un elemento que recibe un evento debe tener definitivamente una máquina de
estados adecuada.
•
Los elementos que envían eventos y también aquellos que reciben eventos
deben ser modelados.
•
La máquina de estados no debe ser complicada por estados y transiciones
superfluos; debe mantenerse simple.
•
La máquina de estados debe ser eficiente en términos de espacio y tiempo.
•
Debe usarse un vocabulario apropiado cuando se nombran los estados y
transiciones para permitir un mejor entendimiento.
•
No deben introducirse subestados que se aniden demasiado profundo; no es
considerada una buena práctica tener más de dos niveles de anidamiento.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
167
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Resumen
Ahora que ha completado esta unidad, usted debe ser capaz de:
•
Discutir eventos y señales.
•
Definir máquinas de estado.
•
Discutir y construir diagramas de estado.
•
Describir de qué modo las restricciones de tiempo y espacio afectan el modelado
del sistema.
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
168
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Examen de Autoevaluación
1) ¿Cuál de los siguientes causa una transición de estado?
a) Estado
b) Evento
c) Acción
d) Ninguno de los anteriores
2) ¿Cuál de los siguientes es asíncrono por naturaleza?
a) Señales
b) Eventos
c) Acciones
d) Ninguno de los anteriores
3) ¿Cuál de los siguientes tipos de eventos representa el despacho de una operación?
a) Acción
b) Tiempo
c) Cambio
d) Llamada
4) ¿Qué tipo de evento es when (tiempo = 10 horas)?
a) Evento de llamada
b) Evento de cambio
c) Evento de tiempo
d) Evento de acción
5) ¿Cuáles de los siguientes elementos pueden modelar su comportamiento con
máquinas de estado?
a) Clase
b) Caso de uso
c) Interacciones
d) Colaboraciones
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
169
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
6) Las acciones de entrada y salida, son parte de:______________________
a) Un estado
b) Un evento
c) Una acción
d) Ninguno de los anteriores
7) Las transiciones internas no resultan en un cambio de estado.
a) Verdadero
b) Falso
8) Un estado puede tener una auto-transición.
a) Verdadero
b) Falso
9) ¿Qué tipo de subestado puede no tener estados inicial o final?
a) Secuencial
b) Concurrente
c) Iterativo
d) Ninguno de los anteriores
10) A menos que se indique el tiempo de inicio para verificar una expresión que sigue a
un after es el momento cuando se ingresó al estado actual
a) Verdadero
b) Falso
Unidad 5: Modelado de Comportamiento Avanzado
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
170
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Respuestas a la Unidad 2: Examen de Autoevaluación
1) b
2) a
3) d
4) b
5) a y b
6) a
7) a
8) a
9) b
10) a
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 5: Modelado de Comportamiento Avanzado
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
171
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
Objetivos de Aprendizaje
Al final de esta unidad, usted será capaz de:
•
Describir componentes, nodos y colaboraciones.
•
Discutir diagramas de componentes.
•
Discutir la necesidad de diagramas de despliegue.
•
Describir estereotipos y relaciones entre componentes y nodos.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
173
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
1. Introducción
En esta unidad se aprenderá acerca del modo en que son modeladas las partes
arquitectónicas de un sistema: componentes, nodos y colaboraciones. En cualquier
esfuerzo de desarrollo de sistemas, ésta es una vista completamente diferente del
sistema. Proporciona una perspectiva que ayuda a modelar los componentes físicos del
mismo. Se construyen modelos lógicos para visualizar y conceptualizar el sistema. El
modelo arquitectónico se usa para modelar las entidades físicas que existen
eventualmente en el mundo real, es importante destacar que tanto las vistas física como
lógica son igual de importantes.
El modelado estructural se ocupa de las abstracciones, instancias de esas
abstracciones y sus relaciones. El Modelado del Comportamiento ayuda a entender el
flujo de control entre dos o más objetos modelados usando diferentes diagramas. Los
diagramas arquitectónicos permiten modelar ejecutables, librerías, tablas, archivos,
código fuente y nodos físicos. En esta unidad, se aprenderá acerca de los diagramas de
componentes y diagramas de despliegue. A continuación se discutirá sobre
componentes.
2. Componentes
Un componente es un tipo Clasificador con la diferencia de que no tiene características
propias, pero contiene las clases que definen las características. Un componente
proporciona una vista encapsulada de la funcionalidad definida por las clases
contenidas.
Un componente es una parte física del sistema. Cada componente tiene un nombre, el
cual puede ser un nombre simple o un nombre de ruta.
En la especificación UML 1.4 se describe como una caja rectangular con dos
rectángulos más pequeños centrados en el borde izquierdo. Se pueden tener
compartimentos y valores etiquetados para un componente, tal como se hizo para las
clases. La Figura 6.1 es un ejemplo en el que se muestra la representación de
componentes en UML.
Figura 6.1: Representación de Componentes en UML
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
174
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
En la Figura 6.1, se observa que el componente ProcesadorImagen.exe tiene una
relación con tres clases ProcesadorImagenes, GeneradorVectores y
GeneradorBMP. Por lo tanto, se puede decir que las clases mencionadas implementan
el componente en cuestión.
La Figura 6.2 muestra otra manera de ver las relaciones del componente y las clases,
estas relaciones son llamadas relaciones de dependencia.
Figura 6.2: Relación de Dependencia entre un Componente y sus Clases
2.1 Clases vs. Componentes
Las clases representan abstracciones lógicas del mundo real, mientras que los
componentes representan las partes físicas de un sistema. Cualquier sistema tiene
elementos físicos y lógicos. Un componente es la implementación física de un conjunto
de elementos lógicos en el sistema. Las clases y colaboraciones son simples ejemplos
de elementos lógicos en un sistema. Por lo tanto, se ve una relación entre un
componente y las clases que realiza. De modo similar, un componente puede ser la
implementación física de un conjunto de colaboraciones. La relación de dependencia se
usa para describir la relación entre clases y componentes.
2.2 Estereotipos de Componentes
Los estereotipos de componentes muestran una vista de los roles que juegan los
componentes en la arquitectura. Los estereotipos de componentes se refieren a los
tipos de artefactos (código fuente, archivos binarios, bases de datos, entre otros), que
son utilizados parta implementar las características del componente.
UML proporciona cinco estereotipos estándar que aplican a componentes. Éstos son:
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
175
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
•
<<executable >>– Para describir que un componente puede ser ejecutado en
un nodo.
•
<<library >>– Para describir una inclusión de una librería. Puede ser una
librería estática o dinámica.
•
<<table >>–Para mostrar que se usa una tabla de la base de datos.
•
<<file >>– Para mostrar que se incluye un código fuente o un archivo de
datos.
•
<<document>> – Para representar un documento.
En la Figura 6.3, se muestra un componente estereotipado.
Figura 6.3: Componente con el Estereotipo File
2.3 Relación entre Interfaces y Componentes
Una interfaz es un conjunto de operaciones en las cuales una clase o componente se
revela al mundo exterior. Una interfaz puede ser realizada por un componente y una
clase. El servicio de una clase está disponible directamente, mientras que los servicios
de un componente están disponibles sólo a través de sus interfaces.
La relación entre un componente y una interfaz puede mostrarse de dos formas:
•
Usando la forma abreviada (icónica).
•
Usando la forma expandida.
Un componente puede realizar o usar una interfaz. Cuando un componente realiza una
interfaz se llama una interfaz exportada o de exportación. Cuando un componente
realiza o implementa una interfaz ofrece como servicio los comportamientos de dicha
interfaz realizada a otros componentes. Una interfaz que es usada por un componente
se llama una interfaz importada. Cuando un componente usa una interfaz, utiliza el
comportamiento de una interfaz realizada por otro componente. En otras palabras, un
componente establece la disponibilidad de su interfaz para que otros componentes
puedan utilizar las operaciones o comportamientos que contiene. En la Figura 6.4 se
muestra un componente que realiza la interfaz MenuArchivo en la forma icónica,
dicha interfaz proporciona la funcionalidad al componente de manejar el archivo de
imagen a procesar (crear archivo, abrir archivo, entre otras).
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
176
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Figura 6.4: Realización de una Interfaz de Forma Icónica
La Figura 6.5 muestra la misma realización pero de forma expandida. Nótese que en
esta representación se da a conocer las operaciones que son parte de la interfaz.
Figura 6.5: Realización de una Interfaz de Forma Expandida
En la Figura 6.6, la interfaz exportada por el componente ProcesadorImagen.exe es
usada por el componente ProcesadorTexto.exe. El enlace entre esos dos
componenentes es a través de la interfaz MenuArchivo. La interfaz MenuArchivo
contiene
las
firmas
de
operaciones
como
abrirArchivo(),
cerrarArchivo(),que
son
realizadas
por
el
componente
ProcesadorImagen.exe; quedando disponibles para cualquier otro componente
que las necesite, tal es el caso del componente ProcesadorTexto.exe
Figura 6.6: Realización y Uso de la Interfaz
2.4 Tipos de Componentes
UML presenta tres tipos de componentes. Éstos son:
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
177
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
•
Componentes de Despliegue o Distribución (Deployment): Estos
componentes se usan para formar un sistema ejecutable. Un ejemplo de tal
componente es la librería de enlace dinámico y los archivos ejecutables. Otros
ejemplos son los componentes COM+, Enterprise Java Beans, componentes
CORBA y objetos de base de datos.
•
Componentes de Producto de Trabajo: Estos componentes son parte del
proceso de desarrollo que es esencial para el sistema. Algunos ejemplos de
componentes de producto de trabajo son los archivos fuente, archivos de datos y
tablas. Ellos son los archivos fuente y archivos de datos que se usan para crear
los componentes de distribución como AgenteAnalizado.java y
AnalizadorDatos.txt.
•
Componentes de Ejecución: Estos componentes son el resultado de un
sistema que se está ejecutando. Cuando un DLL es instanciado como un
componente COM+, es un ejemplo de un componente de ejecución.
3. Diagrama de Componentes
Los diagramas de componentes se usan para modelar la implementación estática de
elementos físicos que residen en un nodo, como los ejecutables, librerías, tablas y
archivos. Los diagramas de componentes son útiles también para construir sistemas
ejecutables a través de la ingeniería reversa y la ingeniería hacia adelante.
Un diagrama de componentes es un conjunto de componentes y la relación entre ellos.
Consiste de componentes, interfaces y relaciones entre ellos. Pueden agregarse notas y
restricciones a un diagrama de componentes.
Figura 6.7: Diagrama de Componentes
La Figura 6.7 muestra un ejemplo de un diagrama de componentes. En este diagrama
el componente ProcesadorImagen.exe es construido usando diversos elementos. El
diagrama de componentes dice el modo en que el componente está compuesto de
diferentes elementos como una librería de enlace dinámico, una librería .h, una tabla y
un archivo fuente CPP.
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
178
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Los diagramas de componentes se usan típicamente para modelar los siguientes
elementos:
•
Código Fuente.
•
Lanzamiento de Ejecutables (releases).
•
Bases de Datos Físicas.
•
Sistemas Adaptables.
•
Ingeniería Hacia Adelante y Reversa.
3.1 Modelar Código Fuente
El conjunto de archivos de código fuente se identifican y modelan. Pueden usarse
paquetes para agrupar archivos fuente. El estereotipo <<parent>> puede mostrar
versiones anteriores. Los valores etiquetados pueden usarse para indicar la versión o
cualquier otra información acerca de un archivo.
La Figura 6.8 muestra el modo en que los archivos de código fuente se describen en
UML.
En la Figura 6.8 se muestra que la versión 3.1 del archivo de encabezado
LibreriaImagenes.h es la versión anterior. Esto se describe usando el estereotipo
<<parent>>. También se muestra que AnalizadorImagen.cpp está usando el
archivo LibreriaImagenes.h y RenderImagen.dll es dependiente de
AnalizadorImagen.cpp. Obtener un diagrama de componentes de esta manera
ayuda a ver las dependencias relacionadas al código fuente.
Figura 6.8: Descripción de Archivos de Código Fuente en UML
3.2 Modelar Lanzamiento de Ejecutables (Releases)
Así como se puede modelar código fuente usando UML, también se puede modelar el
lanzamiento de ejecutables. Aplicaciones simples pueden requerir solamente un solo
archivo .exe. Pero para sistemas grandes, puede ser necesario un archivo ejecutable,
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
179
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
una librería de enlace dinámico y un archivo de base de datos. En Java se necesitan
archivos .class y .jar. Tal como se muestra en la Figura 6.9, también se pueden
modelar las diferentes partes de un lanzamiento.
La liberación ejecutable contiene el AnalizadorComponente.jar, el cuales
dependiente de AnalizadorDatos.jar, quien a su vez es dependiente de dos
archivos de clase.
Figura 6.9: Modelado de Diversas Partes de una Liberación
3.3 Modelar Bases de Datos Físicas
Se pueden modelar bases de datos físicas del mismo modo en que se modela el código
fuente. La Figura 6.10 ilustra esto. Cabe destacar que la base de datos también es un
componente y puede tener relaciones con otros componentes y artefactos. Se puede
observar en la figura que las tablas Estudiantes, Cuotas y Notas residen dentro
del componente Bdimagenes, el estereotipo <<reside>> ayuda a aclarar la
relación.
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
180
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Figura 6.10: Modelado de Bases de Datos Físicas
3.4 Modelar Sistemas Adaptables
Existen dos tipos de sistemas: estáticos y dinámicos. En los sistemas estáticos, los
componentes entran a la escena de ejecución, participan en la ejecución y luego se
retiran. No existe movimiento de componentes de un procesador a otro. Los sistemas
dinámicos contienen agentes que son móviles. Estos agentes móviles se desplazan de
un procesador a otro para manejar el balance de carga y la recuperación ante fallas. Se
puede usar el diagrama de componentes UML para modelar dichas entidades
dinámicas en el sistema.
La Figura 6.11 muestra un ejemplo del modo en que los sistemas adaptables se
modelan. Simplemente muestra la replica de los datos de un servidor a otro. La replica
de bases de datos es típica en cualquier aplicación intensiva de datos. Esto permite a
las aplicaciones su ejecución, incluso si falla el servidor primario.
Figura 6.11: Modelado de Sistemas Adaptables
Se asumirá que existe una falla del servidor primario. En este caso, el componente de
base de datos de la aplicación será adjuntado con aquel disponible en el servidor
secundario. Ésta es una instancia del componente de base de datos que migra del
servidor primario al secundario. Puede describirse usando un diagrama de interacción
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
181
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
que muestra un objeto del componente que migra, además de la acción resultante de la
migración. Existen dos instancias del mismo componente mostrado, pero se diferencian
en cuanto a la localización del servidor. La Figura 6.12 muestra esta migración.
Figura 6.12: Migración del Servidor Primario al Secundario
En la Figura 6.12 se muestra la migración del servidor primario al secundario ante una
falla del servidor y el posterior retorno al servidor primario luego de la recuperación ante
la falla.
3.5 Ingeniería hacia Adelante y Reversa
La ingeniería hacia adelante es la creación del código a partir de un modelo existente.
La ingeniería en reversa es la creación del modelo a partir del código existente. Los
diagramas de componentes pueden usarse para mostrar la ingeniería hacia adelante y
en reversa. Típicamente, los diagramas de componentes ayudan a entender el tipo de
elementos que van hacia un componente. Algunas ayudas están disponibles en forma
de herramientas, las cuales permiten a los diseñadores realizar la ingeniería hacia
adelante y en reversa.
En el caso de la ingeniería hacia adelante, se necesita identificar las clases y
colaboraciones para un componente. Las clases y colaboraciones identificadas permiten
diseñar y escribir el código. El objetivo para la ingeniería hacia adelante es el código
fuente, una librería binaria o un ejecutable.
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
182
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
En el caso de la ingeniería en reversa, tanto el código fuente como las librerías binarias
pueden ser la fuente. Al código fuente se le puede aplicar ingeniería en reversa para
tener componentes seguidos por clases. A las librerías binarias se les puede aplicar
ingeniería en reversa para conocer sus interfaces.
La Figura 6.13 muestra un ejemplo de ingeniería hacia adelante. Muestra el modo en
que el componente AgenteAnalizador recibe ingeniería hacia adelante y se
convierte en un conjunto de códigos fuente y archivos de base de datos. De modo
similar, a una librería de enlace dinámico o un código fuente se le puede hacer
ingeniería en reversa para mostrar los componentes y las clases que se usaron para
construir los archivos de librería y código fuente.
Figura 6.13: Ingeniería Hacia Adelante
4. Colaboraciones
Las colaboraciones son un conjunto de clases, interfaces, nodos, componentes y casos
de uso. La colaboración especifica el modo en que los clasificadores y asociaciones
realizan un elemento. En unidades anteriores, se aprendió el modo en que un caso de
uso es realizado por una colaboración. La notación UML para la colaboración es una
elipsis con líneas punteadas. La Figura 6.14 ilustra la colaboración
AfiliacionClientes. Para el caso de estudio de la tienda de video.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
183
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Figura 6.14: Ilustración de la Colaboración AfiliaciónClientes
Las colaboraciones se ocupan de dos aspectos. Éstos son:
•
Aspectos Estructurales: Incluye clases, interfaces, nodos, componentes y
casos de uso. Típicamente, los aspectos estructurales de una colaboración son
realizados como un conjunto de relaciones entre los elementos estructurales.
Los aspectos estructurales se muestran a través de un diagrama de clases. La
Figura 6.15 muestra una vista simple de los aspectos estructurales de la
colaboración AfiliaciónClientes.
•
Aspectos de Comportamiento: Incluye los aspectos dinámicos del modo en
que los elementos estructurales interactúan unos con otros. Los aspectos de
comportamiento se describen a través del diagrama de interacción. La
colaboración proporciona el contexto en donde pueden modelarse las
interacciones. La Figura 6.16 muestra los aspectos de comportamiento para la
colaboración AfiliacionClientes.
Us uario
(fro m L o g i ca l V i e w)
E m pleado
(f ro m Lo g i ca l V i e w)
+ id_em pleado
- c argo
- fec ha_ingres o
- s tatus _e mp
+
+
+
+
+
+
+
+
nom bre
apel lido
edad
te lefono
di rec c ion
e_c i vi l
nam e
cedul a
T_c redito
(f ro m Lo g ic a l V i e w)
- num _tarjeta
- fec ha_venc im iento
- lim ite_c redito
+ inc luirE m pleado()
+ ret irarE m pleado()
Cliente
TiendaV ideo
(fro m L o g i ca l V i e w)
- r if
- nit
- no mbr e
(f ro m Lo g ic a l V i e w)
a fi li aci on
- id_ c liente
- fec ha_afiliac ion
- s tat us
c ontrato
+ ins c ribi rC lie nte()
+ retira rCli ente()
(fro m L o g i ca l V i e w )
- des c ripc ion
+ generarContrato()
Figura 6.15: Aspectos Estructurales de la Colaboración Afiliación Estudiante
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
184
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
La Figura 6.16 representa un simple diagrama de clases. El diagrama de clases
mostrado anteriormente es la realización de aspectos estructurales de la colaboración
AfilizacionClientes. Las colaboraciones ayudan a modelar el sistema desde una
perspectiva diferente conforme a las necesidades del sistema.
Figura 6.16: Aspectos de Comportamiento para la Colaboración AfiliacionClientes
En el proceso del entendimiento del sistema, los casos de uso son identificados y
diseñados. Pero en la implementación final del sistema, los casos de uso deben ser
convertidos en términos de los aspectos estructurales y de comportamiento del sistema.
Las colaboraciones se usan para modelar la realización de un caso de uso y la
implementación de una operación. La colaboración, se describe usando los aspectos
estructurales y de comportamiento. Para la colaboración especificada, esto resulta en
diagramas de clases y de interacción. En otras palabras, el caso de uso se convierte en
diagramas de clases y de interacción a través de colaboraciones. La Figura 6.17
muestra la realización de uno caso de uso por una colaboración.
Figura 6.17: Realización de Caso de Uso como Colaboración
5. Patrones
El diccionario define un patrón como una forma o modelo propuesto para imitación, por
ejemplo, un diseño. En terminología de computadoras, patrón es algo que brinda una
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
185
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
solución, en un contexto dado, para problemas comunes. Un patrón consiste de tres
elementos:
•
Contexto.
•
Problema.
•
Solución.
Cuando se enfrenta un problema, no siempre es necesario pensar en una solución
nueva y única al problema. Se puede reutilizar una solución existente en vez de dedicar
tiempo y recursos tratando de encontrar una nueva solución.
Se asumirá que se desea construir una casa. Existen diferentes soluciones para
construir una casa. Se puede construir una casa con un estilo Victoriano, Rancho,
Chalet o Europeo. Se puede hacer uso de una o más de las soluciones ya disponibles y
trabajar en la construcción de la nueva casa, quizás mejorando las características que
proporcionan las soluciones existentes. Este ejemplo da a conocer que el contexto es
conocido donde el problema ya tiene una solución. Una casa tiene dos constituyentes
importantes. Éstos son:
•
Vista Externa: Se refiere al exterior de la casa, la cual puede tener estilos
Gótico, Victoriano o Neogótico.
•
Vista Interna: Se refiere al esfuerzo dedicado al diseño de la casa, es decir, la
manera en que los techos son fijados por pilares.
Aunque las vistas son diferentes, los problemas con los que se enfrentan son comunes
y existen soluciones para estos problemas.
En terminología de software, los patrones son una parte importante del vocabulario de
un programador dado que le permiten imaginar, describir, generar y documentar
diferentes partes del sistema de software a ser desarrollado. Los patrones permiten
llevar a cabo tanto la ingeniería reversa (reverse) como la ingeniería hacia adelante
(forward).
Existen 2 tipos de patrones:
•
Patrones arquitectónicos.
•
Patrones de diseño.
Estos patrones no serán discutidos en este curso.
A continuación se aprenderá acerca de los Diagramas de Despliegue.
6. Diagrama de Despliegue
Los diagramas de despliegue (deployment) muestran la disposición de los elementos de
procesamiento en tiempo de ejecución. Estos elementos contienen componentes,
procesos y objetos. Estos elementos de procesamiento en tiempo de ejecución son
referidos como nodos que representan un recurso computacional que tiene memoria y
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
186
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
capacidad de procesamiento. Los diagramas de componentes son normalmente
combinados con diagramas de despliegue para mostrar el modo en que los elementos
físicos están distribuidos sobre diversas plataformas de hardware. Un diagrama de
despliegue es un gráfico de nodos. Cada nodo está conectado para describir la
asociación de comunicación.
Los diagramas de componentes y de despliegue son llamados colectivamente
diagramas de implementación.
6.1 Nodo
Son clasificadores que representan un recurso computacional en tiempo de ejecución.
Por ejemplo un CPU ejecutando un proceso.
Cada nodo tiene un nombre, ya sea un nombre simple o un nombre de ruta. La Figura
6.18 muestra dos ejemplos de un nodo.
Figura 6.18: Dos Ejemplos de un Nodo
La Figura muestra dos maneras en las que un nodo puede ser dibujado. En la primera
instancia, se muestra el nombre simple de un nodo junto con los componentes que
despliega. En la segunda, se muestra el nombre de paquete junto con un valor
etiquetado, el cual especifica el uso de este nodo.
Los nodos y los componentes pueden participar en relaciones de dependencia,
generalización y asociación, también pueden participar en diagramas de interacción y
se pueden crear instancias de nodos y componentes. Sin embargo, existen dos
diferencias entre nodos y componentes, éstas son:
•
Los componentes toman parte en la ejecución de un sistema, mientras que los
nodos ejecutan componentes.
•
Los componentes caracterizan el empaquetamiento de elementos lógicos como
colaboraciones y clases, mientras que los nodos representan componentes
físicamente desplegados.
Cuando un conjunto de componentes es desplegado en un nodo, el grupo es referido
como una unidad de distribución.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
187
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
La relación entre nodo y componente puede mostrarse usando la notación para relación
de dependencia.
La conexión entre dos o más nodos se hace a través de la relación de asociación, y el
mecanismo de comunicación es escrito como un estereotipo. Por ejemplo, el
mecanismo de comunicación puede ser un cable Ethernet.
La Figura 6.19 muestra dos instancias de un nodo conectado a un conjunto de
componentes.
En la Figura 6.19 se usa una simple línea recta para especificar la relación entre nodos,
describiendo la relación de asociación. La relación entre un nodo y los componentes
que despliega es una relación de dependencia.
Un diagrama de despliegue es un conjunto de nodos conectados unos con otros, sin
revelar las conexiones con los componentes que despliegan los nodos. Con la explosión
de un nodo del diagrama de despliegue, se puede obtener la vista mostrada en la
Figura 6.19.
Figura 6.19: Dos Instancias de un Nodo Conectado a un Conjunto de Componentes
Un típico diagrama de despliegue se muestra en la Figura 6.20. Se ha mostrado dos
servidores de almacenamiento temporal (caching servers) conectados a una red de
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
188
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
área local. La red local se conecta a los otros procesadores. En esta figura no se
muestra ninguno de los componentes de los cuales dependen los nodos.
Los diagramas de despliegue pueden llevar notas y restricciones tal como los demás
diagramas. Estos diagramas se usan para modelar la vista estática del sistema, llamada
la vista de despliegue. La vista incluye la distribución, entrega e instalación de los
componentes y nodos que conforman el sistema actual.
Los diagramas de despliegue se usan para modelar lo siguiente:
•
Sistemas Incorporados.
•
Sistemas Cliente-Servidor.
•
Sistemas Distribuidos.
Un sistema comprende un conjunto de elementos usados para cumplir una tarea. Un
sistema se puede categorizar en subsistemas, siendo cada subsistema un grupo de
elementos. Estos elementos pueden ser componentes, clases, interfaces, nodos y sus
relaciones. La relación entre un sistema y un subsistema se llama relación de
agregación. Esta relación denota que el sistema contiene los subsistemas.
Figura 6.20: Un Típico Diagrama de Despliegue
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
189
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Se han estado usando los términos modelo y vista en todo el curso. Ahora se
entenderán estos elementos claramente. Se establece simplemente que un modelo es
una representación. Es un tipo de paquete y por lo tanto no se proporciona una notación
separada para un modelo en UML. Un modelo posee típicamente elementos como
clases, interacciones y relaciones.
Una vista proporciona una observación del modelo. Muestra la parte relevante del
sistema según sea aplicable a la vista.
La notación usada para sistemas y subsistemas en el UML es el ícono de paquete
estereotipado.
7. Caso de Estudio: Componentes y Despliegue
Para el caso de estudio de la tienda de video, se realizarán los diagramas de
componentes y de despliegue. Para un mejor entendimiento, se describe nuevamente el
problema.
Se desea diseñar un sistema computarizado para automatizar un club de video, el cual
debe tener las siguientes características:
•
El sistema debe llevar el control de afiliación y retiro de clientes.
•
Para llenar la ficha del cliente es necesario los siguientes datos:
- Nombre completo.
- Cédula.
- Dirección.
- Teléfono.
- Edad.
- Estado civil.
- Referencias personales.
•
Como requisito de inscripción la persona debe de ser mayor de 18 años.
•
El cliente puede afiliarse por medio del sitio Web y cancelar con su tarjeta de
crédito.
•
El sistema debe permitir alquilar, reservar, devolver y comprar películas.
•
El cliente puede devolver la película por el buzón de devolución el cual
automáticamente realiza el registro.
•
Debe permitir a los clientes consultar las películas disponibles por medio de
terminales remotos instalados en la tienda.
•
Para alquilar una película el operador del sistema introduce la cédula del cliente,
luego introduce el código de la película a ser alquilada, si la cédula del cliente no
aparece en el sistema, la transacción no procede.
•
Las reservaciones son realizadas por la página Web del video.
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
190
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
•
La duración de la reservación es de 24 horas, al cumplirse el lapso, la
reservación es cancelada automáticamente y la película estaría disponible en la
existencia.
•
El sistema gestiona el pago de la película por adelantado con tarjeta de crédito,
emitiendo una factura.
•
El alquiler de las películas tiene una duración de 2 días hábiles, los días
adicionales son cobrados como días de mora.
•
Para alquilar y reservar una película es necesario ser cliente del video club.
•
El sistema debe llevar el inventario de las películas del video.
•
El club de video ya dispone un sistema contable automatizado que se comunica
con el sistema planteado.
Para el sistema de la tienda de video, se supone que el sistema está desarrollado en
Java, una de las interfaces gráficas es la pantalla de reservar películas; la misma se
compone de cajas de texto, combos, entre otros. Esa pantalla es un componente
llamado IreservarPeliculas.class, dicho componente necesita relacionarse con
otros
componentes
para
poder
funcionar
correctamente,
tales
como:
Película.class, Cliente.class, Reservación.class. En la Figura 6.21
puede observar el diagrama de componentes.
Figura 6.21: Diagrama de Componentes para la Interfaz Gráfica
IReservacionPeliculas.class.
El componente IResevacionPeliculas es dependiente de Cliente.class,
Reservación.class y Películas.class, además realiza la interfaz
IEventosReservacion.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
191
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
La Figura 6.22 muestra el diagrama de despliegue que modela las conexiones entre el
sistema central de la tienda video y los terminales donde los clientes pueden consultar
las películas. Se puede notar en la figura que la comunicación entre el nodo
SistemaCentral y el nodo Terminal es realizada por el protocolo TCP/IP. También
se puede notar que en la asociación se coloca la multiplicidad, del mismo modo, un
Sistema Central puede tener cero o muchos Terminales.
Figura 6.22: Diagrama de Despliegue
La Figura 6.23, modela cómo se realiza la comunicación entre el sitio Web de la tienda
de video, el servidor http y el servidor de bases de datos, además muestra los
componentes que juegan el papel más importante en dicho proceso. Puede notarse que
el nodo Cliente utiliza el protocolo HTTP para comunicarse con el servidor ‘HTTP’ y
el servidor HTTP accede a la base de datos por medio del protocolo ODBC. El
componente PaginaPHP-HTML depende de MotorPHP, ya que él se encarga de
interpretar el código PHP que está en la página HTML. El componente MotorPhP
depende de EjecucionBD para acceder a la base de datos.
Figura 6.23: Diagrama de Despliegue
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
192
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
En el ejemplo de trabajo, se ha concentrado solo en algunas funcionalidades del
sistema. El proceso completo de la tienda también puede ser modelado. Éste puede
seguir los mismos principios aplicados a los diversos diagramas que se han visto en los
ejemplos ilustrados en las unidades anteriores.
Con esto, se completa la discusión sobre OOAD usando los elementos de Modelado de
UML, a saber, los modelos estructurales, de comportamiento y arquitectónicos. Cada
uno de estos modelos proporciona una perspectiva diferente del sistema. Es importante
que cada modelo sea entendido desde sus bases conceptuales hasta su aplicación al
dominio de un problema. Típicamente, el análisis empieza con la identificación de los
casos de uso, derivación de clases a través de abstracciones, adjuntar
responsabilidades a las abstracciones y posicionamiento hacia la construcción del
modelo de diseño usando los diversos diagramas.
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
193
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
Resumen
Ahora que ha completado esta unidad, usted debe ser capaz de:
•
Describir componentes, nodos y colaboraciones.
•
Discutir diagramas de componentes.
•
Discutir la necesidad de Diagramas de despliegue.
•
Describir estereotipos y relaciones entre componentes y nodos.
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
194
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Examen de Autoevaluación
1) ¿Qué permiten modelar los diagramas arquitectónicos?
a) Ejecutables
b) Librerías
c) Tablas
d) Archivos
2) ¿Qué representan los componentes?
a) Abstracciones lógicas
b) Partes físicas del sistema
c) Colecciones de abstracciones lógicas
d) a y c
3) ¿Con qué clasificadores puede ser realizada una interfaz?
a) Clase
b) Componente
c) Casos de uso
d) Objetos
4) ¿Cuáles de los siguientes son tipos de componentes?
a) Componentes de desplegado
b) Componentes de producto de trabajo
c) Componentes de ejecución
d) Componentes de librería
5) ¿Cuáles de los siguientes son estereotipos que aplican a componentes?
a) Ejecutable
b) Encapsulado
c) Tabla
d) Documento
6) ¿De qué se ocupan las colaboraciones?
a) Relaciones es-un
b) Relaciones tiene-un
c) Aspectos estructurales
d) Aspectos de comportamiento
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
195
Análisis y Diseño de Sistemas Orientado a Objetos
Guía del Estudiante
7) ¿Para qué se usan las colaboraciones?
a) Para modelar la realización de casos de uso
b) Para la implementación de una operación
c) Para el paso de mensajes
d) Para el manejo de excepciones
8) ¿Cuáles de los siguientes elementos son usados típicamente en los diagramas de
componentes para modelar?
a) Sistemas Adaptables
b) Ingeniería hacia Adelante y en Reversa
c) Elementos Estructurales
d) Elementos de comportamiento
9) La ingeniería hacia adelante es la creación del código a partir de un modelo
existente.
a) Verdadero
b) Falso
10) ¿Cuáles de los siguientes son verdaderos con respecto a diagramas de
despliegue?
a) Los diagramas de despliegue muestran la disposición de los elementos de
procesamiento en tiempo de ejecución.
b) Un diagrama de despliegue es un grafo de nodos.
c) La relación entre diagramas de componentes y de despliegue es fuerte.
d) Los diagramas de despliegue y los diagramas de interacción tienen una fuerte
relación.
Unidad 6: Modelado Arquitectónico
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
196
Guía del Estudiante
Análisis y Diseño de Sistemas Orientado a Objetos
Respuestas a Unidad 4: Examen de Autoevaluación
1) a, b, c y d
2) b
3) a y b
4) a, b y c
5) a, c y d
6) c y d
7) a y b
8) a y b
9) a
10) a, b y c
Libro 1: Análisis y Diseño de Sistemas Orientado a Objetos
Unidad 6: Modelado Arquitectónico
© Copyright IBM Corp. 2007
Los materiales del curso no pueden ser reproducidos total o
parcialmente sin previo permiso escrito de IBM.
197