Libro 1 Completo UML V51

Anlisis y Diseo de
Sistemas Orientado a
Objetos
Versin 5.1
Libro 1
Anlisis y Diseo de
Sistemas Orientado a
Objetos
Cdigo de Curso: CY450
Versin 5.1
Gua del Estudiante
Libro 1: Anlisis y
Diseo de Sistemas
Orientado a Objetos
IBM IT Education Services

Worldwide Certified Material
Informacin de la Publicacin
Esta publicacin 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 compaas, productos, y nombre de servicios pueden ser marcas registradas o
marcas de servicios de otros.
Marcas Registradas de otras compaas segn se muestra
Windows
Microsoft Corporation
Red Hat Linux
Red Hat
Edicin Diciembre 2007

La informacin contenida en este documento no ha sido sometida a ninguna prueba
formal de IBM y est distribuida en base a como est sin ninguna garanta expresa o
implcita. El uso de esta informacin o la implementacin de cualquiera de estas
tcnicas 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 situacin especfica, no hay
garanta de que los mismos resultados o similares, funcionarn en otra parte. Los
clientes que intenten adaptar estas tcnicas 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.
Gua del Estudiante
Anlisis y Diseo de Sistemas Orientado a Objetos
Contenido
Descripcin del Curso........................................................................................1
Descripcin de Unidades ...................................................................................3
Volumen 1: Modelado Bsico ............................................................................6
Unidad 1: Introduccin a UML ...........................................................................7
1. La Necesidad del Anlisis y Diseo Orientado a Objetos (OOAD)
2. Fundamentos de la Orientacin a Objetos
12
3. Importancia del Modelado
19
4. UML
19
5. El Modelo UML
19
Resumen
19
Unidad 1: Examen de Autoevaluacin
19
Respuestas a la Unidad 1: Examen de Autoevaluacin
19
Unidad 2: Modelado del Comportamiento con Casos de Uso ......................19

1. Introduccin
19
2. Importancia de los Casos de Uso
19
3. Casos de Uso
19
4. Anlisis 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
19
Respuestas de la Unidad 2: Examen de Autoevaluacin
19
Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso.........19

1. Ejercicio de Laboratorio
19
Unidad 4: Modelado Estructural Bsico .........................................................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.
Gua del Estudiante
19
19
Volumen 2: Modelado Avanzado .....................................................................19

Unidad 1: Modelado Estructural Avanzado ....................................................19
1. Introduccin
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 Realizacin
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
19
19
Unidad 2: Laboratorio de Modelado Estructural Avanzado ..........................19

Ejercicio de Laboratorio
19
Unidad 3: Modelado de interaccin.................................................................19

1. Introduccin
19
2. Interaccin
19
3. Colaboracin
19
4. Diagramas de Interaccin
19
5. Manejar Tiempo y Espacio
19
6. Cmo Crear un Diagrama de Colaboracin
19
Resumen
19
19
Respuestas a Unidad 3: Examen de Autoevaluacin
19
Unidad 4: Lab. de Modelado de Interaccin ...................................................19

ii
Gua del Estudiante
19
Unidad 5: Modelado de Comportamiento Avanzado .....................................19

1. Introduccin
19
2. Mquinas 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
19
Resumen
19
19
19
Unidad 6: Modelado Arquitectnico................................................................19

1. Introduccin
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
19
19
iii
Gua del Estudiante
Descripcin del Curso

Nombre del Curso
Anlisis y Diseo de Sistemas Orientado a Objetos.
Duracin
La duracin de este curso es de 40 horas acadmicas.
Propsito
El propsito de este curso es obtener conocimientos y destrezas en el manejo de los
Principios de la Orientacin a Objeto y en el Lenguaje Unificado de Modelado UML
(Unified Modeling Language), considerado como un estndar de la industria del
software para apoyar el anlisis y diseo 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 construccin (que incluyen mas de nueve
diagramas), las reglas que ayudan a juntar esos bloques de construccin y algunos
mecanismos de extensin.
Audiencia
Estudiantes, profesionales y desarrolladores que desean conocer acerca de Anlisis y
Diseo de Sistemas Orientado a Objetos.
Prerrequisitos
Introduccin a las computadoras personales y a Windows XP.
Fundamentos a la programacin Orientada a Objetos.
Objetivos del Curso

Al final de este curso Ud. ser capaz de:
Describir la necesidad del estudio del Anlisis y Diseo Orientado a Objetos.
Conocer los conceptos bsicos del paradigma orientado a objetos.
Describir la importancia del modelado UML.
Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos
Descripcin del Curso 1

Gua 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 especificacin UML 1.x y la especificacin UML

2.0.
Describir el uso y funcionamiento de los diagramas de la especificacin UML 2.0

en el aspecto estructural y de comportamiento.
Aprender a manejar herramientas de modelado.
Agenda
Cada unidad del curso tiene una duracin de 2 a 3 horas acadmicas.
Unidad 1:Programacin en C Los Primeros Pasos
Volumen 1: Fundamentos de C

Los materiales del curso no pueden ser reproducidos en parte
o en su totalidad sin el previo permiso escrito de IBM.
Gua del Estudiante
Descripcin de Unidades
Volumen 1: Modelado Bsico
Unidad 1: Introduccin a UML
Esta unidad comienza dando la motivacin para el estudio del Anlisis y el Diseo
Orientado a Objetos. Ayuda a entender los diversos principios de orientado a objetos y
proporciona una introduccin 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 entendera el usuario. Este tipo de diagramas es muy usado en el
transcurso del levantamiento de informacin, debido a que el usuario puede tener una
mejor visin del sistema sin entrar en profundidad de programacin.
Unidad 3: Laboratorio de Modelado del Comportamiento con Casos de

Uso
Esta unidad pretende poner en prctica los conocimientos adquiridos en la unidad
anterior, utilizando un ejercicio prctico de laboratorio.
Unidad 4: Modelado Estructural Bsico

En esta unidad se discute uno de los diagramas ms 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 esttica del sistema.
Volumen 2: Modelado Avanzado

Unidad 1: Modelado Estructural Avanzado
Esta unidad se refiere a los diferentes tipos de clasificadores, adems de proporcionar
mayor informacin sobre interfaces, tipos y paquetes. Discute diagramas e instancias de
objetos. Ayuda al estudiante a aprender cmo 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.
Descripcin de Unidades 3

Gua del Estudiante
Unidad 3: Modelado de Interaccin

Esta unidad proporciona detalles de dos de los diagramas ms importantes para
modelar la dinmica de un sistema, estos diagramas son: Diagramas de secuencia y
diagramas de colaboracin. Los diagramas de interaccin describen el modo en que los
grupos de objetos colaboran para realizar un trabajo y la subclasificacin (Diagramas de
secuencia y colaboracin) permite ver esa colaboracin de dos maneras distintas pero
compatibles.
Unidad 4: Laboratorio de Modelado de Interaccin

Esta unidad de Laboratorio se construye sobre la base de la unidad anterior en el
modelado de interaccin y ayuda a aprender a crear Diagramas de secuencia y
colaboracin 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 seales, mquinas de estado y mtodos de
construccin de diagramas de mapa de estado con cierto detalle. Una enumeracin
breve de las diferencias y similitudes entre procesos e hilos se proporciona como una
base conceptual.
Unidad 6: Modelado Arquitectnico

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
acadmico. Esta unidad enfatiza los componentes, el despliegue y las colaboraciones.
Proporciona detalles de diagramas de componente y diagramas de despliegue.
Volumen 3: Introduccin a UML 2.0 y a Herramientas de Modelado

Unidad 1: Introduccin a UML 2.0 (Diagramas Estructurales)
Esta unidad proporciona una introduccin a la nueva versin de UML llamada UML 2.0.
Explica los cambios ms relevantes entre esta nueva versin y las versiones anteriores
de UML. Tambin, se enumeran las diferencias entre los diagramas estructurales del las
versiones 1.X y la versin 2.0. Se explican de forma bsica los nuevos diagramas de la
nueva especificacin.
Unidad 2: Introduccin a UML 2.0 (Diagramas de Comportamiento)

En esta unidad se explican de manera bsica los diagramas de comportamiento de la
nueva versin de UML, tales como: Diagramas de Casos de Uso, Diagramas de
Actividad, Diagramas de interaccin, Diagramas de Mquinas de Estado, as como
tambin se detallan los nuevos diagramas incluidos en la versin 2.0 de UML.

Gua del Estudiante
Apndice A: Manejo de la Herramienta EclipseUML Free Edition

Esta unidad proporciona una introduccin a la herramienta EclipseUML Free Edition, el
cual es un plugin para ser instalado en la Plataforma Eclipse. Aqu se explica cmo
crear nuevo proyecto en eclipse, como crear paquetes, instalacin en windows y linux,
como crear un diagrama UML y la barra de herramientas de cada tipo de diagrama,
proporcionndole al estudiante las prcticas necesarias para el manejo de herramientas
de modelado.
Apndice B: Manejo de la Herramienta Rational Software Modeler

Esta unidad proporciona una introduccin a la herramienta Rational Software Modeler,
la cual es la herramienta por excelencia de IBM para modelado con UML. Aqu, se
explican cmo crear diagramas, exportar a imagen, crear proyectos, ingeniera hacia
delante y reversa, entre otras caractersticas, proporcionado al estudiante prcticas para
realizar modelos UML en esta herramienta.
Descripcin de Unidades 5

Gua del Estudiante
Volumen 1: Modelado Bsico

Gua del Estudiante

Objetivos de Aprendizaje
Al final de esta unidad, usted ser capaz de:
Describir la necesidad del Anlisis y Diseo Orientado a Objetos (Object

Oriented Analysis and Design - OOAD).
Explicar los principios de la orientacin a objetos.
Describir el trabajo del Lenguaje Unificado de Modelado (Unified Modeling

Language - UML).
Describir la importancia del modelado en UML.
Unidad 1: Introduccin a UML 7

Gua del Estudiante
1. La Necesidad del Anlisis y Diseo Orientado a

Objetos (OOAD)
El desarrollo de aplicaciones de software es fundamentalmente un proceso complejo,
por lo que, entender, disear, 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.
Disear 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 ms documentos (reportes o

cdigo). Estos documentos son llamados productos de trabajo y permiten comprender el
sistema en cada etapa.
Despus 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 anlisis 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 da debido a que los dominios de aplicaciones de
software son cada vez ms variados y complejos. La etapa de analizar los
requerimientos da origen a un producto de trabajo llamado especificacin de
requerimientos de software.
El producto de trabajo de la tercera etapa, correspondiente a disear el sistema, es el
documento de diseo. En la etapa de implementacin, el sistema resulta en la creacin
de manuales de diversos tipos, tales como: el manual de usuario, manual administrativo
y otros. En algunos casos, cualquier tipo de cdigo que se use en la parte inicial de la
implementacin es tambin documentado.
La fase de prueba crea productos de trabajo en las siguientes reas:
Metodologas 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 voltiles 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 difcil. El anlisis y
diseo de sistemas complejos es un proceso difcil que demanda tiempo. Las
Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos 8

Gua del Estudiante
metodologas de anlisis y diseo 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 ms desafiante.
OOAD tiene la capacidad inherente para ocuparse de los diferentes aspectos de
sistemas de software complejos. Mientras la metodologa de anlisis y diseo
estructurado construye un sistema usando funciones, la orientacin 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 difcil transferir conocimiento del mundo real al dominio del
software, usando la orientacin a objetos.
Para mostrar la importancia de OOAD, se muestra una narracin de la construccin del
buque de guerra Vasa, ms conocida como la Tragedia de Vasa.
El Rey Gustav de Suecia, quien obtuvo grandes victorias en las Guerras Blticas,
anhelaba poseer el mejor buque insignia en toda Europa. l quera 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 construccin 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 especificacin escrita. Hybertzoon decidi que el
barco deba tener una longitud de 108 pies y orden que se cortara la madera del
bosque de robles de acuerdo a eso. La construccin estaba progresando hasta que un
da el Rey vino a inspeccionar. l consider que la longitud del barco deba
incrementarse en otros 35 pies. Despus de todo, iba a ser el orgullo de la Marina
Sueca, pero Hybertzoon ya haba cortado la madera y haba terminado de construir la
quilla del barco. La quilla deba 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
tambin estaba construyendo un buque insignia. Tambin se enter que el barco Dans
iba a tener tres cubiertas de caones mientras que su barco tena slo dos! El ego del
Rey Gustav no pudo soportar esto. l orden que se instalara en su buque insignia otra
cubierta de caones con 50 caones de bronce (cada uno pesando ms de una
tonelada). Tambin orden que su barco fuera completado antes de la fecha estimada
original. El dinero no iba a ser un obstculo para este proyecto. Hybertzoon no era
capaz de convencer al Rey de que no era posible hacer cambios estructurales
importantes despus de que la quilla haba sido colocada y se haba hecho el
entarimado. Hybertzoon acept las demandas imposibles del Rey, pero muri antes de
completar la tarea, quizs debido al stress. La tarea de completar el proyecto fue dada a
su hermano, Arent Hybertzoon de Groote, a pesar de su relativa inexperiencia.

Gua del Estudiante
A principio del Siglo 17, los constructores de barcos estaban an por empezar a utilizar
mtodos analticos para construir barcos. Ellos solamente hacan suposiciones bien
fundamentadas acerca de las especificaciones del barco y aprendan a travs 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 clculos para el buque insignia Sueco. Tampoco otros tems
como un horno de cocina que se aadira al peso total. El constructor del barco crey
que el entarimado adicional en los lados y un lastre adicional de 130 toneladas se
encargaran del asunto. El entarimado fue completado, pero el constructor del barco se
dio cuenta entonces que no haba espacio bajo la cubierta para otras 130 toneladas de
roca para proporcionar lastre. Este aspecto fue ignorado completamente.
Despus 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 ocasin, pero nadie supo cmo 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. Difcilmente, el barco haba
navegado apenas unos cuantos kilmetros cuando una pequea rfaga 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 construccin de barcos era un trabajo artesanal. Se practicaba con poco

nfasis en algn mtodo cientfico o de ingeniera.
El Rey no dio especificaciones por escrito. Todos los requerimientos del barco
fueron recogidos verbalmente.
No se aplicaron mtodos de diseo. 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 construccin del barco no se conocan.
La prueba no se condujo cientficamente y cualquier indicacin de algn

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 relacin con lo que sucede tpicamente en
un esfuerzo de desarrollo de software. La construccin de barcos era una tarea grande
y compleja. Los sistemas complejos del mundo real requieren adems que el desarrollo
de sistemas sea dirigido de la manera correcta. Con la llegada del anlisis y diseo
estructurado de sistemas de software, se proporcion un enfoque de ingeniera para el
desarrollo de sistemas de software. Para la mayora de los puntos cubiertos
anteriormente, la metodologa de anlisis y diseo estructurado se ocup de ellos. Sin
embargo, la metodologa no proporcion una solucin para hacer corresponder
directamente los objetos del mundo real en el dominio de software. La orientacin a

Gua del Estudiante
objetos ofrece una solucin que ayuda a los desarrolladores a hacer corresponder el
mundo real tan cerca como sea posible al dominio de la solucin. Existen muchas
metodologas que permiten soluciones para problemas complejos. A continuacin, se
discutirn brevemente las diversas metodologas disponibles y luego se estudiar en
detalle la orientacin a objetos.
Orientada a Aspectos: La Programacin 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 semntica de los componentes en forma sistemtica
(Ejemplo: sincronizacin, manejo de memoria, distribucin, etc.). La POA es una
nueva metodologa de programacin que implica separar la funcionalidad bsica
de los aspectos y los aspectos entre s. Esta separacin se realiza a travs de
mecanismos que permitan la abstraccin y la composicin de los mismos, a fin
de poder implementar todos los requerimientos del sistema.
Literal: Esta metodologa combina un lenguaje de programacin y uno de

documentacin. Donald Knuth es el inventor de la programacin literal. El
propsito de esta metodologa es mejorar la capacidad para la documentacin
del lenguaje de programacin nativo. Un programa es tratado tpicamente como
una pieza de literatura. Tambin puede verse en el modo hipertexto.
Estructurada: Esta metodologa es la ms usada y la mayora est familiarizada

con ella. Lenguajes como BASIC, Pascal, COBOL y C son algunos de los
ejemplos que pueden ser usados para programar usando esta metodologa. La
programacin estructurada permite organizar programas en una jerarqua de
mdulos. Cada mdulo tiene un solo punto de entrada y, a menudo, un solo
punto de salida.
Orientada a Objetos: Esta metodologa se basa en modelar el mundo real y ha

ganado importancia significativa en los ltimos tiempos. En la orientacin a
objetos se trabaja con objetos en el sistema que interactan unos con otros a
travs de mensajes. La orientacin a objetos proporciona los recursos para
ocuparse de los objetos de un sistema complejo. El anlisis y diseo de un
sistema desde una perspectiva orientada a objetos forma el ncleo de este
curso. Se aprender todo acerca de la orientacin a objetos a medida que se
avance en el curso.
Patrones: De acuerdo con Dirk Riehle y Heinz Zullighoven, un patrn es la

abstraccin de una forma concreta, la cual reaparece frecuentemente en
contextos especficos no arbitrarios. Dr. Christopher Alexander, un arquitecto,
concibi el concepto de patrones en el planeamiento urbano y arquitectura de
construcciones. La aplicacin 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 patrn es una regla de tres partes, la cual expresa una relacin
entre un cierto contexto, un problema y una solucin.
Cualquiera de las metodologas mencionadas anteriormente para desarrollar un

sistema, seguir el proceso del ciclo de vida de desarrollo de software.

Gua del Estudiante
Indiferentemente de la metodologa subyacente, el entender los requerimientos,

analizarlos, disear el sistema, implementarlo y probarlo son etapas esenciales de un
proceso de construccin de sistema. Por lo tanto, cada metodologa requerir un
traductor de requerimientos, un analista de requerimientos, un analista de sistemas, un
diseador de sistemas, un programador y un probador, para llevar a cabo las diferentes
etapas del proceso de construccin de sistemas.
2. Fundamentos de la Orientacin a Objetos

Antes de continuar y aprender acerca del Lenguaje de Modelado Unificado (UML), se
discutirn brevemente los principios de la orientacin a objetos.
2.1 Modelado del Mundo Real

El creciente poder de la computacin y la tecnologa ha dado lugar a muchos esfuerzos
de desarrollo de sistemas grandes y complejos. El modelado del mundo real forma la
base para la orientacin a objetos y ayuda a los analistas de sistemas a entender mejor
el sistema.
A continuacin se presentan los requerimientos recopilados para automatizar el pago de
cuentas a travs de la Internet.
Se requiere que el cliente llene un formulario de aplicacin para permitir el pago de
cuentas a travs de los servicios ofrecidos por BillPaymentJunction, Inc.
En el paradigma de anlisis y diseo estructurado, el escenario anterior se pensara de
forma lgica en trminos de las funciones llenarFormularioAplicacin() y pagarFactura().
El paradigma de anlisis y diseo estructurado no est basado en modelar el mundo
real. En la orientacin a objetos, se intentar modelar el mundo real y los objetos del
mundo real. Se aprecia que el mundo real tiene clientes, formularios de aplicacin,
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 aplicacin, 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 orientacin a objetos, el modelado de la vida real resulta en tipos de dato
abstracto. Un tipo de dato abstracto es un modelo matemtico. Las operaciones son
definidas en el modelo para permitir la aplicacin del tipo de dato en un entorno de
programacin. Algunos se refieren a la programacin orientada a objetos como
programacin de los tipos de dato abstracto. Las entidades Cliente y Formulario
Aplicacin del ejemplo presentado en la seccin anterior son tipos de dato abstracto.
En la orientacin a objetos, se trabaja principalmente con datos. Por tanto, las

Gua del Estudiante
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 Abstraccin de Datos

La abstraccin de datos es fundamental para el pensamiento orientado a objetos. La
abstraccin 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 simultneamente. Se
necesita superar la complejidad para poder resolver los problemas. La abstraccin es
una manera conveniente de manejar la complejidad. El Institute of Electrical and
Electronics Engineers Inc. - IEEE define la abstraccin como una visin del problema
que extrae la informacin esencial relevante a un propsito particular e ignora el resto
de la informacin.
Dicho simplemente, la abstraccin 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 ttulo, nombre de la editorial, fecha de
publicacin, nmero de edicin, precio y autor. El mismo libro, desde el punto de vista
de la editorial, puede verse que tiene un ttulo, nmero de pginas, rea impresa del
libro y muchas otras cosas relacionadas a la publicacin del libro. De modo similar, en
una aplicacin, la abstraccin de una entidad se basa en su necesidad y relevancia en
la aplicacin.
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 slo tengan que comprender su interfaz,
olvidndose de cmo est implementada, y en definitiva, reduciendo la complejidad de
utilizacin.
La utilidad del encapsulamiento se ve en la reduccin de la complejidad, esto es debido
a que las Clases se comportan como cajas negras donde slo 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
estn implementadas y los usuarios no estn preocupados por conocerlas.
En la orientacin 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.

DATOS /
CARACTERSTICAS
Gua del Estudiante
OPERACIONES
Figura 1.1: Datos y Operaciones en el Paradigma Procedimental
En el paradigma orientado a objetos, los datos y las operaciones estn juntos dentro de
una cpsula, 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 Informacin

El encapsulamiento conlleva al ocultamiento de la informacin, esto es, tanto los datos
como la implementacin de las operaciones de un objeto son ocultados al usuario. Por
lo general, la mayora de las personas que ve televisin no sabe o no se preocupa de la
complejidad electrnica que hay detrs de la pantalla, ni de todas las operaciones que
tienen que ocurrir para mostrar una imagen en la pantalla. La televisin hace lo que
tiene que hacer sin mostrarnos el proceso necesario para ello, esto es, ocultamiento de
la informacin. Al tener encapsulado juntos los datos miembros y las diferentes
operaciones, el usuario debe saber cmo acceder a las operaciones para trabajar con
los datos.

Gua del Estudiante
2.6 Clase
Las clases son tipos de datos definidos por el usuario. Las clases, en la tecnologa
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 solucin en la tecnologa 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
depsito de plazo fijo. Los clientes usan formularios de depsito 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 diseado para este propsito. 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 descripcin,
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
Depsitos
Figura 1.3: Correspondencia de Entidades del Mundo Real a Clases en el Escenario

Bancario
2.7 Objeto
En trminos sencillos, un objeto es una instancia de una clase. Los objetos interactan
con otros para proporcionar una solucin 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
slo 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.

Gua del Estudiante
Un objeto promete cumplir el contrato prometido por su clase. Cada objeto puede
definirse en trminos 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 fcil caracterizar
un carro como estar en movimiento o esttico. El objeto carro puede poseer otras
propiedades fsicas como modelo, ao de fabricacin, tamao de tanque de
combustible, nmero de llantas, caractersticas de seguridad y nmero 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 estticas,
elemento_pila y tope_de_pila. Los valores que tienen son dinmicos por
naturaleza, dado que pueden cambiar con el paso del tiempo. Un objeto conoce
su estado en cualquier instante de tiempo. En la orientacin a objetos, un objeto
conoce acerca de s mismo y revela su estado a travs 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 definicin de clase debe existir para que los
objetos sean creados y para interactuar unos con otros. Es a travs de la interaccin de
objetos que funciona el sistema completo orientado a objetos.
2.8 Interfaz e Implementacin

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.
Implementacin.

Gua del Estudiante
Una interfaz es la forma en la cual se presenta la clase al mundo real. Una

implementacin es el mtodo que se sigue para hacer que el objeto de la clase realice
sus responsabilidades.
Considere el siguiente ejemplo para entender la distincin entre interfaz e
implementacin:
El aire acondicionado de un automvil es una interfaz con mtodos definidos como:
Distribuir el aire(), enfriar el aire(), entre otros, pero cada automvil implementa estos
mtodos segn sus caractersticas, por ejemplo la distribucin de aire de una camioneta
Pick-up no puede ser la misma que la de una camioneta VAN, ya que esta ltima
necesita ms 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 mayora 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 cmo la entidad satisface el requerimiento. El qu describe la
interfaz de la entidad y el cmo proporciona la implementacin de la entidad. Esta
distincin es crucial para el desarrollo orientado a objetos.
2.9 Mtodos
En la mayora de los lenguajes orientados a objetos, las operaciones que puede realizar
un cliente sobre un objeto se declaran como mtodos. Los mtodos son una parte de la
declaracin de la clase. C++ usa el trmino funcin miembro y Java usa el trmino
mtodos para denotar el mismo concepto. Se usarn estos trminos de modo indistinto.
Los mtodos 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 mtodo.
2.10
Mensajes
Los objetos se comunican unos con otros a travs de mensajes. Un mensaje es un

pedido a un objeto para que realice una tarea a travs de un mtodo 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 accin es iniciada. El
objeto receptor satisface el requerimiento del objeto iniciador aceptndolo e
implementando la tarea.
Un buen ejemplo de la vida real podra ser un televisor y su control remoto, cuando
usted desea ver un programa en especial, busca el control remoto y presiona el botn
de encendido. En ese momento el control remoto le enva literalmente al televisor un
mensaje para que se encienda. El televisor recibe el mensaje, lo identifica como una
peticin y la realiza.

Gua del Estudiante
Un mensaje puede cambiar el estado del objeto receptor. Un mensaje puede tener cero
o ms argumentos explcitos. En este contexto, el objeto receptor es un argumento
implcito que siempre est presente. El mensaje retorna un valor de cierto tipo,
posiblemente void, al emisor del mensaje. Tpicamente, 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. Tambin 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 Vehculo y Carro.
SuperClase
SubClase
Vehculo
Carro
Figura 1.4: Herencia entre Vehculo y Carro
La subclase no slo 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 tambin aumentar
los servicios proporcionados por la superclase. La superclase se denomina tambin la
clase base, mientras que la subclase es tambin referida como la clase derivada.
Ahora, Por qu una clase debe heredar la estructura y comportamiento de otra clase?
La superclase publica algunas caractersticas que son ms generales por naturaleza.
Las subclases pueden especializarse en estas caractersticas al heredar la clase
original y redefinir aquellas caractersticas. Por lo tanto, la herencia se refiere a una
relacin de generalizacin-especializacin entre clases.

Gua del Estudiante
Por ejemplo, animal es una categora 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, tambin 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 tambin tiene algunas excepciones. Mientras casi todas las aves tienen la
habilidad de volar, algunas aves como el avestruz no pueden volar. La especializacin
puede ocuparse tambin de tales excepciones.
La jerarqua de herencia especifica la relacin es un entre la subclase y la superclase.
Es tambin 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
Extensin
Profesor
Profesor
Contratado
Staff
Administrativo
Profesor
Temporal
Figura 1.5: Jerarqua de Herencia
La Figura 1.5 describe una jerarqua 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 jerarqua es un se listan a continuacin:
Bsqueda binaria es un tipo de algoritmo de bsqueda.
Estudiante es una persona.

Rosa es una flor.
Animal es un ser vivo.
Humano es un mamfero.
Carro es un tipo de vehculo.
Pantaln es un tipo de prenda de vestir.
Lapicero es un tipo de instrumento de escritura.
Gua del Estudiante
Los objetos que son diseados cuidadosamente para ser muy generales pueden ser
reutilizados en muchas circunstancias, ahorrando mucho esfuerzo en futuros problemas
de programacin. La herencia que se ha visto hasta ahora es conocida como herencia
simple.
Es tambin posible para una subclase heredar de dos superclases. En esa situacin, la
herencia se conoce como herencia mltiple. Los animales anfibios, como la rana y la
tortuga, son ejemplos de esto. Se muestra un ejemplo en la Figura 1.6.
Animal
Animal
Acutico
Animal
Terrestre
Animal
Anfibio
Figura 1.6: Herencia Mltiple
Sin embargo, la herencia mltiple puede crear problemas. Tanto Animal Terrestre
como Animal Acutico, por ejemplo, pueden definir un mtodo llamado mtodo de
respiracin. Evidentemente, Animal Terrestre respira a travs de la nariz, mientras
que Animal Acutico respira a travs de agallas. Ahora, con herencia mltiple, Cul
de los mtodos de respiracin hereda Animal de anfibio?. Esto se conoce como el
problema del diamante. La jerarqua mostrada en la Figura 1.6 describe un problema
de diamante.

Gua del Estudiante
Cabe destacar que no todos los lenguajes de programacin implementan la herencia

mltiple. C++ usa la palabra reservada virtual durante la herencia para indicar que slo
una copia del mtodo es derivada en la subclase. En el caso de Java no proporciona
dicha capacidad.
2.12
Agregacin
Se estudi que la herencia proporciona una jerarqua de generalizacin-especializacin.

Es tambin 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 relacin de contenedor
cuando se asevera de esta manera. Esto es conocido como una relacin 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: Relacin Tiene un (has a)
La figura anterior describe la relacin tiene un entre Carro y las otras entidades.
Denota que la entidad Carro tiene Puertas, Asientos y un Cap. La relacin tiene un es
conocida tambin como la relacin contenedora.
A veces, se tiende a confundir la relacin contenedora entre dos entidades. Se
entender esto con un ejemplo. Considere las dos entidades, Persona y Bebida. En
espaol, 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 aseveracin no es verdadera
con respecto a Persona y Bebida. Ellas existen separadamente y la entidad Persona
slo es capaz de beber la Bebida, no de contener la entidad Bebida.
Es tambin incorrecto indicar, Lapicero tiene un Color. Color es un atributo de un
Lapicero, no una entidad. Las caractersticas de cualquier entidad sern indicadas en
espaol como la entidad tiene caractersticas. Por eso las propiedades no califican
para que se les llamen entidades. Las jerarquas es un y tiene un son slo entre dos
entidades.
Algunos ejemplos de una relacin tiene un se listan a continuacin:
Libro tiene Prrafos.
Prrafo tiene Palabras.
Sistema de Computadora tiene un Teclado.

Aves tienen Alas.
Edificio tiene Cuartos.
Gua del Estudiante
Entender la distincin entre la relacin 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 operacin 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, da, mes y ao (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 programacin 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 slo un nombre fecha y proporcionar tres diferentes
funcionalidades. La correspondencia entre la llamada actual y la implementacin de la
funcionalidad depender de los argumentos pasados con la llamada. Polimorfismo
significa un nombre, mltiples funcionalidades.
2.14
Tipo
Un tipo (type) es un estereotipo de una clase. Un estereotipo permite al diseador crear

nuevos bloques de construccin extendiendo bloques existentes. Se usa el tipo para
especificar un dominio de objetos y sus operaciones. Las implementaciones de estas
operaciones no estn incluidas en el tipo. Se usa el tipo cuando se desea modelar el
significado de una abstraccin y la adherencia de la abstraccin a una interfaz.
Tpicamente los tipos se usan para representar estructuras de datos. Por ejemplo, una
entidad estudiante se puede disear con una interfaz, mientras que la estructura de
datos que representa los detalles de un estudiante, como la estructura de datos lista, se
puede disear 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.

Gua del Estudiante
2.16
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 mdulos, donde los elementos de la funcin son agrupados.
A continuacin se discutir la importancia del modelado.
3. Importancia del Modelado

Un modelo es una representacin de la realidad. Grady Booch, James Rumbaugh e Ivar
Jacobson definen un modelo como una simplificacin de la realidad. Un modelo
proporciona el diseo 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
construccin. Un lenguaje de modelado consiste tpicamente de elementos del modelo,
notaciones y directivas. Para ocuparse de los sistemas complejos, es esencial la
visualizacin. La visualizacin del sistema se convierte a un formato entendible por los
desarrolladores usando una tcnica 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 continuacin 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 tambin 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 metodologa, 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 estndar para el desarrollo de sistemas Orientados a Objetos. UML fue
desarrollado en Rational Software Corporation, con contribuciones de otros
metodologstas, lderes, vendedores de software y muchos usuarios. Hoy da, UML es
considerado el estndar de la industria para el desarrollo de sistemas de software
orientados a objetos.

Gua del Estudiante
Antes de UML, existieron tres metodologas populares de desarrollo de sistemas

Orientados a Objetos, cada cual un invento de los tres autores anteriores. La
metodologa de Grady Booch fue llamada Boochgrams. La tcnica de James Rumbaugh
era conocida como Tcnica de Modelado de Objetos (Object Modeling Technique OMT) y el mtodo de Ivar Jacobson fue llamado Ingeniera 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 distribucin e implementacin (deployment).
5. El Modelo UML
Para entender UML en su totalidad, se deben aprender tres importantes elementos. Son
estos:
Bloques de construccin de UML.
Reglas que ayuden a agrupar los bloques de construccin.
Mecanismos comunes aplicados en el proceso de uso del lenguaje de

modelado.
La estructura de los bloques de construccin de UML se describe en la Figura 1.8.

Gua del Estudiante
Figura 1.8: Estructura de Bloques de Construccin de UML
A continuacin se discute cada elemento, relacin y diagrama.
5.1 Bloques de Construccin

Los bloques de construccin 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 estticas.

No revelan un comportamiento dinmico. Forman los nombres para el modelo
UML. Representan ya sea un elemento fsico 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.

Gua del Estudiante
- Interfaz: Es un conjunto de operaciones que revela los servicios ofrecidos por

una clase o componente.
- Caso de Uso: Es una descripcin 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 interacta con algn aspecto del sistema. Una definicin
formal de caso de uso ser proporcionada en el Volumen 2, Unidad 1
Modelado Bsico del Comportamiento.
- Colaboracin: Es la realizacin de un caso de uso.
- Clase Activa: Es una clase cuyos objetos pueden poseer uno o ms procesos.
Tales objetos pueden iniciar una actividad de control.
- Componente: Es la parte reemplazable de un sistema. Tal reemplazo es
posible slo 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 ejecucin. Es un elemento estructural fsico.
Elementos de Comportamiento: Los elementos que representan el modelo

dinmico se denominan elementos de comportamiento. Se tienen dos elementos
de comportamiento: Interaccin y Mquina de Estado. Las interacciones son
mensajes que son pasados entre objetos para permitirles interactuar unos con
otros para acometer una tarea particular. Una mquina de estado describe los
diferentes estados que atraviesa un objeto en respuesta a eventos.
Elementos de Agrupacin: Partes del modelo UML que representan aspectos

organizacionales son llamados elementos de agrupacin. El paquete es el nico
elemento de agrupacin. Un paquete se usa para organizar elementos
cohesivos en grupos.
Elementos de Anotacin: Estos elementos se usan para describir las partes de

UML. Se tiene un elemento de anotacin 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 relacin semntica entre dos elementos. Un cambio en

un elemento puede causar un cambio en el elemento dependiente.
Asociacin: Es una relacin estructural. Es el enlace entre dos o ms objetos

en el sistema. Es a travs de la asociacin que los objetos interactan unos con
otros para cumplir tareas especficas.
Generalizacin: Es la relacin de generalizacin / especializacin. El objeto

especializado, el hijo, hereda los atributos, operaciones, relaciones y semntica
de la clase generalizada, el padre.
Realizacin: Esta relacin existe entre las interfaces y las clases o

componentes que realizan las interfaces. Tambin existe entre casos de uso y
las colaboraciones que realizan los casos de uso. La relacin de realizacin

Gua del Estudiante
describe la relacin semntica. Se aprender posteriormente ms acerca de la

relacin de realizacin.
5.4 Diagramas
Un diagrama es una representacin grfica. 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. Tambin muestra el enfoque de control de cada objeto que participa
en un escenario.
Diagrama de Colaboracin: Muestra la organizacin estructural de objetos que

interactan unos con otros.
Diagrama de Estados: Se usa para representar mquinas 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 organizacin y dependencias entre un

conjunto de componentes en el sistema.
Diagrama de Distribucin e Implementacin (Deployment): Muestra los

nodos y los componentes que residen en ellos.
5.5 Reglas
Las reglas ayudan a los bloques de construccin 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 semnticas 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.
Ejecucin: Es la manera en que el modelo dinmico se simula.
Integridad: Especfica cmo 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 construccin
del modelo. Existen cuatro tipos de mecanismos, stos son:

Gua del Estudiante
Especificacin: Es el mecanismo que proporciona la descripcin de la sintaxis y

semntica de los bloques de construccin de UML. La representacin grfica
simplemente proyecta partes relevantes del modelo en consideracin, y por lo
tanto revela un aspecto especfico 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 smbolo bsico para ese
elemento del modelo. Los adornos se usan para agregar ms detalles al
elemento del modelo.
Divisin Comn: La construccin de sistemas orientados a objetos conlleva a

dividir el mundo real en diferentes segmentos. Una divisin se relaciona a:
- Clases e instancias de clases.
- Casos de uso e instancias de casos de uso.
- Componentes e instancias de componentes.
Otra divisin se relaciona a la separacin entre interfaz e implementacin. Las
implementaciones realizan el contrato especificado por la interfaz.
Otra divisin 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 diseador crear nuevos bloques de construccin extendiendo

bloques existentes. Los valores marcados se usan para crear informacin nueva en la
especificacin de un elemento del modelo. Una restriccin 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 arquitectnico.
En los siguientes volmenes se estudiarn cada uno de ellos a profundidad.

Gua del Estudiante
Resumen
Ahora que ha completado esta unidad, usted debe ser capaz de:
Describir la necesidad del Anlisis y Diseo Orientado a Objetos (Object

Oriented Analysis and Design - OOAD).
Explicar los principios de la orientacin a objetos.
Describir el trabajo del Lenguaje Unificado de Modelado (Unified Modeling

Language - UML).
Describir la importancia del modelado en UML.

Gua del Estudiante

1) Cul(es) fase(s) del esfuerzo de la construccin del barco (en la Tragedia de
Vasa) puede relacionarse al esfuerzo del desarrollo de software?
a) Requerimientos
b) Diseo
c) Prueba
d) Todas las anteriores
2) Cul de los siguientes conceptos se relaciona a eliminar lo innecesario?
a) Encapsulamiento
b) Ocultamiento de informacin
c) Abstraccin
d) Ninguna de las anteriores
3) Cul de los siguientes no es un bloque de construccin de UML?
a) Elementos del modelo
b) Relaciones
c) Diagramas
d) Adornos
4) UML fue la primera metodologa inventada para desarrollar sistemas orientados a
objetos
a) Verdadero
b) Falso
5) Cules 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 interactan con otros para proporcionar una solucin a un
problema.
c) Una interfaz es el mtodo 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.

Gua del Estudiante
6) Cul de las siguientes relaciones enfatiza una relacin de uso (using)?

a) Asociacin
b) Agregacin
c) Generalizacin
d) Dependencia
7) Animal mamfero, es una categora general de donde se deriva un caballo. Qu
tipo de relacin existe entre animal y caballo?
a) Asociacin
b) Agregacin
c) Generalizacin
d) Dependencia
8) La relacin tiene un es conocida tambin como la relacin 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) Abstraccin
10) Cules de las siguientes afirmaciones son correctas?
a) La jerarqua de herencia permite que la subclase herede los miembros de
datos y operaciones.
b) Polimorfismo significa la capacidad para hacer que una operacin exhiba el
mismo comportamiento en diferentes instancias.
c) El encapsulamiento es un mecanismo para agrupar los datos y los mtodos
de las clases.
d) Ninguna de las anteriores.

Gua del Estudiante

1) d
2) c
3) d
4) b
5) a y b
6) d
7) c
8) b
9) d
10) a y c

Gua del Estudiante
Unidad 2: Modelado del Comportamiento

con Casos de Uso
Definir la importancia de los casos de uso.
Definir cada uno de los elementos involucrados en un diagrama de casos de

uso.
Describir el anlisis 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.

33
Gua del Estudiante
1. Introduccin
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
funcin, adems 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 anlisis y diseo 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 interaccin entre un usuario u otra entidad y el sistema que es
diseado. Un caso de uso es una descripcin 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 mayora de sistemas orientados a
objetos. El usuario o la entidad que tiene inters en el sistema que se est diseando es
llamado actor. En otras palabras, un actor es una entidad que interacta 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 interactan 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 continuacin se muestran algunos casos de uso tpicos:
Generar nmero identificacin.

34
Gua del Estudiante
Imprimir reporte.
Ver estadsticas.
Asignar curso.
Crear documento.
Publicar libro.
Se observa de lo anterior que todos los casos de uso son una combinacin 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 slo 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 diseando.
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.

35
Gua 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 colaboracin se usa en UML para representar una sociedad de elementos, tanto
estticos como dinmicos, que ayuden a implementar el comportamiento de un caso de
uso, esto es, un caso de uso es realizado por una colaboracin.
La colaboracin de un caso de uso se representa como una elipse punteada, y la
realizacin del caso de uso se describe como una lnea 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: Representacin de una Realizacin de Caso de Uso por Colaboracin
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 descripcin 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 mtodos:
Texto estructurado informal.

36
Gua del Estudiante
Texto estructurado con precondiciones y postcondiciones.
Seudocdigo.
En cualquiera de los mtodos 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 continuacin. Esto es
para un caso de uso llamado Asignar Curso y el actor involucrado es el Gerente
de Registro, quien es responsable de la asignacin 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 cdigo de

disciplina del curso, para el cual tiene que hacerse la asignacin.
El Gerente de Registro ingresa el cdigo de disciplina a travs del teclado.
El sistema verifica la validez del cdigo 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

asignacin.
El Gerente de Registro elige los cursos a ser asignados.
El sistema muestra los detalles al Gerente de Registro y espera una

confirmacin.
El Gerente de Registro confirma la asignacin.
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 operacin en cualquier momento.

No se realiza cambio alguno al registro del estudiante.
El Gerente de Registro puede ingresar el cdigo de disciplina cualquier

nmero de veces. En tanto no presione el botn OK, puede limpiar y reingresar el
cdigo de disciplina.
El sistema indica al Gerente de Registro para ingresar nuevamente el

cdigo de disciplina si el cdigo de disciplina no es vlido.
El flujo de eventos anterior es para uno de los casos de uso. Cada caso de uso puede
ser asociado con una descripcin de flujo de eventos, de un modo similar.
37
Gua 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 expansin
de un caso de uso a un escenario. Un solo caso de uso puede resultar en varios
escenarios. Para la mayora 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 investigacin. 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 (generalizacin): En la herencia de los casos de uso, el

caso de uso secundario hereda las acciones y significado del primario, adems
agrega sus propias acciones. Tal como se muestra en la Figura 2.5.

38
Gua del Estudiante
Validar
curso
Validar
curso
Pregrado
Validar
curso
Postgrado
Figura 2.5: Relacin de Generalizacin
La figura anterior indica que los casos de uso Validar curso Pregrado y
Validar curso Postgrado heredan de un caso de uso ms 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
representacin de la generalizacin es una flecha vaca que apunta del caso de
uso hijo al caso de uso padre
Include (inclusin): Los casos de uso pueden incluir otros casos de uso.
Cuando existen secuencias de pasos en comn es importante crear un nuevo
caso de uso que agrupe esas secuencias, luego existirn casos de usos que
incluirn al nuevo creado, de manera de simplificar el diagrama. Es importante
destacar que los casos de uso que se incluyen nunca aparecern solo,
simplemente funcionan como parte de un caso de uso que lo incluya. El
estereotipo <<include>> se usa para denotar la relacin include. La
representacin 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 (extensin): Los casos de uso pueden extenderse de otros casos de

uso. La relacin 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
ubicacin especificada por el punto de extensin. El caso de uso base puede
existir por s mismo. Los puntos de extensin pueden ser mencionados dentro
del caso de uso base, adems los puntos de extensin son puntos donde el
comportamiento del caso de uso extendido aparece. Estos casos de uso puede
tener uno o ms puntos de extensin. Todos los puntos de extensin tienen
nombre. La representacin 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.

39
Gua del Estudiante
Figura 2.6: Relaciones include y extend
En la Figura 2.6, el caso de uso Generar tarjeta registro incluye explcitamente

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.
Tambin, se muestra que el caso de uso Ver status estudiante extiende el
comportamiento del caso de uso Chequear cuenta de estudiante. El punto de
extensin 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 extensin, 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. Anlisis de un Caso de Uso

Para el anlisis 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 disear. Lo que los usuarios indiquen conformaran los candidatos
para los casos de uso.

40
Gua del Estudiante
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 comunicacin 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 asociacin con el caso de uso Verificar
horario. El actor Manejador Horario interacta con el sistema a travs 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 continuacin se muestra un conjunto de
recomendaciones para entender cmo 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.

41
Gua del Estudiante
El comportamiento comn 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 atmicos, dentro de una mquina de
estados. Las mquinas de estado modelan el comportamiento de un objeto individual.
Las mquinas de estado se discuten ms adelante. Cada actividad resulta en una
accin. Una accin 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 interaccin y
actividad son similares. La diferencia radica en el hecho de que los diagramas de
interaccin 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 accin, estados de actividad y
transiciones.
6.1 Estados de Accin y Actividad

Los estados de accin son definidos usando tres trminos, a saber:
Ejecutable.
Atmico.
Clculo.
Algunos ejemplos se muestran a continuacin:
Invocar una operacin sobre otro objeto.
Enviar una seal a otro objeto.
Crear un nuevo objeto.
Destruir un objeto existente.
Especificar una expresin simple.
Todos los ejemplos anteriores significan estados de accin que son atmicos (no es
posible una descomposicin posterior) por naturaleza. Por lo tanto, un estado de accin
es referido como un clculo atmico ejecutable. Un estado de accin puede ser una
accin simple o una expresin.
La Figura 2.8 ilustra estados de accin.
42
Gua del Estudiante
Figura 2.8: Estados de Accin
El estado de accin Activar Bandera no puede ser ms descompuesto. En la Figura

2.8, se muestra una accin simple y una expresin.
Los estados de actividad denotan algunas actividades a ser realizadas. Un ejemplo es
la invocacin de una funcin o un procedimiento. Los estados de actividad toman una
cantidad de tiempo razonable para completarse. Pueden o no ser atmicos. Los estados
de actividad pueden ser divididos posteriormente en estados de accin. Un estado de
accin es un estado de actividad, el cual es atmico o no puede ser ms dividido. Los
estados de actividad y accin se denotan grficamente en forma de pastilla.
Figura 2.9: Dos Estados de Actividad
La Figura 2.9, muestra dos estados de actividad. Cada uno tiene una accin asociada a
l. Uno tiene una accin de salida llamada noid mientras que el otro tiene una accin
de entrada llamada obtenerAo. Al final del primer estado de actividad, se obtiene un
noid. En la otra representacin, el punto de entrada, obtenerAo 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 accin. 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 accin 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 accin o actividad completa su
trabajo, el flujo de control debe ser pasado al siguiente estado de actividad o accin en
43
Gua del Estudiante
el diagrama. Se usan transiciones para mostrar el cambio de una actividad o accin a

otra en el sistema.
Las transiciones se muestran usando una lnea dirigida con la punta de la flecha
apuntando hacia el siguiente estado o actividad. Para describir el flujo completo, se
muestra tpicamente 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 accin a otro estado de
accin 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 Condicin de Guardia

Algunas veces las transiciones deberan ser ejecutadas solo cuando ciertas cosas han
ocurrido. Una condicin de guardia puede ser asignada a una transicin para restringir
su ejecucin; es decir, si la condicin de guardia no se cumple, la actividad siguiente a
la transicin no se ejecuta. En la Figura 2.11, se muestra un ejemplo de condicin de
guardia.
Figura 2.11: Condiciones de guardia en UML
6.4 Decisin o Bifurcacin

Aunque existe un flujo de control de una actividad a otra, no siempre es puramente
secuencial. Se puede encontrar ramificacin, bifurcacin y unin de acciones. La
44
Gua del Estudiante
bifurcacin es similar a una construccin if ... then ... else. Cuando se

muestra la bifurcacin en diagramas de actividad, se indica la condicin bajo la cual
tuvo lugar la transicin. La bifurcacin se denota con un diamante.
La Figura 2.12, muestra el modo en que es representada la bifurcacin.
Figura 2.12: Representacin de Bifurcacin
El Revisar estado estudiante engloba un estado de actividad. Puede contener

otros estados de actividad y/o estados de accin. Cuando un estudiante se grada, 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 asesora es activada. La Figura
2.12 muestra esta bifurcacin, con la condicin apropiada mostrada como una etiqueta
junto con la transicin bifurcada (condicin de guardia). Es importante destacar que se
pueden tener ms de dos condiciones en una bifurcacin, como se muestra en la Figura
2.13.

45
Gua del Estudiante
Figura 2.13: Bifurcacin con ms de dos Condiciones
6.5 Punto de Fusin

Es el lugar donde dos rutas alternativas se unen y continan juntas, esto es muy usado
cuando en algn momento 2 rutas o ramas de un diagrama realizan la misma secuencia
de pasos, para no repetir esos pasos, se utiliza el punto de fusin. El punto de fusin se
denota con un diamante, como se muestra en la Figura 2.14.
Figura 2.14: Notacin para el Punto de Fusin
6.6 Concurrencia
Imagine una situacin donde se deben manejar flujos concurrentes, es decir, manejar
ms de un flujo al mismo tiempo. UML usa la ramificacin (forking) y unin (joining) para
manejar un flujo concurrente.
Para mostrar la ramificacin y unin de flujos de control, se usa una barra de
sincronizacin, la cual es una lnea gruesa horizontal. Una bifurcacin o ramificacin
(fork) representa la separacin de un flujo de control en dos o ms transiciones
salientes, la simbologa es mostrada en la Figura 2.15.

46
Gua del Estudiante
Figura 2.15: Notacin para la Ramificacin (fork)
Una unin (join) representa la unin de dos o ms transiciones entrantes, la simbologa

es mostrada la Figura 2.16.
Figura 2.16: Notacin para la Unin (join)
Las transiciones salientes, como resultado de una bifurcacin, 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 nmero de flujos que abandonan una bifurcacin con el nmero de flujos que
ingresan a una unin.
La Figura 2.17 muestra un ejemplo de bifurcacin y unin 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 accin donde el noid es asignado.

47
Gua del Estudiante
Encontrar
disciplina
Noid=ao+ disciplina+sno
Figura 2.17: Ejemplo de Bifurcacin y Unin 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 accin, estados de actividad, transiciones,
ramificacin, bifurcacin y unin.
Cuando las actividades son modeladas, existen objetos que sern 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.

48
Gua del Estudiante
Encontrar disciplina
Noid=ao+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 seales traducidas como eventos, dichas seales provocarn que se
ejecute una actividad.
El smbolo utilizado para enviar una seal es un pentgono convexo, y el utilizado para
recibir una seal es un pentgono cncavo. Se puede ver un ejemplo en la Figura 2.19.

49
Gua del Estudiante
Figura 2.19: Envi y Recepcin de Seales
Como se observa en la Figura 2.19, la impresin se ejecuta gracias a que el procesador

de texto transmite una seal (evento) a la impresora, la cual recibe y realiza la
impresin, adems 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 tpicamente la parte de la organizacin
que es responsable de esas actividades. En UML estos grupos son referidos como
carriles (swimlanes). Los carriles son descritos con una lnea 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 ms clases pueden representar cada carril en el
sistema. Cada actividad debe pertenecer a un solo carril. Una transicin de una
actividad a otra puede hacerse desde un carril hacia otro, haciendo que las transiciones
atraviesen los carriles.
50
Gua del Estudiante
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 tambin pueden representar actores del sistema que son
los responsables de llevar a cabo las actividades que estn en su carril.
Los diagramas de actividad se usan para modelar los aspectos dinmicos de un
sistema. Esto puede hacerse ya sea modelando un flujo de trabajo o modelando una
operacin. 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
operacin involucra entender los detalles computacionales de la operacin.
Se puede asociar a cada diagrama de actividad un nombre. Empezando con el flujo de
trabajo principal, se puede continuar lentamente con la identificacin de la ramificacin,
concurrencia, bifurcacin y unin.
7. Caso de Estudio
El caso de estudio planteado a continuacin permitir disear los distintos diagramas
que implementa la metodologa UML; para comenzar se disearn el diagrama de caso
de uso y de actividad, y a lo largo del curso se disearn los diagramas restantes
utilizando el mismo caso de estudio.

51
Gua 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 disear un sistema computarizado para automatizar un club de video, el cual
debe tener las siguientes caractersticas:
El sistema debe llevar el control de afiliacin y retiro de clientes.
Para llenar la ficha del cliente es necesario los siguientes datos:

- Nombre completo.
- Cdula.
- Direccin.
- Telfono.
Como requerimiento de inscripcin la persona debe de ser mayor de 18 aos.
El cliente puede afiliarse por medio del sitio web y cancelar con su tarjeta de
crdito.
El sistema debe permitir alquilar, reservar, devolver y comprar pelculas.
El cliente puede devolver la pelcula por el buzn de devolucin el cual

automticamente realiza el registro.
Debe permitir a los clientes consultar las pelculas disponibles por medio de
terminales remotos instalados en la tienda.
Para alquilar una pelcula el operador del sistema introduce la cdula del cliente,
luego introduce el cdigo de la pelcula a ser alquilada, si la cdula del cliente no
aparece en el sistema, la transaccin no procede.
Las reservaciones son realizadas por la pgina web del video club.
La duracin de la reservacin es de 24 horas, al cumplirse el lapso, la

reservacin es cancelada automticamente y la pelcula estara disponible en la
existencia.
El sistema gestiona el pago de la pelcula por adelantado con tarjeta de crdito,

emitiendo una factura.
El alquiler de las pelculas tiene una duracin de 2 das hbiles, los das
adicionales son cobrados como das de mora.
Para alquilar y reservar una pelcula es necesario ser cliente del video club.
El sistema debe llevar el inventario de las pelculas del video.
El club de video ya dispone un sistema contable automatizado que se comunica

con el sistema planteado.
Cabe destacar que no se disear un diagrama de actividad por cada caso de uso, solo
los necesarios para entender la metodologa, los diagramas restantes quedan para
prcticas del lector.

52
Gua del Estudiante
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 pelculas en el

video club. Adems, maneja el sistema directamente cuando reserva por Internet
y consulta pelculas 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.
Buzn: Representa la mquina automatizada que se conecta con el sistema

para registrar las pelculas devueltas.
7.2 Identificar los Casos de Uso Principales

Los casos de uso para el sistema de video club son:
Alquilar pelcula: Permite al empleado registrar en el sistema las pelculas que

los clientes desean alquilar, verificando el cliente y el cdigo de la pelcula a
alquilar.
Devolver pelcula: El empleado utiliza este caso de uso para registrar la entrega
de una pelcula vencida, integrndola nuevamente en la existencia.
Consultar pelcula: El cliente utiliza este caso de uso cuando quiere consultar la
existencia de una pelcula en especial.
Reservar pelcula: El cliente utiliza este caso de uso cuando desea realizar
reservaciones de pelculas 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 pelculas: El empleado utiliza este caso de uso cuando registra la venta
de una pelcula en el sistema.
Consultar clientes: Es un caso de uso genrico utilizado por los casos de usos
alquilar pelcula, 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 crdito, lo cual interacta con el Banco.
Administrar inventario de pelculas: Se encarga de llevar el control de la

existencia de las pelculas, as como alimentar al sistema de contabilidad de club
de video.

53
Gua 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 pelcula, Desafiliar cliente y Afiliar cliente. La razn por la
cual esto ocurre, es debido a que Consultar cliente es un modulo obligatorio para los
casos de usos mencionados, adems no tiene funcionalidad independiente.
7.4 Flujo de Eventos

En este punto se muestra el flujo de eventos del caso de uso Alquilar pelcula con un
formato del tipo texto estructurado, tomando en cuenta los flujos excepcionales (ver la
Tabla 1).
54
Gua del Estudiante

Nombre C.U:
Actores:
Descripcin:
Casos de Uso
Relacionados:

Alquilar pelcula
Id C.U
Empleado
Permite que el cliente alquile una pelcula
Consultar pelcula, Consultar cliente
CU-001
Datos de la pelcula
Registro de la pelcula actualizado y
y del cliente
Salidas: registro del cliente actualizado
Curso Tpico
Accin del Actor
Respuesta del Sistema
1.- El empleado introduce en el sistema la
cdula del cliente.
2.- El sistema verifica que el cliente este afiliado.
3.- El empleado introduce el cdigo de la
pelcula que el cliente escogi.
4.- El sistema verifica que la pelcula exista o que
est disponible.
5.- El sistema muestra los datos de la pelcula.
6.- El sistema solicita la verificacin de la pelcula
7.-El empleado realiza la confirmacin.
8.- El sistema muestra el monto a cancelar.
9.- El sistema pide los datos de la tarjeta de
crdito.
10.-El empleado introduce los datos de la
tarjeta.
11.- El sistema verifica con el banco la validez de
la tarjeta de crdito.
12.- El sistema muestra mensaje de transaccin
exitosa.
13.- El sistema actualiza el inventario de pelculas
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 tpico, el empleado introduce una cdula
Precondicin:
Accin del Actor
1.- Falla la bsqueda del cliente.
2.- El sistema muestra un mensaje, indicando que
el usuario no est afiliado.
3.- El caso de uso contina en el paso 1 del
flujo principal.
Curso Excepcional # 2: La pelcula esta alquilada
En el paso 3 del flujo tpico, el empleado introduce el cdigo de
la pelcula.
Precondicin:
Accin del Actor
1.- El sistema encuentra que la pelcula no est
disponible.
Entradas:

55
Gua del Estudiante
2.- El sistema muestra en pantalla un mensaje,

indicando que la pelcula no est disponible.
flujo del flujo tpico.
Curso Excepcional # 3: Tarjeta de crdito invlida
En el paso 11 del flujo tpico, el sistema verifica la validez de la
tarjeta de crdito.
Precondicin:
1.- Falla la transaccin con el sistema bancario.
2.- El sistema muestra un mensaje de error
donde indica que la tarjeta es invlida.
flujo tpico.
Tabla 1: Curso Tpico y Excepcional del Caso de Uso Alquilar Pelcula
Cabe destacar que los cursos excepcionales desarrollados no son los nicos que
pueden conseguirse en este caso de uso, tambin existen otros como Cancelar la
operacin, entre otros, los cuales se dejan de prctica 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 Pelcula,
tomando en cuenta el flujo de evento tpico 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 lnea con una
flecha de direccin que termina cuando termina el flujo. A continuacin se describen los
diferentes flujos:
El flujo marcado como 1 (uno), indica el escenario exitoso, donde el cliente est
afiliado, la pelcula que seleccion est disponible y la tarjeta de crdito es
vlida, lo cual produce una transaccin exitosa.
El flujo marcado como 2 (dos), indica un escenario de excepcin, 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
automticamente un ciclo, donde el sistema vuelve a pedir que se introduzca la
cdula.
El flujo marcado como 3 (tres), indica tambin un escenario de excepcin, donde

la pelcula no est disponible. El sistema muestra un mensaje de error indicando
que la pelcula no est disponible, en este caso tambin se genera un ciclo, en el
cual el sistema vuelve a pedir que se introduzca el cdigo de la pelcula.
El flujo marcado como 4 (cuatro), es un escenario de excepcin, donde cliente

no confirma el alquiler de la pelcula, El sistema muestra un mensaje de
operacin cancelada y termina el flujo.
El flujo marcado como 5 (cinco), es un escenario de excepcin, donde el sistema

bancario reporta la tarjeta de crdito 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 crdito.

56
Gua del Estudiante
4
5
Figura 2.22: Diagrama de Actividad para el Caso de Uso Alquilar Pelcula

57
Gua 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 anlisis 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.

58
Gua del Estudiante

1) Un diagrama de actividad es una interaccin entre un usuario u otra entidad y el
sistema que es diseado.
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 combinacin 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 grficamente con un crculo, con el nombre
dentro del crculo.
3) Una colaboracin, es una sociedad de clases, que se utiliza para implementar un
caso de uso
a) Verdadero
b) Falso
4) Cules de los siguientes mtodos 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) Seudocdigo
d) Solo a y b
5) Cules de las siguientes son relaciones entre casos de uso?
a) Asociacin
b) Generalizacin
c) Inclusin
d) Agregacin
6) La relacin de inclusin quiere decir que un caso de uso incluye implcitamente a
otro caso de uso.
a) Verdadero
b) Falso
59
Gua del Estudiante
7) De las siguientes afirmaciones seleccione las respuestas correctas:

a) Un estado de accin es un elemento no atmico.
b) Una condicin de guardia puede ser asignada a una transicin para restringir
su ejecucin.
c) Un diagrama de actividad consiste de objetos, estados de accin, estados de
actividad y transiciones.
d) En los diagramas de actividad la bifurcacin se denota grficamente como un
diamante.
8) Las transiciones se muestran usando una lnea 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 continan juntas.
a) Unin
b) Fusin
c) Concurrencia
d) Bifurcacin
10) El smbolo utilizado para enviar una seal es un pentgono cncavo y el utilizado
para recibir una seal es un pentgono convexo.
a) Verdadero
b) Falso

60
Gua del Estudiante

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

61
Gua del Estudiante
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.

Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso
63
Gua del Estudiante
1. Ejercicio de Laboratorio
Se describe un sistema ATM para un e-Bank (Banco electrnico).
El e-Bank lanz sus operaciones en Venezuela, con su casa matriz en Caracas, en
2002. Dentro de un periodo corto de tres aos, construy una red de 275 sucursales por
toda Venezuela. Quizs 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 disear e implementar un nuevo
sistema ATM basado en las ltimas tecnologas. 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 fciles de extender y mantener.
A continuacin se presenta la descripcin 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 transaccin realizada contra

una cuenta. Algunas de las transacciones registradas incluyen lo siguiente:
- Fecha.
- Hora.
- Tipo de transaccin (o tipo de transaccin).
- Cantidad.
- Balance de Cuenta.
Un cliente individual puede operar tres tipos de cuentas:

- Una cuenta de ahorros.
- Una cuenta de depsito fijo.
- Una cuenta de depsito recurrente.
Un cliente corporativo slo 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 cdigo (PIN) que
tendr que ser insertado despus que se inserta la tarjeta. El cdigo (PIN) est
compuesto de 4 dgitos decimales del 0 al 9.
Se supone que una sola tarjeta ATM proporciona acceso a todas las cuentas del
cliente.
Un cliente puede hacer depsitos en cualquiera de los tipos de cuenta.

64
Gua del Estudiante
El retiro de dinero es permitido en la cuenta de ahorros slo si existe un balance

positivo.
El retiro de efectivo directamente desde la cuenta de depsito fijo o la de

depsito 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 slo por las autoridades del banco y no a
travs del ATM.
Mientras el retiro no est permitido directamente desde la cuenta de depsito 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 transaccin 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 ms relevantes en el sistema, indicando relaciones

extensin e inclusin.
Dibujar el diagrama de casos de usos.
Realizar el flujo de eventos para el caso de uso ms relevante en el sistema,

tomando en cuenta los cursos tpicos y excepcionales.
Realizar el diagrama de actividad del caso de uso ms relevante en el sistema.

65
Gua del Estudiante

Describir el modelado estructural del UML en forma bsica.
Describir clases y sus relaciones.
Conocer los mecanismos comunes que pueden ser aplicados a las clases.
Elaborar Diagrama de Clases.

67
Gua del Estudiante
1. Modelado Estructural
El modelo estructural es el modelo UML bsico. Estructura significa constitucin. El
Modelado estructural de UML especifica cmo 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 vern 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 discusin 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 semnticas. En UML, una clase se
representa grficamente con un rectngulo. A continuacin 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 slo el nombre de
la clase se especifica. La otra forma de nombrar una clase es especificando el nombre
de ruta, la cual contiene tambin el nombre del paquete. Es importante destacar que las
clases deben comenzar con letra mayscula, si el nombre est compuesto por dos
palabras, las mismas deben ser unidas comenzando cada una en mayscula. La Figura
1.9 muestra la notacin ms simple de representar una clase en UML.
Empleado
Estudiante
Vehculo
FormularioDeRegistro
Figura 4.1: Mtodo Simple de Representar una Clase

68
Gua del Estudiante
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::Vehculo
Biblioteca::DetalleMiembro::
FormularioDeRegistro
Figure 4.2: Uso de Nombres de Rutas
El signo :: se usa como el smbolo de separacin. 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 prctica estndar, la primera letra de
un paquete y de un nombre de clase est en maysculas. A continuacin 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 rectngulo 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

69
Gua del Estudiante
Los nombres de atributos que constan de una sola palabra comienzan con letra
minscula. S el nombre del atributo esta formado por ms de una palabra, cada palabra
siguiente comenzar con una letra mayscula, a excepcin de la primera palabra que
comenzar en minscula, tal como en nombreEmpleado. Esto se hace para mejorar la
legibilidad. Es posible adems especificar el tipo de dato al que pertenece el atributo,
as como tambin 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 discutirn las operaciones de una clase.
La sintaxis de un atributo en UML, de forma completa, se muestra a continuacin:
[visibilidad] nombre [multiplicidad] [: tipo ] [= valor inicial]
[{propiedad de la cadena}]
Algunos ejemplos de cmo se pueden especificar atributos en UML:
nmeroIdentidad
Slo el nombre del atributo
+ nmeroIdentidad
Visibilidad y nombre del atributo
- nmeroIdentidad = 10
Visibilidad, nombre y valor inicial
nmeroIdentidad: Integer
Nombre y tipo
nmeroIdentidad {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 fcilmente 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 despus de que el atributo ha sido inicializado.
70
Gua del Estudiante
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 rectngulo ubicado debajo de la lista de
atributos. Esto se ilustra en la Figura 4.5.
Nombre de
Clase
Empleado
...
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 cmo se especifican las operaciones como parte de la clase.
Se puede especificar el parmetro tomado por una operacin junto con su tipo de dato,
indicndolo entre los parntesis que preceden al nombre de la operacin, como en
colocarSalario(salario:Float). Tambin se puede especificar el tipo de retorno
de una funcin, como en obtenerSalario().
La elipsis (...) o puntos suspensivos bajo la seccin de atributos de la clase en la Figura
4.5, indica que tal vez existan ms atributos para esta clase. Una clase juega un rol
particular en cada vista del sistema. Se pueden revelar slo 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 continuacin:
[visibilidad] nombre [(lista de parmetros)]
[: tipo del retorno] [{propiedad de la cadena}]
Algunos ejemplos de cmo se pueden usar las operaciones se muestran a continuacin:
definirEmpleado()
slo nombre de la operacin
+ definirEmpleado ()
visibilidad y nombre
- definirEmpleado (e : Empleado)visibilidad, nombre y parmetro

obtenerEmpleado() : Empleado
nombre y tipo de retorno
obtenerEmpleado () {isQuery}
nombre y propiedad

71
Gua del Estudiante
Existen cuatro tipos de propiedades de cadenas para las operaciones. Estas son:
isQuery (es consulta): Cuando se ejecuta esta operacin, el sistema no

se modifica. Generalmente, la operacin no tiene repercusiones.
Sequential (secuencial): Los que invocan la operacin deben asegurar

que hay un slo flujo del objeto (o slo una llamada a una instancia) en un
instante en el tiempo. Si hay ms, la semntica y la integridad no son
garantizadas por la operacin.
Guarded (garantizada): Mltiples llamadas desde hilos concurrentes

pueden ocurrir simultneamente para una instancia (sobre la operacin
guarded), pero solo a una se le es permitido ejecutarse. Las otras son
bloqueadas hasta que la primera operacin es completada. La semntica y la
integridad son garantizadas por la operacin guarded.
Concurrent (concurrente): Cuando existen muchos flujos de control, se

garantiza la semntica e integridad del objeto tratando la operacin como
atmica, o en otras palabras, mltiples flujos de control pueden ocurrir
simultneamente 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 informacin adicional a la lista de parmetros, usando la siguiente
sintaxis:
[direccin] nombre : tipo [=valor por defecto]
La direccin puede ser in para parmetros de entrada, out para parmetros de
salida e inout para un parmetro que ingresa y puede ser modificado. El parmetro in
no puede ser modificado, mientras que el parmetro out puede ser modificado por la
operacin. Tambin se puede especificar un valor inicial al atributo. A continuacin 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. Tambin ayudan a una mejor
organizacin de atributos y operaciones cuando se especifican como parte de la clase.
La Figura 4.6 brinda un ejemplo de cmo usar los estereotipos. Tpicamente, los
estereotipos son encerrados dentro de << >>.

72
Gua del Estudiante
Nombre de Clase
Empleado
<< detalles bsicos >>

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

bsicos, detalles empleo, operaciones de colocar y operaciones de
recuperar. Los atributos y operaciones que siguen un estereotipo pertenecen a
aquella categora especificada por el estereotipo.
Ahora se examinarn las responsabilidades de una clase.
2.5 Responsabilidades de una Clase

Existe alguna diferencia entre una operacin 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 espaol.
La Figura 4.7 ilustra el modo en que las responsabilidades de una clase se muestran
dentro de la especificacin de una clase.

73
Gua 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 operacin estn disponibles a travs

del nombre de la clase. No hay necesidad de tener un objeto que accede al
atributo u operacin. 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 operacin. 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.
Pblica (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 operacin denota visibilidad public.
Protegida (Protected): Cualquier subclase o descendiente de un clasificador

puede usar el atributo o la operacin de una sper clase. El smbolo # se usa
para denotar miembros protected de una subclase.
Privada (Private): Slo las instancias de un clasificador pueden usar los

atributos y operaciones que tienen visibilidad private, esto es, el atributo o la
operacin slo 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 smbolo ~ se
utiliza para indicar este tipo de visibilidad. Esta visibilidad es vlida en la
especificacin 2.0 de UML.
La Figura 4.8 muestra un ejemplo que ilustra mbito y visibilidad.

74
Gua del Estudiante
Empleado
-cuentaEmpleado
# empleadoId
# empleadoNombre
+ colocarEmpleadoId()
+ colocarEmpleadoNombre()
+ obtenerEmpleadoId()
+ obtenerEmpleadoNombre ()
+ obtenerCuentaEmpleado()
...
Figura 4.8: Ilustracin de mbito y Visibilidad
3. Relaciones entre Clases

Las relaciones conectan dos o ms cosas. En la orientacin a objetos, se hablan de
tales conexiones entre dos o ms clases. Los cuatro tipos de relaciones entre clases
son las siguientes:
Dependencia.
Generalizacin.
Asociacin.
Agregacin.
Cada una de estos tipos de relaciones tiene una notacin especfica en UML. A
continuacin se discute la relacin de dependencia.
3.1 Relacin de Dependencia

La relacin de dependencia es la relacin 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 relacin de dependencia ocurre cuando un objeto es pasado como un
parmetro en una operacin de una clase. La operacin puede usar el objeto a travs
de sus interfaces conocidas. Si la interfaz cambia, afecta al objeto que est usando el
otro objeto. En UML, una lnea punteada dirigida denota una relacin 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 cmo se usa una relacin de dependencia en UML.
75
Gua del Estudiante
GeneradorNomina
DatosNomina
actualizarDataEmpleado()
generarNomina()
DatosNomina
obtenerDataEmpleado()
aadirDataEmpleado()
GerenadorNomina
Figura 4.9: Relacin de Dependencia
En la Figura 4.9, la direccin 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 nmina, la clase GeneradorNomina requiere datos de la clase
DatosNomina. Un cambio en la interfaz de DatosNomina afectar a
GeneradorNomina. A continuacin, se aprender acerca de la relacin de
generalizacin.
3.2 Relacin de Herencia o Generalizacin

La generalizacin consiste de la relacin entre una clase principal (superclase) y la
subclase. La superclase representa un concepto general mientras que la subclase
representa un concepto ms especfico. Esta relacin es llamada tambin una relacin
es un tipo de (is a kind of). Ejemplos de esta relacin 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 relacin de generalizacin, la entidad hija puede aparecer donde sea que
aparezca la entidad padre, pero lo inverso no es vlido. Se alcanza el polimorfismo con
la generalizacin cuando una entidad hija sobrescribe una operacin que es definida en
la entidad padre. En UML se denota la relacin de generalizacin con una lnea slida
dirigida. La Figura 4.10 es una representacin esquemtica de tal relacin.
Empleado
Gerente
IngSoftware
GerenteProduccin
Staff
GerenteVentas
Figura 4.10: Relacin de Generalizacin

76
Gua del Estudiante
La clase Gerente es una subclase de Empleado, y es tambin la superclase para las

clases GerenteVentas y GerenteProduccin. A continuacin se discute la relacin
de asociacin.
3.3 Relacin de Asociacin

La relacin de asociacin es una relacin simple. Conecta dos clases, denotando la
relacin estructural entre ellas. En una asociacin, es posible navegar entre las clases
que participan en la relacin. Tambin puede existir una asociacin de una clase a s
misma. La notacin UML para una asociacin es una lnea slida que conecta las dos
clases que participan en la relacin de asociacin.
Una relacin de asociacin puede tener un nombre que indica la asociacin entre las
dos clases, en este caso debe colocrsele justo sobre la lnea slida que define la
asociacin. Cuando una clase participa en una relacin de asociacin, juega un rol
especfico en esa relacin. Los roles pueden ser especificados para cada clase que
participa en la relacin.
La Figura 4.11 describe una relacin de asociacin, mostrando el nombre de asociacin
y los roles que cumplen las clases en esa relacin.
Trabaja Para
Compaa
Gerente
Empleado
Empleador
Figura 4.11: Relacin de Asociacin
El nombre de la asociacin es Trabaja Para y los roles son Empleado y

Empleador. Agregar estos adornos a la relacin de asociacin mejora el significado de
las clases que participan en la relacin.
3.3.1
Multiplicidad
Tambin se puede mostrar cuntos objetos pueden ser conectados para una instancia
de una relacin de asociacin. Esto se llama la multiplicidad del rol de una asociacin.
Una asociacin tiene dos extremos, en cada extremo se puede especificar un nmero
que indica el nmero de objetos a ser creados para esa asociacin. Vea la Figura 4.12.
VehiculoCuatroRuedas
Puertas
Figura 4.12: Multiplicidad del Rol de una Asociacin

77
Gua del Estudiante
En la figura anterior, se muestra que para cada instancia de VehiculoCuatroRuedas

existen cuatro instancias de Puertas.
Tambin se puede especificar:
0..1 para cero o uno, tambin se puede definir como ninguno o uno.
0..* para cero o ms.
1..* para uno o ms.
3..5 para el rango 3, 4 5.
Adicionalmente, se puede tener conjuntos de multiplicidad, por ejemplo, {7, 8, 12}.
3.3.2
Asociacin Calificada
Cuando un objeto de una clase tiene que seleccionar un objeto de otra clase para
cumplir con un papel especial en la asociacin, la primera clase debe valerse de un
atributo en especfico para localizar al objeto adecuado. Este atributo debe ser un
identificador nico. Esto es llamado asociaciones calificadas, por ejemplo cuando una
persona reserva por telfono entradas para ir al cine, el recepcionista le entrega un
nmero de reservacin nico (localizador) de las entradas, si en algn momento se
desea saber el estado de la reservacin o se va a comprar las entradas al cine, se debe
entregar el nmero de la reservacin para realizar la operacin. La Figura 4.13 muestra
la representacin grfica del ejemplo anterior.
RecepcionistaCine
NumeroReservacion
localiza 1..*
Reservacion
Figura 4.13: Asociacin Calificada
3.3.3
Clase Asociacin
Una clase asociacin modela atributos y operaciones de una asociacin, la clase

asociacin se crea de la misma manera que una clase estndar, la conexin se realiza
mediante una lnea discontinua entre la asociacin de dos clases relacionadas.
La clase asociacin puede tener asociaciones con otras clases. En la Figura 4.14, se
muestra una clase asociacin Contrato para la asociacin trabaja para entre la clase
Empleado y la clase Compaa. Esta misma clase Contrato se asocia con la Clase
Gerente.
78
Gua del Estudiante
Empleado
trabaja para
Compaia
Contrato
Gerente
aprobado por
Figura 4.14: Clase Asociacin
3.4 Relacin de Agregacin

Tambin se puede especificar una relacin de agregacin al extender la relacin bsica
de asociacin. Se conoce como una relacin todo-parte (whole-part). La clase en un
extremo de la relacin contendr las clases en el otro extremo de la relacin. La relacin
todo-parte significa la relacin es parte de o tiene un. Algunos ejemplos de una
relacin de agregacin son los siguientes:
Un cuarto tiene una puerta.
Edificio tiene cuartos.
Vehculo tiene un motor.
Compaa tiene departamentos.
Libro tiene captulos.
Existen dos formas de agregacin:
Agregacin simple.
Composicin.
Una agregacin establece una relacin del tipo tiene un entre dos clases. En una
agregacin simple, el tiempo de vida del todo y las partes no estn enlazados. Por otro
lado, en la composicin, si estn enlazados. Si el todo deja de existir, las partes
automticamente dejan de existir.
La Figura 4.15 muestra una agregacin simple. Esta relacin se muestra usando un
diamante sin rellenar. El diamante se ubica cerca de la clase que forma el todo en la
relacin. Puerta y Asiento existen como entidades incluso si la clase
VehiculoCuatroruedas deja de existir. Ellas estn disponibles para su uso con otros
vehculos similares.

79
Gua del Estudiante
VehiculoCuatroRuedas
Puerta
Asiento
Figura 4.15: Agregacin Simple
La Figura 4.16 describe la composicin y la multiplicidad.

Edificio
nombreEdificio
numeroDePisos
colocarNombre()
colocarNumeroDePisos()
...
1
4..6
Habitacin
Piso
numeroPisos
numeroDeHabitaciones
obtenerNumeroPiso()
obtenerNumeroDeHabit()
12
numeroHabitacin
lugarHabitacin
obtenerNumeroHabit()
obtenerLugarHabit()
...
Figura 4.16: Composicin y Multiplicidad
Edificio tiene una relacin de composicin con Piso, y Piso a su vez tiene una
relacin de composicin con Habitacin.
En la primera instancia, Edificio es el todo y Piso es la parte. En la segunda
instancia, Piso es el todo y Habitacin es la parte. Esta relacin se muestra como un
diamante negro relleno, que se coloca cerca de la clase que representa el todo en la
relacin.
80
Gua del Estudiante
Tambin se muestra la multiplicidad del rol de la agregacin. Un edificio puede tener 4,

5 6 pisos mientras que cada piso tiene 12 habitaciones.
Antes de ver un ejemplo para ilustrar cmo se dibujan los diagramas de clase usando la
notacin UML, se discutir brevemente algunos adornos usados comnmente en
diagramas de clase.
4. Mecanismos Comunes
Se aprendi que los mecanismos comunes, tal como los adornos, mejoran el
entendimiento del sistema.
A continuacin 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 grficamente como un rectngulo con una
esquina doblada. Tambin contiene comentarios textuales o grficos. Vea la
Figura 4.17.
Los comentarios
van aqu
Figura 4.17: Especificacin de Comentarios en UML
Valor Etiquetado (Value tagged): Los valores etiquetados permiten crear

nueva informacin en la especificacin 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

construccin que son especficos al sistema que est siendo analizado. Estos
bloques de construccin son similares a los existentes. Los estereotipos estn
encerrados dentro de << >> y son ubicados encima del elemento al cual se
refieren.
Restriccin: 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 notacin de clase para

proporcionar mayor significado a la existencia de la clase en el modelo.

81
Gua del Estudiante
La Figura 4.18 ilustra los mecanismos comunes discutidos anteriormente.
La clase que
maneja todas las
operaciones de
nmina de la
compaa.
<< Subsistema Nmina >>

GerenteNmina
{version = 1.3}
revisarFecha()
activarProcesoNmina()
...
{Corre slo el ltimo

da de cada mes}
GeneradorNmina
{autor = jerry}
InformacionNmina
generarNmina()
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: Ilustracin 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

82
Gua del Estudiante
etiquetados son tiles para especificar el nmero de versin, nombre de autor y

la fecha en que se escribi el programa.
Restriccin para GerenteNomina, colocada fuera de dicha clase, para indicar

que las operaciones de esta clase corren slo en el ltimo da del mes. sta es
la nica restriccin 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.
Tambin 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 resolucin del caso de estudio planteado en la unidad 2,
ahora se aprender a construir un diagrama de clases. Un diagrama de clases describe
grficamente un conjunto de clases, interfaces, colaboraciones y las relaciones entre
ellas.
Se coloca nuevamente el problema para mayor comprensin del mismo.
Al momento de la afiliacin por Internet el sistema muestra un contrato, el cual

debe ser aceptado por el cliente para ser afiliado.

- Nombre completo.
- Cdula.
- Direccin.
Como requerimiento de inscripcin la persona debe de ser mayor de 18 aos.
El cliente puede afiliarse por medio del sitio web y cancelar con su tarjeta de
crdito.

Las reservaciones son realizadas por la pgina Web del club de video.

83
Gua del Estudiante

existencia.

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

descripcin del problema:
que son identificadas en la
Figura 4.19: Clases Identificadas
Para el diagrama final varias de estas clases no sern 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 abstraccin de las clases realizadas, puede variar segn la
capacidad de anlisis de la persona encargada de realizar el modelo. Por lo tanto varias
personas pueden tener diferentes diagramas de clase del mismo problema.

84
Gua del Estudiante
5.2 Identificar Propiedades y Mtodos

En la Figura 4.20, se muestra las propiedades y los mtodos principales extrados de la
descripcin de problemas, acompaado 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.
Figura 4.20: Identificacin de Propiedades y Mtodos con Visibilidad
5.3 Identificar Relaciones

En la Figura 4.21, se observan las diferentes relaciones identificadas en el problema.
Asociacin: Como se puede observar en la Figura 4.21, la asociacin es la

relacin ms utilizada comnmente. Se describe a continuacin cada una de las
relaciones:

85
Gua del Estudiante
Un cliente realizar distintas operaciones con pelculas, esto implica una relacin de
asociacin entre la clase Cliente y la clase Pelcula
Figura 4.21: Diagrama de Clases
El cliente realiza los pagos de las pelculas, lo cual genera una relacin de asociacin
entre la clase Cliente y la clase Pagos.
La relacin de asociacin entre la clase Empleado y la Pelcula, permite el registro del
empleado con la transaccin de la pelcula.
La clase Inventario tiene una relacin de asociacin con la clase Pelcula, debido
a que el inventario contiene la cantidad de pelculas que hay en el stock de la
tienda de video.

86
Gua del Estudiante
Dependencia: La clase Factura depende de la clase Cliente, si cambian los

datos del cliente la factura es afectada directamente. Tambin existe una
relacin entre la clase Factura y la clase Pagos, la cual permite que en la factura
se imprima la forma de pago de la pelcula.
Adems de observar las relaciones, observe las clases que fueron descartadas del
anlisis 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 abstraccin conceptual en el mundo real. Lo siguiente debe tenerse en
cuenta para lograr una clase bien estructurada:
La clase debe proporcionar una abstraccin clara de algo desde el dominio del
problema o desde el dominio de la solucin. Usualmente puede ser parte del
vocabulario del dominio del problema o del dominio de la solucin.
La clase tiene un pequeo conjunto de responsabilidades bien definidas y las

lleva a cabo de una buena forma.
La clase proporciona una clara separacin de la especificacin y la

implementacin.
La clase es fcilmente entendible.
La clase es simple.
Cuando se dibuja la clase en UML, es una buena idea seguir los consejos que se dan a
continuacin:
Limitar la presentacin de todas las propiedades de la clase siendo considerada

a niveles aceptables. Se debe mostrar slo aquellas propiedades de la clase que
son importantes para entender la naturaleza de la abstraccin en su contexto.
Si se tiene una larga lista de atributos, trate de agruparlos de acuerdo con

alguna categora.
Si cierto conjunto de clases est relacionado, mustrelos en el mismo diagrama.

87
Gua del Estudiante
Resumen
Describir el modelado estructural del UML en forma bsica.
Describir clases y sus relaciones.
Conocer los mecanismos comunes que pueden ser aplicados a las clases.
Elaborar Diagrama de Clases.

88
Gua del Estudiante

1) Cul de las siguientes es una relacin simple, que conecta dos clases, denotando
la relacin estructural entre ellas?
a) Realizacin
b) Generalizacin
c) Agregacin
d) Asociacin
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) Cul 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 lnea punteada dirigida denota una relacin de:
a) Generalizacin
b) Dependencia
c) Asociacin
6) En una agregacin simple, el tiempo de vida del todo y las partes estn enlazadas.
a) Verdadero
b) Falso

89
Gua 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) Cules de las siguientes multiplicidades son correctas?
a) 0..1 para cero o uno
b) 0..* para cero o ms
c) 1..* para uno o ms
d) 3..5 para el rango 3 , 4 5
9) Una asociacin calificada se realiza cuando un objeto de una clase debe valerse
de un atributo en especfico para localizar al objeto adecuado?
a) Verdadero
b) Falso
10) Indique cules de los siguientes nombres de clases son vlidos:
a) DetalleEmpleado::Empleado
b) Empleado
c) Automvil
d) Biblioteca::DetalleMiembro:: FormularioDeRegistro

90
Gua del Estudiante

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

91
Gua del Estudiante
Volumen 2: Modelado Avanzado

93
Gua del Estudiante
Unidad 1: Modelado Estructural

Avanzado
Describir los tipos de clasificadores.
Explicar acerca de las interfaces, roles, tipos y paquetes.
Describir instancias y diagramas de objetos.
Construir diagramas de objetos.

parcialmente sin previo permiso escrito de IBM.
95
Gua del Estudiante
1. Introduccin
En la Unidad 4 Modelado Estructural Bsico del Volumen 1, se explicaron los
conceptos bsicos de la orientacin a objetos, modelado de ideas y diagramas de clase.
Esta unidad, se ocupa de las caractersticas avanzadas del modelado estructural del
UML.
2. Clasificadores
Los clasificadores son bloques de construccin de UML. Son elementos del modelo,
que pueden tener instancias. UML utiliza clasificadores para describir las caractersticas
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 aplicacin
bancaria, se tienen abstracciones que modelan clientes, planillas de depsitos o
cuentas. Estas abstracciones son la esencia del modelo. Se crean instancias de los
elementos del modelo anterior, que interactan 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 caractersticas idnticas. Los atributos de la clase forman las
caractersticas estructurales de un clasificador mientras las operaciones de la clase
forman las caractersticas de comportamiento.
Los dems clasificadores se muestran a continuacin:
Interfaz: La interfaz describe los servicios proporcionados por una clase o un

componente.
Componente: Los componentes son las partes fsicas de un sistema, que son
reemplazables. Ellos se adhieren a la interfaz y proporcionan la realizacin de un
conjunto de interfaces.
Nodo: Un nodo es un elemento fsico que predomina en tiempo de ejecucin.

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 agrupacin de elementos del modelo.
Tipo de datos: Un tipo de dato puede ser primitivo o enumerado.
Seal: Una seal significa el estmulo asincrnico comunicado entre instancias.
La nica excepcin a la regla acerca de los clasificadores que tienen caractersticas

estructurales y de comportamiento es la interfaz. Las interfaces podran no tener
atributos. La Figura 1.1 proporciona las notaciones UML para todos los clasificadores.

96
Gua del Estudiante
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
Seal
<<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 ms operaciones que no son implementadas. Dichas operaciones se dejan
abiertas para que las implementen las clases que heredan de una clase abstracta. Las
97
Gua del Estudiante
operaciones que no son implementadas, pero proporcionan slo una interfaz, se

denominan operaciones abstractas. Estas operaciones deben ser implementadas en
algn nivel de la jerarqua 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 polimrficas.

Se implementan en la clase abstracta, que puede ser heredada por la subclase,
dependiendo de su visibilidad. Una operacin de hoja es una operacin
concreta.
En UML, las clases abstractas y las operaciones abstractas se describen usando letra
cursiva o itlica. Las operaciones de hoja se indican como {leaf}. Las operaciones
desprovistas de adornos son operaciones polimrficas, 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 ms hijos est adornada con {leaf}.
Usuario
{root}
# cedula
Operacin
Abstracta
Operacin
Polimrfica
incluir()
actualizarDatos()
...
Empleado
{leaf}
Cliente
{leaf}
# id_empleado
# id_cliente
incluir()
retirarEmpleado
actualizarDatos()
...
Incluir()
RetirarCliente()
actualizarDatos()
Figura 1.2: Ejemplo de Elementos Abstractos, Raz (root), leaf y Polimrficos
La Figura 1.2 muestra una porcin del diagrama de clases del caso de estudio anterior
agregndole algunas operaciones, donde se puede notar que la clase Usuario es una
clase abstracta, que tambin es la raz y la clase base de la jerarqua de herencia. Las
98
Gua del Estudiante
clases Empleado y Cliente son hijos de la clase abstracta Usuario, las cuales no
pueden tener ms hijos. Con respecto a las operaciones se tiene:
incluir(): Indicado en cursiva representa una operacin abstracta, la cual es

implementada en las clases Empleado y Cliente.
actualizarDatos(): Es una operacin polimrfica. Las clases hijas pueden

sobrescribirla, tal como lo hacen las clases Empleado y Cliente.
4. Multiplicidad
La multiplicidad se usa para permitir al diseador especificar el nmero de objetos que
pueden ser creados para una clase. Generalmente, una clase puede tener cualquier
nmero de objetos. Pero en ciertas situaciones, se podra querer indicar el nmero
exacto de objetos para una clase. El nmero se muestra dentro de la notacin de clase
para indicar el nmero de objetos para una clase.
En el caso de un atributo, como se vio anteriormente, se puede especificar el nmero de
objetos despus del nombre del atributo. Adicionalmente, se puede disear una clase
que tenga slo un objeto. Dichas clases se denominan clases singleton. Un ejemplo de
una clase singleton es cualquier generador o clase monitor, donde slo se necesita una
instancia que puede ser usada por los dems objetos.
La Figura 1.3 ilustra la multiplicidad.
Empleado
Libro
1..3
100..*
Cliente
1..*
Biblioteca
libros[100..*]:Libro
Figura 1.3: Ilustracin 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 ms instancias de la clase Libro
Una o ms instancias de la clase Cliente

99
Gua del Estudiante
Exactamente una instancia de la clase Biblioteca, pero contiene 100 o ms

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 definicin.
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 parmetro 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 aadir caractersticas 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 notacin 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: Notacin UML para un Template y su Correspondiente Clase Concreta
En la Figura 1.4, Pila es una clase template que est representada por el parmetro
dentro de un rectngulo 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 relacin a la clase template. La
relacin no describe una relacin de generalizacin. Junto a la flecha dirigida, se
100
Gua del Estudiante
proporciona el tipo real que est asociado a los formales. El estereotipo <<bind>>
indica la asociacin de clases template con las clases concretas.
6. Estereotipos para Clases

Estos estereotipos son una manera de especificar cmo una clase es utilizada en el
diseo. Un estereotipo de clase no es parte del nombre de la clase y no genera cdigo
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 informacin 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 Pelcula puede tener el estereotipo <<entity>>,
debido a que no importa en que tienda de video se utilice, siempre un objeto
instanciado por la clase Pelcula tendr caractersticas en comn, tales como
gnero, ttulo, 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 informacin sobre s mismo. Representa un comportamiento, ms que
un recurso. Este tipo de clase se refiere ms a dirigir el comportamiento de otros
objetos y no tiene casi ningn comportamiento propio. Por ejemplo, en el caso
de estudio de la tienda de video, se podra tener una clase llamada Gestor, la
cual tendra operaciones como alquilar pelcula, reservar pelcula, afiliar cliente,
devolver pelcula y estara relacionada con clases como Pelcula, Cliente,
Factura. Ver Figura 1.6.

101
Gua del Estudiante
<<control>>
Gestor
+ devolverPelicula()
+ afiliarEmpleado()
+ generarFactura()
...
Figura 1.6: Ejemplo de estereotipo <<control>>
Existen 4 formas de representar grficamente los estereotipos <<entity>> y <<control>>,

las cuales se muestran en la Figura 1.7.
Pelcula
Pelcula
Pelcula
Pelcula
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 dems 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 travs de un sistema. Por ejemplo, una clase
Calculo, puede proporcionar funciones matemticas bsicas, 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>>

102
Gua del Estudiante
Enumeration: Son tipos de datos definidos por el usuario, que definen las
constantes de un sistema. Una clase enumeracin define un conjunto de valores
literales, usados generalmente para validacin. 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 seccin se explican los conceptos avanzados de las tres
relaciones que se aprendieron en la Unidad 2 Modelado Estructural Bsico del
Volumen 1.
7.1 Relacin de Dependencia

La relacin 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 ningn estereotipo, UML permite dar ms significado a las
dependencias, es decir concretar ms, mediante el uso de estereotipos.
7.1.1
Estereotipos que se Aplican a Relaciones de Dependencia entre clases
Hay cinco estereotipos en esta categora:
Bind: Se usa en enlace del template o plantilla. La fuente enlaza al template

destino junto con los parmetros 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
aosEnServicio deriva del atributo fechaDeInicio, que es una instancia de
la clase Fecha. As aosEnServicio 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 dems 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

103
Gua 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 ms
refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
Use: Se usa cuando se debe describir una relacin semntica entre dos
elementos. La semntica del elemento origen depende de la semntica de la
parte pblica del elemento destino. Se aplica cuando se requiere marcar
explcitamente una relacin de dependencia.
La Figura 1.10 ilustra un ejemplo de algunos de los estereotipos mencionados

anteriormente.
Empleado
<<derive>>
empleadoID
empleadoNombre
fechaDeInicio:Date
empleadoDireccion
aosEnServicio
...
<<friend>>
GeneradorPerfilEmpleado
empleadoPerfil[1..*]: Perfil
Figura 1.10: Ejemplo de Algunos Estereotipos
Existen otros estereotipos para la relacin de dependencia pero estn ligados a otros
diagramas por lo cual se explican ms adelante.
7.2 Relacin de Generalizacin

La Figura 1.11 muestra cmo la herencia mltiple se representa grficamente 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 mltiples.

104
Gua del Estudiante
Empleado
Gerente
GerenteProduccin
IngenieroSoftwareSenior
GerenteVentas
PersonalOficina
GerenteProyecto
Figura 1.11: Herencias Simples y Mltiples
7.2.1
Estereotipo para la Relacin de Generalizacin
El estereotipo asociado con la generalizacin es la implementacin. El estereotipo de

implementacin 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 pblico el comportamiento. Tambin declara que no soporta
interfaces padre.
7.2.2
Restricciones en Relaciones de Generalizacin
Para una relacin de generalizacin, existen cuatro restricciones que son:
Complete: Sugiere que el nmero de hijos requeridos por el modelo debe ser
especificado. No se permiten hijos adicionales.
Incomplete: Es lo contrario a la restriccin anterior. Se permiten hijos

adicionales. Es til para mostrar que la especificacin completa de la jerarqua
de herencia no se realiza.
Disjoint: Especifica que los objetos del padre no pueden contener ms de un

hijo como tipo. Esto se aplica en el contexto de herencia mltiple.
Overlapping: Permite ms de un hijo en tiempo de ejecucin. Esto tambin se

aplica en el contexto de herencia mltiple.
Las ltimas dos restricciones se usan para distinguir entre clasificacin esttica y
dinmica. La restriccin disjoint permite clasificacin esttica, mientras que el
overlapping permite clasificacin dinmica. La clasificacin dinmica ocurre cuando un
objeto cambia su tipo en tiempo de ejecucin. Por defecto, para una generalizacin
simple las restricciones son {incomplete,disjoint}. En la Figura 1.12 se muestra un
ejemplo de alguna de estas restricciones.
105
Gua del Estudiante
Usuario
{incomplete, disjoint}
Cliente
Empleado
Figura 1.12: Restricciones de la Relacin de Generalizacin
7.3 Relacin de Asociacin

Esta relacin se usa para mostrar que estn conectados dos elementos del modelo. Los
tres adornos para esta relacin son: nombre, rol, multiplicidad para cada uno de los
extremos de la asociacin.
Ahora se presentarn otras dos propiedades importantes de una relacin de asociacin:
Navegacin: Generalmente, una lnea slida entre las dos clases que estn en
asociacin denota una relacin de asociacin. Tambin se puede mostrar la
direccin de la asociacin colocando una cabeza de flecha en la lnea. Se
muestra la direccin de la asociacin entre GerenteDeRegistro y
TarjetaDeRegistro en la Figura 1.13. A menos que se especifique una
direccin de la lnea, la navegacin es bidireccional.
GerenteResgitro
TarjetaRegistro
1..
generarRegistroTarjeta
generarRegistroTarjeta()
crearPlantillaTarjeta()
Figura 1.13: Direccin de la Asociacin
Visibilidad: Se pueden usar los smbolos asociados con la visibilidad public,

protected y private para mostrar si una clase en una asociacin es visible a otras
clases o no. Se usan los smbolos +, # y fuera del objeto, cerca de la clase que
necesita ser visible. La visibilidad private indica que las clases fuera de la
asociacin no pueden tener acceso al objeto al final de la asociacin 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.

106
Gua del Estudiante
GerenteRegistro
TarjetaRegistro
# Generador
generarRegistroTarjeta
generarRegistroTarje
ta()
crearPlantillaTarjet
Solicitante
Figura 1.14: Visibilidad Protected
7.3.1
Restricciones en Relaciones de Asociacin
Son limitaciones hechas en un elemento del modelo que permiten asegurar su

integridad a lo largo de la vida del sistema. Para una relacin de asociacin existen
restricciones tales como:
Ordenacin (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: Restriccin 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 asociacin entre una
clase Administrador de eventos y una clase eventos, el administrador de eventos
podra realizar una auditoria a un evento o tambin podra 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: Restriccin XOR
Subconjunto (subset): Indica que una coleccin esta incluida en otra coleccin.
Por ejemplo en una escuela en la mayora de los casos los representantes de
los alumnos tambin son sus padres.

107
7.3.2
Gua del Estudiante
Asociacin Reflexiva
Es una clase que tiene una asociacin con ella misma. Esto ocurre cuando una clase
tiene objetos que juegan diferentes roles. En importante que los roles estn bien
definidos para que se entienda con claridad la relacin. Por ejemplo, en la Figura 1.17,
la clase Persona muestra la relacin 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: Asociacin Reflexiva
8. Interfaces y Realizacin
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, adems es importante resaltar que
las interfaces no tienen atributos solo operaciones que sern implementadas por una o
varias clases.
UML representa las interfaces de dos maneras, como una clase con el estereotipo
<<interface>> o utilizando crculos pequeos conectados con una lnea 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 ms informacin a una interfaz para hacerla fcilmente

comprensible.

108
Gua del Estudiante
Se pueden adjuntar precondiciones o post condiciones para cada operacin. Las

precondiciones son aquellas que deben ser satisfechas cuando la operacin es
invocada. Las post condiciones son las que deben ser satisfechas al final de la
operacin.
Las Interfaces pueden estar asociadas con mquinas de estado.
Las colaboraciones pueden ser adjuntadas a una interfaz.
8.1 Realizacin
Esta es una relacin semntica entre dos clasificadores. La notacin utilizada es una
lnea punteada con una punta de flecha en forma de tringulo sin rellenar apuntando
hacia el clasificador que especifica el contrato.
La relacin de realizacin tiene algunos ingredientes de relaciones de dependencia y
generalizacin, adems se usa en el contexto de interfaces y colaboraciones.
Semnticamente, es correcto decir una clase o un componente es la realizacin de una
interfaz. Las clases implementan interfaces y de aqu el trmino realizacin es usado
en lugar de generalizacin. En el caso de generalizacin, se enfatiza una relacin
padre/hijo. No hay tal relacin enfatizada en una relacin de realizacin. Tambin es
muy usual ver realizaciones en casos de uso, las cuales son llamadas colaboraciones.
La Figura 1.18a muestra un ejemplo de una relacin de realizacin.
Las Figuras 1.19a y 1.19b representan la realizacin 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 lnea
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 realizacin de la interfaz
IAgenteFigura.
La Figura 1.19c representa la realizacin de un caso de uso a travs de una
colaboracin.
Las formas usadas para la realizacin de las Figuras 1.19a y 1.19c se denominan
formas cannicas y la usada en la Figura 1.19b se refiere a la forma abreviada (elided
form).

109
Gua 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: Realizacin de la Clase ObjetoDocumento desde la interfaz IAgenteFigura
GenerarReporte
Generacin
Figura 1.19c: Realizacin de Colaboracin de un Caso de Uso
9. Roles
Una clase puede llevar a cabo ms 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 podra revelar slo 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 abstraccin se presenta al mundo.
La Figura 1.20 muestra cmo se describen los roles para una interfaz. El
ObjetoDocumento tiene dos interfaces, IFigureAgent y IDocumentoAgent. En el
contexto dado de la participacin 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.

110
Gua del Estudiante
Figura
IFigureAgent
ObjetoDocumento
Documento
IDocumentoAgent
Figura 1.20: Descripcin 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.
Nmina
ENomina:: Nmina
{author:jerry}
Figura 1.21: Paquetes con un Nombre Simple y un Nombre de Ruta
Tambin se puede revelar las clases o componentes dentro del paquete, junto con su
visibilidad. Esto se puede hacer de dos formas:
Anidamiento textual.
Anidamiento grfico.
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
pblicas, 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.
111
Nmina
+GeneradorNmina
+GeneradorPago
-ConectorBaseDatos
Gua del Estudiante
Nmina
+GeneradorNmina
+ GeneradorPago
- ConectorBaseDatos
Anidamiento Textual
Anidamiento Grfico
Figura 1.22: Anidamiento Textual y Anidamiento Grfico
10.1
Estereotipos de Paquetes
UML proporciona cuatro estereotipos para paquetes:
Facade: Esto permite especificar que un paquete es una vista a algn otro
paquete.
Framework: Se usa cuando un paquete principalmente slo 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 slo paquete representa el sistema

completo.
La Figura 1.23, muestra como se representa grficamente los estereotipos de paquetes.

<<System>>
TiendaVideo
<<System>>
TiendaVideo
Figura 1.23: Anidamiento textual y Anidamiento Grfico
10.2
Relacin de Dependencia con Paquetes
Existen estereotipos que permiten clarificar la dependencia entre paquetes, entre ellos
se tienen:
112
Gua del Estudiante
Import: Una clase contenida dentro de un paquete puede tambin aparecer en

otro paquete en la forma de un elemento importado, por medio de una relacin
de dependencia entre paquetes. Es necesario resaltar que no todas las clases
dentro de un paquete son visibles por otros paquetes. La dependencia de
importacin se utiliza para agregar nombres al espacio de nombres del paquete
del cliente como sinnimos 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 automticamente,
simplemente concede permiso para establecer referencias.
La Figura 1.24 muestra un ejemplo de esta relacin y estereotipos.

A
<<import>>
<<access>>
C
Figura 1.24: Ejemplo de estereotipos con relacin de dependencia
En la Figura 1.24, el paquete A agrega el contenido pblico del paquete B al espacio de

nombres del paquete A. El paquete B puede ver todo el contenido pblico del paquete
C, sin aadirlo a su espacio de nombre, por lo cual para hacer una referencia a un
elemento pblico 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.

113
Gua del Estudiante
GUI
+ Ventana
+
WebGUI
+ Marco
+ GUI:Ventana
ApliGUI
+ Marco
+ GUI:Ventana
Figura 1.25: Ejemplo de Generalizacin de Paquetes
11. Instancias
Las clases son abstracciones del mundo real. Los objetos son instancias de una clase.
Una instancia es la manifestacin concreta de una abstraccin. En un sistema orientado
a objetos, las instancias forman el ncleo 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 explcitamente 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 annima: No hay un nombre explcito para un objeto. Slo se da el

nombre de la clase o paquete junto con el nombre de la clase.
Instancia hurfana: Una instancia hurfana es aquella cuya abstraccin no es

conocida. Es til en situaciones en que los objetos se cargan dinmicamente en
memoria. Al momento del diseo, la abstraccin podra no ser conocida. Si
despus se descubre la abstraccin a la que corresponde esta instancia, se le
puede cambiar a una instancia nombrada.
Tambin se puede mostrar una coleccin de objetos llamados multiobjetos.

La Figura 1.26 muestra ejemplos de las instancias nombradas y annimas.

114
Gua del Estudiante
esteEmpleado
Instancia nombrada, sin especificar el

nombre de la clase
esteEmpleado: Empleado
Instancia nombrada con el nombre de

clase dado
Instancia sin nombrar, slo nombre de clase

dado
:Empleado
:EmpleadoData ::Empleado
Instancia sin nombre pero, tanto el paquete

como la clase son especificados
Multiobjeto, coleccin de objetos

annimos
:Empleado
Figura 1.26: Ejemplos de Instancias Nombradas y Annimas
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 jerarqua de herencias, la operacin puede o no ser invocada
como una operacin polimrfica.
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 esttica empleadoNombre y el valor actual jerry. Usando la notacin 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 rectngulo oscuro.
La Figura 1.27 muestra los atributos de un objeto y los objetos activos.
115
Gua del Estudiante
esteEmpleado
empleadoNombre="Scooby"
empleadoEdad=28
Instancia con valores de atributo
Instancia con un estado explcito
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 especficos.
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
relacin 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 relacin entre una
clase y un objeto.
Instantiate: Este estereotipo establece que la fuente crea instancias del destino.
11.4.2 Restricciones
Las instancias slo tienen una restriccin, referida como transient. Una restriccin
transient especifica que la instancia debe ser creada durante la ejecucin de una
interaccin cerrada. Dichos objetos son destruidos despus de que la ejecucin se
completa.
116
Gua del Estudiante
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 conexin semntica
entre objetos. Tambin es una instancia de una asociacin. Un enlace se muestra como
una lnea. 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 extrado 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 relacin de generalizacin entre Usuario/Cliente y Usuario/Empleado.
Tambin muestra una relacin de asociacin entre Cliente/Pagos,
Cliente/Reservacin, 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, tambin como la relacin y la multiplicidad que existen entre ellos. Un
cliente puede tener cero o ms reservaciones y cada reservacin es realizada
nicamente por un cliente especfico.

117
Gua 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_afiliacin
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 mltiples 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, tambin los atributos pueden estar en
blanco o pueden ser nulos, todo depende de la definicin del atributo en la clase.

118
Gua del Estudiante

<<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

En el contexto del modelado de relaciones, se pueden considerar las siguientes pautas:
Restringir el uso de dependencias slo a aquellas relaciones que no son

estructurales.
Hacer uso de la relacin de generalizacin slo si se encuentra una relacin es

un (herencia).
Evitar herencias mltiples. Usar agregacin 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 slo donde hay relaciones estructurales
entre objetos.
Mantener un diagrama UML simple. Esto permitir no tener demasiadas lneas

que crucen y lo hagan difcil de leer y comprender.

119
Gua 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.

120
Gua del Estudiante

1) Cul de las siguientes declaraciones es falsa?
a) Un clasificador es un bloque de construccin 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 caractersticas estructurales y de comportamiento.
2) El mbito de clase para las operaciones declara que las operaciones pueden ser
invocadas usando slo 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) Cul de los siguientes son restricciones para una asociacin?
a) Complete
b) Ordered
c) Disjoint
d) Or exclusive
5) Cules de las siguientes pueden ser operaciones de una clase abstracta?
a) Una operacin abstracta.
b) Una operacin de hoja.
c) Una operacin de polimorfismo.
d) Ninguna de las anteriores.
6) La multiplicidad no puede ser mostrada para los atributos de una clase.
a) Verdadero
b) Falso

121
Gua del Estudiante
7) Cul de los siguientes utiliza el estereotipo <<bind>> ?

a) Clases
b) Clases abstractas
c) Clases template
d) Sper clases
8) Cul de los siguientes utiliza un estereotipo import?
a) Objetos
b) Interfaces
c) Clases
d) Paquetes
9) La realizacin 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

122
Gua del Estudiante

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

123
Gua del Estudiante
Unidad 2: Laboratorio de Modelado

Estructural Avanzado
Al final de esta unidad, debera estar en capacidad de:
Identificar las clases de un determinado documento de requerimientos.
Dibujar diagramas de clase.
Dibujar diagramas de objeto para diferentes escenarios.

Unidad 2: Laboratorio de Modelado Estructural Avanzado
125
Gua del Estudiante
El e-Bank lanz sus operaciones en Venezuela, con su casa matriz en Caracas, en
2002. Dentro de un periodo corto de tres aos, construy una red de 275 sucursales por
toda Venezuela. Quizs 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 disear e implementar un nuevo
sistema ATM basado en las ltimas tecnologas. 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 fciles de extender y mantener.
para el e-Bank:

contacto.

- Fecha.
- Hora.
- Cantidad.


corriente.
cliente.

126
Gua del Estudiante

positivo.



travs del ATM.


1) Identificar los paquetes en los cuales sern ubicadas las clases identificadas en el
volumen anterior. Mostrar la visibilidad apropiada.
2) Mostrar una realizacin de interfaz.
3) Dibujar el diagrama de objetos para cualquier instancia del diagrama de clases.

127
Gua del Estudiante
Unidad 3: Modelado de interaccin

Al final de esta unidad, debera estar en capacidad de:
Definir colaboraciones.
Definir interacciones.
Elaborar Diagramas de secuencias.
Elaborar Diagramas de colaboracin.
Describir pasos para realizar diagramas de colaboracin.

129
Gua del Estudiante
1. Introduccin
La vista de interaccin describe secuencias de intercambios de mensajes entre los roles
que implementan el comportamiento de un sistema.
Esta visin proporciona una vista integral del comportamiento del sistema, es decir,
muestra el flujo de control a travs de muchos objetos. La vista de interaccin se exhibe
en dos diagramas centrados en distintos aspectos pero complementarios: centrados en
los objetos individuales y centrados en objetos cooperantes. A continuacin se explican
2 conceptos importantes para entender estos diagramas.
2. Interaccin
Es el conjunto de mensajes intercambiados por los roles del clasificador a travs de los
roles de asociacin. Un mensaje es una comunicacin unidireccional entre dos objetos,
un flujo de objeto con la informacin de un remitente a un receptor. Un mensaje puede
tener parmetros que transporten valores entre objetos. Un mensaje puede ser una
seal (comunicacin explcita entre objetos, con nombre y asncrona) o una llamada (la
invocacin sncrona de una operacin con un mecanismo para el control, que retorna
posteriormente al remitente).
3. Colaboracin
Es una descripcin de una coleccin de objetos que interactan para implementar un
cierto comportamiento dentro de un contexto. Describe una sociedad de objetos
cooperantes unidos para realizar un cierto propsito. Una colaboracin contiene ranuras
que son rellenadas por los objetos y enlaces en tiempo de ejecucin. Una ranura de
colaboracin se llama Rol porque describe el propsito de un objeto o un enlace dentro
de la colaboracin. Conociendo estos conceptos, se puede aprender sobre estos
diagramas.
4. Diagramas de Interaccin
Los diagramas de interaccin 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 patrn de interaccin entre los objetos. Por lo tanto, un diagrama de
interaccin consiste de:
Conjunto de objetos.
Relaciones o enlaces entre objetos.
Mensajes entre objetos.
Existen dos tipos de diagramas de interaccin. stos son:
Diagramas de Secuencia: Describen el comportamiento del sistema

enfatizando el orden secuencia en el tiempo de los mensajes. El orden

130
Gua del Estudiante
secuencia en el tiempo se representa grficamente 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 Colaboracin: Representan colaboraciones que enfatizan la

organizacin estructural de los objetos que pasan mensajes entre ellos mismos.
La notacin para un diagrama de colaboracin es un conjunto de arcos y
vrtices.
Ambos diagramas consisten tpicamente 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 colaboracin incluyen una ruta y diversos nmeros de
secuencia. Estas dos caractersticas subrayan la diferencia entre estos diagramas.
Los diagramas de secuencia y colaboracin son como dos caras de la misma moneda.
De hecho son considerados semnticamente equivalentes, esto significa que
representan la misma informacin, dado que son creados a partir del mismo conjunto de
datos. As un diagrama puede ser convertido en otro y viceversa. No se perdern datos
durante el proceso de conversin. Sin embargo, de modo explcito, dan a conocer
diferentes vistas del mismo sistema.
Los diagramas de secuencia tienen varias caractersticas importantes que son
necesarias para este modelado, las cuales se denotan a continuacin.
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 comunicndose el uno con el otro. El
examinar cmo los objetos trabajan bajo circunstancias especficas, revela la naturaleza
exacta de la comunicacin. Por lo tanto, los diagramas de secuencia modelan al nivel
de objetos ms que al nivel de clases. El diagrama de secuencia utiliza dos elementos
fundamentales los cuales se muestran a continuacin.
4.1.1 Lnea de Vida del Objeto
La notacin de la lnea de vida de un objeto es una combinacin de un objeto con una
lnea de tiempo, la cual es una lnea discontinua que sale de la base del objeto. El largo
de dicha lnea representa el tiempo que el objeto interacta en el escenario.
El tope del diagrama es la localizacin por defecto de los objetos en un diagrama de
secuencia, si los objetos estn en el tope del diagrama significa que el objeto existe con
anterioridad en el escenario, pero si el objeto es dibujado niveles ms abajo, esto
significa que el objeto es creado durante el escenario. En la Figura 3.1 se muestra un
ejemplo de lneas de vida de un objeto.

131
:Cliente
:Cliente
:Reservacin
Gua del Estudiante
:Empleado
Figura 3.1: Tres Objetos con Lneas de Vida
4.1.2 Mensajes
Un mensaje es la definicin para la comunicacin entre objetos, estos mensajes pueden
invocar una operacin, enviar una seal, causar una creacin o destruccin de un
objeto. Los mensajes se representan con una flecha, pero segn 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 envo 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
mtodo
cunsultar_Pelicula(id_pelicula) es invocado mucho antes que el mensaje
obtenerPelicula(). Tambin 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
restriccin {transient}. Dicho objeto luego de ser utilizado se destruye. La barra
vertical muestra el enfoque de control. Es el perodo de tiempo durante el cual un objeto
est realizando una accin. Tambin es importante nombrar que las flechas punteadas
132
Gua del Estudiante
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.
Sncronos: El objeto remitente pasa un mensaje y espera a que el receptor

acepte la llamada. El receptor despacha la operacin y enva un valor de retorno
al remitente. Observe la Figura 3.3.
Figura 3.3: Mensajes Sncronos en Diagramas de Secuencia
Asncronos: El objeto remitente enva una seal y contina con sus tareas
independientes. El receptor recibe la seal, la procesa y luego de la finalizacin de la tarea, contina con sus tareas independientes. El remitente no espera a
que el receptor complete la tarea. Los dos objetos no estn sincronizados en
este tipo de comunicacin. La Figura 3.4 ilustra el paso asncrono de mensajes.
Figura 3.4: Mensajes Asincrnico 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 Pelcula luego de
recibir la lista de pelculas, enva un mensaje invocando al mtodo
llenarPelicula(). Este ltimo, se encarga de crear la lista en el objeto para luego
seleccionar a travs del Id, la pelcula requerida por el objeto de la clase Cliente.

133
Gua del Estudiante
4.1.3 Comentarios
En algunos casos es importante proporcionar alguna explicacin sobre lo que sucede
en el diagrama o en los elementos dentro del diagrama. Para realizar esto la
especificacin UML se vale del mecanismo comn como las notas. Estas notas pueden
ser colocadas en cualquier parte del diagrama o pueden ser unidas a los elementos por
medio de una lnea punteada. Como se muestra en la Figura 3.5.
Figura 3.5: Comentarios en Diagramas de Secuencia
4.1.4 Iteracin
Una iteracin significa que uno o ms mensajes son ejecutados en secuencia ms de
una vez. La iteracin se denota usando un asterisco (*) y una condicin para controlar el
nmero 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 pelculas en existencia segn sus gneros entre otras cosas. El diagrama
de secuencia para este caso de uso utilizara una iteracin para recuperar de la base de
datos las pelculas segn un filtro de bsqueda. Observe este ejemplo en la Figura 3.6.
Figura 3.6: Iteraciones en Diagrama de Secuencia

134
Gua del Estudiante
4.2 Diagramas de Colaboracin

Los diagramas de colaboracin brindan una orientacin visual acerca del flujo, en el
contexto de la organizacin estructural de objetos que interactan unos con otros. Dado
que no existe un ordenamiento en el tiempo de los mensajes, se proporciona a los
mensajes un nmero de secuencia y as se mantiene una correspondencia uno a uno
entre los dos diagramas. La ventaja de un diagrama de colaboracin es que puede
ayudar a validar las asociaciones entre las clases o a descubrir nuevas.
La Figura 3.7 ilustra un diagrama de colaboracin.
Figura 3.7: Diagrama de colaboracin
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 Colaboracin

Normalmente, los diagramas de colaboracin se usan para modelar el flujo secuencial.
Sin embargo, se pueden modelar flujos ms complejos que involucren iteracin y
bifurcacin.
En el caso de la iteracin, el nmero de secuencia tiene como prefijo la expresin de
iteracin [m: = 1 to 100], o simplemente *, para indicar que el mensaje es llamado
varias veces.
En el caso de la bifurcacin, una condicin como [a > b] es puesta como prefijo al
nmero de secuencia. Las rutas de la rama llevan el mismo nmero de secuencia pero
la condicin asociada a ellas no debe solaparse. UML no formula estndar alguno para
las expresiones usadas en ambos casos. Puede ser usado cualquier seudo cdigo
acordado.
135
Gua del Estudiante
La Figura 3.8 ilustra la iteracin y bifurcacin en diagramas de colaboracin. Dado que

el nmero 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 iteracin.
GerenteRegistro
[id:=1 to 499]
1: graduaEstudiante()
Graduador
3: estudianteNoGraduado()
2: modificaEstadoEstudiante()
[no aprobado]
[aprobado]
ManejadorExepcion
ConectorBaseDato
Figura 3.8: Iteracin y Bifurcacin en Diagrama de Colaboracin
5. Manejar Tiempo y Espacio

El tiempo y espacio se modelan tpicamente 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 operacin 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 aqul en donde los componentes se distribuyen a lo largo de
diferentes nodos. Los nodos pueden ser diferentes computadoras ubicadas fsicamente
aparte unas de otras, o pueden estar en la misma computadora usando diferentes
procesadores.
La especificacin del tiempo es importante para sistemas en tiempo real y la ubicacin
para sistemas distribuidos.
Los trminos 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.

136
Gua del Estudiante
Restriccin de Tiempo: Se refiere a un valor absoluto o relativo del tiempo, que

se debe cumplir. En UML, la restriccin de tiempo se denota por una cadena
encerrada entre llaves. Un ejemplo es {TiempoDeEspera <= 10 ns}.
Ubicacin: 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 in < 10 ns }
{Location= servidor
Base de datos}
EnrutadorDatos
4: haltOperacio nes()
Figura 3.9: Representacin de Tiempo y Espacio
6. Cmo Crear un Diagrama de Colaboracin

Para una mejor comprensin 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 gua.
Agregar un mensaje con una flecha paralela, en el enlace entre dos objetos.
Enumere el mensaje en el orden de ejecucin.
Repita los pasos 3 y 4 hasta que este modelado todo el escenario.

137
Gua del Estudiante
Resumen
Definir colaboraciones.
Definir interacciones.
Describir diagramas de secuencias.
Describir diagramas de colaboracin.
Describir pasos para realizar diagramas de colaboracin.

138
Gua del Estudiante

1) Cul de las siguientes es una instancia de asociacin?
a) Interaccin
b) Enlace
c) Actividad
d) Relacin
2) Cul de los siguientes introduce un ordenamiento dinmico de mensajes pasados
entre dos o ms objetos?
a) Interacciones
b) Actividades
c) Clases
d) Carriles
3) Cules son estereotipos asociados a los enlaces?
a) new
b) transient
c) destroy
4) Los diagramas de colaboracin muestran los mensajes en orden ascendente en el
tiempo.
a) Verdadero
b) Falso
5) Los diagramas de interaccin comprenden de: Seleccione los que apliquen
a) Conjunto de objetos.
b) Relaciones o enlaces entre objetos.
c) Mensajes entre objetos.
d) Generalizaciones.
6) Los trminos asociados al tiempo y espacio son: Seleccione los que apliquen
a) Marca de tiempo
b) Expresin de tiempo
c) Ubicacin
d) Restriccin de espacio
139
Gua del Estudiante
7) Un diagrama de colaboracin puede ser convertido en un diagrama de secuencia.

a) Verdadero
b) Falso
8) Algunas de las semejanzas entre el diagrama de secuencia y de colaboracin son:
Seleccione las que apliquen.
a) Ambos diagramas consisten tpicamente de objetos, enlaces y mensajes.
b) Los diagramas de secuencia y colaboracin describen el tiempo de vida de un
objeto y el enfoque de control.
c) Estos diagramas son creados a travs del mismo conjunto de datos.
d) Los diagramas de secuencia y colaboracin 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 asincrnico
c) Mensaje sncrono
d) Mensaje reflexivo
10) La iteracin se denota usando un numeral (#) y una condicin para controlar el
nmero de iteraciones.
a) Verdadero
b) Falso

140
Gua del Estudiante

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

141
Gua del Estudiante
Unidad 4: Lab. de Modelado de

Interaccin
Disear diagramas de secuencia.
Disear diagramas de colaboracin.
Aplicar los conceptos aprendidos en la unidad anterior.

Unidad 4: Lab. de Modelado de Interaccin
143
Gua del Estudiante
El e-Bank lanz sus operaciones en Venezuela, con su casa matriz en Caracas en el
ao 2002. Dentro de un periodo corto de tres aos, construy una red de 275
sucursales por toda Venezuela. Quizs 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 disear e implementar un
nuevo sistema ATM basado en las ltimas tecnologas. 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 fciles de extender y mantener.
para el e-Bank:

contacto.

- Fecha.
- Hora.
- Cantidad.


corriente.
cliente.

144
Gua del Estudiante

positivo.



travs del ATM.


1) Realizar un diagrama de secuencia y colaboracin para retirar efectivo de la
cuenta corriente.

145
Gua del Estudiante
Unidad 5: Modelado de Comportamiento

Avanzado
Discutir qu son los eventos y las seales.
Definir mquinas de estado.
Discutir y construir diagramas de estado.

147
Gua del Estudiante
1. Introduccin
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 interaccin y diagramas de actividad. En esta unidad, se aprender
otro diagrama el diagrama de estados el cual permite realizar un Modelado de
Comportamiento.
2. Mquinas de Estado
En la dinmica de anlisis y diseo orientado a objetos, los objetos son tpicamente
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
mquinas 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 algn 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 mquinas de estado ayudan a modelar estos cambios de una
manera simple.
Las mquinas de estado representan un conjunto de estados que atraviesa un objeto
durante su tiempo de vida. Tambin incluyen la reaccin del objeto ante un evento.
Las mquinas de estado se pueden usar para modelar el comportamiento de una
instancia de una clase o un caso de uso. A veces, las mquinas de estado se usan para
modelar el sistema completo.
Las mquinas de estado pueden ser visualizadas de dos maneras, segn se menciona
a continuacin:
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 terminologas asociadas a las mquinas 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:
148
Gua del Estudiante
Satisfacer una condicin.
Realizar una actividad especfica.
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 annimo.
Acciones de Entrada: Se puede especificar una accin cuando un objeto est

entrando a un estado. Por ejemplo, se puede fijar la accin colocarAlarma() al
entrar a un estado.
Acciones de Salida: Tambin se puede especificar una accin cuando un

objeto sale de un estado. Por ejemplo, se puede fijar la accin
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 accin y se genera un cambio de
estado.
Transiciones Internas: Son transiciones que suceden internamente entre

subestados de un mismo estado. Se ejecuta una accin 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 representacin grfica de los estados.
Figura 4.1: Representacin Grfica de los Estados
UML define dos tipos especiales de estados:
Estado Inicial: Representa el inicio del diagrama. El estado inicial se representa

grficamente con un punto slido junto con una flecha que apunta al primer

149
Gua 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 culminacin del diagrama de estados. El estado

final es una subclase de estado, razn por la cual toma todas las caractersticas
de un estado con la excepcin que no puede salir ninguna transicin de l. El
estado final se representa grficamente como un ojo de buey (un punto dentro
de un crculo), tal como se muestra a la derecha de la Figura 4.2.
Figura 4.2: Representacin Grfica de Estado Inicial y Final
Es importante sealar que tanto el estado inicial como el final se denominan

seudoestados, ya que no cumplen con todas las caractersticas de un estado simple.
3. Eventos
Un evento es un suceso o hecho en el sistema que causa una transicin de estado. Un
evento posee tiempo y espacio asociados a l. La Figura 4.3 es una ilustracin de un
evento simple.
Figura 4.3: Evento Simple
La figura anterior describe dos estados: Inactivo y Activo. La transicin del estado
Activo al estado Inactivo se debe al evento llamado Colgar. La mayora de los
eventos resultan en una accin. En la Figura 4.3, el evento Colgar resulta en la accin
liberarConexion().
Los eventos pueden ser de dos tipos:

150
Gua del Estudiante
Eventos Externos: Los eventos que ocurren entre los actores y el sistema se
denominan eventos externos. La insercin 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 excepcin de desbordamiento
de punto flotante es un ejemplo de un evento interno.
Un evento es anlogo a los mensajes en un diagrama de secuencia. Existen cuatro

tipos de eventos que pueden ser modelados en UML: seales, eventos de llamada,
eventos de tiempo y eventos de cambio.
3.1 Seales
Las seales se refieren a la comunicacin asncrona entre objetos. Las seales no
devuelven valores a los que envan la seal. Las seales son siempre enviadas de un
objeto a otro, nunca son invocadas. Normalmente en un sistema se espera que los
objetos acten y reaccionen al evento. De igual manera, las seales se usan para
manejar eventos excepcionales. Por lo tanto, una seal es un evento que es lanzado
asincrnicamente por un objeto y es capturado por otro objeto en el sistema. Esta
comunicacin asncrona entre objetos es referida como excepcin, en los lenguajes de
programacin modernos. Las excepciones son el tipo ms comn de seales que se
modelan en un sistema.
La Figura 4.4 muestra el modo en que las seales se representan en UML. Se muestra
que la seal ConexionFallida es lanzada asincrnicamente por la operacin
obtenerConexion() del ConectorBaseDatos cuando existe una falla en la
conexin a la base de datos. Se usa el estereotipo <<send>> para indicar que se enva
una seal.
ConectorBaseDato
<<send>>
ObtenerConexion()
obtenerPelicula()
ObtenerPeliculA()
ObtenerListaPelicula()
ObtenerListaPelicula()
<<seal>>
ConexionFallida
nombreBd
Figura 4.4: Representacin de Seales en UML
Tpicamente, las excepciones son modeladas usando seales. La Figura 4.5 muestra un
ejemplo del modo en que pueden ser modeladas.

151
Gua del Estudiante
Figura 4.5: Excepciones Modeladas con Seales usando Estereotipo <<exception>>
La seal es una clase estereotipada o que tiene un estereotipo. Los parmetros

enviados junto con la seal sirven de atributos de la seal. En el ejemplo anterior de la
Figura. 4.4, nombrebd es el parmetro.
Las seales tambin tienen relaciones de generalizacin. La Figura 4.6 ilustra la
jerarqua de seales.
Figura 4.6: Jerarqua de Seales

152
Gua del Estudiante
La
seal
FallaTeclado
es
una
especializacin
de
la
seal
FallaDispositivoEntrada, la cual a su vez es una especializacin de la seal
FallaHardware. En la Figura 4.6, se intenta modelar los eventos asncronos para un
sistema de computadora.
Una seal puede ser enviada como una accin de una transicin de estado en una
mquina de estado. Tambin puede ser un mensaje enviado desde un objeto hacia otro
en una interaccin. Las seales pueden ser enviadas dentro de una operacin durante
su ejecucin.
3.2 Eventos de Llamada

La emisin de operaciones se llama eventos de llamada. El despacho de la operacin
resulta en una transicin de estado a diferencia de las seales que son asncronas, por
lo general, los eventos de llamada son tpicamente sncronos. Un objeto invoca una
operacin sobre otro objeto que tiene un estado, as el objeto receptor completa la
operacin y cambia a un nuevo estado, despus del cual el control es regresado al
emisor. El emisor espera hasta que el receptor finalice la operacin.
La Figura 4.7 muestra un ejemplo de un evento de llamada.
Figura 4.7: Evento de Llamada
La Figura 4.7 describe una transicin de estado de Inactivo a Procesando. El

objeto estaba en el estado Inactivo cuando recibi el mensaje
validarIdSeguridad. Al completar la validacin, 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 expresin que caracteriza el tiempo. Por ejemplo, after (4
segundos) o after (2 horas) son formas vlidas 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.

153
Gua del Estudiante
Inactivo
Figura 4.8: Evento de Tiempo
La Figura 4.8 ilustra una funcionalidad simple de un salva pantalla. La expresin 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 expresin 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 condicin se puede representar
usando eventos de cambio. La palabra reservada usada para describir eventos de
cambio es when, seguida de una expresin condicional. El evento de cambio ocurre
cuando la condicin en la expresin 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 condicin 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 reunin 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 travs de una transicin. Cuando
un objeto se mueve de un estado a otro, el movimiento se muestra usando una
transicin. Bajo la ocurrencia de un evento, el objeto ingresa al siguiente estado en la
154
Gua del Estudiante
relacin. La ocurrencia del evento resulta en alguna accin especificada. Una transicin
puede tener mltiples fuentes y mltiples destinos.
Un estado puede transitar a s mismo. Esto es referido como autotransicin. En la
autotransicin, el objeto abandona el estado debido a la ocurrencia de un evento,
maneja el evento, ejecuta una accin y reingresa al mismo estado. Un ejemplo de
autotransicin puede verse en la Figura 4.10.
Figura 4.10: Autotransicin
En la Figura 4.10, se muestra el modo en que un telfono realiza el discado de un

nmero telefnico. Cada vez que se presiona un dgito numrico se activa un evento
que va asociado a la accin AadirDigito() que almacena el nmero para luego
validarlo y conectar la llamada. Cada vez que es presionado un nmero, el objeto
abandona el estado Marcando para ejecutar una accin y luego regresar al mismo.
Nmero vlido es una restriccin que debe cumplirse para ir al estado En lnea.
Existen cinco partes en una transicin. stas son:
Estado Fuente: Un estado fuente es aquel que es afectado por la transicin.

Antes de la transicin, el objeto est activo en el estado fuente.
Estado Destino: Se alcanza este estado despus de completar la transicin. El

objeto ahora est activo en ese estado.
Accin: Es la computacin atmica que puede afectar el objeto al que

pertenece la mquina de estado. La accin puede afectar otros objetos
indirectamente, si estn visibles para ese objeto.
Evento Activador: El evento activador dispara la transicin que permite

moverse al siguiente estado. Debe cumplirse la condicin de guarda.
Condicin de Guarda: Hay una evaluacin de una expresin Booleana cuando

ocurre el activador de eventos. Si la evaluacin de la expresin resulta
verdadero, la transicin se dispara, de lo contrario no se dispara.
Antes de ver cmo son modelados los subestados en UML, se vern brevemente las
caractersticas avanzadas asociadas a estados y transiciones. Vea la Figura 4.11.

155
Gua del Estudiante
Figura 4.11: El Estado Procesando de un Objeto
La Figura 3.11 describe el estado Procesando de un objeto. A continuacin se

discuten cinco caractersticas asociadas a estados y transiciones:
Accin de Entrada (Entry): Las acciones de entrada pueden no tener

condiciones de guarda, sin embargo pueden tener parmetros. Los parmetros
pueden representar los argumentos que recibe la mquina de estado durante el
proceso de creacin 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 mltiples flujos de eventos concurrentes desde mltiples estados.
Accin de Salida (Exit): Pueden existir mltiples 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 despus 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: Tpicamente, 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 transicin 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 accin 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 transicin 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 algn otro momento. Esto significa solamente
que el evento no es manejado inmediatamente.

156
Gua del Estudiante
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 tambin 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 accin 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 mquinas 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 algn subestado especfico del estado
compuesto.

157
Gua del Estudiante
4.2 Subestados Concurrentes

Los subestados concurrentes permiten especificar dos o ms 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 transicin 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 ramificacin. Cuando una transicin 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 unin.
Los subestados concurrentes pueden no tener estados inicial, final o historial. Sin
embargo, el subestado secuencial dentro de un subestado concurrente puede incluir
estas caractersticas. 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 tambin llamados subestados ortogonales.

158
Gua del Estudiante
4.3 Historial de Estados

A veces es til y necesario mantener el ltimo subestado activo antes de salir por
transicin 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 condicin. Basado en la condicin, 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 incmodo, dado que
cada subestado necesita mantener una accin de salida. Al reingresar al estado
compuesto, se realiza una verificacin para encontrar la transicin hacia el estado
correcto.
UML proporciona una manera ms simple en donde un historial del estado puede ser
modelado. No hay necesidad de mantener acciones de salida con este mtodo. En vez
de ello, se usa el smbolo H dentro de un crculo para indicar que el estado compuesto
mantiene un historial. La transicin 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 transicin en
medio del flujo de control secuencial. Una vez que la transicin dentro de los
subestados anidados alcance al estado final, se pierden los detalles del historial. Vea la
Figura 4.14.

159
Gua del Estudiante
Figura 4.14: Mquina de Estado Compleja
La Figura 4.14 es una mquina de estado razonablemente compleja. El estado

compuesto Reportando representa un historial profundo. ste recuerda el historial del
estado anidado ms interno, el cual es Conectando. El subestado anidado Generando
muestra un historial superficial y mantiene el historial slo para los subestados dentro
de su espacio circundante.
El evento activarReporte() causa una transicin 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 crculo y un historial profundo es descrito con una H* dentro de
un crculo. El historial superficial mantiene el historial del subestado anidado inmediato.
El historial profundo mantiene el historial hasta el subestado anidado ms interior de
cualquier profundidad.
La Figura 4.14 muestra un ejemplo de historial superficial y profundo. Los estados del
historial se pueden usar slo 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.

160
Gua del Estudiante
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 estmulos y mensajes exteriores. Un
diagrama de estados se representa grficamente como vrtices y arcos. El nombre UML
designado para la mquina 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 estmulo externo,
para causar que un objeto acte 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. Tambin 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 mquina 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 seal de activacin realizan una llamada a una
central de bomberos y descuelgan la llamada.

161
Gua del Estudiante
Figura 4.15: Una Mquina 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. Tpicamente, 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 direccin 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 direccin. Los hilos pueden ser
conocidos para el sistema operativo, pero tpicamente 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 semntica de
concurrencia. Esto ayuda a la sincronizacin de las interacciones entre flujos
independientes.
162
Gua del Estudiante
Una clase activa es descrita grficamente en la Figura 4.16. El borde exterior del
rectngulo es ms grueso. Una clase activa es como una clase normal con atributos,
operaciones y compartimentos adicionales. Los objetos activos reciben seales, las
cuales se listan en un compartimiento llamado Seales.
La Figura 4.16 muestra las diversas partes de una clase activa. Las clases estticas no
reciben seales y por lo tanto no tienen un compartimiento llamado Seales. Se ve
que la clase ConectorBaseDatos recibe dos seales.
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 aplicacin, 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 estndar 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 continuacin:
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 operacin
desde un objeto hacia otro objeto. La Figura 4.17 muestra este tipo de paso de
mensaje.
163
Gua del Estudiante
Figura 4.17: Paso de Mensaje entre Objetos Pasivos
2) Pasar un mensaje desde un objeto activo hacia otro objeto activo

La comunicacin interprocesos ocurre cuando dos objetos activos se involucran en una
comunicacin. Existen dos maneras en las que ocurre la comunicacin interprocesos:
Un objeto activo invoca una operacin sobre otro objeto activo sincrnicamente.
El objeto llamador pasa un mensaje y espera a que el receptor acepte la
llamada. El receptor despacha la operacin y enva un valor de retorno al
llamador. El llamador y el receptor continan con sus tareas independientes. Por
la duracin de la operacin, los dos objetos son sincronizados. La Figura 4.18
muestra un ejemplo de paso sncrono de mensajes.
Figura 4.18: Paso Sncrono de Mensajes
Un objeto activo invoca una operacin sobre otro objeto activo

asincrnicamente. El objeto llamador enva una seal y contina con sus tareas
independientes. El receptor recibe la seal, la procesa y luego de la finalizacin
de la tarea, contina con sus tareas independientes. El llamador no espera a que
el receptor complete la tarea. Los dos objetos no estn sincronizados en este
tipo de comunicacin. La Figura 4.19 ilustra el paso asncrono de mensajes.
Figura 4.19: Paso Asncrono de Mensajes
Note la diferencia entre los smbolos usados en las Figuras 4.18 y 4.19 para el paso
sncrono y asncrono de mensajes. En el primer caso, el objeto de
:ConectorBaseDatos espera hasta que el objeto :EnrutadorDatos encuentre una
164
Gua del Estudiante
nueva ruta. Esto puede ocurrir cuando existe una saturacin de la red. En el segundo
caso, el objeto :EnrutadorDatos pasa un mensaje asncrono haltOperations() y
luego contina con su tarea independiente. La finalizacin de la tarea
haltOperations() no afecta las tareas independientes de :EnrutadorDatos.
3) Pasar un mensaje desde un objeto pasivo hacia un objeto activo
Algn flujo de control inicia desde un objeto activo. Esto permite que el objeto pasivo
invoque una operacin sobre el objeto activo. La misma semntica 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
invocacin de una operacin. Sin embargo, se tiene que ver el tema de la sincronizacin
cuando ms 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 ms de un objeto activo pasa
mensajes a un objeto pasivo.
Figura 4.21: Paso de Mensajes desde Mltiples Objetos Activos hacia un Objeto Pasivo
En la figura anterior, dos instancias de la clase Parser estn enviando mensajes al

objeto :AcumuladorDatos.

165
Gua del Estudiante
7. Caso de Estudio: Trabajar con Diagramas de Estado

Para el caso de estudio de la tienda de video, a continuacin se muestra el diagrama de
estados para un objeto Pelcula. 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 pelcula existe
en Stock, estando en ese estado la pelcula puede ser Alquilada, Comprada o
Reservada. Note que para que ocurra una transicin al estado Alquilada, es necesario
que el cliente que desea alquilar la pelcula este afiliado, igual pasa cuando ocurre una
transicin del estado Reservada al estado Alquilada si la reservacin tiene menos de 24
horas ocurre la transicin y si es mayor de 24 horas la reservacin es rechazada
(eventos de cambio). En el caso del estado Comprada no existe ninguna restriccin
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 pelcula. Ver Figura 4.23
En esta figura se muestran 2 estados en la que un objeto cliente puede estar cuando
alquila y devuelve pelculas, estos son: SinPelicula y ConPelicula.

166
Gua del Estudiante
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 SinPelcula

cuando no realiza ningn alquiler, al activarse el evento AlquilerPelicula()ocurre
una transicin al estado ConPelicula, el cual tiene 2 transiciones reflexivas. La
transicin reflexiva de la izquierda se realiza cuando se activa el evento
DevolverPelcula(), tomando en cuenta que el cliente tiene ms de una pelcula
alquilada. La transicin reflexiva de la derecha se realiza cuando se activa el evento
AlquilarPelicula() y el cliente ya tiene pelculas 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 pelcula alquilada.
Las siguientes, son algunas recomendaciones en el contexto de manejo de eventos:
Puede construirse una jerarqua de seales; esto le permitir sacar provecho de

las propiedades comunes de algunas seales relacionadas.
Un elemento que recibe un evento debe tener definitivamente una mquina de

estados adecuada.
Los elementos que envan eventos y tambin aquellos que reciben eventos
deben ser modelados.
La mquina de estados no debe ser complicada por estados y transiciones

superfluos; debe mantenerse simple.
La mquina de estados debe ser eficiente en trminos 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 prctica tener ms de dos niveles de anidamiento.

167
Gua del Estudiante
Resumen
Discutir eventos y seales.
Definir mquinas de estado.
Discutir y construir diagramas de estado.
Describir de qu modo las restricciones de tiempo y espacio afectan el modelado

del sistema.

168
Gua del Estudiante

1) Cul de los siguientes causa una transicin de estado?
a) Estado
b) Evento
c) Accin
2) Cul de los siguientes es asncrono por naturaleza?
a) Seales
b) Eventos
c) Acciones
3) Cul de los siguientes tipos de eventos representa el despacho de una operacin?
a) Accin
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 accin
5) Cules de los siguientes elementos pueden modelar su comportamiento con
mquinas de estado?
a) Clase
b) Caso de uso
c) Interacciones
d) Colaboraciones

169
Gua del Estudiante
6) Las acciones de entrada y salida, son parte de:______________________

a) Un estado
b) Un evento
c) Una accin
7) Las transiciones internas no resultan en un cambio de estado.
a) Verdadero
b) Falso
8) Un estado puede tener una auto-transicin.
a) Verdadero
b) Falso
9) Qu tipo de subestado puede no tener estados inicial o final?
a) Secuencial
b) Concurrente
c) Iterativo
10) A menos que se indique el tiempo de inicio para verificar una expresin que sigue a
un after es el momento cuando se ingres al estado actual
a) Verdadero
b) Falso

170
Gua del Estudiante

1) b
2) a
3) d
4) b
5) a y b
6) a
7) a
8) a
9) b
10) a

171
Gua del Estudiante

Describir componentes, nodos y colaboraciones.
Discutir diagramas de componentes.
Discutir la necesidad de diagramas de despliegue.
Describir estereotipos y relaciones entre componentes y nodos.

173
Gua del Estudiante
1. Introduccin
En esta unidad se aprender acerca del modo en que son modeladas las partes
arquitectnicas 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 fsicos del
mismo. Se construyen modelos lgicos para visualizar y conceptualizar el sistema. El
modelo arquitectnico se usa para modelar las entidades fsicas que existen
eventualmente en el mundo real, es importante destacar que tanto las vistas fsica como
lgica 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 ms objetos modelados usando diferentes diagramas. Los
diagramas arquitectnicos permiten modelar ejecutables, libreras, tablas, archivos,
cdigo fuente y nodos fsicos. En esta unidad, se aprender acerca de los diagramas de
componentes y diagramas de despliegue. A continuacin se discutir sobre
componentes.
2. Componentes
Un componente es un tipo Clasificador con la diferencia de que no tiene caractersticas
propias, pero contiene las clases que definen las caractersticas. Un componente
proporciona una vista encapsulada de la funcionalidad definida por las clases
contenidas.
Un componente es una parte fsica del sistema. Cada componente tiene un nombre, el
cual puede ser un nombre simple o un nombre de ruta.
En la especificacin UML 1.4 se describe como una caja rectangular con dos
rectngulos ms pequeos 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 representacin de
componentes en UML.
Figura 6.1: Representacin de Componentes en UML

174
Gua del Estudiante
En la Figura 6.1, se observa que el componente ProcesadorImagen.exe tiene una

relacin con tres clases ProcesadorImagenes, GeneradorVectores y
GeneradorBMP. Por lo tanto, se puede decir que las clases mencionadas implementan
el componente en cuestin.
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: Relacin de Dependencia entre un Componente y sus Clases
2.1 Clases vs. Componentes

Las clases representan abstracciones lgicas del mundo real, mientras que los
componentes representan las partes fsicas de un sistema. Cualquier sistema tiene
elementos fsicos y lgicos. Un componente es la implementacin fsica de un conjunto
de elementos lgicos en el sistema. Las clases y colaboraciones son simples ejemplos
de elementos lgicos en un sistema. Por lo tanto, se ve una relacin entre un
componente y las clases que realiza. De modo similar, un componente puede ser la
implementacin fsica de un conjunto de colaboraciones. La relacin de dependencia se
usa para describir la relacin 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 (cdigo fuente, archivos binarios, bases de datos, entre otros), que
son utilizados parta implementar las caractersticas del componente.
UML proporciona cinco estereotipos estndar que aplican a componentes. stos son:

175
Gua del Estudiante
<<executable >> Para describir que un componente puede ser ejecutado en

un nodo.
<<library >> Para describir una inclusin de una librera. Puede ser una
librera esttica o dinmica.
<<table >>Para mostrar que se usa una tabla de la base de datos.
<<file >> Para mostrar que se incluye un cdigo 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 Relacin 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 estn disponibles slo a travs de sus interfaces.
La relacin entre un componente y una interfaz puede mostrarse de dos formas:
Usando la forma abreviada (icnica).
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 exportacin. 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 icnica,
dicha interfaz proporciona la funcionalidad al componente de manejar el archivo de
imagen a procesar (crear archivo, abrir archivo, entre otras).

176
Gua del Estudiante
Figura 6.4: Realizacin de una Interfaz de Forma Icnica
La Figura 6.5 muestra la misma realizacin pero de forma expandida. Ntese que en
esta representacin se da a conocer las operaciones que son parte de la interfaz.
Figura 6.5: Realizacin 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 travs 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: Realizacin y Uso de la Interfaz
2.4 Tipos de Componentes

UML presenta tres tipos de componentes. stos son:
177
Gua del Estudiante
Componentes de Despliegue o Distribucin (Deployment): Estos

componentes se usan para formar un sistema ejecutable. Un ejemplo de tal
componente es la librera de enlace dinmico 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 distribucin como AgenteAnalizado.java y
AnalizadorDatos.txt.
Componentes de Ejecucin: 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 ejecucin.
3. Diagrama de Componentes
Los diagramas de componentes se usan para modelar la implementacin esttica de
elementos fsicos que residen en un nodo, como los ejecutables, libreras, tablas y
archivos. Los diagramas de componentes son tiles tambin para construir sistemas
ejecutables a travs de la ingeniera reversa y la ingeniera hacia adelante.
Un diagrama de componentes es un conjunto de componentes y la relacin 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 librera de enlace dinmico, una librera .h, una tabla y
un archivo fuente CPP.
178
Gua del Estudiante
Los diagramas de componentes se usan tpicamente para modelar los siguientes

elementos:
Cdigo Fuente.
Lanzamiento de Ejecutables (releases).
Bases de Datos Fsicas.
Sistemas Adaptables.
Ingeniera Hacia Adelante y Reversa.
3.1 Modelar Cdigo Fuente

El conjunto de archivos de cdigo 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 versin o
cualquier otra informacin acerca de un archivo.
La Figura 6.8 muestra el modo en que los archivos de cdigo fuente se describen en
UML.
En la Figura 6.8 se muestra que la versin 3.1 del archivo de encabezado
LibreriaImagenes.h es la versin anterior. Esto se describe usando el estereotipo
<<parent>>. Tambin 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 cdigo fuente.
Figura 6.8: Descripcin de Archivos de Cdigo Fuente en UML
3.2 Modelar Lanzamiento de Ejecutables (Releases)

As como se puede modelar cdigo fuente usando UML, tambin 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,
179
Gua del Estudiante
una librera de enlace dinmico y un archivo de base de datos. En Java se necesitan

archivos .class y .jar. Tal como se muestra en la Figura 6.9, tambin se pueden
modelar las diferentes partes de un lanzamiento.
La liberacin 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 Liberacin
3.3 Modelar Bases de Datos Fsicas

Se pueden modelar bases de datos fsicas del mismo modo en que se modela el cdigo
fuente. La Figura 6.10 ilustra esto. Cabe destacar que la base de datos tambin 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
relacin.

180
Gua del Estudiante
Figura 6.10: Modelado de Bases de Datos Fsicas
3.4 Modelar Sistemas Adaptables

Existen dos tipos de sistemas: estticos y dinmicos. En los sistemas estticos, los
componentes entran a la escena de ejecucin, participan en la ejecucin y luego se
retiran. No existe movimiento de componentes de un procesador a otro. Los sistemas
dinmicos contienen agentes que son mviles. Estos agentes mviles se desplazan de
un procesador a otro para manejar el balance de carga y la recuperacin ante fallas. Se
puede usar el diagrama de componentes UML para modelar dichas entidades
dinmicas 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 tpica en cualquier aplicacin intensiva de datos. Esto permite a
las aplicaciones su ejecucin, 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 aplicacin 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 interaccin
181
Gua del Estudiante
que muestra un objeto del componente que migra, adems de la accin resultante de la
migracin. Existen dos instancias del mismo componente mostrado, pero se diferencian
en cuanto a la localizacin del servidor. La Figura 6.12 muestra esta migracin.
Figura 6.12: Migracin del Servidor Primario al Secundario
En la Figura 6.12 se muestra la migracin del servidor primario al secundario ante una
falla del servidor y el posterior retorno al servidor primario luego de la recuperacin ante
la falla.
3.5 Ingeniera hacia Adelante y Reversa

La ingeniera hacia adelante es la creacin del cdigo a partir de un modelo existente.
La ingeniera en reversa es la creacin del modelo a partir del cdigo existente. Los
diagramas de componentes pueden usarse para mostrar la ingeniera hacia adelante y
en reversa. Tpicamente, los diagramas de componentes ayudan a entender el tipo de
elementos que van hacia un componente. Algunas ayudas estn disponibles en forma
de herramientas, las cuales permiten a los diseadores realizar la ingeniera hacia
adelante y en reversa.
En el caso de la ingeniera hacia adelante, se necesita identificar las clases y
colaboraciones para un componente. Las clases y colaboraciones identificadas permiten
disear y escribir el cdigo. El objetivo para la ingeniera hacia adelante es el cdigo
fuente, una librera binaria o un ejecutable.
182
Gua del Estudiante
En el caso de la ingeniera en reversa, tanto el cdigo fuente como las libreras binarias
pueden ser la fuente. Al cdigo fuente se le puede aplicar ingeniera en reversa para
tener componentes seguidos por clases. A las libreras binarias se les puede aplicar
ingeniera en reversa para conocer sus interfaces.
La Figura 6.13 muestra un ejemplo de ingeniera hacia adelante. Muestra el modo en
que el componente AgenteAnalizador recibe ingeniera hacia adelante y se
convierte en un conjunto de cdigos fuente y archivos de base de datos. De modo
similar, a una librera de enlace dinmico o un cdigo fuente se le puede hacer
ingeniera en reversa para mostrar los componentes y las clases que se usaron para
construir los archivos de librera y cdigo fuente.
Figura 6.13: Ingeniera Hacia Adelante
4. Colaboraciones
Las colaboraciones son un conjunto de clases, interfaces, nodos, componentes y casos
de uso. La colaboracin 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 colaboracin. La notacin UML para la colaboracin es una
elipsis con lneas punteadas. La Figura 6.14 ilustra la colaboracin
AfiliacionClientes. Para el caso de estudio de la tienda de video.
183
Gua del Estudiante
Figura 6.14: Ilustracin de la Colaboracin AfiliacinClientes
Las colaboraciones se ocupan de dos aspectos. stos son:
Aspectos Estructurales: Incluye clases, interfaces, nodos, componentes y

casos de uso. Tpicamente, los aspectos estructurales de una colaboracin son
realizados como un conjunto de relaciones entre los elementos estructurales.
Los aspectos estructurales se muestran a travs de un diagrama de clases. La
Figura 6.15 muestra una vista simple de los aspectos estructurales de la
colaboracin AfiliacinClientes.
Aspectos de Comportamiento: Incluye los aspectos dinmicos del modo en

que los elementos estructurales interactan unos con otros. Los aspectos de
comportamiento se describen a travs del diagrama de interaccin. La
colaboracin proporciona el contexto en donde pueden modelarse las
interacciones. La Figura 6.16 muestra los aspectos de comportamiento para la
colaboracin 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 Colaboracin Afiliacin Estudiante

184
Gua del Estudiante
La Figura 6.16 representa un simple diagrama de clases. El diagrama de clases

mostrado anteriormente es la realizacin de aspectos estructurales de la colaboracin
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 Colaboracin AfiliacionClientes
En el proceso del entendimiento del sistema, los casos de uso son identificados y
diseados. Pero en la implementacin final del sistema, los casos de uso deben ser
convertidos en trminos de los aspectos estructurales y de comportamiento del sistema.
Las colaboraciones se usan para modelar la realizacin de un caso de uso y la
implementacin de una operacin. La colaboracin, se describe usando los aspectos
estructurales y de comportamiento. Para la colaboracin especificada, esto resulta en
diagramas de clases y de interaccin. En otras palabras, el caso de uso se convierte en
diagramas de clases y de interaccin a travs de colaboraciones. La Figura 6.17
muestra la realizacin de uno caso de uso por una colaboracin.
Figura 6.17: Realizacin de Caso de Uso como Colaboracin
5. Patrones
El diccionario define un patrn como una forma o modelo propuesto para imitacin, por
ejemplo, un diseo. En terminologa de computadoras, patrn es algo que brinda una
185
Gua del Estudiante
solucin, en un contexto dado, para problemas comunes. Un patrn consiste de tres

elementos:
Contexto.
Problema.
Solucin.
Cuando se enfrenta un problema, no siempre es necesario pensar en una solucin

nueva y nica al problema. Se puede reutilizar una solucin existente en vez de dedicar
tiempo y recursos tratando de encontrar una nueva solucin.
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 ms de las soluciones ya disponibles y
trabajar en la construccin de la nueva casa, quizs mejorando las caractersticas que
proporcionan las soluciones existentes. Este ejemplo da a conocer que el contexto es
conocido donde el problema ya tiene una solucin. Una casa tiene dos constituyentes
importantes. stos son:
Vista Externa: Se refiere al exterior de la casa, la cual puede tener estilos

Gtico, Victoriano o Neogtico.
Vista Interna: Se refiere al esfuerzo dedicado al diseo 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 terminologa 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 ingeniera reversa (reverse) como la ingeniera hacia adelante
(forward).
Existen 2 tipos de patrones:
Patrones arquitectnicos.
Patrones de diseo.
Estos patrones no sern discutidos en este curso.

A continuacin se aprender acerca de los Diagramas de Despliegue.
6. Diagrama de Despliegue
Los diagramas de despliegue (deployment) muestran la disposicin de los elementos de
procesamiento en tiempo de ejecucin. Estos elementos contienen componentes,
procesos y objetos. Estos elementos de procesamiento en tiempo de ejecucin son
referidos como nodos que representan un recurso computacional que tiene memoria y
186
Gua del Estudiante
capacidad de procesamiento. Los diagramas de componentes son normalmente

combinados con diagramas de despliegue para mostrar el modo en que los elementos
fsicos estn distribuidos sobre diversas plataformas de hardware. Un diagrama de
despliegue es un grfico de nodos. Cada nodo est conectado para describir la
asociacin de comunicacin.
Los diagramas de componentes y de despliegue son llamados colectivamente
diagramas de implementacin.
6.1 Nodo
Son clasificadores que representan un recurso computacional en tiempo de ejecucin.
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,
generalizacin y asociacin, tambin pueden participar en diagramas de interaccin 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 ejecucin de un sistema, mientras que los

nodos ejecutan componentes.
Los componentes caracterizan el empaquetamiento de elementos lgicos como

colaboraciones y clases, mientras que los nodos representan componentes
fsicamente desplegados.
Cuando un conjunto de componentes es desplegado en un nodo, el grupo es referido

como una unidad de distribucin.
187
Gua del Estudiante
La relacin entre nodo y componente puede mostrarse usando la notacin para relacin
de dependencia.
La conexin entre dos o ms nodos se hace a travs de la relacin de asociacin, y el
mecanismo de comunicacin es escrito como un estereotipo. Por ejemplo, el
mecanismo de comunicacin 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 lnea recta para especificar la relacin entre nodos,
describiendo la relacin de asociacin. La relacin entre un nodo y los componentes
que despliega es una relacin 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 explosin
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 tpico 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
188
Gua del Estudiante
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 dems
diagramas. Estos diagramas se usan para modelar la vista esttica del sistema, llamada
la vista de despliegue. La vista incluye la distribucin, entrega e instalacin 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 relacin entre un sistema y un subsistema se llama relacin de
agregacin. Esta relacin denota que el sistema contiene los subsistemas.
Figura 6.20: Un Tpico Diagrama de Despliegue

189
Gua del Estudiante
Se han estado usando los trminos modelo y vista en todo el curso. Ahora se
entendern estos elementos claramente. Se establece simplemente que un modelo es
una representacin. Es un tipo de paquete y por lo tanto no se proporciona una notacin
separada para un modelo en UML. Un modelo posee tpicamente elementos como
clases, interacciones y relaciones.
Una vista proporciona una observacin del modelo. Muestra la parte relevante del
sistema segn sea aplicable a la vista.
La notacin 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 realizarn los diagramas de
componentes y de despliegue. Para un mejor entendimiento, se describe nuevamente el
problema.

- Nombre completo.
- Cdula.
- Direccin.
- Telfono.
- Edad.
- Estado civil.
- Referencias personales.
Como requisito de inscripcin la persona debe de ser mayor de 18 aos.
El cliente puede afiliarse por medio del sitio Web y cancelar con su tarjeta de
crdito.

Las reservaciones son realizadas por la pgina Web del video.

190
Gua del Estudiante

existencia.

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 grficas es la pantalla de reservar pelculas; 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:
Pelcula.class, Cliente.class, Reservacin.class. En la Figura 6.21
puede observar el diagrama de componentes.
Figura 6.21: Diagrama de Componentes para la Interfaz Grfica

IReservacionPeliculas.class.
El componente IResevacionPeliculas es dependiente de Cliente.class,

Reservacin.class y Pelculas.class, adems realiza la interfaz
IEventosReservacion.
191
Gua 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 pelculas. Se puede notar en la figura que la comunicacin entre el nodo
SistemaCentral y el nodo Terminal es realizada por el protocolo TCP/IP. Tambin
se puede notar que en la asociacin 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 cmo se realiza la comunicacin entre el sitio Web de la tienda
de video, el servidor http y el servidor de bases de datos, adems muestra los
componentes que juegan el papel ms 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 cdigo PHP que est en la pgina HTML. El componente MotorPhP
depende de EjecucionBD para acceder a la base de datos.
Figura 6.23: Diagrama de Despliegue

192
Gua del Estudiante
En el ejemplo de trabajo, se ha concentrado solo en algunas funcionalidades del

sistema. El proceso completo de la tienda tambin 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 discusin sobre OOAD usando los elementos de Modelado de
UML, a saber, los modelos estructurales, de comportamiento y arquitectnicos. Cada
uno de estos modelos proporciona una perspectiva diferente del sistema. Es importante
que cada modelo sea entendido desde sus bases conceptuales hasta su aplicacin al
dominio de un problema. Tpicamente, el anlisis empieza con la identificacin de los
casos de uso, derivacin de clases a travs de abstracciones, adjuntar
responsabilidades a las abstracciones y posicionamiento hacia la construccin del
modelo de diseo usando los diversos diagramas.

193
Gua del Estudiante
Resumen
Describir componentes, nodos y colaboraciones.
Discutir diagramas de componentes.
Discutir la necesidad de Diagramas de despliegue.
Describir estereotipos y relaciones entre componentes y nodos.

194
Gua del Estudiante

1) Qu permiten modelar los diagramas arquitectnicos?
a) Ejecutables
b) Libreras
c) Tablas
d) Archivos
2) Qu representan los componentes?
a) Abstracciones lgicas
b) Partes fsicas del sistema
c) Colecciones de abstracciones lgicas
d) a y c
3) Con qu clasificadores puede ser realizada una interfaz?
a) Clase
b) Componente
c) Casos de uso
d) Objetos
4) Cules de los siguientes son tipos de componentes?
a) Componentes de desplegado
b) Componentes de producto de trabajo
c) Componentes de ejecucin
d) Componentes de librera
5) Cules 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
195
Gua del Estudiante
7) Para qu se usan las colaboraciones?

a) Para modelar la realizacin de casos de uso
b) Para la implementacin de una operacin
c) Para el paso de mensajes
d) Para el manejo de excepciones
8) Cules de los siguientes elementos son usados tpicamente en los diagramas de
componentes para modelar?
a) Sistemas Adaptables
b) Ingeniera hacia Adelante y en Reversa
c) Elementos Estructurales
d) Elementos de comportamiento
9) La ingeniera hacia adelante es la creacin del cdigo a partir de un modelo
existente.
a) Verdadero
b) Falso
10) Cules de los siguientes son verdaderos con respecto a diagramas de
despliegue?
a) Los diagramas de despliegue muestran la disposicin de los elementos de
procesamiento en tiempo de ejecucin.
b) Un diagrama de despliegue es un grafo de nodos.
c) La relacin entre diagramas de componentes y de despliegue es fuerte.
d) Los diagramas de despliegue y los diagramas de interaccin tienen una fuerte
relacin.

196
Gua del Estudiante

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

197

Libro 1 Completo UML V51

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Libro 1 Completo UML V51

Uploaded by

Copyright:

Available Formats

Anlisis y Diseo de

Gua del Estudiante

IBM IT Education Services

Red Hat Linux

Edicin Diciembre 2007

Gua del Estudiante

Anlisis y Diseo de Sistemas Orientado a Objetos

2. Fundamentos de la Orientacin a Objetos

3. Importancia del Modelado

Unidad 1: Examen de Autoevaluacin

Respuestas a la Unidad 1: Examen de Autoevaluacin

Unidad 2: Modelado del Comportamiento con Casos de Uso ......................19

2. Importancia de los Casos de Uso

4. Anlisis de un Caso de Uso

5. Diagrama de Caso de Uso

Unidad 2: Examen de Autoevaluacin

Respuestas de la Unidad 2: Examen de Autoevaluacin

Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso.........19

Unidad 4: Modelado Estructural Bsico .........................................................19

3. Relaciones entre Clases

Anlisis y Diseo de Sistemas Orientado a Objetos

Gua del Estudiante

Unidad 4: Examen de Autoevaluacin

Respuestas de la Unidad 4: Examen de Autoevaluacin

Volumen 2: Modelado Avanzado .....................................................................19

5. Clases Plantillas (Template)

6. Estereotipos para Clases

12. Diagramas de Objetos

13. Caso de Estudio

14. Algunas Recomendaciones

Unidad 1: Examen de Autoevaluacin

Respuestas de la Unidad 1: Examen de Autoevaluacin

Unidad 2: Laboratorio de Modelado Estructural Avanzado ..........................19

Unidad 3: Modelado de interaccin.................................................................19

5. Manejar Tiempo y Espacio

6. Cmo Crear un Diagrama de Colaboracin

Unidad 3: Examen de Autoevaluacin

Respuestas a Unidad 3: Examen de Autoevaluacin

Unidad 4: Lab. de Modelado de Interaccin ...................................................19

Gua del Estudiante

Anlisis y Diseo de Sistemas Orientado a Objetos

Unidad 5: Modelado de Comportamiento Avanzado .....................................19

7. Caso de Estudio: Trabajar con Diagramas de Estado

Unidad 5: Examen de Autoevaluacin

Respuestas a la Unidad 2: Examen de Autoevaluacin

Unidad 6: Modelado Arquitectnico................................................................19

7. Caso de estudio Componentes y Despliegue

Unidad 6: Examen de Autoevaluacin

Respuestas a Unidad 4: Examen de Autoevaluacin

Gua del Estudiante

Anlisis y Diseo de Sistemas Orientado a Objetos

Descripcin del Curso

Introduccin a las computadoras personales y a Windows XP.

Fundamentos a la programacin Orientada a Objetos.

Objetivos del Curso

Describir la necesidad del estudio del Anlisis y Diseo Orientado a Objetos.

Conocer los conceptos bsicos del paradigma orientado a objetos.

Describir la importancia del modelado UML.

Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos

Descripcin del Curso 1

Copyright IBM Corp. 2007

Anlisis y Diseo de Sistemas Orientado a Objetos

Gua del Estudiante

Describir el uso y funcionamiento de los diagramas UML en el aspecto