Fase 9 Modelo de Diseño Orientado A Objetos Teórico 301403 - 33

Proyecto de Investigación Curso Académico de Programación Orientada a Objetos
Proyecto de Investigación Teórico

Sistema de Asignación de cuartos de Hotel
Presentado por:
Grupo 301403_33
Alby Vargas Muñoz

Ulises Viloria Rondón
Edward Díaz
Edgar Enrique Duque
Jaider Ariel García
Tutor:
Cesar Orlando Jiménez Angarita
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA
PROGRAMA INGENIERIA DE SISTEMAS
COLOMBIA
Página 1
Tabla de Contenidos
Capítulo 1 Introducción
Capítulo 2 Objetivos
2.1 Objetivos Generales
2.2 Objetivos Específicos
Capítulo 3 Justificación
3.1 Justificación Metodológica
3.2 Justificación Práctica
3.3 Justificación Innovativa
3.4 Justificación Profesional
Capítulo 4 Metodología
4.1 Tipo de Metodología
4.2 Metodología de Investigación
Capítulo 5 Marco Conceptual y Teórico
5.1 Introducción a Java

5.1.1 Características
5.1.2 Procesamiento
5.1.3 Bibliotecas
5.2 Programación Básica

5.2.1 Aspectos generales
5.2.2 Estructuras básicas
5.3 Programación Avanzada

5.3.1.ARCHIVOS
5.3.2 BASES DE DATOS
5.3.3 EXCEPCIONES
5.3.4 CÓDIGO NATIVO
5.3.5 SINCRONIZACIÓN
5.3.6 SERIALIZACIÓN
5.3.7 FINALIZADOR
5.4 UML y Java

5.4.1 Objetos y clases
5.4.2 Ligas, asociaciones y composición
5.4.3 Generalización y herencia
5.4.4 Estructuras estáticas
5.4.5 Metaclases
5.5 Aplicaciones y Applets
Página 2
5.5.1 Aplicaciones
5.5.2 Applets
5.6 Interfaces Gráficas del Usuario
Capítulo 6 Modelo de Requisitos
6.1. Descripción del Problema

6.2.1 Actores
6.2.2 Casos de uso
6.2.3 Documentación
6.2. Modelo de Caso de Uso

6.2.1 Actores
6.2.2 Casos de uso
6.3. Modelo de Interfaces
6.4. Actores y Caso de Uso

6.4.1 Actores
6.4.2 Casos de uso
6.5. Modelo de Dominio del Problema

6.5.1 Identificación de clases
6.5.2 Identificación de asociaciones
6.5.3 Identificación de atributos
6.5.4 Diccionario de clases
6.5.5 Identificación de Módulos
Capítulo 7 Modelo de Análisis
7.1. Arquitectura de Clases

7.1.1 Clases con estereotipos
7.1.2 Clases para casos de uso
7.2. Identificación de Clases según Estereotipos

7.2.1 Borde
7.2.2 Entidad
7.2.3 Control
7.3. Clases según Casos de Uso

7.3.1 Validar Usuario
7.3.2 Ofrecer Servicios
7.3.3 Registrar Usuario
7.3.4 Registrar Tarjeta
Página 3
7.3.5 Consultar Información

7.3.6 Hacer Reservación
7.3.7 Pagar Reservación
7.4. Diagramas de Secuencia

7.5. Casos de Uso para el Sistema

7.6. Diccionario de Clases

7.6.1 Interface Usuario
7.6.2 Principal
7.6.3 Registro
7.6.4 Servicios
Capítulo 8 Modelo de Diseño
8.1. Estrategias de Diseño

8.1.1 Arquitectura
8.1.2 Robustez
8.1.3 Reuso
8.1.4 Extensibilidad
8.2. Diseño de Objetos

8.2.1 Tarjetas de clases
8.2.2 Responsabilidades
8.2.3 Colaboraciones
8.2.4 Jerarquías
8.2.5 Contratos
8.2.6 Subsistemas
8.2.7 Protocolos
8.2.8 Atributos
8.2.9 Algoritmos
8.3. Diseño de Sistema
Página 4
8.3.1 Lenguajes de programación

8.3.2 Interfaces gráficas
8.3.3 Bases de datos
8.3.4 Archivos
8.4. Revisión del Diseño
8.5. Diagrama de Secuencia del Diseño

8.5.1 Registrar Usuario: Crear Registro Usuario
8.5.2 Registrar Usuario: Actualizar Registro Usuario
8.5.3 Registrar Usuario: Eliminar Registro Usuario
8.5.4 Registrar Tarjeta: Crear Registro Tarjeta
8.5.5 Registrar Tarjeta: Actualizar Registro Tarjeta
8.5.6 Registrar Tarjeta: Eliminar Registro Tarjeta
Capítulo 9: Modelo de Implementación
9.1. Programación en Java de su proyecto de Investigación

9.1.2 Principal
9.1.3 Dominio
9.1.4 Registro
9.1.5 Servicios
9.2. Diagrama de Clases de su proyecto de Investigación

9.2.2 Principal
9.2.3 Dominio
9.2.4 Registro
9.2.5 Servicios
Capítulo 10: Modelo de Pruebas
10.1. Definición de Conceptos de su proyecto de Investigación
10.2. Tipos de Pruebas de su proyecto de Investigación

10.2.1 Técnicas de pruebas
10.2.2 Nivel de pruebas
10.3. Proceso de Pruebas de su proyecto de Investigación

10.3.1 Estrategia de prueba
10.3.2 Planeación de la prueba
10.3.3 Construcción de la prueba
10.3.4 Ejecución de la prueba
10.4. Pruebas del Sistema de su proyecto de investigación

Página 5
10.4.2 Registrar tarjeta
Capítulo 11 Conclusiones
Capítulo 12 Recomendaciones
Capítulo 13 Bibliográficas
Página 6
Capítulo 1 Introducción
La programación orientada a objetos (POO) es una forma de programación en computadoras que tiene
surge los años 70. Se diferencia de la programación clásica o estructurada en que las instrucciones hacen
referencia a los elementos del entorno. Esos elementos representan "objetos"; y todos los datos y todas las
acciones que se hagan con ellos o sobre ellos, están encapsuladas u ocultas en el objeto. Teniendo en
cuenta estos conceptos para la elaboración de este proyecto que se basa en la elaboración de un sistema de
información para reservar habitaciones en un hotel, se hará énfasis en el modelo de requisitos y su
posterior análisis, que permitirán la fácil ejecución e implementación del sistema como tal.
Para realizar el modelo de requisitos hay que tener en claro el planteamiento del problema que en este
caso pretende mostrar las deficiencias que existen en el ingreso del personal visitante en días de visita,
quienes deben soportar varias horas de espera, seguidamente debe elaborarse los modelos e identificar los
actores que interactuaran con el sistema y por último se hará un análisis.
Página 7
Capítulo 2 Objetivos
2.1 Objetivos Generales
Análisis, Modelado de Requisitos en la implementación y Modelado de diseño en la implementación en el

desarrollo de un Software Orientado a Objetos como son: Arquitectura de Clase, Identificación de las
clases según Estereotipo, Clases Según Caso de Uso, Diagramas de Secuencia, Diccionario de Clases. Etc.
2.2 Objetivos Específicos
 Diseñar los casos de uso del sistema de reserva de habitaciones en un hotel.

 Describir los escenarios planteados en el caso de uso
 Establecer la arquitectura a implementar en el sistema de reserva de habitaciones.
 Iniciar el proceso de formación Profesional de Ingeniería de Sistemas; creando en el estudiante la
capacidad de participar activamente en procesos de desarrollo de aplicativos, con conceptos
básicos de la Programación Orientada a Objetos.
Capítulo 3 Justificación
3.5 Justificación Metodológica

3.6 Justificación Práctica
3.7 Justificación Innovativa
3.8 Justificación Profesional
Capítulo 4 Metodología
4.3 Tipo de Metodología

4.4 Metodología de Investigación
Capítulo 5 Marco Conceptual y Teórico
5.1 Introducción a Java
Java, el lenguaje orientado a objetos diseñado para ser multiplataforma y poder ser empleado el
mismo programa en diversos sistemas operativos.
Esta característica junto con la posibilidad de emplearlo para crear applets e insertarlos en
páginas HTML, o mediante servlets y páginas jsp generar código HTML dinámico. Todo ello con
la capacidad de acceder a bases de datos1.
5.1.1 Características
1
http://www.mundojava.net/
Página 8
5.1.2 Procesamiento
5.1.3 Bibliotecas
5.2 Programación Básica
5.2.1 Aspectos generales
La programación orientada a Objetos básicamente define una serie de conceptos y técnicas de programación para
representar acciones o cosas de la vida real basada en objetos, a diferencia de otras formas de programación como
por ejemplo la estructurada, con la POO se trabaja de manera distinta vinculando diferentes conceptos tales como
clases, objetos, métodos, propiedades, estados, herencia, encapsulación entre otros, generando cada vez
interrelaciones en nuestro desarrollo en pro del funcionamiento del sistema principal, definiendo el programa como
un conjunto de estos objetos relacionados entre sí2.
5.2.3 Estructuras básicas
5.3 Programación Avanzada
Clase: s simplemente una abstracción que hacemos de nuestra experiencia sensible. El ser humano tiende a agrupar
seres o cosas.
Objeto: es una abstracción de algo en el dominio del problema, que refleja las capacidades de un sistema de
almacenar información acerca de ello, interactuar con ello o ambas
Herencia: Esta es la cualidad más importante de un sistema OOP, la que dará mayor potencia y productividad,
permitiendo ahorrar horas y horas de codificación y de depuración de errores, además permite reutilizar todo el
código escrito para las superclases reescribiendo solo aquellas diferencias que existan entre éstas y las subclases.
Encapsulación: Se refiere a la capacidad de agrupar y condensar en un entorno con límites bien-definidos distintos
elementos. Cuando hablemos de encapsulación en general siempre nos referiremos, pues, a encapsulación abstracta.
De manera informal, primero generalizamos (la abstracción) y luego decimos: la generalización está bien, pero
dentro de un cierto orden: hay que poner límites (la encapsulación), y dentro de esos límites vamos a meter, a saco,
todo lo relacionado con lo abstraído: no sólo datos, sino también métodos, comportamientos, etc.
Polimorfismo: aquella cualidad que poseen los objetos para responder de distinto modo ante el mismo mensaje
5.3.1.ARCHIVOS
5.3.2 BASES DE DATOS
5.3.3 EXCEPCIONES
5.3.4 CÓDIGO NATIVO
5.3.5 SINCRONIZACIÓN
5.3.6 SERIALIZACIÓN
5.6.7 FINALIZADOR
2
http://codejavu.blogspot.com.co/2013/05/conceptos-de-programacion-orientada.html
Página 9
5.7 UML y Java
UML: el lenguaje de modelamiento unificado es como lo dice un lenguaje grafico el cual permite visualizar,
especificar y documentar cada una de las partes que comprende el desarrollo de software. Este permite modelar
conceptualmente los procesos y funciones del sistema, y determina las clases y el esquema de base de datos. También
se relaciona con java.
5.4.1 Objetos y clases

5.4.2 Ligas, asociaciones y composición
5.4.3 Generalización y herencia
5.4.4 Estructuras estáticas
5.4.5 Metaclases
5.8 Aplicaciones y Applets

5.5.1 Aplicaciones
5.5.2 Applets
5.9 Interfaces Gráficas del Usuario
La interfaz gráfica de usuario, conocida también como GUI (del inglés graphical user interface) es un programa
informático que actúa deinterfaz de usuario, utilizando un conjunto de imágenes y objetos gráficos para representar
la información y acciones disponibles en la interfaz. Su principal uso, consiste en proporcionar un entorno visual
sencillo para permitir la comunicación con el sistema operativo de una máquina o computador 3.
Aplicaciones: Se pueden ejecutar directamente en un entorno Java
Tipos:
 Modo de consola
 Interacción mediante teclado
 Interfaz basado en texto
 Aplicaciones con interfaz gráfica (GUI)
 Ventanas gráficas para entrada y salida de datos
 Iconos
 Dispositivos de entrada (p.ej. ratón, teclado)
 Interacción directa Applets
 Pequeñas aplicaciones que se ejecutan dentro de un navegador (o en el visualizador de applets
(Appletviewer)
 Interfaz gráfica
 Limitaciones por motivos de seguridad
Capítulo 6 Modelo de Requisitos

3
http://emmanuelgs.blogspot.com.co/2011/05/poo-clase-10-interfaces-graficas-de.html
Página 10
6.1. Descripción del Problema
El dueño de un hotel le pide a usted desarrollar un programa para consultar sobre las piezas disponibles y
reservar piezas de su hotel.
El hotel posee tres tipos de piezas: simple, doble y matrimonial, y dos tipos de clientes: habituales y
esporádicos y comodidades (frigobar, TV, y DVD). Una reservación almacena datos del cliente, de la
pieza reservada, la fecha de comienzo y el número de días que será ocupada la pieza.
El recepcionista del hotel debe poder hacer las siguientes operaciones:
 Obtener un listado de las piezas disponible de acuerdo a su tipo

 Preguntar por el precio de una pieza de acuerdo a su tipo
 Preguntar por el descuento ofrecido a los clientes habituales
 Preguntar por el precio total para un cliente dado, especificando su número de RUT, tipo de pieza
y número de noches.
 Dibujar en pantalla la foto de un pieza de acuerdo a su tipo
 Reservar una pieza especificando el número de la pieza, rut y nombre del cliente.
 Eliminar una reserva especificando el número de la pieza
El administrador puede usar el programa para:
 Cambiar el precio de una pieza de acuerdo a su tipo

 Cambiar el valor del descuento ofrecido a los clientes habituales
 Calcular las ganancias que tendrán en un mes especificado (considere que todos los meses tienen
treinta días).
El hotel posee información sobre cuales clientes son habituales. Esta estructura puede manejarla con un
diccionario, cuya clave sea el número de RUT y como significado tenga los datos personales del cliente.
El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de pieza o clientes y a su vez
permitir agregar nuevas consultas.
6.2. Modelo de Caso de Uso
6.2.1 Actores
Identificamos 2 actores en nuestro sistema, mostramos la delimitación de este:
6.2.2 Casos de uso
Página 11
Nombre Reserva Pieza

Resumen El módulo deberá permitir al actor hacer la reserva de una habitación a un
cliente para un período determinado.
Actores Recepcionista
Objetivo Reservar una habitación.
Precondición El actor debe elegir el tipo de habitación
Curso normal de 1. El actor ingresa al módulo de Reservas y selecciona la opción Alta de
acontecimientos Reserva.
2. El sistema muestra la pantalla “Alta de Reserva” con los siguientes
campos:
Página 12
 Fecha desde (campo obligatorio): el sistema deberá

desplegar un calendario para que el actor seleccione la
fecha.
 Fecha hasta (campo obligatorio): el sistema deberá
desplegar un calendario para que el actor seleccione la
fecha.
 Tipo de Habitación (combo opcional): lista todos los tipos
de habitaciones activas.
3. El actor registra los parámetros de búsqueda y presiona Aceptar.
4. El sistema muestra todas las habitaciones disponibles por tipo para las
fechas indicadas. El sistema detallará los siguientes campos:
 Fecha Desde
 Fecha Hasta
 Numero de Habitación
 Tipo de Habitación
5. El actor selecciona una habitación entre las desplegadas y presiona
“Continuar”.
6. El sistema solicita el ingreso de un Cliente para la reserva.
7. El actor ingresa el cliente y presiona Aceptar.
8. El sistema indica:
 Precio diario y total (con descuentos): correspondiente a la
habitación seleccionada para el cliente registrado.
 Detalle de Descuentos
9. El actor presiona aceptar para hacer efectiva la reserva. El sistema
muestra un mensaje de Reserva Exitosa en caso que se haya
efectivizado la misma. En ese mensaje también se indicará un código
numérico de la reserva que estará asociado a ese evento.
Alternativas 2.1 El sistema deberá validar que:

 la fecha hasta sea mayor o igual a la fecha desde.
 La fecha desde sea igual o mayor a sysdate.
El punto 2.1 no es un curso alterno, estas validaciones deberían estar en el curso
normal; dentro de las alternativas mostraríamos que pasaría si estas validaciones
no se cumplieran.
5.1 El sistema deberá validar que el actor haya seleccionado una o más
habitaciones. Caso contrario, se mostrará el mensaje “Debe seleccionar al
menos una habitación”.
7.1 El actor podrá presionar Cancelar para volver atrás con la Reserva. Se
visualizará la pantalla de Alta de Reserva con los parámetros en blanco.
9.1 El actor podrá presionar Volver para cancelar la operación.
9.2 El sistema deberá mostrar la pantalla de Alta de Reserva con los parámetros
en blanco para que puedan ingresarse nuevos.
Página 13
Nombre Eliminar Reserva

Actores Recepcionista
Resumen El módulo deberá permitir al actor hacer la baja de una reserva ya efectuada de
una habitación a un cliente para un período determinado.
Objetivo Dar de baja una reserva de una habitación.
Precondición El actor debe tener una reserva.
Curso normal de 1. El actor ingresa al módulo de Reservas y selecciona la opción Baja de
acontecimientos Reserva.
2. El sistema muestra la pantalla “Baja de Reserva” con los siguientes
campos:
 Código de Reserva (combo opcional): el sistema deberá
desplegar un campo de búsqueda con todas las reservas
activas.
 Cliente (campo opcional)
 Fecha desde (campo opcional): el sistema deberá desplegar
un calendario para que el actor seleccione la fecha.
 Fecha hasta (campo opcional): el sistema deberá desplegar
un calendario para que el actor seleccione la fecha.
3. El actor registra los parámetros de búsqueda y presiona Aceptar.

4. El sistema muestra el siguiente detalle de campos de acuerdo a los
parámetros indicados:
 Código de Reserva
 Cliente
 Tipo de Cliente
 Fecha Desde
 Fecha Hasta
 Habitación
 Tipo Habitación
 Precio total
5. El actor selecciona la reserva y presiona Aceptar.

6. El sistema muestra el mensaje “Está seguro que desea cancelar la
reserva”.
7. El actor presiona Aceptar para Cancelar la misma.
8. El sistema muestra el mensaje “Reserva Cancelada” en caso que se
haya efectivizado la operación.
Alternativas 2.1 El sistema deberá validar que:

 La fecha hasta sea mayor o igual a la fecha desde.
 La fecha desde sea igual o mayor a sysdate.
 El cliente exista en el maestro de clientes. VAL1_Valida Cliente. En
caso que no exista mostrará el mensaje “Ingrese un Cliente existente”
Página 14
 El código de reserva corresponda a una reserva que exista.

4.1 En caso que el actor no ingrese ninguno de los parámetros indicados, el
sistema mostrará todas las reservas activas detallándose los siguientes campos:
 Código de Reserva
 Cliente
 Tipo de Cliente
 Fecha Desde
 Fecha Hasta
 Habitación
 Tipo Habitación
 Precio total
Nombre Ingresar Habitación

Actores Administrador Hotel
Resumen
Objetivo Dar de alta a una nueva habitación
Precondición  Numero de habitación inexistente
 Tipo de habitación existente.
Curso normal de 1. El actor hace clic sobre la opción “Alta Habitación”.
acontecimientos 2. Sistema despliega la pantalla “nueva habitación”.
3. completar el campo número habitación.
4. Sistema valida número de habitación.
5. El actor escoge el tipo de habitación: Simple, doble o matrimonial.
6. El sistema confirma la nueva habitación.
Alternativas 4.1 El sistema detecta número de habitación existente.

4.2 El sistema muestra un mensaje que notifica la habitación existente.
6.3. Modelo de Interfaces
6.4. Actores y Caso de Uso
6.4.1 Actores
Actor Recepcionista
Casos de Uso Reservar Pieza, Eliminar Reserva, imprimir Listado piezas, consultar precio
pieza, consultar precio cliente, dibujar foto pieza, consultar descuento
cliente.
Tipo Primario.
Descripción Representa un trabajador del hotel que maneja las reservas de piezas.
Página 15
Actor Administrador
Casos de Uso Cambiar descuento cliente, calcular ganancia, cambiar precio pieza.
Tipo Primario.
Descripción Representa a aquella persona que tiene permitido hacer modificaciones a la
información de las piezas.
6.5. Modelo de Dominio del Problema
6.5.1 Identificación de clases
Clases Identificadas
Habitación
Tipo habitación
Comodidad
Reserva
Cliente
Descuento
6.5.2 Identificación de asociaciones
Asociaciones Identificadas con roles y multiplicidad

Una habitación tiene un tipo
Una habitación tiene varias comodidades
Una Habitación tiene muchas reservas
Un cliente tiene muchas reservas
Un descuento aplica a muchos clientes
6.5.3 Identificación de atributos
Clases Atributos
Habitacion Nro_Habitacion, Cod_Comodidad, Precio_Habitacion
Tipo_habitacion Cod_tipo, Descripcion_Tipo, Precio_Tipo, Foto
Comodidad Cod_Comodidad, Descrip_Comodidad, Precio_Comodidad
Reserva Nro_Habitacion, Fecha_Desde, Fecha Hasta, Precio Total.
Cliente Nro_Doc_Cliente, Nombre_Cliente, Tipo_Cliente
Descuento Cod_Descuento, Descuento.
Página 16
6.5.4 Diccionario de clases
Reserva: Para poder hospedarse en el hotel, es necesario contar con una reserva previa, para conocer el
número de la habitación, el tipo de habitación y el tiempo que va a estar hospedado. Una persona puede
hacer reserva de varias habitaciones. Para realizar la reserva esta la persona debe estar registrada.
Habitación: se denomina por medio de un número. La habitación tiene como atributos el tipo de
habitación, la acomodación, el precio y cantidad de días reservados. Una habitación puede ser reservada
varias veces y en diferentes días a la semana. La habitación pertenece al hotel y puede estar disponible
según las reservas
6.5.5 Identificación de Módulos
Página 17
Capítulo 7 Modelo de Análisis
7.1. Arquitectura de Clases
La arquitectura para el modelo de análisis se basa en tres características de correspondientes a las tres
dimensiones (Entidad, Control y Borde), este modelo tiene como objetivo generar una arquitectura de
objetos que sirve como base para el diseño del sistema.
7.1.1 Clases con estereotipos
Control: Corresponde a la información en línea, aquí se pueden generar los informes periódicos para
sacar las estadísticas del servicio de habitación.
Borde: Corresponde a la alimentación de información del sistema de habitación, allí se registran las
novedades y se realizan las modificaciones a las que haya lugar, Ejemplo cambio de tarifas, disponibilidad
de habitaciones.
Entidad: Corresponde al Sistema donde se encuentra la información real de habitaciones disponibles,

características, fechas de disponibilidad, valores entre otros, cabe resaltar que también aquí se puede tener
el registro de clientes.
7.1.2 Clases para casos de uso
En el desarrollo del modelo de análisis para cada caso de uso se identifican los objetos necesarios para su
implementación. Se identifican estos objetos según sus estereotipos para corresponder a la funcionalidad
ofrecida en cada caso de uso.:
Página 18
7.2. Identificación de Clases según Estereotipos
Se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de
objetos debe considerar los tres tipos de estereotipos
7.2.1 Borde
Página 19
Relación entre casos de Uso, Actores y Clases
Borde para el Sistema Reservación de Pieza

Caso De Uso Actores Clase Borde
Interfaz para información estado
de la Reserva, Interfaz para
Reservar Pieza Recepcionista
Reservar Habitación, Interfaz
inicio de sesión.
Eliminar Reservas Recepcionista Interfaz para Cancelar Reservas
Interfaz para información estado
Ingresar Habitación Administrador
de la Reserva,
Modificar Reservas Recepcionista Interfaz para modificar Reservas
Interfaz información estado de la
Cancelar Reservas Recepcionista
Reserva
Interfaz información estado de la
Consultar Reservas Recepcionista
Reserva
Cambiar Descuentos Administrador Interfaz Cambiar Precios
Consultar Precios Recepcionista, Administrador Interfaz Cambiar Precios
7.2.2 Entidad
Relación entre casos de Uso y clase
Página 20

Caso De Uso Actores Clase Entidad
Consultar Reservas Recepcionista Usuarios Registrados
7.2.3 Control
Relación entre casos de Uso y clase

Caso De Uso Actores Clase control
Reservar Pieza Recepcionista Manejo Para apartar Reservas
Eliminar Reservas Recepcionista Manejo para cancelar Reservas
Modificar Reservas Recepcionista Manejo para Modificar Reserva
Consultar Reservas Recepcionista Manejo registro del sistema
Cambiar Descuentos Administrador Manejo Cambios Precios
Consultar Precios Recepcionista, Administrador Manejo Cambios Precios
7.3. Clases según Casos de Uso
Página 21
7.4. Diagramas de Secuencia
Reserva Habitación
Página 22
Tomado de: http://osl2.uca.es/wikiIW/index.php/MAXIMUS
Consultar Disponibilidad pieza
Tomado de: http://osl2.uca.es/wikiIW/index.php/MAXIMUS
Cancelar Reservas
Página 23
Tomado de:
http://osl2.uca.es/wikiIW/index.php/MAXIMUS#Sprint_3:_Cancelar_reserva._8.2FJunio.2F2011
7.5. Casos de Uso para el Sistema

7.6. Diccionario de Clases

7.6.2 Principal
7.6.3 Registro
7.6.4 Servicios
Capítulo 8 Modelo de Diseño
Página 24
8.1. Estrategias de Diseño
8.1.1 Arquitectura
Asegurar la integralidad es crear un Control en las clases, mediante manejadores (manejo) para cada caso
de uso. Con esto evitamos que se haga un cambio o modificación, en ese caso de uso, que pueda afectar el
funcionamiento, de toda la aplicación
Los Manejos o controles para sistema de reserva de piezas son:
 Manejo Registro del Sistema

 Manejo para administrar sistema
 Manejo para modificar Reserva
 Manejo para Cancelar Reserva
 Manejo para apartar Reservas
 Manejo Cambios Precios
8.1.2 Robustez
La aplicación de reserva de piezas, es segura a prueba de usuarios, ya que tenemos jerarquías de Actores,
lo cual, delimita el acceso, a zonas del programa.
La seguridad e integridad de la aplicación reserva de piezas está Basada en:
• Las mayorías de los datos, son Declarados de tipo String, con el fin de evitar errores, debido a que
muchos usuarios mezclan caracteres especiales, para separar, letras y/o números.
• Así mismo, implementar al código el ciclo PHVA (Planificar, Hacer, Verificar y Actuar), con el fin de
encontrar una mejora continua a nuestro aplicativo, siempre, se puede mejorar, para cubrir más
necesidades, al igual que se puede verificar con el objetivo de prevenir daños.
• Crear mensajes de alertas, cuando se ingresen datos no correspondientes, a lo que piden cada campo.
8.1.3 Reusó
El reúso se ve reflejado en la herencia que haremos en ciertas clases, como lo es la clase Datos Personas.
Cuyos atributos, pueden ser usados por Paciente, y administradores.
8.1.4 Extensibilidad
Otro aspecto a tener en cuenta en la eficiencia del sistema es que este sea extendido, es decir, que le
permita al usuario ser general. Para conseguir esto en el sistema de reservas, se puede:
 Encapsular las clases
Página 25
 No exportar estructuras de datos desde un método

 Tener un concomimiento limitado de la arquitectura de las clases del sistema
 Evitar expresiones especificas o difíciles
 Distinguir entre operaciones privadas y públicas
8.2. Diseño de Objetos

Este es un proceso para añadir detalles al análisis y discernir entre múltiples opciones sobre el diseño del
sistema de reservación del Hotel, para lograr una especificación precisa antes de comenzar la
implementación final.
Los aspectos a resolver es determina como las clases, atributos y asociaciones del modelo de análisis
deben de implementarse en la estructura de datos, es necesario precisar si se requiere incluir nuevas clases
en el modelo de diseño, también es necesario determinar los algoritmos para implementar las
operaciones.
Para el diseño de objetos se seguirá el diseño por responsabilidad (RDD- Responsability Driven Design)
el diseño RDD se basa en el modelo Cliente-Servidor donde las clases se ven como clientes cuando
generan una petición hacia otra clase y como servidor cuando reciben peticiones de otras clases. Una
misma clase se ve en diferentes momentos como cliente o servidor.
8.2.1 Tarjetas de clases
Interface Usuario
Clase: Interface Usuario

Descripción: Toda la interacción con el usuario se hace por medio de la interface Usuario
Modulo: Interface Usuario
Estereotipo: Borde
Atributos:
Manejador Principal
Clase: Manejador Principal

Descripción: El manejador Principal es el encargado de desplegar la pantalla principal de
interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados
apropiados.
Modulo: Principal
Estereotipos: Control
Atributos:
Página 26
REGISTRO USUARIO
Clase: Manejador Registro Usuario. El Manejador de Registro Usuario se encarga de todo lo

relacionado con el registro de usuario para utilizar el sistema.
Modulo: Registro de Usuario
Estereotipo: Control
Atributos:
PANTALLA CREAR REGISTRO.
Clase: Pantalla Crear Registro Usuario

Descripción: Pantalla de Solicitud de Registro de Usuario.
Modulo: Registro Usuario
Estereotipo: Borde
Atributos:
REGISTRO DE USUARIO.
Clase: Registro de Usuario

Descripción: Para utilizar el sistema de consultas de reservación y cancelación de habitaciones, el
usuario debe estar registrado en el sistema. El registro debe tener información acerca del usuario
que incluye nombre, documento, dirección, ciudad, país, celular, email, usuario y contraseña
Estereotipo: Entidad
Atributo:
INTERFACES BASES DE DATOS.
Clase: Interface Base Datos Registro

Descripción: La información de cada usuario se almacena en la base de datos de registro que se
accede mediante la interface de la base de datos de registro.
Modulo: Registro Interface Base Datos
Estereotipo: Interface
Atributos:
MANEJADOR SERVICIOS.
Página 27
Clase: Manejador Servicios

Descripción: El manejador de servicios se encarga de enviar las peticiones particulares de servicios
a los manejadores especializados para la consulta de solicitud y cancelación de citas
Modulo: Servicios
Atributos:
8.2.2 Responsabilidades
Validar usuarios
Flujo Principal Manejador Principal Solicita desplegar Pantalla Principal a la interface usuario.
La Interface Usuario Despliega la Pantalla Principal. La Pantalla se despliega.
El Usuario selecciona entre las siguientes opciones “Registrarse por primera
Vez”, “OK” y “Salir”.
Si la actividad seleccionada es “Registrase por Primera Vez”, La Pantalla
Principal envía el evento “Registrase por Primera Vez” a la Interface Usuario.
La Interface Usuario envía el evento “Registrase por Primera Vez” al
Manejador Principal. El Manejador Principal solicita “Registrar” al Manejador
Registro Usuario.
Se ejecuta el caso de uso Registrar Usuario Sub flujo Registrar Usuario (S-1).
Si la actividad seleccionada es “OK” se valida el Registro Usuario, mediante
un Login y Password insertados por el Usuario en la Pantalla Principal. La
Pantalla Principal envía el evento “OK” a la Interface Usuario. La Interface
Usuario envía el evento “OK” al manejador Principal. El Manejador Principal
solicita validar Registro Usuario al Manejador Registro Usuario. El Manejador
Registro Usuario solicita validar al Registro Usuario a la Base Datos Registro.
La Base Datos Registro valida el Usuario y devuelve el OK a la Interface Base
Datos Registro. La Interface Datos registro devuelve el OK al Manejador
Registro Usuario. El Manejador Registro Usuario devuelve OK al Manejador
Principal. Una vez validado el Usuario el Manejador Principal Solicita Ofrecer
Servicio al Manejador Servicio. Se continúa con el caso de uso obtener
servicios.
Si la actividad es “Salir”, La Pantalla Principal envía el evento “Salir” a la
Interface Usuario. La Interface Usuario envía el evento “Salir” al Manejador
Principal. El Manejador Principal sale del sistema.
INTERFACE USUARIO.
Responsabilidades asignadas teniendo en cuenta ofrece servicio, valida usuario. Registra usuario.
Clase: interface Usuario
Página 28
Descripción: Toda la interacción con el usuario se hace por medio de la interface de usuario
Modulo : Interface Usuario
Estereotipo: Borde
Atributos:
Solicita Ir a la pantalla Principal a la interface de Usuario
Envía el evento “Registrase por primera vez” al Manejador
Principal
Envía el evento “OK” al Manejador Principal
Envía el evento “Salir” al Manejador Principal
Solicitar ir a la pantalla de Servicio
Envía el evento “Obtener Registro” al Manejador de Servicio
Envía el evento “Salir” al Manejador de Servicio
Solicita ir a la pantalla de crear Registro de Usuario
Remite el evento “Registrar” al Manejador Registro Usuario
Envía el evento “Salir” al Manejador de Usuario
Solicitar ir a la Pantalla Obtener Registro Usuario
Envía el evento “Servicios” al Manejador Registro de Usuario
Envía el Evento “Actualizar” al Manejador Registro de
Usuario
Envía el Evento “Eliminar” al Manejador Registro de Usuario
MANEJADOR PRINCIPAL.
apropiados.
Modulo: Principal
Atributos:
Solicita Desplegar Pantalla Principal a la Interface Usuario
Ejecuta el evento “Registrase por Primera Vez”
Solicita crear Registro Usuario al Manejador Registro Usuario
Opera el evento “OK”
Solicita validar Registro Usuario al Manejador Registro
Usuario
Solicita ofrecer Servicio al Manejador Servicio
Opera el evento “Salir”
Abandona Sistema
MANEJADOR REGISTRO USUARIO.
Página 29

Atributos:
Crear Registro de Usuario.
Requiere Validar Registro Usuario a la Interface de base datos
registro
Solicitar desplegar pantalla Crear Registro Usuario a la interface
usuario
Opera el evento “Registrar”
Requiere Crear Registro Usuario a la Interface base datos Registro
Solicita Administrar Registro Usuario
Maneja el evento “Salir”
Abandona el Sistema.
Maneja el evento “Servicios”
Solicita ofrecer servicios al Manejador Servicios
Maneja el evento “Actualizar”
Solicita Actualizar Registro Usuario a la Interface Base Datos
Registro
Maneja el evento “Eliminar”
Solicita Eliminar Registro Usuario a la Interface Base Datos Registro

Estereotipo: Borde
Atributos:
Envía el evento “Registrar” a la Interface Usuario.
Envía el evento “Salir” a la interface Usuario.
REGISTRO DE USUARIO.
Clase: Registro de Usuario
Descripción: Para utilizar el sistema de consultas de reservación y cancelación de habitaciones, el
usuario debe estar registrado en el sistema. El registro debe tener información acerca del usuario
que incluye nombre, documento, dirección, ciudad, país, celular, email, usuario y contraseña
Página 30
Atributo:

Atributos:
Requiere Validar Registro Usuario a la Base Datos Registro.
Requiere Crear Registro Usuario a la Base Datos Registro.
Requiere Obtener Registro Usuario a la Base Datos Registro.
Requiere Actualizar Registro Usuario a la Base Datos Registro.
Requiere Eliminar Registro Usuario a la Base Datos Registro.
Modulo: Servicios
Atributos:
Ofrecer Servicio
Solicitar desplegar Pantalla Servicio a la Interface Usuario
Maneja el evento “Obtener Registro”
Solicita Registrar al Manejador Registro Usuario
Maneja el Evento “Salir”
PANTALLA DE SERVICIOS.
Clase: Pantalla Servicio
Descripción: Pantalla de Servicios
Modulo: Servicios
Estereotipo: Borde
Atributos:
Despliega
Envía el evento “Obtener Registro” a la Interface Usuario.
Envía el Evento “Salir” a la interface Usuario.
Página 31
8.2.3 Colaboraciones
INTERFACE DE USUARIO
Clase: interfaceUsuario
Estereotipo: Borde
Atributos:
Solicita Ir Pantalla Principal
Envía el evento “Registrase por primera vez” Manejador Principal
Envía el evento “OK” Manejador Principal
Envía el evento “Salir” Manejador Principal
Solicitar ir Pantalla de Servicio
Envía el evento “Obtener Registro” Manejador de Servicio
Envía el evento “Salir” Manejador de Servicio
Solicita ir crear Registro de Usuario
Remite el evento “Registrar” Manejador Registro Usuario
Envía el evento “Salir” Manejador de Usuario
Solicitar ir Pantalla Obtener Registro Usuario
Envía el evento “Servicios” Manejador Registro de Usuario
Envía el Evento “Actualizar” Manejador Registro de Usuario
Envía el Evento “Eliminar” Manejador Registro de Usuario
MANEJADOR PRINCIPAL

interacción con el usuario, y luego delegar las diferentes funciones a los manejadores
especializados apropiados.
Modulo: Principal
Atributos:
Solicita Desplegar Pantalla Principal Interface Usuario
Ejecuta el evento “Registrase por Primera Vez” Interface Usuario
Solicita crear Registro Usuario Manejador Registro Usuario
Opera el evento “OK” Interface Usuario
Solicita validar Registro Usuario Manejador Registro Usuario
Solicita ofrecer Servicio Manejador Servicio
Opera el evento “Salir” Interface Usuario
Abandona Sistema Interface Usuario
Página 32
MANEJADOR REGISTRO USUARIO

Atributos:
Requiere Validar Registro Usuario Interface de base datos
registro
Solicitar desplegar pantalla Crear Registro Usuario interface usuario
Requiere Crear Registro Usuario Interface base datos Registro
Solicita ofrecer servicios Manejador Servicios
Solicita Actualizar Registro Usuario Interface Base Datos
Registro
Solicita Eliminar Registro Usuario Interface Base Datos
Registro

Estereotipo: Borde
Atributos:
Envía el evento “Registrar” Interface Usuario.
Envía el evento “Salir” interface Usuario

Atributos:
Página 33


Modulo: Servicios
Atributos:
Ofrecer Servicio
Solicitar desplegar Pantalla Servicio Interface Usuario
Solicita Registrar Manejador Registro Usuario

Modulo: Servicios
Estereotipo: Borde
Atributos:
Despliega
Envía el evento “Obtener Registro” Interface Usuario.
Envía el Evento “Salir” Interface Usuario.
8.2.4 Jerarquías
INTERFACEUSUARIO
Grupo de responsabilidades y colaboraciones para la clase interfaceUsuario

Solicita ir… Pantalla Principal, Pantalla de Servicio, crear Registro de Usuario, Pantalla
Obtener Registro Usuario
Envía el evento… Manejador Principal, Manejador de Servicio, Manejador Registro Usuario
Página 34
Grupo de responsabilidades y colaboraciones para la clase interfaceUsuario con dos nuevas super
clases: Pantalla y Manejador
Solicita ir… Pantalla: PantallaPrincipal, PantallaServicio, PantallaRegistroUsuario,
PantallaObtenerRegistroUsuario
Envía el evento… Manejador: ManejadorPrincipal, ManejadorServicio,
ManejadorRegistroUsuario
Estereotipo: Borde
Atributos:
Solicita ir… Pantalla: PantallaPrincipal, PantallaServicio, PantallaRegistroUsuario,
PantallaObtenerRegistroUsuario
Envía el evento… Manejador: ManejadorPrincipal, ManejadorServicio,
ManejadorRegistroUsuario
8.2.5 Contratos
Mecanismo que consiste en realizar una agrupación de las responsabilidades, siendo un indicador de los
distintos servicios.
INTERFACE DE USUARIO
Clase: Interface Usuario

Descripción: toda interacción con el usuario, se hace por medio de la interface de usuario.
Modulo: Interface Usuario
Estereotipo: Borde
Propiedades: Concreta.
Subclases:
Página 35
Atributos: Pantalla: Pantalla Principal, Pantalla Servicio,

Contratos Pantalla Crear Registro Usuario, Pantalla
1. Ir a Pantalla Obtener Registro Usuario,
Enviar Pantalla
Manejador: Manejador Principal, Manejador

2. ir Evento Servicio,
Enviar Evento Manejador Registro Usuario,
PRINCIPAL
En la principal encontramos un evento el cual lo dirige a una pantalla donde ofrecerás el servicio. Tendrá
la opción de ingresar al servicio o simplemente salir, en este evento no encontramos más ítems.
Las responsabilidades, las colaboraciones y las jerarquías para un manejador.
 Clase: Manejador
 Descripción: superclase heredada por todos los manejadores del sistema.
 Modulo: Principal
 Estereotipo: Control
 Propiedades: Abstracta
 Superclases:
 Subclases: Manejador Principal, Manejador Servicio, Manejador Registro Usuario,
 Atributos:
Página 36
 Contratos
 Manejar Evento
 Manejar Evento
 Responsabilidades Privadas
 Desplegar Pantalla
 Manejar Evento Ofrecer Servicio
 Ofrecer Servicio
 Manejar Evento Salir
 Salir.
 Clase: Interface Usuario

 Descripción: toda la interacción con el usuario se hace por medio de la interface de usuario.
 Modulo: Interface Usuario
 Estereotipo: Borde
 Propiedades: Concreta
 Atributos:
Contratos
1. Desplegar Pantalla Pantalla (1): Pantalla Principal (1), Pantalla
desplegar Pantalla Servicio (1),
Pantalla Crear Registro usuario (1), Pantalla
Obtener Registro Usuario (1),
Manejador (1): Manejador Principal (1),

2. Enviar Evento Manejador Servicio (1),
Enviar Evento Manejado Registro Usuario (1),
Dominio son los contratos que se implementa en los datos.
Clase: Datos
Descripción: superclase para todas las clases entidad.
Modulo: Dominio
Propiedades: Abstracta
Superclases:
Subclases: Registro Usuario
Página 37
Interface base de datos registros.
SERVICIO.
8.2.6 Subsistemas
Según los casos de uso las clases se pueden distribuir en dos subsistemas. El primero corresponde al
registro de los huespedes el cual se llamará Subsistema registro y el segundo contendrá las clases que
sirven de soporte para ofrecer algún servicio, este se llamara subsistema servicio. Adicionalmente se crea
un subsistema para contener la clase Interface Usuario y uno para la clase Manejador Principal, las cuales
brindan soporte para servicios internos y no se pueden catalogar dentro de los subsistemas determinados
inicialmente.
Página 38
Subsistema Interface Usuario
Tarjeta para subsistemas

Subsistema: SubsistemaInterfaceUsuario
Descripción: En este subsistema están reunidos los objetos necesarios para gestionar las
interfaces
Clases: InterfaceUsuario, PantallaPrincipal, PantallaServicio, PantallaCrearRegistro,
PantallaObtenerRegUsuario.
1. Enviar Pantalla InterfaceUsuario
Subsistema Manejador principal

Subsistema: SubsistemaManejadorPrincipal
Descripción: En este subsistema están reunidos los objetos necesarios para el manejo de la
aplicación
Clases: ManejadorPrincipal
1. Manejar evento ManejadorPrincipal
Subsistema Registro
Subsistema: SubsistemaRegistro
Página 39
Descripción: En este subsistema están reunidos los objetos encargados del registro de un
paciente.
Clases: ManejadorRegistroUsuario, InterfaseBaseDeDatosRegistro,
1. Manejar evento RegistroUsuario (1)
2. Registrar usuario RegistroUsuario (2)
Subsistema Servicios

Subsistema: SubsistemaServicios
Descripción: En este subsistema se agrupan los objetos encargados de los servicios referentes a
la gestión de las citas médicas.
Clases: ManejadorServicio
1. Manejar servicio ManejadorServicio(1)
2. Ofrecer servicio ManejadorServicio(2)
8.3. Diseño de Sistema
8.3.1 Lenguajes de programación
De manera general, la implementación se basara en definiciones y manejos estándares de Java.
La capacidad de una clase para ocultar su implantación se conoce como encapsulamiento. Al ocultar, se
implica que un atributo o método no queda disponible o es manipulable por ciertas clases En lenguajes
como Java, existen cuatro maneras de calificar a un atributo o método:
Privado. El elemento sólo es accesado por objetos de la misma clase que lo contiene (Simbolizado en
UML con un -)
Público. El elemento es manipulado por cualquier clase. En UML se simboliza con un +.
Página 40
Protegido (Protected). El elemento es manipulado por la clase o sus descendientes. En UML es

simbolizado por #
Visible al paquete. Por omisión, si no existe ningún calificador, implica que solo clases que pertenecen al
mismo paquete, lo pueden accesar.
Por ultimo también se hará uso de los tipos u objetos primitivos de java como int, float, boolean, y objetos
con tipos predefinidos en Java, como String, Vector.
8.3.2 Interfaces gráficas

Las interfaces gráficas de usuario (GUI) ofrecen al usuario ventanas, cuadros de diálogo, barras de
herramientas, botones, listas desplegables y muchos otros elementos con los que ya estamos muy
acostumbrados a tratar.
Las aplicaciones son conducidas por eventos y se desarrollan haciendo uso de las clases que para ello nos
ofrece la API de Java.
La interfaz de usuario es la parte del programa que permite al usuario interaccionar con él. La API de Java
proporciona una biblioteca de clases para el desarrollo de Interfaces gráficas de usuario (en realidad son
dos).
La biblioteca proporciona un conjunto de herramientas para la construcción de interfaces gráficas que
tienen una apariencia y se comportan de forma semejante en todas las plataformas en las que se ejecuten.
La estructura básica de la biblioteca gira en torno a componentes y contenedores. Los contenedores
contienen componentes y son componentes a su vez, de forma que los eventos pueden tratarse tanto en
contenedores como en componentes.
La API está constituida por clases, interfaces y derivaciones.
Swing es una biblioteca de interfaces gráficas de usuario (GUI) para Java.

● Viene incluida con el entorno de desarrollo de Java (JDK).
● Extiende a otra librería gráfica más antigua llamada AWT.
● Paquetes:
● javax.swing
● java.awt
● java.awt.event
8.3.3 Bases de datos

El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos de
almacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden ser
implementados directamente en una base de datos orientada a objetos. Aun así, en el entorno de desarrollo
actual, la base de datos relacional es el método más usado para el almacenamiento de datos. Es en el
modelado de esta área donde UML se queda corto. El diagrama de clase de UML se puede usar para
modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semántica
involucrada en el modelado relacional, mayoritariamente la noción de atributos clave que relacionan entre
sí las tablas unas con otras. Para capturar esta información, un Diagrama de Relación de Entidad (ER
diagram) se recomienda como extensión a UML.
El Diagrama de Clase se puede usar para modelar la estructura lógica de la base de datos,
independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos
Página 41
de clase representando columnas. Si una base de datos relacional es el método de implementación

escogido, entonces el diagrama de clase puede ser referenciado a un diagrama de relación de entidad
lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus
atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre
entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entre
entidades en un diagrama de relación de entidad (ER diagram).
Diseño tabla reservación.
Fecha Cant_dias Cliente Pieza

01-11-2016 5 952468 25
8.4. Revisión del Diseño
En esta fase del diseño del sistema, se procede a realizar una revisión, con el fin de que se optimice el
diseño y buscar las posibles redundancias, con el fin de eliminarlas y así hacer eficaz el sistema
Para eso se realiza el siguiente resumen:
 Clases del sistema

o Validar cliente
o Consultar información de la habitación
o Elegir Habitaciòn
 Número de la habitación
 Fecha ingreso
 Fecha de salida
 Medio de pago
o Aceptar Reservación
8.5. Diagrama de Secuencia del Diseño
8.5.1 Registrar Usuario: Crear Registro Usuario
Página 42
Página 43
8.5.2 Registrar Usuario: Actualizar Registro Usuario
Página 44
8.5.3 Registrar Usuario: Eliminar Registro Usuario
Página 45
8.5.4 Registrar Reserva: Crear Registro Reserva
Página 46
8.5.5 Registrar Tarjeta: Actualizar Reserva
Página 47
8.5.6 Registrar Reserva: Eliminar Reserva
Página 48
Página 49
Capítulo 9: Modelo de Implementación
9.1. Programación en Java de su proyecto de Investigación
Estereotipo: Borde
Atributos:
Solicita Ir Pantalla Principal
Envía el evento “Registrase por primera vez” Manejador Principal
Envía el evento “OK” Manejador Principal
Envía el evento “Salir” Manejador Principal
Solicitar ir Pantalla de Servicio
Envía el evento “Obtener Registro” Manejador de Servicio
Envía el evento “Salir” Manejador de Servicio
Solicita ir crear Registro de Usuario
Remite el evento “Registrar” Manejador Registro Usuario
Envía el evento “Salir” Manejador de Usuario
Solicitar ir Pantalla Obtener Registro Usuario
Envía el evento “Servicios” Manejador Registro de Usuario
Envía el Evento “Actualizar” Manejador Registro de Usuario
Envía el Evento “Eliminar” Manejador Registro de Usuario
public class InterfaceUsuario extends Frame

implements WindowListener, ActionListener
private Manejador manejador;
private Pantalla pantalla;
public void windowClosed(WindowEvent event) {}
public void windowDeiconified(WindowEvent event) {}
public void window!conified(WindowEvent event) {}
public void windowActivated(WindowEvent event) {}
public void windowDeactivated(WindowEvent event) {}
Página 50
public void windowOpened(WindowEvent event) {}
public void windowClosing(WindowEvent event) {
System.exit(O);
public void actionPerformed(ActionEvent event)
if (manejador != null)
manej ado r.manej arEvento(event.getActi onCommand());
public void desplegarPantalla(Pantalla p)
if (pantalla != null)
pantalla.borrarPantallaQ;
if (p != null)
pantalla = p;
if (pantalla != null)
pantal1 a.desplegarPantal1a();
show();
public InterfaceUsuario(Manejador m);
setSize(800,600);
setBackground(Color.lightGray);
addWi ndowLi stener(thi s);
manejador = m;
9.1.2 Principal

apropiados.
Página 51
Modulo: Principal
Atributos:
Solicita Desplegar Pantalla Principal Interface Usuario
Ejecuta el evento “Registrase por Primera Vez” Interface Usuario
Solicita crear Registro Usuario Manejador Registro Usuario
Opera el evento “OK” Interface Usuario
Solicita validar Registro Usuario Manejador Registro Usuario
Solicita ofrecer Servicio Manejador Servicio
Opera el evento “Salir” Interface Usuario
Abandona Sistema Interface Usuario
public class ManejadorPrincipal extends Manejador
private Pantalla pantallaPrincipal;
private ManejadorServicio ms;
private ManejadorRegistroUsuario mru;
public static void main(String[] args) {
ManejadorPrincipal m = new ManejadorPrincipal ();
public Mane jadorPrincipal () {
interfacellsuario = new Interfacellsuario(this);
ms = new ManejadorServicio(this,interfaceUsuario);
mru = new ManejadorRegistroUsuario(this,interfaceUsuario);
ms.setManejadorRegistroUsuario(mru);
desplegarPantal1aPrincipal();
private void desplegarPantallaPrincipal () {
if (pantallaPrincipal == null)
PantallaPrincipal = new PantallaPrincipal(interfaceUsuario,this);
despl egarPantal 1 a(new Pantal 1 aPri nci pal (i nterf acellsuari o, thi s) ) ;
Página 52
public void manejarEvento(String str) {
if(str.equals("Registrarse por Primera Vez"))
manejarEventoRegistrar();
else if (str.equalsC'OK11))
manejarEventoValidar();
else
manejarEventosAdicionales(str);
private void manejarEventoRegistrarQ
if (mru != null)
mru.crearRegi stroUsuari o();
private void manejarEventoValidarQ {
String log = pantalla.leerTexto("login");
String pass = pantalla.leerTextoC'password");
if (mru != null) {
if (mru.validarRegistroUsuario(log,pass) == true)
manejarEventoOf recerServicioQ;
else
desplegarPantal1a(pantal1 a);
}
}
9.1.3 Dominio

Página 53

Atributos:
public class Atributo
private String nombre;
private String valor;
public Atributo(String str, String v) {
nombre = str;
valor = v;
public String leerNombreQ {
return nombre;
public String leerValorQ {
return valor;
public void escribi rVal or (String v) {
valor = v;
public void print() {
Página 54
System.out.print(nombre+": ") ;
System.out.pri ntln(valor);
Entidad datos
public class Datos
protected Vector listaAtributos;
protected int numAtributosBD;
protected Atributo atributo;
public Datos() {
listaAtributos = new Vector;
protected void agregarAtributo(String nombre,
String valor, boolean fg) {
atributo = new Atributo(nombre,valor);
1i staAtri butos.addElement(atri buto);
if (fg == true)
numAtri butosBD++;
public String leerNombre(int i) {
String str = null;
atributo = (Atributo) 1istaAtributos.elementAt(i);
if (atributo != null)
str = atributo.leerNombreQ;
return str;
Página 55
public String leerValor(int i) {
String str = null;
atributo = (Atributo) 1istaAtributos.elementAt(i);
str = atributo. leerValorQ;
return str;
public void escribi rValor(int i, String str) {
atributo = (Atributo) listaAtributos.elementAt(i);
atributo. escribirValor (str);
public int numeroAtributos() {
return listaAtributos.sizeQ;
9.1.4 Registro

Atributos:
Requiere Validar Registro Usuario a la Interface de base datos
registro
Solicitar desplegar pantalla Crear Registro Usuario a la interface
usuario
Requiere Crear Registro Usuario a la Interface base datos Registro
Página 56

Solicita ofrecer servicios al Manejador Servicios
Solicita Actualizar Registro Usuario a la Interface Base Datos
Registro
Solicita Eliminar Registro Usuario a la Interface Base Datos Registro
clase ManejadorRegistroUsuario.
public class ManejadorRegistroUsuario extends Manejador
private Pantalla pantallaCrearRegUsuario;
private Pantalla pantallaObtenerRegUsuario;
private RegistroUsuario registroUsuario;
private ManejadorRegistroTarjeta mrt;
private InterfaceBaseDatosRegistro interfaceRegistro;
public ManejadorRegistrbllsuario(Manejador m,InterfaceUsuario ui) {
super(m,ui);
registroUsuario = new RegistroUsuarioQ;
interfaceRegistro = new InterfaceBaseDatosRegistroQ;
public void manejarEvento(String str) {
if (str.equalsC'Registrar11))
manejarEventoRegistrar();
else if (str.equals("Actualizar"))
manejarEventoActualizar();
else if (str.equalsC'Eliminar"))
Página 57
manejarEventoEliminarO ;
else if (str.equalsC'Registrar Tarjeta11))
manejarEventoRegi strarTarjetaQ;
else
manejarEventosAdicionales(str);
public void crearRegistroUsuarioQ {
if (pantallaCrearRegUsuario == null)
pantallaCrearRegUsuario =
new PantallaCrearRegUsuario(interfaceUsuario,this);
desplegarPantal1a(pantal1aCrearRegUsuari o);
public boolean validarRegistroUsuario(String log, String pass) {
if (registroUsuario == null)
registrollsuario = new RegistroUsuarioQ;
return
i nterfaceRegi stro. val i darRegi stro(regi strollsuario, 1 og, pass) ;
public void obtenerRegistrollsuarioO {
if (registroUsuario != null)
administrarRegistroUsuarioQ;
private void administrarRegistroUsuarioQ {
if (pantallaObtenerRegUsuario == null)
pantallaObtenerRegUsuario =
Página 58
new Pantal1aObtenerRegUsuario(interfaceUsuario,this);
escribi rElementos(pantallaObtenerRegUsuario,registroUsuario);
desplegarPantal1a(pantal1aObtenerRegUsuari o);
protected void escribirElementos(Pantalla p,Datos datos) {
p.escribi rElementos(datos);
private void manejarEventoRegistrarQ {
if (registrollsuario == null)
registrollsuario = new RegistroUsuarioC);
leerElementosCpantalla,registroUsuario);
i nterfaceRegi stro.crearRegi stro(regi stroUsuario);
admi ni strarRegi stroUsuari o();
protected void leerElementos(Pantalla p,Datos datos) {
p.1eerElementos (datos);
private void manejarEventoActualizarQ {
if (registroUsuario == null)
registroUsuario = new RegistroUsuarioQ;
1eerElementos(pantalla,registroUsuario);
i nterfaceRegi stro.actuali zarRegi stro(regi stroUsuari o);
private void manejarEventoEliminarQ {
if (registroUsuario != null) {
Página 59
i nterfaceRegi stro.elimi narRegi stro(regi stroUsuari o);
crearRegi stroUsuarioQ;
private void manejarEventoRegistrarTarjetaQ {
if (registrollsuario != null) {
if (mrt == null)
mrt = new ManejadorRegistroTarjeta(this,interfacellsuario);
String id = registroUsuario.leerValor(O);
mrt.registrarTarjeta(id);
public String leerTexto(String nameO) {
String name = null, str = null;
for (int j = 0; nameO.equals(name) == false && j < textos.sizeQ;
j++) {
name = ((Component) textos.elementAt(j)).getName();
if (nameO.equals(name) == true)
str = ((TextField) textos.elementAt(j)).getText();
return str;
name = ((Component) textos.elementAt(j)).getNameQ;
str = ((TextField) textos.elementAt(j)).getTextQ;
Página 60
public void leerElementos(Datos datos) {
String nameO,str,name;
for (int i = 0 ; i < datos.numeroAtributos(); i++) {
nameO = (String)datos.leerNombre(i);
str = null;
name = null;
for (int j = 0; nameO.equals(name) == false && j <
textos.sizeQ; j++) {
if (nameO.equals(name) == true) {
str = ((TextField) textos.elementAt(j)).getTextO;
datos.escribi rValor(i ,str) ;
datos.escribi rValor(i,str) ;
public void escribirElementos(Datos datos) {
String nameO,str,name;
for (int i = 0; i < datos.numeroAtributos(); i++) {
str = (String)datos.leerValor(i);
for (int j = 0; nameO.equals(name) == false && j <
textos.sizeQ; j++) {
Página 61
((TextField) textos.elementAt(j)).setText(str);
str = (String)datos.leerValor(i);
((TextField) textos.elementAt(j)).setText(str);
9.1.5 Servicios

Descripción: El manejador de servicios se encarga de enviar las peticiones particulares de
servicios a los manejadores especializados para la consulta de solicitud y cancelación de citas
Modulo: Servicios
Atributos:
Ofrecer Servicio
Solicitar desplegar Pantalla Servicio Interface Usuario
Solicita Registrar Manejador Registro Usuario

Modulo: Servicios
Estereotipo: Borde
Atributos:
Despliega
Envía el evento “Obtener Registro” Interface Usuario.
Envía el Evento “Salir” Interface Usuario.
Página 62
9.2. Diagrama de Clases de su proyecto de Investigación

9.2.2 Principal
9.2.3 Dominio
9.2.4 Registro
9.2.5 Servicios
Página 63
Capítulo 10: Modelo de Pruebas
10.1. Definición de Conceptos de su proyecto de Investigación
 Una Falla (Failure) esta ocurre cuando un programa no corre bien y no se comporta de
manera adecuada. la falla es una propiedad estadística de un sistema de ejecución.
 Un error es una acción humana que provoca que un software contenga una falta. Un error
puede significar la existencia de una falta en el programa, lo cual hace que el sistema falle.
 Una falta (fault) tiene en el código del programa. La existencia de una falta en el programa
puede ocasionar una falla en el sistema.
Con lo anterior se puede decir que no se puede garantizar un sistema falle, solo se puede demostrar que
contiene faltas.
10.2. Tipos de Pruebas de su proyecto de Investigación
Los tipos de pruebas se dividen en pruebas de verificación y validación.
El de verificación se revisa el resultado de especificación del sistema y el de validación lo realiza el

cliente donde verifica la funcionalidad del sistema y da su aceptación.
Existen diferentes técnicas y niveles de pruebas que se pueden aplicar.
10.2.1 Técnicas de Pruebas
 Prueba de Regresión: Basándonos en el ciclo PHVA (Planificar, Hacer, Verificar y Actuar).
Podemos observar si un cambio determinado en el sistema, altero el proceso del mismo, así
mismo siempre se busca una mejora continua de la aplicación, pues se organiza todo, se realizan
los cambios, y se controlan para ver cómo funcionan.
Página 64
 Pruebas de Operación: Al realizar pruebas de ejecución al aplicativo durante horas continuas,
podríamos ver si muestra fallos, o lentitud, Este tipo de prueba mide la confiabilidad de un
sistema.
 Prueba de Escala Completa: cuando declaramos los campos de tipos Char, en su mayoría
evitamos que se generen errores al ingresar caracteres especiales, sin embargo, se crearon
excepciones que emiten un mensaje de alerta informando que se han ingresado datos incorrectos.
Se realiza la prueba de estrés donde se lleva al límite extremo al sistemapa verificar su nivel de
tolerancia
 Prueba de Rendimiento: este se basa en la capacidad de respuesta de la aplicación, este lo
controlamos, mediante equipos de hardware que se han especificado en los requerimientos no
Funcionales, del sistema, pues gracias a esto, se garantiza un mejor funcionamiento del sistema.
 Prueba de Sobrecarga: para evitar la sobrecarga del sistema en las famosas horas pico, se
Puede implementar la programación en hilo así no se ejecuta toda la aplicación al tiempo, sino
solamente la parte que se llame a trabajar.
 Prueba Negativa: Pueden tomarse todas las precauciones posibles, pero en cualquier momento
puede fallar, para esto, Podríamos tener una réplica de la base de datos en otro servidor con el fin
que, si se llega a presentar algún problema, de servidor, el alterno tome las operaciones que se
están realizando.
Página 65
 Prueba Basada en Requisitos, o Prueba de casos De Uso: toda la aplicación es basada, en los
casos de usos, o especificaciones generales del hotel, para su sistema de reservas de habitaciones.
 Prueba Ergonómica: las diferentes interfaces de la aplicación, se Pueden Distribuir de manera
adecuada, sencilla y clara para el fácil entendimiento de los usuarios, así mismo los colores, de las
interfaces, y ubicaciones de los botones, guardan armonía y coherencia.
 Prueba de Documentación y Manuales De Usuario: se verifica, que las especificaciones del
manual tengan concordancia, con las interfaces para evitar que los usuarios confundan o no
encuentren coherencia con la aplicación.
 Prueba de Aceptación o Validación: Cuando entreguemos la primera versión, vemos si es
soportable, y si es compatible con la mayoría de equipos.
10.2.2 Nivel de pruebas
PRUEBA DE UNIDAD
 Prueba de Caja Negra: al ingresar información, si nos da una salida podemos determinar
que paso, Allí también se verifica la integridad de los datos suministrados.
 Prueba de Caja Blanca: se verifica si la lógica del programa está funcionando bien y
tomando las decisiones correctas.
 Pruebas error: si el usuario da caracteres o dígitos erróneos o Repetidos Como los Números
de Documentos dará error ejemplo: números de identificación repetidos, la salida es un
mensaje de error, avisando que se ingresaban datos erróneos, o números existentes.
Página 66
 Prueba Estructural: Son pruebas al código fuente donde ejecutamos clase por clase, para
entender el funcionamiento del código y como se comportaba con los valores ingresados. Para
la reserva de una cita se puede implementar con el fin de ver la seguridad del código para
evitar, un posible ataque al sistema, y que este afecte el funcionamiento del aplicativo.
PRUEBAS DE INTEGRACION
Las pruebas de integración Son concordancias que existen en toda la documentación del
aplicativo, se revisan los casos de uso, los diagramas de clases, de secuencias, y las tarjetas para
las clases, si todas cumplen un orden mejoran el programa.
PRUEBAS DEL SISTEMA
Estas pruebas se caracterizan por someter al sistema a un alto estrés, es decir trabajar todas las
partes del sistemas simultáneamente, pero al trabajar programación en hilos, evitamos ese
problemas, debido a que es poco probable que varios eventos, ocurran al mismo tiempo,
siempre hay segundos o milésimas de segundos que hacen la diferencia, y al tener el sistema
de filas, la primera que ingresa esa se trabaja, no se afectara el sistema.
10.3. Proceso de Pruebas de su proyecto de Investigación
10.3.1 Estrategia de prueba
 Orden de Pruebas: En nuestro proyecto nos basamos en el ciclo PHVA, debido a esto, nuestras
pruebas se basan en planificar el modelo, hacerlo, verificarlo y actuar, al trabajar de esta forma,
casi siempre estamos realizando simulaciones del sistema, para controlar los posibles errores a
temprana edad, y no cuando ya la aplicación esté funcionando, y comience a fallar.
 Alcance de Pruebas: la principal prueba está realizada en la base de datos debido a que esta es
la más delicada, si no está bien planteada con todas sus relaciones, puede afectar el
Página 67
funcionamiento del aplicativo, pues no estaría arrojando los resultados esperados al momento
de agregar un nuevo paciente, realizar una reserva, una modificación o cancelar una cita, podría
arrojar resultados erróneos o simplemente no realizarlo.

 Basada en el Modelo del dominio: la estrategia basada en el dominio la aplicamos en segundo
lugar para verificar el dominio de los datos que van a ser ingresados al sistema y las salidas del
sistema. Allí verificamos los errores que se puedan presentar y la frecuencia del uso.
10.3.2 Planeación de la Prueba
Las pruebas se realizarán semiautomáticas, debido a que usaremos simuladores, que bosquejen el
comportamiento del sistema, pero los datos ingresado al aplicativo para que realice la simulación son
datos, reales, digitados por el que realiza la prueba.
10.3.3 Construcción de la Prueba
Una vez preparada la prueba se debe describir exactamente se ejecuta cada prueba y su propósito de
manera que cada persona no familiarizada con el sistema pueda ejecutarla, cada prueba no importa su
nivel debe ser documentada y también como se debe ejecutar la prueba, en qué orden y cuál es el
resultado esperado.
10.3.4 Ejecución de la Prueba
En la ejecución de las pruebas que realizaremos mediante simuladores, se trabajara en prueba y error, se
realizan las pruebas se encuentra el error, se detiene se corrige el posible error y se vuelve a ejecutar, con
el fin de identificar el problema de raíz.
10.4. Prueba de su proyecto de investigación.
Página 68
10.4.1 Registrar usuario
Se prueban las secuencias más importantes de los casos de usos Registrar Usuario, Crear Usuario,
Actualizar usuario y eliminar usuario
Capítulo 11 Conclusiones
Este proyecto fue realizado bajo parámetros establecidos, se plasmó la información mediante, las
necesidades que se buscaban satisfacer y los resultados arrojados, fueron los plasmados en los
diseños que se trabajaron.
Todo esto se logró gracias a los conocimientos en programación obtenida a lo largo del curso
Programación Orientada a Objetos, tanto en Java como en Base De Datos.
Capítulo 12 Recomendaciones
Página 69
Capítulo 13: Referencias Bibliográficas
1. Weitzenfeld, Alfredo. Ingeniería de Software Orientada a Objetos con UML, Java e internet.
Mexico City: Cengage Learning, 2005. Gale Virtual Reference Library. "Desarrollo de Software
Orientado a Objetos." Ingeniería de Software Orientada a Objetos con UML, Java e Internet.
Alfredo Weitzenfeld. Mexico City: Cengage Learning, 2005. [193]. Gale Virtual Reference
Library. Web. 8 July 2014.
Página 70

Fase 9 Modelo de Diseño Orientado A Objetos Teórico 301403 - 33

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Fase 9 Modelo de Diseño Orientado A Objetos Teórico 301403 - 33

Diunggah oleh

Hak Cipta:

Format Tersedia

Proyecto de Investigación Curso Académico de Programación Orientada a Objetos

Proyecto de Investigación Teórico

Alby Vargas Muñoz

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

Capítulo 5 Marco Conceptual y Teórico

5.1 Introducción a Java

5.2 Programación Básica

5.3 Programación Avanzada

5.4 UML y Java

5.5 Aplicaciones y Applets

5.6 Interfaces Gráficas del Usuario

Capítulo 6 Modelo de Requisitos

6.1. Descripción del Problema

6.2. Modelo de Caso de Uso

6.3. Modelo de Interfaces

6.4. Actores y Caso de Uso

6.5. Modelo de Dominio del Problema

Capítulo 7 Modelo de Análisis

7.1. Arquitectura de Clases

7.2. Identificación de Clases según Estereotipos

7.3. Clases según Casos de Uso

7.3.5 Consultar Información

7.4. Diagramas de Secuencia

7.5. Casos de Uso para el Sistema

7.6. Diccionario de Clases

Capítulo 8 Modelo de Diseño

8.1. Estrategias de Diseño

8.2. Diseño de Objetos

8.3. Diseño de Sistema

8.3.1 Lenguajes de programación

8.4. Revisión del Diseño

8.5. Diagrama de Secuencia del Diseño

Capítulo 9: Modelo de Implementación

9.1. Programación en Java de su proyecto de Investigación

9.2. Diagrama de Clases de su proyecto de Investigación

Capítulo 10: Modelo de Pruebas

10.1. Definición de Conceptos de su proyecto de Investigación

10.2. Tipos de Pruebas de su proyecto de Investigación

10.3. Proceso de Pruebas de su proyecto de Investigación

10.4. Pruebas del Sistema de su proyecto de investigación

10.4.2 Registrar tarjeta

2.1 Objetivos Generales

Análisis, Modelado de Requisitos en la implementación y Modelado de diseño en la implementación en el

2.2 Objetivos Específicos

 Diseñar los casos de uso del sistema de reserva de habitaciones en un hotel.

3.5 Justificación Metodológica

4.3 Tipo de Metodología

Capítulo 5 Marco Conceptual y Teórico

5.1 Introducción a Java

5.2 Programación Básica

5.2.1 Aspectos generales

5.2.3 Estructuras básicas

5.3 Programación Avanzada

5.7 UML y Java

5.4.1 Objetos y clases

5.8 Aplicaciones y Applets

5.9 Interfaces Gráficas del Usuario

Aplicaciones: Se pueden ejecutar directamente en un entorno Java

Capítulo 6 Modelo de Requisitos

6.1. Descripción del Problema

El recepcionista del hotel debe poder hacer las siguientes operaciones:

 Obtener un listado de las piezas disponible de acuerdo a su tipo

El administrador puede usar el programa para: