D61808CS21 Ag

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
D77130
Edición 2.1
D61808CS21
Junio de 2010
OO-226 Rev E
Guía de Actividades
Modeling Language)
Análisis y Diseño Orientados a
Objetos mediante UML (Unified
Oracle University and Nanfor Iberica, S.L. use only

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle y/o sus filiales. Todos los derechos reservados.
Descargo de responsabilidad
Este documento contiene información patentada, está sujeto a un contrato de licencia que incluye restricciones de uso y
revelación y se encuentra protegido por la legislación sobre la propiedad intelectual. Puede copiar o imprimir este documento
sólo para uso propio durante una capacitación de Oracle. El documento no se podrá modificar ni alterar en modo alguno. A
menos que figure explícitamente en el contrato de licencia o esté permitido por la ley, no se podrá utilizar, copiar, reproducir,
traducir, emitir, modificar, conceder licencias, transmitir, distribuir, exhibir, representar, publicar ni mostrar ninguna parte, de
ninguna forma, por ningún medio.
La información contenida en este documento puede someterse a modificaciones sin previo aviso. Si detecta algún error, le
agradeceremos que nos lo comunique por escrito a: Oracle University, 500 Oracle Parkway, Redwood Shores, California
94065, EE. UU. No se garantiza que este documento se encuentre libre de errores.
Descargo de responsabilidad de Sun Microsystems, Inc.

Este manual de formación puede incluir referencias a materiales, ofertas o productos que previamente ofrecía Sun
Microsystems, Inc. Es posible que algunos materiales, ofertas, servicios o productos ya no se ofrezcan o suministren. Oracle
y sus filiales no se considerarán responsables de tales referencias en el caso de que aparezcan en el texto proporcionado.
Aviso de derechos restringidos
Si este documento se entrega al Gobierno de EE.UU. o a cualquier entidad que adquiera licencias en nombre del Gobierno
de EE.UU. se aplicará la siguiente disposición:
DERECHOS DEL GOBIERNO DE EE. UU.

Los derechos del Gobierno de EE. UU. de usar, modificar, reproducir, publicar, efectuar, mostrar, divulgar este material de
capacitación quedan sujetos a las restricciones y los términos del contrato de licencia de Oracle correspondiente y/o el
contrato del Gobierno de EE. UU. correspondiente.
Aviso de marca registrada
Oracle y Java son marcas comerciales registradas de Oracle y/o sus filiales. Todos los demás nombres pueden ser marcas
comerciales de sus respectivos propietarios.
Página dejada en blanco intencionadamente.

Página dejada en blanco intencionadamente.

Contenido

Acerca de este Manual....................................................... Prefacio-ix
Realización de Prácticas ...................................................... Prefacio-ix
Convenciones..........................................................................Prefacio-x
Convenciones Tipográficas..........................................Prefacio-x
Convenciones Adicionales..........................................Prefacio-xi
Examen de Terminología y Conceptos Orientados a Objetos..........1-1
Objetivos............................................................................................. 1-1
Actividad 1: Uso de la Abstracción ................................................. 1-2
Actividad 2: Uso de la Herencia ...................................................... 1-3
Actividad 3: Uso de la Delegación y la Cohesión ......................... 1-5
Actividad 4: Comprensión de las Ventajas del Uso
de Interfaces ..................................................................................... 1-6
Actividad 5: Definición de Terminología Orientada a Objetos ......... 1-7
Introducción al Modelado y al Proceso de Desarrollo
de Software .......................................................................................2-1
Objetivos............................................................................................. 2-1
Actividad 1: Definición de Flujos de Trabajo................................. 2-2
Actividad 2: Identificación de las Características del Flujo
de Trabajo de Recopilación de Requisitos................................... 2-3
de Trabajo de Análisis de Requisitos ........................................... 2-4
de Trabajo de Arquitectura............................................................ 2-5
de Trabajo de Diseño ...................................................................... 2-6
Actividad 6: Exploración de las Ventajas del Modelado.............. 2-7
Actividad 7: Identificación de Ventajas del Modelado
de Software ...................................................................................... 2-8
Actividad 8: Identificación de Tipos de Diagramas...................... 2-9
Creación de Diagramas de Casos de Uso......................................3-1
Objetivos............................................................................................. 3-1
v
Copyright 2010 Sun Microsystems, Inc. Todos los derechos reservados. Sun Learning Services, Revisión E
Actividad 1: Identificación de los Símbolos de los Casos

de Uso ............................................................................................... 3-2
Sistema de Hotel: Resumen de Requisitos Adicionales (1).......... 3-3
Actividad 2: Creación de un Diagrama de Casos de Uso ............ 3-4
Sistema de Hotel: Resumen de Requisitos Adicionales (2).......... 3-6
Actividad 3: Acotación del Diagrama de Casos de Uso............... 3-7
Creación de Escenarios y Formularios de Casos de Uso ........... 4-1
Objetivos............................................................................................. 4-1
Actividad 1: Examen de los Escenarios de los Casos de Uso ...... 4-2
Actividad 2: Creación de Formularios de Casos de Uso.............. 4-4

Actividad 3: Redacción del Glosario de Términos........................ 4-5
Creación de Diagramas de Actividades......................................... 5-1
Objetivos............................................................................................. 5-1
Actividad 1: Identificación de los Símbolos del Diagrama
de Actividades................................................................................. 5-2
Actividad 2: Creación de un Diagrama de Actividades............... 5-3
Determinación de las Abstracciones Clave .................................. 6-1
Objetivos............................................................................................. 6-1
Actividad 1: Búsqueda de Abstracciones Clave Candidatas....... 6-2
Actividad 2: Búsqueda de Abstracciones Clave con CRC ........... 6-3
Construcción del Modelo de Dominio de Problema..................... 7-1
Objetivos............................................................................................. 7-1
Actividad 1: Identificación de los Elementos del Diagrama
de Clases........................................................................................... 7-2
Actividad 2: Ampliación de un Diagrama de Clases.................... 7-3
Actividad 3: Identificación de Símbolos del Diagrama
de Objetos......................................................................................... 7-5
Actividad 4: Validación de un Diagrama de Clases ..................... 7-6
Transición del Análisis al Diseño mediante Diagramas de
Interacción........................................................................................ 8-1
Objetivos............................................................................................. 8-1
de Comunicación ............................................................................ 8-2
Actividad 2: Creación de un Diagrama de Comunicación .......... 8-3
de Secuencias ................................................................................... 8-4
Actividad 4: Creación de un Diagrama de Secuencias................. 8-5
Modelado del Estado del Objeto con Diagramas de
Máquina de Estados ........................................................................ 9-1
Objetivos............................................................................................. 9-1
de Máquina de Estados .................................................................. 9-2
Actividad 2: Creación de un Diagrama de Estados ...................... 9-3
vi Análisis y Diseño Orientados a Objetos mediante UML (Unified Modeling Language)

Aplicación de Patrones de Diseño al Modelo de Diseño............10-1

Objetivos........................................................................................... 10-1
Actividad 1: Aplicación de CRP .................................................... 10-2
Actividad 2: Aplicación del Patrón de Estrategia ....................... 10-3
Actividad 3: Aplicación del Patrón Observador ......................... 10-4
Actividad 4: Aplicación del Patrón de Estado ............................. 10-5
Introducción a los Diagramas y Conceptos Arquitectónicos.........11-1
Objetivos........................................................................................... 11-1
Actividad 1: Identificación de Niveles, Capas y Cualidades
Sistémicas ....................................................................................... 11-2

Actividad 2: Exploración de Diagramas de Componentes........ 11-4
Actividad 3: Comprensión de los Diagramas de Despliegue .......... 11-6
Actividad 4: Creación de un Diagrama de Despliegue de
Alto Nivel....................................................................................... 11-7
Introducción a los Niveles Arquitectónicos.................................12-1
Objetivos........................................................................................... 12-1
Actividad 1: Actualización y Ampliación de un Diagrama
de Niveles y Capas........................................................................ 12-2
Actividad 2: Creación de las Clases DAOFactory y DAO ......... 12-3
Acotación del Modelo de Diseño de Clases ................................13-1
Objetivos........................................................................................... 13-1
Actividad 1: Acotación de Atributos............................................. 13-2
Actividad 2: Acotación de Asociaciones mediante
Agregación y Composición ......................................................... 13-4
Actividad 3: Acotación de la Dirección del Transversal ............ 13-5
Actividad 4: Acotación de Métodos de Negocio y
Constructores................................................................................. 13-6
Actividad 5: Comprobación de la Alta Cohesión y el Bajo
Acoplamiento del Diagrama de Clases...................................... 13-7
Actividad 6: Creación de Componentes con Interfaces.............. 13-8
Visión General sobre los Procesos de Desarrollo de Software.14-1
Objetivos........................................................................................... 14-1
Actividad 1: Identificación de Características de
Metodología ................................................................................... 14-2
Actividad 2: Definición de las Cinco Metodologías
Orientadas a Objetos .................................................................... 14-3
Actividad 3: Producción de un Plan de Iteración........................ 14-4
Actividad 4: Selección de Metodologías....................................... 14-5
Visión General de los Marcos .......................................................15-1
Objetivos........................................................................................... 15-1
Actividad 1: Creación de un Marco Conceptual ......................... 15-2
Actividad 2: Identificación de Marcos Potenciales ..................... 15-3
Revisión del Curso .........................................................................16-1
vii

Prefacio
Acerca de este Manual

Realización de Prácticas
A excepción de las actividades de autorrevisión o donde se indique lo
contrario, se sugiere que las actividades prácticas de este libro se
completen en pequeños grupos. Esto favorece los ideales de modelado
UML sobre la comunicación y el intercambio de ideas para crear mejores
soluciones, que puedan mejorar la experiencia de aprendizaje. El
instructor ayudará en la asignación de grupos.
Se supone que las actividades de autorrevisión debe realizarlas cada

alumno de forma individual. Sin embargo, estas actividades también
pueden completarse en parejas o pequeños grupos.
Prefacio-ix
Convenciones
Convenciones
En este curso se usan las siguientes convenciones para representar
distintos elementos de formación y recursos alternativos de aprendizaje.
Convenciones Tipográficas
Courier se usa para los nombres de comandos, archivos, directorios,

códigos de programación y salidas de computadora en pantalla; por
ejemplo:
Utilice ls -al para enumerar todos los archivos.
system% You have mail.
La fuente Courier también se usa para indicar las construcciones de

programación, como nombres de clases, métodos y palabras clave; por
ejemplo:
El método getServletInfo se utiliza para obtener información
sobre el autor.
La clase java.awt.Dialog contiene el constructor Dialog .
La fuente Courier negrita se usa para los caracteres y números que se

escriben; por ejemplo:
Para enumerar los archivos de este directorio, escriba:
#ls
Courier negrita se usa también para cada línea de código de

programación a la que se haga referencia en una descripción textual; por
ejemplo:
1 import java.io.*;
2 import javax.servlet.*;
3 import javax.servlet.http.*;
Tenga en cuenta que la interfaz javax.servlet se importa para
permitir el acceso a sus métodos de ciclo de vida (línea 2).
Courier cursiva se usa para variables y marcadores de posición de

línea de comandos que son reemplazados por un nombre o un valor
reales; por ejemplo:
Para suprimir un archivo, use el comando rm filename.
Prefacio-x Análisis y Diseño Orientados a Objetos mediante UML (Unified Modeling Language)
Convenciones
La fuente Courier negrita cursiva se usa para representar las

variables cuyos valores debe introducir el alumno como parte de una
actividad; por ejemplo:
Escriba chmod a+rwx filename para otorgar derechos de lectura,
escritura y ejecución a todos los usuarios, a un grupo de ellos o a
algunos usuarios sobre filename.
La fuente Palatino cursiva se usa para los títulos de libros, palabras o

términos nuevos, o bien, para las palabras que se desea enfatizar; por
ejemplo:

Lea el capítulo 6 de User's Guide.
Estos se denominan opciones de clase.
Convenciones Adicionales
En los ejemplos de lenguaje de programación Java™ se utilizan las
siguientes convenciones adicionales:
O No se usan paréntesis después de los nombres de métodos, a menos
que se muestre una lista de parámetros formales o reales; por
ejemplo:
"El método doIt..." se refiere a cualquier método llamado doIt.
"El método doIt()..." se refiere a un método llamado doIt que no
incluye argumentos.
O Los saltos de línea tienen lugar cuando hay separaciones (comas),
conjunciones (operadores) o espacios en blanco en el código. Un
código roto tiene una sangría de cuatro espacios debajo del código
inicial.
O Si en el entorno operativo Solaris™ se usa un comando distinto al
que se utiliza en la plataforma Microsoft Windows, se muestran
ambos comandos; por ejemplo:
Si trabaja en el entorno operativo Solaris
$cd $SERVER_ROOT/bin
Si trabaja en Microsoft Windows
C:>cd %SERVER_ROOT%\bin
Acerca de este Manual Prefacio-xi


Práctica 1
Examen de Terminología y Conceptos

Orientados a Objetos

Objetivos
Al finalizar estas actividades, debería estar capacitado para:
O Definir los conceptos orientados a objetos (OO) fundamentales
O Crear diagramas de clases sencillos con clases, asociaciones,
herencias e interfaces
O Aplicar los conceptos de cohesión y delegación a los diagramas de
clases
1-1
Actividad 1: Uso de la Abstracción
Actividad 1: Uso de la Abstracción

En este ejercicio va a utilizar la abstracción en un objeto car del mundo
real. Deberá asegurarse de mantener exclusivamente las
responsabilidades del objeto car que sean relevantes para cada dominio
especificado.
Preparación

No es necesaria ninguna preparación especial para esta actividad.
Tareas
Lleve a cabo el siguiente paso:
1. Dibuje una descripción de clase UML para cada uno de los contextos
de dominio de negocio siguientes:
a. Car utilizado en un contexto de negocio "Uso del parking"
b. Car en un contexto de negocio "Juego de circuito de carreras de
motor"
Nota: El "juego de circuito de carreras de motor" puede tratarse de una

simulación de computadora o de un juego físico (por ejemplo, el Scaletrix
Digital) con métodos para controlar el vehículo.
c. Car en un contexto de negocio "Registro de licencias de

vehículos"
d. Car en cualquier otro contexto de negocio con el que esté de
acuerdo su grupo (opcional)
Nota: Puede consultar los diagramas UML de ejemplo del módulo 1 de la

Guía del Alumno y revisar la notación gráfica de un diagrama de clases
UML.
1-2 Análisis y Diseño Orientados a Objetos mediante UML (Unified Modeling Language)
Actividad 2: Uso de la Herencia

En este ejercicio utilizará la herencia para ampliar las responsabilidades
(atributos y métodos) de una clase.
Preparación

Tarea 1: Crear una Jerarquía de Herencias
1. Dibuje las clases UML que están relacionadas por herencia. Cada
clase debería incluir su nombre, atributos y métodos. Estas clases,
que proceden todas del dominio de la banca, son las siguientes:
O Una clase Account que contiene los atributos y métodos
siguientes:
O Atributos: balance y accountNumber
O Métodos: credit y debit
O Una clase SavingsAccount entre cuyas reglas de negocio se
establece que el balance no puede ser inferior a cero.
O Una clase LoanAccount, entre cuyas reglas de negocio se
establece que el balance no puede ser superior a cero y que
debit sólo se puede utilizar una vez (es decir, al abrir la cuenta).
O Una clase CheckingAccount(CurrentAccount), entre cuyas
reglas de negocio se establece lo siguiente:
O Puede existir un límite de sobregiro.
O Si existe un límite de sobregiro, el balance puede caer por
debajo de cero, pero no puede superar ese límite de sobregiro.
O Una clase TaxFreeSavingsAccount, entre cuyas reglas de
negocio se establece un límite crediticio anual y que no se
puede obtener más crédito que esa cantidad anualmente.
Nota: Puede consultar los diagramas UML de ejemplo del módulo 1 de la

Guía del Alumno y revisar la notación gráfica de la herencia.
Examen de Terminología y Conceptos Orientados a Objetos 1-3

Nota: El problema tiene un ámbito reducido para eliminar las

distracciones que no agregan ningún valor en este momento. Por ejemplo,
no se agregará ningún aspecto sobre el interés cargado o a pagar.
Tarea 2: Asignar Reglas de Negocio a los Métodos


1. Para cada método identificado en la tarea anterior, cree una lista que
contenga la información siguiente:
a. Nombre de clase y nombre de método
b. Reglas de negocio que se aplican a ese método
Actividad 3: Uso de la Delegación y la Cohesión
Actividad 3: Uso de la Delegación y la Cohesión

En este ejercicio, delegará responsabilidades coherentes a clases por
medio de herencia y asociaciones de clases.
Preparación

Tareas
Lleve a cabo los siguientes pasos:
1. Agregue los detalles siguientes al diagrama de clases creado en la
actividad anterior:
O Información del cliente (por ejemplo, nombre, dirección y
número de teléfono)
O Un cliente empresarial también debe tener un número de
registro de compañía.
O Un cliente personal quizás tenga un número de referencia
fiscal.
O Un identificador de código de sucursal (cada sucursal de este
banco tiene un identificador único)
O Detalles del nombre y dirección del banco
2. Asegúrese de que el diagrama de clases cumple la condición
siguiente:
Un cliente puede tener muchas cuentas en este banco. Sin embargo,
una cuenta sólo puede ser propiedad de un cliente.

Actividad 4: Comprensión de las Ventajas del Uso de Interfaces
Actividad 4: Comprensión de las Ventajas del Uso de

Interfaces
En este ejercicio comprenderá cómo las interfaces permiten crear
soluciones flexibles.
Preparación

Tareas
1. Lea el escenario siguiente:
Se le ha pedido que escriba un sistema de software que se pueda
utilizar para comprar y vender propiedades. Ha decidido delegar el
comportamiento de compra y venta específico de las propiedades a
una clase PropertyTradingService que incluye los métodos buy y
sell.
Ahora se le pide que se cerciore de que este sistema de software es
capaz de soportar el comercio de distintos tipos de elementos, por
ejemplo vehículos y acciones que cotizan en bolsa.
2. Dibuje un diagrama de clases que describa las clases e interfaces que
serán necesarias para proporcionar una solución flexible al problema
especificado en el paso 1. Deberá cerciorarse de que los nuevos tipos
de elementos se pueden agregar al sistema de software con unos
cambios mínimos en el sistema de software existente.
Actividad 5: Definición de Terminología Orientada a Objetos
Actividad 5: Definición de Terminología Orientada a

Objetos
Autorrevisión: Relacione los términos de programación orientados a
objetos con sus definiciones.

Término Definición
polimorfismo Identificación exclusiva de los métodos y

atributos que son relevantes para la clase dentro
del sistema.
enlace de objeto Capacidad de derivar nuevas clases que
adquieren atributos y métodos de una clase base.
herencia Diseño para un objeto.
abstracción Ocultación de métodos y datos internos para
evitar el acceso directo desde fuera de la clase.
objeto Relación entre dos objetos (instancias).
delegación Medida del soporte de una entidad (componente
o clase) de un propósito concreto dentro de un
sistema.
encapsulación Capacidad de determinar el método real al que se
llama según el subtipo del objeto.
asociación Instancia de una clase.
clase Descarga de algunas responsabilidades
coherentes a otro componente (una o varias
clases) o método.
acoplamiento Relación entre dos clases.
cohesión Grado de dependencia que tienen entre sí las

clases dentro del sistema.


Práctica 2
Introducción al Modelado y al Proceso de

Desarrollo de Software

Objetivos
O Definir los flujos de trabajo en el proceso de desarrollo de software
orientado a objetos (OOSD)
O Identificar las características del flujo de trabajo de recopilación de
requisitos
O Identificar las características del flujo de trabajo de análisis de
requisitos
O Identificar las características del flujo de trabajo de arquitectura
O Identificar las características del flujo de trabajo de diseño
O Identificar las ventajas del software de modelado
O Definir los distintos tipos de diagramas de lenguaje unificado de
modelado (UML)
2-1
Actividad 1: Definición de Flujos de Trabajo
Actividad 1: Definición de Flujos de Trabajo
Autorrevisión: Relacione cada flujo de trabajo con su descripción.


Recopilación de Modela la estructura de nivel superior del
requisitos sistema, prestando especial atención a los
requisitos no funcionales y a la mitigación de
riesgos.
Análisis de Instala la implantación en el entorno de
requisitos producción.
Arquitectura Crea/codifica los componentes de software
definidos en el modelo de solución.
Diseño Determina los requisitos del sistema reuniéndose
con el propietario del negocio y los usuarios del
sistema propuesto.
Implantación Garantiza que la implantación satisfaga las
expectativas definidas en los requisitos.
Prueba Crea un modelo de solución del sistema que
satisface los requisitos funcionales.
Despliegue Analiza, acota y modela los requisitos del
sistema.
Actividad 2: Identificación de las Características del Flujo de Trabajo de Recopilación de Requisitos

de Trabajo de Recopilación de Requisitos
Autorrevisión: Seleccione las características del flujo de trabajo de
recopilación de requisitos mencionadas durante la clase.
a. ___ Este flujo de trabajo incluye reuniones con el propietario del

negocio y los usuarios del sistema propuesto para

comprender sus requisitos.
b. ___ Este flujo de trabajo precisa el modelado de la estructura del
sistema de alto nivel para satisfacer los requisitos no
funcionales (NFR).
c. ___ El propósito de este flujo de trabajo es determinar lo que
debe hacer el sistema.
d. ___ Durante este flujo de trabajo se crea un diagrama de clases
de dominio de negocio que muestra las clases empresariales
requeridas.
e. ___ Durante este flujo de trabajo se crean diagramas de casos de
uso iniciales.
Introducción al Modelado y al Proceso de Desarrollo de Software 2-3

Actividad 3: Identificación de las Características del Flujo de Trabajo de Análisis de Requisitos

de Trabajo de Análisis de Requisitos
Autorrevisión: Seleccione las características del flujo de trabajo de análisis
de requisitos mencionadas durante la clase.
a. ___ Este flujo de trabajo incluye la grabación de escenarios de

casos de uso.

b. ___ Este flujo de trabajo comienza con el análisis y los escenarios
de casos de uso.
c. ___ El propósito de este flujo de trabajo es modelar cómo el
sistema soportará los casos de uso.
d. ___ Durante este flujo de trabajo se crea un diagrama de clases
de dominio de negocio que muestra las clases empresariales
requeridas.
e. ___ Durante este flujo de trabajo se crea un diagrama de
despliegue detallado que muestra la arquitectura del
sistema.
Actividad 4: Identificación de las Características del Flujo de Trabajo de Arquitectura

de Trabajo de Arquitectura
Autorrevisión: Seleccione las características del flujo de trabajo de
arquitectura mencionadas durante la clase.
a. ___ Durante este flujo de trabajo se crea un diagrama de

despliegue detallado.

b. ___ El propósito de este flujo de trabajo es modelar la estructura
de alto nivel del sistema para satisfacer los requisitos no
funcionales.
c. ___ Durante este flujo de trabajo se crea un diagrama de niveles
y capas.
d. ___ El propósito de este flujo de trabajo es modelar la estructura
de alto nivel del sistema para satisfacer los requisitos
funcionales.
e. ___ Durante este flujo de trabajo se acota el modelo de diseño.

Actividad 5: Identificación de las Características del Flujo de Trabajo de Diseño

de Trabajo de Diseño
Autorrevisión: Seleccione las características del flujo de trabajo de diseño
mencionadas durante la clase.
a. ___ Durante este flujo de trabajo se utiliza un diagrama de

actividades para verificar los diagramas de casos de uso.

b. ___ Durante este flujo de trabajo se analizan los escenarios de
casos de uso para determinar los detalles adicionales.
c. ___ Durante este flujo de trabajo se crea un modelo de solución.
d. ___ Durante este flujo de trabajo se puede crear un diagrama de
estados.
e. ___ El propósito de este flujo de trabajo es modelar cómo el
sistema soportará los casos de uso.
Actividad 6: Exploración de las Ventajas del Modelado
Actividad 6: Exploración de las Ventajas del Modelado

En este ejercicio explorará las ventajas del modelado.
Preparación

Tareas
Con su grupo, complete los pasos siguientes:
1. Revise las vistas frontal y de planta de un objeto que la compañía
quiere que cree:
Front View Plan/Top View
Figura 0-1 Vista frontal y vista de planta de un objeto
2. Responda a las siguientes preguntas:

O ¿Le ha proporcionado suficiente información la compañía para
crear el objeto? En caso negativo, ¿qué información adicional
necesita?
O En el supuesto de que alguien creara realmente el objeto para la
compañía, ¿cuál cree que sería su aspecto?

Actividad 7: Identificación de Ventajas del Modelado de Software
Actividad 7: Identificación de Ventajas del Modelado de

Software
Autorrevisión: Seleccione las ventajas del modelado de software que se
han mencionado durante la clase.
a. ___ Los modelos sólo proporcionan un punto de inicio para un

sistema nuevo.

b. ___ Los modelos sólo ayudan a comprender lo que se ha
desarrollado.
c. ___ Los modelos ayudan a visualizar los sistemas nuevos o
existentes.
d. ___ Los modelos son una concreción de un sistema.
e. ___ Los modelos ayudan a comunicar decisiones a los
participantes del proyecto.
Actividad 8: Identificación de Tipos de Diagramas
Autorrevisión: Relacione el diagrama UML con la descripción de su tipo.

Nombre del
Definición

diagrama
Caso de uso Representa los cambios de estado o valor junto con las
restricciones de estado y duración.
Clase Representa un flujo de tareas que podría realizar un
sistema o un actor.
Objeto Representa una recopilación de componentes y muestra
su distribución por uno o más nodos de hardware.
Comunicación Representa un flujo de tareas con fragmentos de
interacciones de objetos detalladas.
Secuencia Representa una recopilación de objetos que trabajan juntos
para soportar algunos comportamientos del sistema.
Actividad Representa la estructura interna de una clase en términos
de partes.
Máquina de estados Representa una visión conceptual de una recopilación de
otros diagramas y elementos de modelado.
Componente Representa una recopilación de componentes de software
físicos y cómo se relacionan entre sí.
Despliegue Representa el juego de estados que un objeto puede
experimentar junto con los disparadores que
desencadenan la transición del objeto de un estado a otro.
Paquete Representa una perspectiva con orientación temporal de
la comunicación entre objetos.
Visión general de Representa una instantánea en tiempo de ejecución de
interacciones objetos de software y sus interrelaciones.
Tiempos Representa ampliaciones de diagramas estándar.
Estructura Representa el juego de comportamientos de alto nivel que
compuesta el sistema debe realizar para un actor determinado.

Nombre del
Definición
diagrama
Perfil Representa una recopilación de clases de software y sus

interrelaciones.
Práctica 3
Creación de Diagramas de Casos de Uso
Objetivos

O Identificar los elementos esenciales de un diagrama de casos de uso
O Ampliar un diagrama de casos de uso basándose en una lista de
requisitos funcionales de alto nivel adicionales proporcionada por el
propietario del negocio
O Dividir un diagrama de casos de uso en vistas
O Ampliar las vistas del diagrama de casos de uso basándose en una
lista de FR de alto nivel adicionales proporcionada por otros
participantes
O Acotar las vistas del diagrama de casos de uso mediante el modelado
de relaciones de dependencia
3-1
Actividad 1: Identificación de los Símbolos de los Casos de Uso
Actividad 1: Identificación de los Símbolos de los Casos de

Uso
Autorrevisión: Escriba el nombre de cada símbolo del diagrama de casos
de uso en el espacio proporcionado junto a cada uno.
Symbol Symbol Name

employee
<<actor>>
IDVerification
GetEmployeeInfo
IDVerification
system verifies
employee ID
badges
Sistema de Hotel: Resumen de Requisitos Adicionales (1)

Este libro de trabajo contiene varios ejercicios para poder aplicar lo
aprendido. La mayoría de los ejercicios presentan un estudio de caso
ficticio en el que se pide ampliar el ejemplo del sistema de hotel.
Debe utilizar el siguiente resumen de requisitos de alto nivel adicionales

hallados durante una reunión con el propietario del negocio
correspondiente a la "Actividad 2: Creación de un Diagrama de Casos de
Uso" en la página L3-4 de este libro de trabajo.

Resumen
El recepcionista debe ser capaz de realizar los trámites de salida de los
clientes antes de que abandonen el hotel. En el procedimiento de salida, se
debe calcular y presentar al cliente su factura. En la mayoría de los casos,
se requerirá el pago inmediato de la factura en lo que se refiere a
cualquier habitación, comida o cualquier otro elemento facturable
pendiente que se haya agregado a la factura durante la estancia. El
método de pago más común será una tarjeta de crédito o de débito.
Algunos clientes tendrán garantizado el pago de la totalidad o parte de la

factura por medio de un pedido. Las facturas de estos cargos se generarán
diariamente y se enviarán en forma impresa o electrónica a la compañía o
la agencia de viajes.
Los clientes que estén registrados en el momento y que aún no hayan

abandonado la habitación podrán cargar a la cuenta de ésta comidas,
bebidas u otros servicios.
El teléfono de la habitación se activa con el registro y se desactiva al

abandonar la habitación.
Creación de Diagramas de Casos de Uso 3-3

Actividad 2: Creación de un Diagrama de Casos de Uso

En este ejercicio, ampliará el diagrama de casos de uso inicial del sistema
de hotel basándose en requisitos de alto nivel adicionales descubiertos
durante una reunión con el propietario del negocio.
La Figura 3-1 ilustra el diagrama de casos de uso inicial del sistema de

hotel.

Figura 3-1 Diagrama de casos de uso inicial del sistema de hotel
Preparación
Tareas
1. Lea el resumen de requisitos adicionales para el sistema de hotel que
se proporciona en la página L3-3.
2. Cree un límite del sistema para el sistema de hotel.
Indicación: los diagramas de casos de uso pueden hacerse enormes.
Por tanto, al iniciar el diagrama, es recomendable dibujar sólo la

esquina superior izquierda del límite del sistema.
3. A partir de la Figura 3-1 en la página L3-4, copie cualquiera de los
actores, casos de uso y asociaciones que sean relevantes para los
requisitos adicionales.
4. Agregue los actores que precisen los requisitos adicionales.
5. Agregue los casos de uso que precisen los requisitos adicionales.
6. Establezca las asociaciones entre actores y casos de uso que precisen
los requisitos adicionales.


Debe utilizar el siguiente resumen de requisitos de alto nivel adicionales
hallados durante una reunión con los participantes adicionales
correspondientes a la "Actividad 3: Acotación del Diagrama de Casos de
Resumen

El personal de marketing puede publicitar las ofertas en curso para su
base de clientes a través de correo electrónico.
El grupo hotelero no dispone actualmente de un programa de fidelidad.

Sin embargo, el grupo está asociado a aerolíneas, compañías de alquiler
de vehículos y otros programas de recompensas por puntos. Por ejemplo,
los clientes que viajan en aerolíneas asociadas obtienen kilómetros de
vuelo. Los clientes que registren una tarjeta de fidelidad recibirán puntos
de ese programa externo en el momento de abonar la factura de una
reserva.
A los clientes que proporcionen un número de teléfono habrá de

enviárseles un mensaje de texto en la mañana del día en que esté prevista
su llegada. Será un mensaje de texto de cortesía recordándoles su reserva.
El personal de limpieza podrá solicitar una lista de las habitaciones que

han quedado vacías. Una vez que una habitación vacía queda preparada
para el siguiente cliente, el personal de limpieza habrá de marcar la
habitación como preparada para su uso.
En ocasiones habrá discrepancias con la factura de un cliente. Por tanto, el

personal de recepción tendrá que poder realizar ajustes en la factura.
Los auditores de noche solicitarán que el sistema genere un informe de

discrepancias durante la noche. En base a este informe, los auditores de
noche podrían necesitar hacer ajustes en la factura de un cliente. Las
tareas de los auditores de noche finalizarán por esa jornada únicamente
cuando ya no queden discrepancias.
Actividad 3: Acotación del Diagrama de Casos de Uso

En este ejercicio, realizará las tareas siguientes:
O Agregar casos de uso, actores y asociaciones nuevos
O Ampliar casos de uso de alto nivel
O Acotar el diagrama de casos de uso con dependencias y herencias
donde corresponda

Preparación
Tareas
1. Lea el resumen de requisitos adicionales para el sistema de hotel que
se proporciona en la página anterior.
2. Cree una estructura de paquete que albergue las distintas vistas de
casos de uso.
3. Copie los casos de uso, actores y asociaciones creados en la
“Actividad 2: Creación de un Diagrama de Casos de Uso” en las
vistas de paquetes relevantes.
Nota: Un caso de uso o actor puede aparecer en varias vistas del diagrama
de casos de uso.
4. Acote las vistas del diagrama de casos de uso agregando actores,

casos de uso y asociaciones para los requisitos recién hallados.
5. Acote las vistas del diagrama de casos de uso ampliando cualquier
caso de uso de alto nivel.
6. Acote las vistas del diagrama de casos de uso indicando las
dependencias entre los casos de uso.

Nota: Podrá tratarse de dependencias <<include>>, <<extend>> o

generalization.
7. Si dispone de tiempo, agregue otros casos de uso o dependencias de

casos de uso no mencionados en los requisitos adicionales que le
resulten esclarecedores.
Práctica 4
Creación de Escenarios y Formularios de

Casos de Uso

Objetivos
O Crear descripciones breves de los escenarios principales de un caso
de uso
O Rellenar los apartados de un formulario de caso de uso para
documentar el caso de uso y sus escenarios
O Agregar al glosario de términos del proyecto determinados términos
empresariales localizados en los escenarios
4-1
Actividad 1: Examen de los Escenarios de los Casos de Uso

En este ejercicio, redactará los resúmenes de los escenarios de un
determinado caso de uso.
Preparación

Tareas
1. Lea los factores clave siguientes del caso de uso Check In que se
determinaron durante una reunión con algunos de los participantes:
O La reserva se puede identificar por el nombre del cliente (en
cuyo caso puede coincidir con más de un cliente) o por el
número de reserva. En ambas situaciones, es posible que no se
localice la reserva solicitada. Por ejemplo, si el nombre del
cliente no se escribe correctamente o si el número
proporcionado es incorrecto, la reserva no se encontrará.
O Debe darse la opción al cliente de alojarse en una habitación
mejor que la reservada, en cuyo caso habrán de calcularse los
costos adicionales.
O El cliente podrá pedir cambiar cualquiera de las habitaciones
reservadas por una alternativa del mismo tipo. Por ejemplo, el
cliente puede preguntar en recepción si la habitación tiene
vistas y, ante una respuesta negativa, solicitar que se le cambie
de habitación.
O A menos que ya esté garantizado de otro modo, habrá de
obtener una preautorización del pago de los servicios
adicionales (por ejemplo, comidas, bebidas y películas) que
puedan adquirirse. Por ejemplo, la tarjeta de crédito del cliente
podría estar preautorizada con los servicios de pago electrónico.
O Si no hay una garantía de pago de los servicios adicionales, no
se permitirá que los clientes carguen nada en sus facturas.
O Si el registro se realiza correctamente, se genera una llave
electrónica para cada habitación reservada.
O Cuando el registro se realiza correctamente, el teléfono de cada

habitación reservada se activa para las llamadas salientes,
siempre que el cliente tenga garantía de pago de los servicios
adicionales.
O Se crea una factura (también denominada minuta) de la reserva.
O El proceso de registro debe completarse en un máximo de 8
minutos.
O Tras la finalización del caso de uso Check In, las habitaciones
asignadas se marcan como ocupadas.

Nota: Esta lista de factores clave no es exhaustiva. Durante la práctica,
quizás su grupo desee agregar algo a la misma.
2. Cree una breve descripción de un escenario (correcto) primario.

3. Cree una breve descripción de otros escenarios (correctos) primarios
y de cualquier otro escenario (no correcto) secundario que pueda
producirse.
4. Vuelva al diagrama de casos de uso que acotó en la "Actividad 3:
Acotación del Diagrama de Casos de Uso" en la página L3-7 de este
libro de trabajo y determine si el diagrama sigue siendo correcto. De
lo contrario, actualice el diagrama.
5. Opcionalmente, si dispone de tiempo, repita los pasos 2 a 4 para otro
caso de uso (por ejemplo, Charge Customers Bill o Check Out
Customer).
Creación de Escenarios y Formularios de Casos de Uso 4-3

Actividad 2: Creación de Formularios de Casos de Uso
Actividad 2: Creación de Formularios de Casos de Uso

En este ejercicio, documentará un caso de uso por medio de un formulario
de caso de uso.
Preparación
El instructor le proporcionará una plantilla de formulario de caso de uso

para que documente el caso de uso. También puede utilizar una pizarra
de presentaciones blanca o de papel para escribir los detalles del
formulario de caso de uso.
Tareas
1. Rellene todos los elementos del formulario de caso de uso a partir de
la información incluida en el escenario del caso de uso Check In de la
actividad anterior, además de los factores clave proporcionados en
dicha actividad.
2. Opcionalmente, si dispone de tiempo, repita el paso 1 para otro caso
de uso (por ejemplo, Charge Customers Bill o Check Out Customer).
Actividad 3: Redacción del Glosario de Términos
Actividad 3: Redacción del Glosario de Términos

En este ejercicio agregará algunos términos empresariales nuevos al
glosario de términos del proyecto.
Preparación

Tareas
1. Identifique algunos términos empresariales utilizados en los
escenarios de la “Actividad 1: Examen de los Escenarios de los Casos
de Uso” o en el formulario de caso de uso de la “Actividad 2:
Creación de Formularios de Casos de Uso” que sea necesario definir
en el glosario de términos del proyecto.
2. Escriba una definición de cada uno de los términos identificados en
el paso 1.
Creación de Escenarios y Formularios de Casos de Uso 4-5


Práctica 5
Creación de Diagramas de Actividades
Objetivos

O Identificar los elementos esenciales de un diagrama de actividades
O Crear un diagrama de actividades para modelar un diagrama de
casos de uso
5-1
Actividad 1: Identificación de los Símbolos del Diagrama de Actividades
Actividad 1: Identificación de los Símbolos del Diagrama

de Actividades
Autorrevisión: Escriba el nombre de cada símbolo del diagrama de
actividades en el espacio asignado junto a cada uno en la tabla siguiente.

Symbol Symbol Name
Design Product
Actividad 2: Creación de un Diagrama de Actividades
Actividad 2: Creación de un Diagrama de Actividades

En este ejercicio, construirá un diagrama de actividades para un caso de
uso del estudio de caso del sistema de hotel.
Preparación
No es necesaria ninguna preparación para esta actividad.

Tarea
1. Examine los flujos de eventos del formulario de caso de uso de
solución del ejercicio práctico del módulo 4.
2. Cree un diagrama de actividades para representar el flujo de
eventos.
3. Comience el diagrama con un nodo de inicio.
4. Empezando por la primera, represente cada actividad del formulario
de caso de uso como un nodo de actividad. Puede representar un
juego de actividades complejo como un nodo de actividad en el
diagrama de actividades principal y después mostrar las actividades
internas en otro diagrama de actividades.
Nota: Comience con un diagrama sencillo utilizando bifurcaciones,

iteraciones y simultaneidades. Agregue después carriles, regiones de
actividad interrumpible y flujos de objetos donde sea necesario.
5. Identifique si ha comprendido algo nuevo o descubierto algún

problema con los artefactos anteriores.
6. Opcionalmente, modele otro caso de uso con un diagrama de
actividades.
Creación de Diagramas de Actividades 5-3


Práctica 6
Determinación de las Abstracciones Clave
Objetivos

O Identificar las abstracciones clave candidatas a partir de los
artefactos del proyecto
O Utilizar el análisis de clase-responsabilidad-colaboración (CRC) para
identificar las abstracciones clave a partir de las candidatas
6-1
Actividad 1: Búsqueda de Abstracciones Clave Candidatas
Actividad 1: Búsqueda de Abstracciones Clave

Candidatas
En este ejercicio, buscará las abstracciones clave candidatas a partir de los
artefactos del sistema de hotel.
Preparación

Tareas
1. Valiéndose de los formularios de caso de uso, escenarios y
descripciones de glosario de la práctica anterior, identifique las
abstracciones clave candidatas y confeccione una lista de las mismas
en un formulario de plantilla de abstracciones clave candidatas.
2. Con los formularios de caso de uso, escenarios y descripciones de
glosario del ejemplo del módulo 6 de la Guía del Alumno,
identifique cualquier abstracción clave candidata adicional y
agréguela al formulario de plantilla de abstracciones clave
candidatas.
Actividad 2: Búsqueda de Abstracciones Clave con CRC
Actividad 2: Búsqueda de Abstracciones Clave con CRC

En este ejercicio, identificará las abstracciones clave valiéndose de CRC.
Preparación

Tareas
1. Seleccione una abstracción clave candidata de la solución de
abstracciones clave candidatas de la primera actividad de este
módulo.
2. Identifique si hay un caso de uso en el que destaque la abstracción
clave candidata. Si la abstracción clave candidata no se destaca en un
caso de uso, probablemente no se trate de una abstracción clave.
3. Examine los artefactos relevantes del proyecto para identificar
responsabilidades y colaboradores para la abstracción clave
candidata. Si la abstracción clave candidata no tiene ninguna
responsabilidad o colaborador, probablemente no se trate de una
abstracción clave.
4. Documente cualquier responsabilidad y colaborador mediante una
tarjeta CRC.
5. Modifique sus abstracciones clave candidatas conforme a la
información encontrada durante el proceso CRC. Escriba las razones
que justifiquen que una abstracción clave candidata no pueda
calificarse de abstracción clave.
Determinación de las Abstracciones Clave 6-3


Práctica 7
Construcción del Modelo de Dominio de

Problema

Objetivos
Al finalizar este módulo, debería estar capacitado para:
O Identificar los elementos esenciales de un diagrama de clases
O Ampliar el diagrama de clases de modelo de dominio para el sistema
de hotel mediante la agregación de abstracciones clave
O Identificar los elementos esenciales de un diagrama de objetos
O Validar el modelo de dominio utilizando uno o varios diagramas de
objetos
7-1
Actividad 1: Identificación de los Elementos del Diagrama de Clases

de Clases
Autorrevisión: Escriba el nombre de cada símbolo del diagrama de clases
en el espacio proporcionado junto a cada uno.

Symbol Symbol Name

Account
Account
firstName:String
lastName:String
Amount:BigDecimal
getAmount()
setFirstName()
1..*
employs
ClassA ClassB
ClassX
Actividad 2: Ampliación de un Diagrama de Clases

En este ejercicio, ampliará el diagrama de clases de modelo de dominio
del sistema de hotel agregando abstracciones clave identificadas durante
un análisis CRC.
Preparación

Copie las clases del diagrama de clases de modelo de dominio del sistema
de hotel que aparece en la Figura 7-1.
1..* made for 1

Reservation Customer
resv cust
reservation number 1..* first name
status last name
arrival date
res address
v
departure date phone number
1 g
ua
ra
nt
<<operations>> ee 1..*
reserve a room d
by roo 1..* located at 1
m Room room property
Property
1
Payment
Guarantee
Figura 7-1 Diagrama de clases de modelo de dominio del sistema de

hotel
Asegúrese de dejar espacio para nuevas clases, atributos y operaciones.
Nota: Esta actividad se realiza mejor en grupos con una pizarra de

presentaciones blanca o de papel.
Construcción del Modelo de Dominio de Problema 7-3

Tareas
1. Agregue nuevos nodos de clase para cada abstracción clave que haya
encontrado en la "Actividad 2: Búsqueda de Abstracciones Clave con
CRC" en la página L6-3 de este libro de trabajo. Asegúrese de incluir
también una lista de atributos y responsabilidades conocidos.
Indicación: empiece por crear un sencillo diagrama que contenga los
nombres de clase y los enlaces de asociación entre los colaboradores,

dejando espacio para agregar atributos y operaciones. Cuando la
forma (topología) del diagrama de clases tenga consistencia, cree la
versión final del diagrama con atributos y operaciones.
2. Agregue los nuevos nodos de clase que se documentan en el archivo
exercises/DomainModel/AdditionalKeyAbstractions.pdf.
3. Agregue asociaciones entre clases colaboradoras.
4. Agregue nombres de relaciones junto con una flecha que indique la
dirección para leer la asociación.
5. Agregue multiplicidad de la asociación.
6. Agregue nombres de rol sólo en el caso de que mejoren la nitidez del
diagrama.
Actividad 3: Identificación de Símbolos del Diagrama de Objetos
Actividad 3: Identificación de Símbolos del Diagrama de

Objetos
objetos en el espacio proporcionado junto a cada uno.
Symbol Symbol Name

Bryan:Account
:Account
:Account
firstName:Bryan
lastName:Smith
Amount:10.29
Autorrevisión: Seleccione las afirmaciones verdaderas sobre los
diagramas de objetos UML.
a. ___ Los diagramas de objetos se pueden validar

con diagramas de clases.
b. ___ Los diagramas de objetos muestran enlaces
de tiempo de ejecución.
c. ___ Los símbolos de los objetos pueden tener tres
compartimentos: nombre, atributo y un
compartimento de operaciones.
d. ___ Los diagramas de objetos a menudo
muestran estados de objeto.
e. ___ Un diagrama de objetos es una instancia de
un diagrama de clases.
Construcción del Modelo de Dominio de Problema 7-5

Actividad 4: Validación de un Diagrama de Clases
Actividad 4: Validación de un Diagrama de Clases

En este ejercicio validará un diagrama de clases mediante uno o varios
diagramas de objetos.
Preparación
Elija un subjuego de clases que quiera modelar como objetos. Este

subjuego de clases tendrá que basarse en las clases utilizadas en el
escenario primario (correcto) creado para el caso de uso Check In de la
"Actividad 1: Examen de los Escenarios de los Casos de Uso" en la
página L4-2 de este libro de trabajo.
Tareas
1. Dibuje un nodo de objeto para cada abstracción clave del escenario.
2. Dibuje enlaces entre objetos que colaboren.
3. Siga un flujo parcial del escenario elegido, modificando el modelo de
objeto a medida que progrese el flujo.
4. Compare el diagrama de objetos con el modelo de dominio.
Práctica 8
Transición del Análisis al Diseño mediante

Diagramas de Interacción

Objetivos
O Identificar los elementos esenciales de un diagrama de comunicación
O Crear un diagrama de comunicación
O Identificar los elementos esenciales de un diagrama de secuencias
O Crear un diagrama de secuencias
8-1
Actividad 1: Identificación de los Elementos del Diagrama de Comunicación

de Comunicación
colaboración en el espacio proporcionado junto a cada uno.

Symbol Symbol Name
:Account
2.1: getAccountInfo()
<<create>>
:MainUI
:AccountSvc
Bill:Customer
Actividad 2: Creación de un Diagrama de Comunicación
Actividad 2: Creación de un Diagrama de Comunicación

En este ejercicio creará un diagrama de comunicación para el caso de uso
Check-In.
Preparación
Necesitará el formulario del caso de uso Check-In de la práctica 4.

Tareas
1. Lea el flujo de eventos principal del formulario del caso de uso
Check-In.
2. Sitúe al actor del caso de uso en el diagrama.
3. Analice el flujo de eventos. Para cada acción del caso de uso:
a. Identifique y agregue componentes límite.
b. Identifique y agregue componentes de control.
c. Identifique y agregue componentes de entidad.
d. Dibuje las asociaciones entre estos componentes.
e. Etiquete las acciones que ejecute cada componente para cumplir
las interacciones del caso de uso.
4. Opcionalmente, cree otro diagrama o fragmento de diagrama para
otro escenario.
Nota: Si su grupo lo prefiere, pueden realizar la actividad 4 antes de la 2.

En tal caso, puede que les resulte más sencillo realizar la conversión a
partir del diagrama de secuencia creados en la actividad 4.
Transición del Análisis al Diseño mediante Diagramas de Interacción 8-3

Actividad 3: Identificación de los Elementos del Diagrama de Secuencias

de Secuencias
secuencias en el espacio proporcionado junto a cada uno.
Symbol Symbol Name

Customer
:Account
message()
Actividad 4: Creación de un Diagrama de Secuencias
Actividad 4: Creación de un Diagrama de Secuencias

En este ejercicio creará un diagrama de secuencias para el caso de uso
Check-In.
Preparación
Necesitará el formulario del caso de uso Check-In de la práctica 4.

Tareas
1. Lea el flujo de eventos principal del formulario del caso de uso
Check-In.
2. Organice los componentes en la parte superior del diagrama de
secuencias.
Indicación: sitúe los actores y componentes límite a la izquierda,
seguidos de los componentes de servicio en el medio y de las
entidades a la derecha.
3. Agregue enlaces de mensaje y barras de activación para cada
mensaje de la primera actividad.
4. Repita el paso 3 para cada actividad del caso de uso hasta finalizar la
tarea.
Nota: Cuando termine la actividad 2, puede resultarle más sencillo

convertir a partir del diagrama de comunicación.
Transición del Análisis al Diseño mediante Diagramas de Interacción 8-5


Práctica 9
Modelado del Estado del Objeto con

Diagramas de Máquina de Estados

Objetivos
O Identificar los elementos esenciales de un diagrama de máquina de
estados
O Crear un diagrama de máquina de estados para un objeto complejo
9-1
Actividad 1: Identificación de los Elementos del Diagrama de Máquina de Estados

de Máquina de Estados
máquina de estados en el espacio proporcionado junto a cada uno.
Symbol Symbol Name

AcctOverdrawn
AcctOverdrawn
entry / notifyCustomer
entry / doNotAllowSpending
exit / allowSpending
Actividad 2: Creación de un Diagrama de Estados

En este ejercicio, creará un diagrama de estados para un ejemplo de banca.
Preparación

Tareas
1. Lea la descripción siguiente de un objeto Account complejo.
O Todas las cuentas comienzan con un saldo de cero.
O El estado de una cuenta cuyo saldo sea mayor o igual a cero
será "Active". Cuando las cuentas están activas, un cliente
puede depositar cualquier cantidad de dinero, retirar cualquier
cantidad de dinero (siempre que no se alcance el límite de
sobregiro) y transferir dinero desde la cuenta Active a otra
cuenta.
Nota: El límite de sobregiro es una cantidad fija que puede tener a débito
la cuenta de un cliente a corto plazo (menos de 3 meses) sin quedar
congelada. Es similar a un préstamo bancario a corto plazo. Por ejemplo,
si el banco proporciona a sus clientes un límite de sobregiro de 100,00 €,
significa que el saldo de la cuenta de un cliente puede ser de –99,99 € sin
quedar congelada. Tan pronto como la cuenta alcance –100,00 € o una
deuda mayor, quedará congelada y el cliente ya no podrá retirar dinero.
O Si el saldo de una cuenta es inferior a cero (aunque superior al

límite de sobregiro como el del ejemplo anterior), el estado de la
cuenta cambia a "Overdrawn". Cuando una cuenta está en
número rojos:
O El cliente sigue pudiendo sacar dinero de la cuenta en
números rojos siempre que la cantidad retirada no
provoque que el saldo supere el límite de sobregiro.
O El cliente recibe notificaciones mensuales sobre el estado de
la cuenta.
Modelado del Estado del Objeto con Diagramas de Máquina de Estados 9-3
O El cliente recibe una notificación de estar en números rojos

al retirar dinero de un cajero automático (ATM).
O El cliente no puede transferir dinero de una cuenta en
números rojos a otra cuenta.
O El cliente no puede cerrar la cuenta.
O Si se mantiene en "Overdrawn" durante más de 3 meses, el
estado de la cuenta pasa a "Frozen". Cuando una cuenta está
congelada:
O El cliente no puede retirar dinero de la cuenta.

O El cliente puede depositar dinero en la cuenta.
O El cliente recibe notificaciones mensuales sobre el estado de
la cuenta.
O El cliente recibe una notificación del ATM comunicándole
que debe reunirse con el encargado del banco para
descongelar la cuenta.
O El cliente no puede cerrar la cuenta.
O El encargado del banco puede decidir cerrar todas las
cuentas del cliente y emprender acciones legales contra el
cliente. En tal caso, el cliente no puede volver a abrir una
cuenta en este banco.
O Siempre que el saldo de la cuenta cae por debajo de cero con
una cantidad equivalente al límite de sobrecargo, el estado de la
cuenta pasa a "Frozen". Consulte la información anterior sobre
el estado "Frozen".
O Si el cliente cierra la cuenta, su estado pasa a "Closed" y ya no
puede utilizar la cuenta más.
2. Elija los estados inicial y final del objeto. Especifique las condiciones
previas del estado inicial y las condiciones posteriores del estado
final.
3. Elija los estados estables del objeto.
4. Especifique la ordenación parcial de estados estables durante la vida
útil del objeto.
5. Especifique los eventos que disparan las transiciones entre los
estados del objeto. Especifique las acciones de transición (si las
hubiera).
6. Especifique las acciones con un estado (si las hubiera).
Práctica 10
Aplicación de Patrones de Diseño al Modelo

de Diseño

Objetivos
O Aplicar el principio de reutilización compuesta (CRP)
O Aplicar el patrón de estrategia
O Aplicar el patrón observador
O Aplicar el patrón de estado
10-1
Actividad 1: Aplicación de CRP
Actividad 1: Aplicación de CRP

En este ejercicio, aplicará el CRP a un estudio de caso.
Preparación

Tareas
1. Lea la información siguiente relativa a un sistema de información de
vehículos:
Es necesario un sistema que registre los detalles de distintos tipos de
vehículos que pueden moverse en tierra, agua, aire o una
combinación de estas superficies. La información que es necesario
registrar de cada vehículo es la siguiente:
O Peso
O Dimensiones máximas (h, l, w), siendo "h" la altura, "l" la
longitud y "w" la anchura
O Motores y tipo de combustible
O Velocidad máxima en cada superficie
O Información de certificación (aeronavegabilidad,
navegabilidad e inspección de vehículos terrestres)
Su trabajo consiste en cerciorarse de que el sistema puede acomodar
a estos distintos tipos de vehículo y que se puede modificar
fácilmente para nuevas superficies y motores en el futuro.
2. Dibuje un sencillo diagrama de clases que muestre cómo se puede
aplicar CRP al problema para crear una solución flexible.
Actividad 2: Aplicación del Patrón de Estrategia
Actividad 2: Aplicación del Patrón de Estrategia

En este ejercicio aplicará el patrón de estrategia al estudio de caso del
sistema de hotel.
Preparación

Tareas
1. Lea la información siguiente relativa al estudio de caso del sistema
de hotel.
El departamento de marketing del hotel va a implantar distintas
ofertas de descuento que se emplearán para calcular el precio de los
presupuestos. Las ofertas pueden incluir lo siguiente:
O Estancia de dos noches por el precio de una siempre que se
trate del fin de semana, es decir, viernes, sábado o
domingo.
O Estancia de 5 noches por el precio de 4 en cualquier
momento mientras esté vigente la oferta.
O Descuento del 10% mientras esté vigente la oferta.
Estas ofertas de descuento variarán entre las propiedades del hotel.
Su trabajo consiste en cerciorarse de que el sistema de hotel puede
acomodar los algoritmos para estas distintas ofertas. Además, debe
asegurarse de que también se puedan agregar fácilmente en el futuro
nuevas ofertas con algoritmos diferentes.
2. Dibuje un sencillo diagrama de clases que muestre el patrón de
estrategia para resolver el problema del estudio de caso.
Aplicación de Patrones de Diseño al Modelo de Diseño 10-3

Actividad 3: Aplicación del Patrón Observador
Actividad 3: Aplicación del Patrón Observador

En este ejercicio aplicará el patrón observador al estudio de caso del
sistema de hotel.
Preparación

Tareas
1. Lea la información siguiente relativa al estudio de caso del sistema
de hotel:
Cuando un cliente abandone la habitación tras el procedimiento de
salida, distintos miembros concretos del personal deberán recibir una
notificación de forma inmediata y actualizarse las pantallas de los
departamentos. La notificación a los miembros del personal
concretos se realizará a través de un mensaje enviado a un
dispositivo de bolsillo portátil. Puede abarcar a los miembros del
personal de limpieza y mantenimiento de habitaciones, supervisores
del servicio de habitaciones y reponedores del minibar. Las pantallas
de los departamentos deben mostrar el estado de las habitaciones de
distintos departamentos, incluidos el servicio de habitaciones y el
mantenimiento.
Su trabajo consiste en cerciorarse de que el sistema de hotel incluye
la función para notificar a los miembros del personal
correspondientes y para actualizar las pantallas de los
departamentos lo antes posible una vez la habitación queda vacía.
También debe asegurarse de que se pueden agregar fácilmente otras
notificaciones que puedan ser necesarias en el futuro para cuando el
cliente haya abandonado la habitación.
2. Dibuje un sencillo diagrama de clases que muestre el patrón
observador para resolver el problema del estudio de caso.
Actividad 4: Aplicación del Patrón de Estado

O Simplificar el pseudocódigo refactorizándolo en función del patrón
de estado.
O Crear un diagrama de clases que implante el patrón de estado del
ejemplo anterior.

Preparación
Tareas
1. Examine el pseudocódigo siguiente. En la actualidad se utiliza este
gran bloque de código en el objeto Account para asegurarse de que
actúa adecuadamente cuando un cliente intenta sacar dinero.
withdrawlMethod() {
if (accountStatus = “Active”) {
allow customer to withdrawl up to (OverdraftLimit
+ currentBalance);
}
else if (accountStatus = “Overdrawn”{
DisplayMessage(“You are Overdrawn”);
allow customer to withdrawl up to (OverdraftLimit
+ currentBalance);
}
else if (accountStatus = “Frozen”) {
DisplayMessage(“Account Frozen, you cannot
withdrawl money, please visit with bank manager”);
}
else {
DisplayMessage(“Account is closed, you cannot
withdrawl money.”
}
2. Teniendo en cuenta lo que conoce sobre el patrón de estado, ¿cómo
refactorizaría este código?
Aplicación de Patrones de Diseño al Modelo de Diseño 10-5

3. Cree un diagrama de clases que represente la refactorización (basada

en el patrón de estado). Cerciórese de anotar cada clase en el
diagrama para mostrar dónde va el código.
Práctica 11
Introducción a los Diagramas y Conceptos

Arquitectónicos

Objetivos
O Identificar los niveles, capas y cualidades sistémicas de la
metodología arquitectónica SunTone
O Identificar los elementos esenciales de un diagrama de componentes
O Identificar los elementos esenciales de un diagrama de despliegue
O Crear un diagrama de despliegue de alto nivel
11-1
Actividad 1: Identificación de Niveles, Capas y Cualidades Sistémicas
Actividad 1: Identificación de Niveles, Capas y Cualidades

Sistémicas
Autorrevisión: Una las capas con sus definiciones.
Capa Definición
Aplicación Proporciona las API que implantan los

componentes de la aplicación
Plataforma virtual Consiste en el sistema operativo
Plataforma de Incluye componentes informáticos como
nivel superior servidores, almacenamiento y dispositivos
de red
Plataforma de Proporciona una implantación concreta de
nivel inferior componentes para satisfacer los requisitos
funcionales
Plataforma de Se compone de productos como
hardware contenedores web y middleware
Autorrevisión: Una los niveles con sus definiciones.
Nivel Definición
Cliente Proporciona servicios y entidades

Presentación Todos los componentes de backend, por ejemplo,
un sistema de gestión de bases de datos (DBMS) o
un sistema de información empresarial (EIS)
Negocio Normalmente se le aplica el calificativo "thin"; a
menudo se trata de un explorador web
Integración Proporciona las páginas y formularios de lenguaje
de marcado de hipertexto (HTML) que se envían a
un explorador web y procesa las solicitudes del
usuario
Recurso Proporciona componentes que unen el nivel de
negocio al nivel de recursos
Actividad 1: Identificación de Niveles, Capas y Cualidades Sistémicas
Autorrevisión: Una las cualidades sistémicas con sus definiciones.
Cualidad
Definición
sistémica
Para el desarrollo Trata de las cualidades requeridas a medida

que evoluciona el sistema
Manifiestas Trata de las cualidades que se reflejan en la
ejecución del sistema

Evolutivas Trata de las cualidades requeridas en
producción
Operativas Trata de las cualidades requeridas durante el
desarrollo del sistema
Introducción a los Diagramas y Conceptos Arquitectónicos 11-3

Actividad 2: Exploración de Diagramas de Componentes
componentes en el espacio proporcionado junto a cada uno.
Symbol Symbol Name
<<JAR>>

PayrollSystemJAR
<<reside>>
DBMS
DrawApp
*
diagramas de componentes UML.
a. ___ Un componente representa una unidad de software.

b. ___ Hay formularios de descriptor e instancia de los
diagramas de componentes.
c. ___ Los componentes no pueden ser abstractos.
d. ___ Los diagramas de componentes muestran las

organizaciones y las dependencias entre
componentes.
e. ___ Se pueden crear iconos de componentes propios
para ampliar el UML.

Actividad 3: Comprensión de los Diagramas de Despliegue
Actividad 3: Comprensión de los Diagramas de Despliegue
despliegue en el espacio proporcionado junto a cada uno.
Symbol Symbol Name

<<FTP>>
<<JAR>>
PayrollSystemJAR
PC
diagramas de despliegue UML.
a. ___ Se pueden asignar iconos propios para representar

el hardware en los diagramas de despliegue.
b. ___ Hay formularios de descriptor e instancia de los
diagramas de despliegue.
c. ___ Los diagramas de despliegue de descriptor
muestran un despliegue concreto de un sistema.
d. ___ El estereotipo «deploy» se puede utilizar para
documentar los componentes dentro de un nodo.
e. ___ Sólo hay un formulario de descriptor de los
diagramas de despliegue.
Actividad 4: Creación de un Diagrama de Despliegue de Alto Nivel
Actividad 4: Creación de un Diagrama de Despliegue de

Alto Nivel
En este ejercicio creará un diagrama de despliegue de alto nivel para el
estudio de caso del sistema de hotel.
Preparación

Lea los requisitos siguientes sobre el estudio de caso del sistema de hotel:
Sistema de Hotel: Resumen Adicional de Requisitos

El servidor de bases de datos y el servidor web han de estar en nodos de
hardware independientes.
Sistema de Hotel: Resumen de Requisitos del Sistema
Nota: La recapitulación de requisitos del sistema es un resumen de los

requisitos proporcionados en las prácticas 3 y 10.
El agente de reservas (personal interno) debe poder gestionar las reservas

de los clientes que las soliciten por teléfono o correo electrónico. La
mayoría de estas solicitudes creará una nueva reserva, pero en ocasiones se
tendrá que modificar o cancelar una reserva. La reserva retiene una o
varias habitaciones de un tipo durante un único período, y se debe
garantizar mediante el pago con tarjeta electrónica o la recepción de un
pedido en el caso de los clientes corporativos y agencias de viajes. Estas
garantías de pago se deben guardar para referencia futura.
Una reserva también se puede realizar por vía electrónica desde el sistema
del agente de viajes y también directamente a través de Internet.
El recepcionista debe ser capaz de registrar los clientes que llegan al hotel.
Esta acción asignará una o más habitaciones del tipo solicitado. En la mayoría
de los casos, se requiere otra garantía de pago con tarjeta electrónica.
El recepcionista debe ser capaz de realizar los trámites de salida de los

clientes antes de que abandonen el hotel. En el procedimiento de salida, se
debe calcular y presentar al cliente su factura. En la mayoría de los casos,
se requerirá el pago inmediato de la factura en lo que se refiere a
cualquier habitación, comida o cualquier otro elemento facturable
pendiente que se haya agregado a la factura durante la estancia. El
método de pago más común será una tarjeta de crédito o de débito.

Algunos clientes tendrán garantizado el pago de la totalidad o parte de la

factura por medio de un pedido. Las facturas de estos cargos se generarán
diariamente y se enviarán en forma impresa o electrónica a la compañía o
la agencia de viajes.
El teléfono de la habitación se activa con el registro y se desactiva al

abandonar la habitación.
El personal de marketing puede publicitar las ofertas en curso para su

base de clientes a través de correo electrónico.

El grupo hotelero no dispone actualmente de un programa de fidelidad.
Sin embargo, el grupo está asociado a aerolíneas, compañías de alquiler
de vehículos y otros programas de recompensas por puntos. Por ejemplo,
los clientes que viajan en aerolíneas asociadas obtienen kilómetros de
vuelo. Los clientes que registren una tarjeta de fidelidad recibirán puntos
de ese programa externo en el momento de abonar la factura de una
reserva.
A los clientes que proporcionen un número de teléfono habrá de

enviárseles un mensaje de texto en la mañana del día en que esté prevista
su llegada. Será un mensaje de texto de cortesía recordándoles su reserva.
El personal de limpieza podrá solicitar una lista de las habitaciones que

han quedado vacías. Una vez que una habitación vacía queda preparada
para el siguiente cliente, el personal de limpieza habrá de marcar la
habitación como preparada para su uso.
Cuando un cliente abandone la habitación tras el procedimiento de salida,

distintos miembros concretos del personal deberán recibir una notificación
de forma inmediata y actualizarse las pantallas de los departamentos. La
notificación a los miembros del personal concretos se realizará a través de
un mensaje enviado a un dispositivo de bolsillo portátil. Puede abarcar a
los miembros del personal de limpieza y mantenimiento de habitaciones,
supervisores del servicio de habitaciones y reponedores del minibar. Las
pantallas de los departamentos deben mostrar el estado de las
habitaciones de distintos departamentos, incluidos el servicio de
habitaciones y el mantenimiento.
Su trabajo consiste en cerciorarse de que el sistema de hotel incluye la

función para notificar a los miembros del personal correspondientes y
para actualizar las pantallas de los departamentos lo antes posible una
vez la habitación queda vacía. También debe asegurarse de que se pueden
agregar fácilmente otras notificaciones que puedan ser necesarias en el
futuro para cuando el cliente haya abandonado la habitación.
Tareas
1. Cree un diagrama de despliegue de alto nivel a partir del tipo de
arquitectura y tecnologías seleccionados.
2. Confeccione una lista de las aplicaciones mencionadas en el estudio
de caso.
Recuerde, algunas aplicaciones podrían existir en el contexto de otra

aplicación. Por ejemplo, un applet que se ejecute en un explorador
web.
3. Confeccione una lista de actores y nodos de hardware.
4. Dibuje las relaciones entre los actores y los nodos de hardware.
Dibuje las relaciones entre los nodos de hardware.
5. Etiquete los nodos de hardware.
6. Sitúe las aplicaciones identificadas en el paso 2 en el nodo de
hardware correspondiente.


Práctica 12
Introducción a los Niveles Arquitectónicos
Objetivos

O Actualizar y ampliar el diagrama de paquetes de niveles y capas
utilizado en el estudio de caso de ejemplo del sistema de hotel
O Ampliar la clase DAOFactory utilizada en el estudio de caso de
ejemplo para permitir un cambio de base de datos y la integración de
recursos externos
12-1
Actividad 1: Actualización y Ampliación de un Diagrama de Niveles y Capas
Actividad 1: Actualización y Ampliación de un Diagrama de

Niveles y Capas
En este ejercicio actualizará y ampliará el diagrama de paquetes de niveles
y capas utilizado en el estudio de caso de ejemplo del sistema de hotel.
Preparación

Tareas
1. Abra el archivo TiersAndLayers.pdf que se encuentra en el
directorio exercises/ArchTiers/.
2. Actualice y amplíe el diagrama de niveles y capas utilizando la
información que se proporciona en el archivo TiersAndLayers.pdf.
Actividad 2: Creación de las Clases DAOFactory y DAO
Actividad 2: Creación de las Clases DAOFactory y DAO

En este ejercicio creará un diagrama de clases para las clases DAOFactory
y DAO que precisa el sistema de hotel.
Preparación

Tareas
1. Cree un diagrama de clases que contenga las clases DAO que le
permitan acceder a dos orígenes de datos diferentes. Sólo necesita
mostrar un número representativo de DAO para soportar las
entidades de reserva y cliente.
2. Agregue las clases DAOFactory que precise para crear los objetos
DAO.
Introducción a los Niveles Arquitectónicos 12-3


Práctica 13
Acotación del Modelo de Diseño de Clases
Objetivos

O Acotar atributos
O Encapsular atributos
O Acotar asociaciones
O Acotar métodos
O Declarar constructores
O Revisar su diseño de clases para cerciorarse de que mantiene una
gran cohesión y un acoplamiento bajo
O Crear componentes con interfaces bien definidas
13-1
Actividad 1: Acotación de Atributos

En este ejercicio va a:
O Acotar los atributos de clase del modelo de diseño.
O Encapsular los atributos de clase del modelo de diseño.
Preparación

Revise el diagrama de clases del estudio de caso del sistema de hotel
creado en la "Actividad 2: Ampliación de un Diagrama de Clases" en la
página L7-3 de este libro de trabajo. Tal diagrama de clases es el punto de
partida de esta actividad.
Tarea 1: Acotar Atributos

1. Acote los atributos de clase del diagrama de clases.
2. Acote el nombre de cada atributo para que siga las convenciones.
3. Identifique el tipo de dato de cada atributo. Cree nuevos tipos de
<<utility>> en caso necesario. Por ejemplo, la fecha de llegada y de
partida podrían combinarse en una clase DateRange con un método
para comprobar las fechas superpuestas y un método para devolver
la duración.
4. Diseñe un valor inicial para cada atributo (en caso aplicable).
5. Identifique la propiedad de cada atributo (changeable, addOnly o
frozen).
Tarea 2: Encapsular Atributos

1. Encapsule los atributos de clase del diagrama de clases.
2. Haga que cada atributo sea privado.
3. Agregue métodos de acceso público para todos los atributos. Quizás
desee mantener ocultos algunos; en tal caso, no cree un método de
acceso para esos atributos.
4. Agregue métodos de mutador público para todos los atributos. No

agregue un método de mutador para cualquier atributo que esté
marcado con la propiedad “frozen”.
5. En caso conveniente, identifique cualquier atributo derivado y cree
métodos de acceso o mutador para conectar con esos atributos.
Acotación del Modelo de Diseño de Clases 13-3

Actividad 2: Acotación de Asociaciones mediante

Agregación y Composición
En este ejercicio acotará las asociaciones de clases mediante agregación o
composición cuando resulte conveniente.
Preparación

Como punto de partida de esta actividad, utilizará el diagrama de clases
del estudio de caso del sistema de hotel que habrá actualizado en la
actividad anterior.
Tarea: Agregar Agregación y Composición

1. Revise cada asociación de clases y determine qué va a resultar más
adecuado, la agregación o la composición.
2. Acote su diagrama de clases para agregar cualquier agregación o
composición encontrada en el paso 1.
Actividad 3: Acotación de la Dirección del Transversal
Actividad 3: Acotación de la Dirección del Transversal

O Determinar la dirección del transversal de las asociaciones.
O Elaborar métodos de clase para mantener las asociaciones.
Preparación

actividad anterior.
Tarea: Acotar la Dirección del Transversal de

Asociaciones
1. Identifique la dirección del transversal (navegación).
2. Agregue métodos de asociación.

Actividad 4: Acotación de Métodos de Negocio y Constructores
Actividad 4: Acotación de Métodos de Negocio y

Constructores
O Elaborar métodos empresariales.
O Declarar constructores.
O Anotar métodos y constructores.

Preparación
actividad anterior.
Tarea: Acotar Métodos de Negocio y Constructores

1. Agregue o defina nuevos métodos empresariales.
2. Agregue constructores.
3. Anote los métodos y constructores que haya agregado en los pasos 1
y 2.
Actividad 5: Comprobación de la Alta Cohesión y el Bajo Acoplamiento del Diagrama
Actividad 5: Comprobación de la Alta Cohesión y el Bajo

Acoplamiento del Diagrama de Clases
En este ejercicio revisará su diagrama de clases para cerciorarse de que
tiene alta cohesión y bajo acoplamiento.
Preparación

actividad anterior.
Tarea: Revisar la Cohesión y el Acoplamiento

1. Revise su diagrama de clases y analice con su grupo si tiene alta
cohesión.
2. Revise su diagrama de clases y analice con su grupo si tiene bajo
acoplamiento.
3. Resuelva cualquier incidencia identificada en los pasos 1 y 2
modificando el diagrama de clases.

Actividad 6: Creación de Componentes con Interfaces
Actividad 6: Creación de Componentes con Interfaces

En este ejercicio va a crear componentes cohesivos a partir de grupos de
clases que deben funcionar juntos.
Preparación

actividad anterior. Además, utilizará las clases de servicios creadas en la
"Actividad 2: Creación de un Diagrama de Comunicación" en la
página L8-3 y en la "Actividad 4: Creación de un Diagrama de Secuencias"
en la página L8-5 de este libro de trabajo para especificar los nombres de
las interfaces.
Tarea: Definir Componentes e Interfaces

1. Cree componentes para las distintas áreas de función común.
Nota: Por ejemplo, en el sistema de biblioteca de préstamos, hemos creado

los componentes Membership y BookInventory.
2. Para cada componente creado en el paso 1, agregue cualquier

interfaz proporcionada.
Nota: Las interfaces proporcionadas a menudo son las interfaces de las

clases de servicios.
3. Para cada componente creado en el paso 1, agregue cualquier

interfaz necesaria que el componente exija que otros componentes le
suministren.
Práctica 14
Visión General sobre los Procesos de

Desarrollo de Software

Objetivos
O Describir dos características de metodologías comunes
O Definir las cinco metodologías orientadas a objetos
O Desarrollar un plan de iteración
O Seleccionar la metodología adecuada para los estudios de casos
14-1
Actividad 1: Identificación de Características de Metodología
Actividad 1: Identificación de Características de

Metodología
Autorrevisión: Seleccione las afirmaciones verdaderas sobre las
metodologías impulsadas por casos de uso.
a. ___ Se centran en las relaciones entre actores y el sistema

b. ___ Se basan en la noción de que el software realiza actividades

para los usuarios
c. ___ Utilizan requisitos no funcionales para impulsar la
estructura del sistema
d. ___ Deben ser iterativas
e. ___ Se centran en las cualidades sistémicas, como la fiabilidad y
la escalabilidad
Autorrevisión: Seleccione las afirmaciones verdaderas sobre las
metodologías centradas en arquitectura.
a. ___ Se centran en las relaciones entre actores y el sistema

b. ___ Se basan en la noción de que el software realiza actividades
para los usuarios
c. ___ Utilizan requisitos no funcionales para impulsar la
arquitectura del sistema
d. ___ Deben ser iterativas
e. ___ Se centran en las cualidades sistémicas, como la fiabilidad y
la escalabilidad
Actividad 2: Definición de las Cinco Metodologías Orientadas a Objetos
Actividad 2: Definición de las Cinco Metodologías

Orientadas a Objetos
Autorrevisión: Una los términos de metodologías de desarrollo de
software orientados a objetos con sus definiciones.

Cascada Proceso de desarrollo de software iterativo, creado

por Booch, Jacobson y Rumbaugh, disponible
gratuitamente para su uso.
eXtreme Programming Las actividades clave de esta metodología son la

(XP) codificación y las pruebas.
Proceso Unificado de Marco orientado a los equipos, en que cada sprint

Desarrollo de Software produce una versión funcional del software.
(UP)
Rational Unified Process Esta metodología utiliza una fase sencilla en la que
(RUP) todos los flujos de trabajo siguen una trayectoria
lineal.
Scrum Implantación comercial de la metodología UP.
Visión General sobre los Procesos de Desarrollo de Software 14-3

Actividad 3: Producción de un Plan de Iteración
Actividad 3: Producción de un Plan de Iteración

En este ejercicio producirá un plan de iteración para el estudio de caso del
sistema de hotel.
Preparación

Tareas
1. Reconsidere las prioridades y riesgos del formulario de caso de uso
creado en la "Actividad 2: Creación de Formularios de Casos de Uso"
en la página L4-4 de este libro de trabajo.
2. Considere las prioridades y riesgos del resto de casos de uso
descubiertos en la "Actividad 3: Acotación del Diagrama de Casos de
3. Considere la importancia arquitectónica de cada caso de uso.
4. Construya un plan de iteración basado en los resultados de los pasos
1 a 3.
Actividad 4: Selección de Metodologías

En este ejercicio seleccionará la metodología adecuada para cada estudio
de caso.
Preparación

Tareas
1. Lea los escenarios siguientes.
2. Seleccione y justifique la metodología adecuada para cada caso de
estudio. Nota: puede haber más de una metodología para un
escenario.
Estudio de Caso ACME Insurance
ACME Insurance Corporation (AIC) desea crear un sistema para

introducir y almacenar las pólizas de seguros de sus más de 200.000
clientes de todo el mundo. AIC dispone de un pequeño equipo de
desarrollo de 4 personas para trabajar en este proyecto; el equipo se
compone de un gestor de proyecto (que también escribe la
documentación) y tres ingenieros. Se ha pedido al gestor de proyecto que
se ocupe de la documentación de todas las fases del proyecto utilizando el
proceso de documentación más reciente de la Organización Internacional
de Normalización (ISO).
Selección de metodología ________________
Justificación _________________________________________
_________________________________________________
_________________________________________________
Visión General sobre los Procesos de Desarrollo de Software 14-5

Estudio de Caso NoLycra.com
NoLycra.com es una pequeña compañía de reciente constitución que

produce maillots para ciclismo. La compañía está situada en un pequeño
taller que incluye todas las funciones empresariales (ventas, marketing,
fabricación, envío, etc.). NoLycra.com ha saltado a la fama por sus diseños
de maillots exclusivos que presentan vivos colores y tejidos poco
tradicionales. NoLycra.com ha contratado recientemente a dos ingenieros
informáticos de la competencia para crear un sistema de control de
inventario que haga el seguimiento de los pedidos de los clientes y de los
niveles de inventario. La contratación de estos ingenieros por parte de

NoLycra.com es la consecuencia de la creación por parte de éstos de un
sistema de control de inventario en la compañía para la que antes
trabajaban que ayuda a que los productos accedan a mercado rápidamente.
Justificación _________________________________________
_________________________________________________
_________________________________________________
Estudio de Caso Bravo
Bravo Software ha contratado los servicios de un contratista para realizar

el análisis y diseño de un sistema basado en lenguaje de marcado
extensible (XML) que pueda almacenar soluciones para los problemas de
soporte técnico habituales. El contratista trabajará con un pequeño equipo
de empleados con el fin de diseñar e implantar el sistema. La mayoría de
estos empleados tienen experiencia técnica (incluida escritura técnica,
ingeniería, pruebas y capacidades gráficas), pero se les contrató con la
categoría de analistas de soporte técnico (TSA). Uno de los TSA sugiere
que el equipo utilice Rational Rose para el proyecto, puesto que Bravo
posee una licencia de este producto. El mismo TSA recuerda también al
equipo que deben seguir el proceso del ciclo de vida de producto en el
desarrollo y entrega del sistema nuevo.
Justificación _________________________________________
_________________________________________________
_________________________________________________
Práctica 15
Visión General de los Marcos
Objetivos

O Crear un diagrama de clases conceptual de alto nivel en el que se
muestren las clases e interfaces que se necesitarían para un
subsistema de marco genérico
O Descubrir los posibles marcos neutros de dominio que se podrían
compartir entre dominios de negocio
15-1
Actividad 1: Creación de un Marco Conceptual
Actividad 1: Creación de un Marco Conceptual

O Identificar las clases genéricas que serían necesarias para el marco
O Identificar las clases de dominio específicas que podrían utilizar el
marco
O Crear un diagrama de clases conceptual para las clases y relaciones
que se hayan identificado

Preparación
Tareas
1. Identifique las clases que serían necesarias para crear un marco para
un sistema de asignación de recursos genérico en el que los recursos
se asignan durante un período.
2. Dibuje un diagrama de clases de alto nivel que muestre las clases e
interfaces genéricas que serían necesarias para el marco identificado
en el paso 1.
3. Dibuje las clases específicas de dominio que podrían utilizar el
marco creado en el paso 2.
Actividad 2: Identificación de Marcos Potenciales
Actividad 2: Identificación de Marcos Potenciales

En este ejercicio, identificará los marcos potenciales que una selección de
dominios de negocio podría compartir.
Preparación

Tareas
1. Identifique los marcos potenciales que podrían compartir las
aplicaciones siguientes: un sistema de hotel, un sistema de alquiler
de vehículos y un sistema de hospital privado.
2. Identifique otras aplicaciones que pudieran utilizar los marcos
descubiertos en el paso 1.
3. Opcionalmente, modele los marcos identificados en el paso 1, así
como los usos específicos de esos marcos.
Visión General de los Marcos 15-3


Práctica 16
Revisión del Curso
No hay actividades para este módulo.
16-1

D61808CS21 Ag

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

D61808CS21 Ag

Cargado por

Copyright:

Formatos disponibles

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Oracle University and Nanfor Iberica, S.L. use only

Descargo de responsabilidad de Sun Microsystems, Inc.

Oracle University and Nanfor Iberica, S.L. use only

Aviso de derechos restringidos

DERECHOS DEL GOBIERNO DE EE. UU.

Aviso de marca registrada

Página dejada en blanco intencionadamente.

Oracle University and Nanfor Iberica, S.L. use only

Página dejada en blanco intencionadamente.

Oracle University and Nanfor Iberica, S.L. use only

Oracle University and Nanfor Iberica, S.L. use only

Actividad 1: Identificación de los Símbolos de los Casos

Oracle University and Nanfor Iberica, S.L. use only

vi Análisis y Diseño Orientados a Objetos mediante UML (Unified Modeling Language)

Aplicación de Patrones de Diseño al Modelo de Diseño............10-1

Oracle University and Nanfor Iberica, S.L. use only

Oracle University and Nanfor Iberica, S.L. use only

Acerca de este Manual

Oracle University and Nanfor Iberica, S.L. use only

Se supone que las actividades de autorrevisión debe realizarlas cada

Oracle University and Nanfor Iberica, S.L. use only

La fuente Courier también se usa para indicar las construcciones de

La fuente Courier negrita se usa para los caracteres y números que se

Courier negrita se usa también para cada línea de código de

Courier cursiva se usa para variables y marcadores de posición de

La fuente Courier negrita cursiva se usa para representar las

La fuente Palatino cursiva se usa para los títulos de libros, palabras o

Oracle University and Nanfor Iberica, S.L. use only

Acerca de este Manual Prefacio-xi

Oracle University and Nanfor Iberica, S.L. use only

Examen de Terminología y Conceptos

Oracle University and Nanfor Iberica, S.L. use only

Actividad 1: Uso de la Abstracción

Oracle University and Nanfor Iberica, S.L. use only

Nota: El "juego de circuito de carreras de motor" puede tratarse de una

c. Car en un contexto de negocio "Registro de licencias de

Nota: Puede consultar los diagramas UML de ejemplo del módulo 1 de la

Actividad 2: Uso de la Herencia

Oracle University and Nanfor Iberica, S.L. use only

Nota: Puede consultar los diagramas UML de ejemplo del módulo 1 de la

Examen de Terminología y Conceptos Orientados a Objetos 1-3

Nota: El problema tiene un ámbito reducido para eliminar las

Tarea 2: Asignar Reglas de Negocio a los Métodos

Oracle University and Nanfor Iberica, S.L. use only

Actividad 3: Uso de la Delegación y la Cohesión

Oracle University and Nanfor Iberica, S.L. use only

Examen de Terminología y Conceptos Orientados a Objetos 1-5

Actividad 4: Comprensión de las Ventajas del Uso de

Oracle University and Nanfor Iberica, S.L. use only

Actividad 5: Definición de Terminología Orientada a

Autorrevisión: Relacione los términos de programación orientados a

 objetos con sus definiciones.

Oracle University and Nanfor Iberica, S.L. use only

polimorfismo Identificación exclusiva de los métodos y

cohesión Grado de dependencia que tienen entre sí las

Examen de Terminología y Conceptos Orientados a Objetos 1-7

Oracle University and Nanfor Iberica, S.L. use only

Introducción al Modelado y al Proceso de

Oracle University and Nanfor Iberica, S.L. use only

Actividad 1: Definición de Flujos de Trabajo

Autorrevisión: Relacione cada flujo de trabajo con su descripción.

objetos con sus definiciones.

recopilación de requisitos mencionadas durante la clase.

de requisitos mencionadas durante la clase.

arquitectura mencionadas durante la clase.

mencionadas durante la clase.

han mencionado durante la clase.

de uso en el espacio proporcionado junto a cada uno.