especificaciones de diseño de software para una página de viajes

Documento de
Especificaciones de Diseño de
Software para “Skapate”

Versión 1.0

18 de noviembre del 2011

Preparado por: Asteria SA.

Realizó: Deysi Santamaría Martín.
Ericka Caceres Lopez
Adrián Rodríguez Lizama.
Gabriel Góngora Sánchez
Roger Cabrera

1

Tabla de Contenido

1. Introducción………………………………………………..... 3
1.1. Propósito del sistema
1.2. Objetivos y restricciones de diseño
1.3. Definiciones, acrónimos y abreviaturas
1.4. Referencias
1.5. Estructura del documento

2. Arquitectura del Sistema ……………………………… 16
2.1. Arquitectura lógica (descomposición en subsistemas)
2.2. Arquitectura física (topología del sistema)

3. Diseño de los subsistemas…………………………… 20
3.1. Diseño del subsistema
3.1.1. Vista de uso del subsistema
3.1.2. Vista de datos del subsistema
3.1.3. Realizaciones de Casos de Uso
3.1.3.1. Realización del caso de uso <nombre caso de uso 1>
3.1.3.1.1. Escenario del caso de uso
3.1.3.1.2. Diagrama de clase del caso de uso
3.1.3.1.3. Diagrama de secuencia detallado del caso de uso
3.1.3.1.4. Interfaz gráfica de usuario del caso de uso
3.1.3.1.5. Diagrama de navegación del caso de uso
3.1.3.2. Realización del caso de uso <nombre caso de uso 2>
3.2. Diseño del subsistema <nombre del subsistema 2>

4. Diseño de la Base de Datos ……………………………. 54
4.1. Esquema Conceptual
4.2. Esquema Implementable
4.3. Diccionario de Datos

2

1. Introducción
El propósito de este documento es poder dar una visión detallada de cómo
funcionara el sistema que se va a implementar, especificando paso a paso el
proceso de consulta y de cada privilegio que cuentan cada uno de los niveles de
usuarios involucrados. Se brindara la información necesaria y apta para poder
entender el funcionamiento del sistema y de cada una de sus partes, de igual
manera, se demostrara como se comportan las solicitudes exigidas al sistema y
de los resultados que debe generar. Se enunciaran los componentes del sistema,
la función de cada uno de estos y por medio de casos de uso de detallaran los
procesos de acceso de cada usuario.
Este documento va dirigido al Lic. Augusto Moguel quien solicito la herramienta
y será quien valore que se cumplan todos los requerimientos y también es él
quien aportara los recursos financieros para la elaboración de la página web.
De igual manera va dirigido a las agencias de viajes y los clientes que dispongan
el servicio ya que representarán a los usuarios finales del producto que por
cierto resulta de vital importancia que entiendan el funcionamiento del proceso
ya que estos serán los principales usuarios del sistema.

La estructura general de composición de esta herramienta constará de una
página web en php con módulos y ventanas interactivas y botones, almacenada
en un hosting, enlazada a una base datos SQL alojada en un servidor bajo
Windows Server 2008 perteneciente a la empresa y administrada por el hosting.

Propósito del sistema

La página web a crear será un sistema de información y captura que tendrá
como propósito fundamental brindarle al cliente toda la información necesaria
para poder adquirir en el instante, cualquiera de los servicios de hotelería
disponibles y como propósito secundario, nos permitirá una centrada
administración de las ventas, generación de comisiones y control de publicidad.
El subsistema de igual manera generará información para la administración de
la ocupación del hotel, sobre la disponibilidad y paquetes utilizados. Entre los
procesos que el subsistema realiza están:
El registro de una reserva realizada por un cliente o agencia intermediaria.
La asignación de reservas a las agencias para la construcción de sus paquetes.
Sugerencia de otros paquetes u hoteles cuando no haya disponibilidad.
La cancelación o modificación de reservas o paquetes con previo registro.
El pago de algún servicio en el instante de reserva, vía internet (tarjeta de
crédito). Calculo de comisiones por ventas de reservas para las agencias.
Entre otra especificadas en este documento.
Sin embargo es necesario que para generar estos procesos el sistema tenga
información de entrada, la que deberá ser:
Información personal de los clientes. Los datos específicos de las reservas, estas
contenidas al llenar un formulario. La información adicional de promociones
por parte de las agencias.
Y como salida el subsistema proporciona la siguiente información:
El mensaje de confirmación de una reserva
La factura o recibo de consumo de un cliente La comisión por penalización de
una reserva no cancelada

3

Información estadística de reservas tomadas, modificadas, canceladas y
caducadas.”


El diseño en general deberá cumplir con el objetivo ya mencionado con
anterioridad, el cual es crear una página web que englobe todos los servicios de
hotelería y administre todos los paquetes y promociones existentes y así tener
un mejor control de las transacciones que se realicen. Podrán entrar a la página
web y verificar ofertas y disponibilidades y desde luego realizar reservaciones,
esto para los clientes finales.
Además el sistema reducirá costos en las ventas al mismo tiempo que genera
comisiones, creara una cartera de clientes ampliando el mercado meta y
simplificar el acceso a los servicios que se brindan.

Sin embargo es necesario contar con requerimientos específicos para su
implantación, como podemos mencionar:
La empresa necesitará crear un dominio, un hosting donde se albergara la
página web, un servidor donde se almacenara la base de datos y por ultimo una
certificado de seguridad SSL (El cual el trámite se encargara posteriormente la
empresa ya que no lo incluye el proyecto.) para poder realizar transacciones
monetarias y para mayor confianza por parte del cliente.

Para poder implementar esta página web no es necesario que se cuente con una
gran infraestructura. Por lo anterior se le sugiere la contratación de un tercero
quien será nuestro proveedor tanto de dominio, hosting y servicio de servidores,
esto para mayor seguridad para la empresa en cuestión de respaldos y soporte,
además de un escalamiento seguro.

Con respecto al software necesitado:

La página web será creada en PHP 4, con animaciones Macromedia Flas 8 y la
base de datos SQL Server 2008, se puede ejecutar en Sistemas Operativos
Windows y Linux, al igual que visualizado en navegador Firefox, Internet
Explorer , Opera, Safari y Chrome.

La interfaz que visualizaran los usuarios finales contara de lo siguiente.

Ventanas (Cuenta, Reportes, Inscripciones, avisos)
Botones (guardar, borrar, cancelar, cerrar, reservar, comprar)

Textos descriptivos
Barras de desplazamiento

Menús Interactivos
Cuadros de alerta al realizar alguna selección
Imágenes
Checkbox

4

De igual manera especificamos que la base de datos SQL server podrá
encontrarse como alternativa en un servidor propio de la empresa para
seguridad e integridad de la información.

Con respecto a los requerimientos de hardware.:

El servidor donde estará almacenada la información será proporcionada por el
cliente, y debe cumplir con los siguientes requisitos mínimos:
1. GB de Memoria Ram
2. Disco duro de 250 GB
3. Lector Cd-DVD


Iconix.- Es una metodología de desarrollo de software que es anterior tanto en
el Rational Unified Process (RUP).
A diferencia de los enfoques XP y Agile, Iconix proporciona requisito suficiente
y documentación de diseño, pero sin parálisis por análisis. El proceso de Iconix
utiliza sólo cuatro diagramas UML basada en un proceso de cuatro pasos que
convierte el texto de casos de uso en el código de trabajo.

Una distinción fundamental de Iconix es el uso de análisis de robustez, un
método para cerrar la brecha entre el análisis y el diseño. Análisis de robustez
reduce la ambigüedad de las descripciones de casos de uso, asegurando que
todo está escrito en el contexto de un modelo de dominio que acompaña. Este
proceso hace que los casos de uso mucho más fácil de diseñar, evaluar y estimar.

En esencia, el proceso de Iconix describe el núcleo de "lógico" proceso de
análisis y modelado de diseño. Sin embargo, el proceso puede ser utilizado sin
mucha adaptación en proyectos que siguen la gestión de proyectos diferentes.

Diagrama.- Un diagrama o gráfico es un tipo de esquema de información que
representa datos numéricos tabulados.
Diagrama de actividades.- En el Lenguaje de Modelado Unificado, un
diagrama de actividades representa los flujos de trabajo paso a paso de negocio
y operacionales de los componentes en un sistema al igual que muestra el flujo
de control general este demuestra la serie de actividades que deben ser

5

realizadas en un uso-caso, así como las distintas rutas que pueden irse
desencadenando en el uso-caso.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos
en una aplicación a través del tiempo y se modela para cada caso de uso.
Caso de uso.- En el contexto de ingeniería del software, un caso de uso es una
secuencia de interacciones que se desarrollarán entre un sistema y sus actores
en respuesta a un evento que inicia un actor principal sobre el propio sistema.
Los diagramas de casos de uso sirven para especificar la comunicación y el
comportamiento de un sistema mediante su interacción con los usuarios y/u
otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los
actores y los casos de uso en un sistema.
Relacion.- Una relación es una conexión entre los elementos del modelo, por
ejemplo la especialización y la generalización son relaciones. Los diagramas de
casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar
cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Tipos de relaciones

 ``comunica (<<communicates>>): Relación (asociación) entre un actor
y un caso de uso que denota la participación del actor en dicho caso de
uso.
 ``usa ( <<uses>>) (o <<include>> en la nueva versión de UML):
Relación de dependencia entre dos casos de uso que denota la inclusión
del comportamiento de un escenario en otro.
 ``extiende (<< extends>>): Relación de dependencia entre dos casos de
uso que denota que un caso de uso es una especialización de otro. Por
ejemplo, podría tenerse un caso de uso que extienda la forma de pedir
azúcar, para que permita escoger el tipo de azúcar (normal, dietético o
moreno) y además la cantidad en las unidades adecuadas (cucharadas o
bolsas). Un posible diagrama se muestra en la figura

Diagrama de estado.- Los diagramas de estado muestran el conjunto de
estados por los cuales pasa un objeto durante su vida en una aplicación en
respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o

6

errores), junto con sus respuestas y acciones. También ilustran qué eventos
pueden cambiar el estado de los objetos de la clase. Normalmente contienen:
estados y transiciones. Como los estados y las transiciones incluyen, a su vez,
eventos, acciones y actividades, vamos a ver primero sus definiciones.

RUTA .- Una ruta es una secuencia de segmentos de recta o de curva que se
unen en sus puntos finales. Conceptualmente una ruta es una sola entidad
topológica, aunque sus segmentos se pueden manipular gráficamente. un
segemento no debería existir separado de su ruta. Las rutas siempre van
conectdas en ambos extremos.

UML.- es un lenguaje para hacer modelos y es independiente de los métodos de
análisis y diseño. Existen diferencias importantes entre un método y un lenguaje
de modelado. Un método es una manera explícita de estructurar el pensamiento
y las acciones de cada individuo. Además, el método le dice al usuario qué hacer,
cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de
modelado carece de estas instrucciones. Los métodos contienen modelos y esos
modelos son utilizados para describir algo y comunicar los resultados del uso
del método.
Diagrama de objetos.- Los diagramas de objetos son utilizados durante el
proceso de Análisis y Diseño de los sistemas informáticos en la metodología
UML.
Objeto.- es una entidad discreta con límites bien definidos y con identidad, es
una unidad atómica que encapsula estado y comportamiento.

Identificador de objeto (OID) .-es un identificador utilizado para nombrar un
objeto (compare URN). Estructuralmente, un OID consiste en un nodo en un
espacio de nombres jerárquico asignado. Los sucesivos números de los nodos, a
partir de la raíz del árbol, identificar a cada nodo de la árbol. Los diseñadores
crear nuevos nodos mediante el registro bajo la autoridad de registro del nodo.

7

Estado en un objeto:

El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el
comportamiento agrupa las competencias de un objeto y describe las acciones y
reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un
estímulo externo representado como mensaje enviado desde otro objeto.

Persistencia en un objeto.- La persistencia de los objetos designa la capacidad
de un

objeto trascender en el espacio/tiempo, podremos después reconstruirlo, es
decir, cogerlo de memoria secundaria para utilizarlo en la ejecución
(materialización del objeto). Los lenguajes no proponen soporte adecuado para
la persistencia, la cual debería ser transparente, un objeto existe desde su
creación hasta que se destruya.

Comunicación en un objeto.- Un sistema informático puede verse como un
conjunto de objetos autónomos y concurrentes que trabajan de manera
coordinada en la consecución de un fin específico. El comportamiento global se
basa pues en la comunicación entre los objetos que la componen.

Mensaje en un objeto.- El mensaje es el soporte de una comunicación que
vincula dinámicamente los objetos que fueron separados previamente en el
proceso de descomposición.
Diagrama de clases.- El Diagrama de Clases es el diagrama principal para el
análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus
relaciones estructurales y de herencia. La definición de clase incluye
definiciones para atributos y operaciones.

Agregación.- La agregación representa una relación parte de entre objetos. En
UML se proporciona una escasa caracterización de la agregación.

8

Transición simple.- Una transición simple es una relación entre dos estados
que indica que un objeto en el primer estado puede entrar al segundo estado y
ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones
son satisfechas.

Transición interna.- Es una transición que permanece en el mismo estado,
en vez de involucrar dos estados distintos. Representa un evento que no causa
cambio de estado.

Acciones.- Podemos especificar la solicitud de un servicio a otro objeto como
consecuencia de la transición.

Subestados.- Un estado puede descomponerse en subestados, con transiciones
entre ellos y conexiones al nivel superior.

Transacción Compleja.- Una transición compleja relaciona tres o más
estados en una transición de múltiples fuentes y/o múltiples destinos.

Transición a estados anidados.- Una transición de hacia un estado
complejo (descrito mediante estados anidados) significa la entrada al estado
inicial del subdiagrama.

Diagrama de interacción.- La vista de interacción describe secuencias de
intercambios de mensajes entre los roles que implementan el comportamiento
de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de
un objeto, que desempeña un determinado papel dentro de una interacción,
distinto de los otros objetos de la misma clase.

Colaboración.- Es una descripción de una colección de objetos que
interactúan para implementar un cierto comportamiento dentro de un contexto.

9

Interacción.- Es el conjunto de mensajes intercambiados por los roles de
clasificador a través de los roles de asociación. Un mensaje es una comunicaión
unidireccional entre dos objetos,

Patron.- Un patrón es una colaboración parametrizada, junto con las pautas
sobre cuándo utilizarlo. Un parámetro se puede sustituir por diversos valores,
para producir distintas colaboraciones.

Diagramas de despliegue.- Los Diagramas de Despliegue muestran la
disposición física de los distintos nodos que componen un sistema y el reparto
de los componentes sobre dichos nodos.

Diagrama de componentes.- Los diagramas de componentes describen los
elementos físicos del sistema y sus relaciones. Muestran las opciones de
realización incluyendo código fuente, binario y ejecutable.

Componente.- Es una parte física reemplazable de un sistema que empaqueta
su implementación y es conforme a un conjunto de interfaces a las que
proporciona su realización.

Componente del código.- Un componente contiene el código para las clases
de implementación y otros elementos. Un componente de código fuente es un
paquete para el código fuente de las clases de implementación.

Componente de identidad.- Un componente de identidad tiene identidad y
estado. Posee los objetos físicos que están situados en él. Puede tener atributos,
relaciones de composición con los objetos poseídos, y asociaciones con otros
componentes.

Componente de estructura.- Ofrece un conjunto de elementos de
implementación, esto significa que el componente proporciona el código para
los elementos.

Paquete.- Un paquete es una parte de un modelo. Cada parte del modelo debe
pertenecer a un paquete. Pero para ser funcional, la asignación debe seguir un
cierto principio racional, tal como funcionalidad común, implementación
relacionada y punto de vista común.

10

1.3. Referencias

Para realizar este proyecto nos basamos en las especificaciones que nos dio el
Lic. Augusto Moguel en las entrevistas que tuvimos con el.

En las citas el Lic. Moguel nos explicó las necesidades que buscaba satisfacer y
el presupuesto con el que contaba para el proyecto también nos expreso que
quiere una visión muy detallada de cómo le gustaría que trabajara el sistema.

En entrevista con el nos expreso que necesita que necesita que el documento
brinde información necesaria y apta para poder entender el funcionamiento del
sistema. De igual manera, nos pidió que se demostrara cómo se comportan las
solicitudes exigidas al sistema y de los resultados que debe generar.

Nos basamos también en la referencia de que la página web a crear será un
sistema de información y captura que tendrá como propósito fundamental
brindarle al cliente toda la información necesaria para poder adquirir en el
instante, cualquiera de los servicios de hotelería disponibles y como propósito
secundario, nos permitirá una centrada administración de las ventas,
generación de comisiones y control de publicidad.
Todo esto lo tomamos como referencia para poder elaborar el proyecto en si.

11


1.1. Propósito del sistema
A continuación en esta parte hablaremos de cuál fue el propósito principal
de construir el sistema.


Aquí hablaremos de cuáles son los objetivos y cuáles son las restricciones del
diseño a emplear para el desarrollo de la web.

En esta parte nos enfocamos a explicar las definiciones, acrónimos y
abreviaturas que se encuentran en el documento con el fin de que todo el
documento quede completamente entendido.

1.4. Referencias
Aquí hablaremos de las referencias que tomamos en cuenta para poder
desarrollar el proyecto.

Es explicar brevemente de que se trata cada punto de los cuales tocaremos
en este tema.

2. Arquitectura del Sistema
La arquitectura del sistema se refiere de cómo va a ser el diseño lógico y
físico que

En esta parte hablaremos de del conjunto de patrones y abstracciones
coherentes que proporcionan en el marco.

12

En esta parte de cómo está físicamente la página si esta tiene botones, de
cómo lo ve físicamente el usuario.

3. Diseño de los subsistemas
En esta parte hablaremos de todas y cada una de los subsistemas desde sus
vista, las realizaciones, escenario, diagrama, interfaz grafica, diagrama de
navegación del de caso de uso.

En esta parte hablaremos del diseño de nuestro proceso y como esta
dividido ya que es muy grande como por ejemplo:
Usuario reserva hotel
Las agencias se inscriben
Los Hoteles registran en la página
Usuario compra paquete
Hotel arma sus paquetes
Agencia se pone en contacto con los hoteles
etc.

3.1.1. Vista de uso del subsistema
Aquí se hablara de cómo se va a ver al publico físicamente todos y cada uno
de los subsistemas.

3.1.2. Vista de datos del subsistema
Aquí se hablara de cómo se van a relacionar los datos por ejemplo a las
reservaciones de qué manera se van a relacionar con los hoteles.

3.1.3.1.1. Escenario del caso de uso
Aquí se mostraran los diferentes escenarios en donde se lleva a cabo los
procesos.

13

3.1.3.1.2. Diagrama de clase de caso de uso
Aquí se hablara de como se describen los procesos que antes
mencionamos en los casos de uso ya que depende de la clase de uso el
tipo de diagrama que se usara.

3.1.3.1.3. Diagrama de secuencia detallado del caso de uso
En esta parte se hablara de él diagrama de secuencia que se refiere a la
secuencia lógica de cómo se va a llevar a cabo el proceso de cada caso
de uso.

3.1.3.1.4. Interfaz gráfica de usuario del caso de uso
Se mostrara la interfaz grafica tal y como la vera el usuario
físicamente.
3.1.3.1.5. Diagrama de navegación del caso de uso
En esta parte mostraremos como va a navegar el usuario hacia donde
lo va direccionar que va a ser , y como se va a mover en la página web.

3.1.3.2. Realización del caso de uso
En esta parte se hablara de cómo se va a realizar cada proceso.

4. Diseño de la Base de Datos
En esta parte hablaremos del diseño que se le dará a la base de datos que
pertenecen a un mismo contexto y que están almacenados sistemáticamente
para su posterior uso.

En esta parte nos enfocaremos a hablar sobre la representación gráfica o
simbólica de los conceptos.
En esta parte se busco un esquema que pudiera incorporarse a los
estándares que el cliente pidió tomando en cuenta cada uno de los
requisitos que el mismo pidió para la pagina lo que es desde que hoteles
forman parte, tipos de paquete de viaje, agencias, reservaciones,
reportes, etc. Todo esto para poder implementar el sistema.

14

4.3 Diccionario de Datos

En esta parte hablaremos de el conjunto de metadoatos que contiene las
características lógicas y puntuales de los datos que se van a utilizar en el sistema
que se está programando.

15

2. Arquitectura del Sistema


El Sistema está conformado por los siguientes componentes:

 Administración de usuarios.
Este componente se encarga de la administración de las cuentas de los
usuarios , editar, borrar, agregar.
 Avisos
Este componente se encarga de los avisos sobre cambios de políticas,
promociones o estado de la cuenta del usuario como lo es el aviso un mes
anterior al vencimiento de la membresía.
 Aplicaciones de comunicaciones
Este componente se utilizara las tecnologías de correo electrónico y
mensajería instantánea.
 Formularios
Este componente se integra de los formularios inherente a como los
datos de la empresas dirección, acta constitutiva.

 Buscador
Este componente se encargara de búsquedas como lo es datos de
empresas, paquetes, promociones, datos financieros.
 Catálogos de productos y servicios

16

Este componente se encargara de en listar los distintos productos y
servicios ofrecidos por las agencias y hoteles.
 Aplicación de Pagos
Este componente es externo proveniente de paypal para las transacciones
bancarias
 Catalogo multimedia.
Este componente contendrá la información en listada multimedia
generada por las empresas como lo son videos, imágenes y audio.
 Multimedia
En este componente tendrá almacenada contendrá la información en
listada multimedia generada por las empresas como lo son videos,
imágenes y audio
 Realizar reportes
Este componente realizara reportes financieros como los son estado de
cuenta, ingresos, ventas, descuentos o información de la cuenta de los
clientes.
 FAQ
Este componente contendrá los manuales, guías y ayudas para el usuario
 Control de estadísticas.
Este componente se encargara de control sobre las estadísticas generadas
al día a día del funcionamiento normal de la página.
 Encuestas
Este componente generara encuestas para medir la calidad del servicio y
opinión de los clientes para la mejora continua
 Copias de seguridad
Este componente se encargara de los respaldo de la información genera
durante el funcionamiento normal de la página web.
 Control de Acceso
Este componente se encargara del control de acceso no autorizado a las
cuentas, información privada de la empresa.
 Base de datos
Este componente se encargara del almacenaje de toda la información de
los hoteles, agencias de viaje y clientes.

17

Este es el Diagrama de 3 Capas de la página web “Skapate”

18


Este diagrama describe como los usuarios a través de sus ordenadores acceden a
la página web www.skapate.com a través del servidor web Apache y el servidor
de base de SQL Server 2008

19

3. Diseño de los subsistemas


A continuación describiremos cada uno de los subsistemas que se presentaron
en el diagrama de
paquetes en la sección: “arquitectura lógica del sistema”. El método para tal
descripción es una
descripción de la funcionalidad del sistema mediante la vista de casos de usos,
una descripción
del modelo de datos que soporta, mostrados mediante una vista de datos y la
inclusión de una serie de elementos de modelado que describen como los casos
de
uso del sistema pueden ser Realizados.
quedando la estructura de la siguiente forma:
I. vista de uso del subsistema. Esta vista muestra la funcionalidad del
sistema como es
percibida por los usuarios
finales, analista y encargados de las pruebas
por medio de diagramas de paquetes.
II. Realizaciones de Casos de Uso. En esta sección se detalla como cada uno
de los casos de
uso que pertenecen a este subsistema. Mediante:
escenarios de casos de uso.
Diagrama de clases.
diagrama de secuencia del caso de uso.

1 diseño del subsistema “reservaciones”.
1.1. vista de uso del subsistema “reservaciones”.

20

Diagrama de paquetes del caso de uso reservaciones.
Para que el cliente realice una reservación tiene que visitar primero la página,
entrar al catálogo de
productos y servicios y posteriormente realizar el pago mediante el subsistema
de pagos lo cual
genera un aviso del sistema a la agencia y al cliente.

Diseño de los subsistemas.

A continuación describiremos cada uno de los subsistemas que se presentaron en el
diagrama de paquetes en la sección: “arquitectura lógica del sistema”. El método para
tal descripción es una descripción de la funcionalidad del sistema mediante la vista de
casos de usos, una descripción
del modelo de datos que soporta, mostrados mediante una vista de datos y la
inclusión de una serie de elementos de modelado que describen como los casos de
uso del sistema pueden ser Realizados.

Quedando la estructura de la siguiente forma:

I. vista de uso del subsistema. Esta vista muestra la funcionalidad del sistema
como es percibida por los usuarios
finales, analista y encargados de las pruebas
por medio de diagramas de paquetes.

II. Realizaciones de Casos de Uso. En esta sección se detalla como cada uno
de los casos de uso que pertenecen a este subsistema. Mediante:
 escenarios de casos de uso.
 Diagrama de clases.
 diagrama de secuencia del caso de uso.

21

1 diseño del subsistema “reservaciones”.
1.1. vista de uso del subsistema “reservaciones”.

Diagrama de paquetes del caso de uso reservaciones.

Para que el cliente realice una reservación tiene que visitar primero la página,
entrar al catálogo de productos y servicios y posteriormente realizar el pago
mediante el subsistema de pagos lo cual genera un aviso del sistema a la agencia
y al cliente.

22

1.2 escenario de casos de uso reservaciones.
Caso de uso: reservaciones.
Actores: Cliente, hotel, agencia.
Descripción: Para que el cliente realice una reservación tiene que visitar primero la
página, entrar al catálogo de productos y servicios, hacer clic en
“reservar ahora” y posteriormente realizar el pago mediante el
subsistema de pagos PAYPAL.
Precondición: 1. El clientes está visitando la página.
2. La agencia ha anunciado su paquete.
Flujo normal: 1. el cliente hace clic en “reservar ahora” {flujo alterno A, “el
paquete de viaje no esta disponible”}.
2. El sistema le pide llenar el formulario con sus datos para futuro
contacto de la agencia.
3. El sistema le lleva a la página de paypal.
4. El cliente realiza el pago de la reservación.
Flujo alterno: Flujo alterno A, “el paquete de viaje no esta disponible”.

1. El cliente hace clic en reservar.
2. El sistema verifica que no hay disponibilidad.
3. El sistema le avisa que no hay cupo al cliente.
Postcondición: El cliente ha realizado una reservación.

23

1.3 Diagrama de clase del caso de uso reservaciones.

24

1.4 diagrama de secuencias del caso de uso reservaciones.

25

2 diseño del subsistema “reportes”.
2.1. vista de uso del subsistema reportes.

Diagrama de paquetes del caso de uso reportes.

El subsistema “reportes” requiere la información de los accesos a la página, los
registros de los datos de los usuarios de la página, el catálogo de productos y
servicios y de las estadísticas

26

2.2. escenario de caso de uso de reportes.

Caso de uso: reportes.
Actores: Administrador.
Descripción: El administrador genera reportes.
Precondición: 1. El administrador a ingresado al sistema.
Flujo normal: 1. Hacer clic en “elaborar de reportes”.
2. Seleccionar el tipo de reporte que desea hacer. {flujo alterno A, “el
Administrador desea realizar un reporte de ingresos}, {flujo alterno B,
“el administrador desea realizar un reporte de las agencias”}, {flujo
alterno C, “el administrador desea realizar un reporte de los hoteles”}.
3. Seleccionar “descargar” o “ver” para visualizar el archivo sin
descargarlo.

Flujo alterno: Flujo alterno A, “El administrador desea realizar un reporte de
ingresos”
1. hacer clic en el botón “reporte de ingresos”.
2. El sistema le preguntará si desea descargar el archivo o verlo.
3. Continuar con el punto 3 del flujo normal.

Flujo alterno B, “El administrador desea realizar un reporte de las
agencias”.
1. hacer clic en el botón “agencias”.

Flujo alterno C, “El administrador desea realizar un reporte de los
hoteles”.
4. hacer clic en el botón “hoteles”.

Postcondición: El administrador ha generado un reporte.

27

2.3 Diagrama de clase del caso de uso reportes.

28

2.4 diagrama de secuencias del caso de uso reportes.

29

3 diseño del subsistema “administración”.

3.1. vista de uso del subsistema administración.
Diagrama de paquetes para el caso de uso de administración.

La administración de las cuenta incluye las cuentas de las agencias, hoteles e
incluso las del propio administrador de la página.

30

3.2 realización del caso de uso de administración.
CASO DE USO DAR DE ALTA.

ACTOR Administrador

DESCRIPCIÓN El administrador del sistema da de alta a una agencia o a un hotel para
que puedan publicitar sus servicios en la página.
PRECONDICIÓN 1. la agencia o el hotel ha pagado su membresía.
2. El administrador ha verificado la veracidad de la información
suministrada por los suscriptores.
3. El administrador ha verificado el pago de la membresía.
4. El administrador ha ingresado al sistema.
FLUJO NORMAL 1. Hacer clic en “dar de alta a usuarios”.
2. El sistema le mostrará la ventana “dar de alta”.
3. seleccionar “hotel” o “agencia” según sea el caso.
4. Ingresar el nombre del usuario (agencia u hotel).
5. Ingresar el nombre del representante legal del usuario.
6. Indicar el nombre de la persona que utilizará la pagina a
nombre de la agencia o del hotel.
7. Indicar la dirección legal del hotel o de la agencia.
8. Indicar la ubicación del negocio.
9. Indicar el e-mail del usuario.
10. Indicar la vigencia de la cuenta.
11. Hacer clic en el botón “generar contraseña”. Al hacer clic en este
botón se genera una contraseña aleatoria la cual será cambiada
al ingresar por primera vez el usuario y se guardará la
información.
12. El sistema le mostrará la ventana “avisar al usuario”.
13. Leer la información en el mensaje. Si lo desea puede cambiarla.
14. Hacer clic en enviar.
15. El sistema enviará el mensaje y le regresará a la ventana
“administración”.

FLUJOS No hay flujo alterno.
ALTERNOS
POSTCONDICIÓ El administrador ha dado de alta a una agencia o un hotel.
N
CASO DE USO MODIFICAR CUENTA DE USUARIO.
ACTOR Administrador.

31

DESCRIPCIÓN El administrador del sistema modifica una cuenta de una agencia o de
un hotel ya sea para darla de baja, desbloquearla o simplemente
cambiar datos.
PRECONDICIÓN 1. el administrador a ingresado al sistema.
FLUJO NORMAL 1. Hacer clic en “modificar cuentas de usuario”.
2. El sistema le mostrará la ventana para “modificar las cuentas
de usuario”.
3. Seleccionar si el usuario es una agencia o un hotel.
4. Escoger en la lista emergente al usuario. Esta lista esta
ordenada alfabéticamente.
5. El sistema le mostrará la ventana con las “opciones para
modificar”.
6. Hacer clic en el botón de la opción deseada. {flujo alterno A,
“Dar de baja a un usuario”}, {flujo alterno B, “bloquear
cuenta”}, {flujo alterno C, “desbloquear cuenta”}, {flujo alterno
D, “editar datos”}.
7. Después de editar la cuenta el sistema le regresa a la ventana
“modificar cuentas de usuario”.

32

FLUJOS Flujo alterno A, “dar de baja a un usuario”.
ALTERNOS
1. Hacer clic en el botón “dar de baja”.
2. El sistema le avisará que se perderá toda la información del
usuario y si desea conservar la información es mejor bloquear
la cuenta.
3. Hacer clic en “aceptar” para eliminar o “cancelar” para no dar
de baja a un usuario.
4. El sistema le regresará a la ventana para modificar las cuentas
del usuario.

Flujo alterno B, “bloquear cuenta”.
1. hacer clic en “bloquear cuenta”.
2. El sistema le avisará que al bloquear la cuenta no esta
eliminando los datos del usuario y que podrá desbloquearla
cuando quiera.
3. Hacer clic en “aceptar” para bloquear o “cancelar” para no
bloquear la cuenta.
del usuario.

Flujo alterno C, “desbloquear cuenta”.
1. hacer clic en “desbloquear cuenta”.
2. El sistema le avisará que está por desbloquear la cuenta y el
usuario podrá nuevamente ingresar al sistema.
3. Hacer clic en “aceptar” para bloquear o “cancelar” para no
bloquear la cuenta.
del usuario.

Flujo alterno D, “editar datos”.
1. hacer clic en “editar datos”.
2. El sistema le mostrará la ventana “editar datos”.
3. Modificar la información del usuario. {flujo alterno E, “cambiar
la contraseña y/o nombre del usuario”.}
4. Hacer clic en “guardar”.
del usuario.

Flujo alterno E, “cambiar la contraseña y/o nombre del usuario”.
33 1. Si lo desea cambie el nombre del usuario.
2. Si desea cambiar la contraseña de clic en “generar contraseña”.
3. En ambos casos el sistema le mostrará la ventana “avisar al

5. Hacer clic en enviar.
6. El sistema enviará el mensaje y le regresará a la ventana para
modificar las cuentas de usuario.
POSTCONDICIÓN El administrador ha modificado una cuenta de un usuario.

34

3.3 Diagrama de clase del caso de uso administración.

35

3.4 diagrama de secuencias del caso de uso de administración.

36

4 diseño del subsistema “pagos”.

4.1. vista de uso del subsistema de pagos.

37

4.2 escenario de casos de uso de pagos.

CASO DE USO EL HOTEL PAGA SU MEMBRESÍA.

ACTOR Hotel.

DESCRIPCIÓN El hotel paga su membresía para que el administrador pueda darle de
alta en el sistema. Dependiendo del tipo de pago será membresía
anual o semestral.
PRECONDICIÓN 1. El hotel se ha registrado.
2. El hotel ha recibido el aviso del administrador de la página que
ya puede pagar su membresía.
3. el hotel navega a la página en internet www.eskapate.com

FLUJO NORMAL 1. hacer clic en el botón “paypal”.
2. El sistema abrirá la ventana para realizar pagos.
3. seguir las indicaciones.
4. realizar el pago en linea.

FLUJOS No hay flujos alternos.
ALTERNOS
POSTCONDICIÓ El hotel ha realizado el pago de su membresía.
N

38

CASO DE USO LA AGENCIA PAGA SU MEMBRESÍA.

ACTOR Agencia.

DESCRIPCIÓN La agencia paga su membresía para que el administrador pueda
darle de alta en el sistema.
PRECONDICIÓN 1. la agencia se ha registrado.
2. La agencia ha recibido el aviso del administrador de la página
que 3. ya puede pagar su membresía.
4. El hotel navega a la página en internet www.eskapate.com

FLUJO NORMAL 1. hacer clic en el botón “paypal”.
2. El sistema abrirá la ventana para realizar pagos.
3. seguir las indicaciones.
4. realizar el pago en linea.

FLUJOS ALTERNOS No hay flujos alternos.

POSTCONDICIÓN La agencia ha realizado el pago de su membresía.

39

4.3 Diagrama de clase del caso de uso pagos.

40

4.4 diagrama de secuencias del caso de uso pagos.

41

5 diseño del subsistema “comunicaciones”.

5.1.vista de uso del subsistema comunicaciones.

44

5.2 escenario de casos de uso comunicaciones.

CASO DE USO CONSULTAR A AGENCIA.

ACTOR Cliente.

DESCRIPCIÓN El cliente utiliza el sistema para realizar una consulta a una agencia
en la cual esta interesado en uno de sus paquetes de viajes.
PRECONDICIÓN 1. El cliente esta visitando la página.
2. El cliente esta visualizando la publicidad de algún destino.
FLUJO NORMAL 1. El cliente da clic en “consultar a la agencia”.
2. El sistema abrirá la ventana con el formulario para consultar a
la agencia.
3. El cliente ingresa sus datos para que la agencia pueda
contactarle.
4. El cliente llena el cuadro de texto con la cuestión
correspondiente.
5. Hacer clic en el botón “enviar”.
6. El sistema le regresa a la publicidad que el cliente estaba
visualizando.

FLUJOS No hay flujo alterno.
ALTERNOS
POSTCONDICIÓ El Cliente ha realizado una consulta a una agencia sobre algún
N paquete.

45

CASO DE USO RESPONDER A CLIENTES.

ACTOR agencia

DESCRIPCIÓN La agencia responde una consulta realizada por un clientes sobre
las características de sus paquetes o cualquier tema relativo.
PRECONDICIÓN 1. La agencia se encuentra dada de alta por el Administrador.
2. la agencia ha accesado a la pagina.
FLUJO NORMAL 1. Hacer clic en “consultas”.
2. El sistema le mostrará el buzón de consultas recibidas.
3. Leer la consulta realizada por el cliente.{flujo alterno A, “la
agencia no desea responder la consulta en este momento”.
4. Dar clic en “responder”.
5. El sistema le mostrará el formato para responder consultas.
6. Responder la consulta.
7. Dar clic en enviar.
8. El sistema le regresará al buzón de consultas recibidas.

FLUJOS ALTERNOS 1. Flujo alterno A, “La agencia no desea responder la consulta en
este momento”.
2. dar clic “en regresar”.
3. El sistema le regresará al punto 2 del flujo normal.

POSTCONDICIÓN La agencia ha respondido a una consulta de un cliente.

46

5.3 Diagrama de clase del caso de uso comunicaciones.

47

5.4 diagrama de secuencias del caso de uso comunicaciones.

48

6 diseño del subsistema “buscador”.

6.1. vista de uso del subsistema buscador.

50

6.2. escenario de casos de uso buscador.

CASO DE USO buscador

ACTOR Cliente

DESCRIPCIÓN El cliente usa la herramienta “buscador” para encontrar algún
destino, agencia de viaje u hotel.
PRECONDICIÓN 1. el cliente visita la página.

FLUJO NORMAL 1. hacer clic en el textbox del buscador.
2. Escribir la palabra deseada.
3. Dar enter.
4. El sistema le mostrará la ventana con los resultados de la
busqueda.

FLUJOS ALTERNOS No existen

POSTCONDICIÓN El cliente ha realizado una busqueda.

51

6.3. diagrama de clases del caso de uso buscador.

52

6.4. diagrama de secuencias del caso de uso buscador.

53

Diseño de la Base de Datos


Este es el modelo de conceptual del sistema de la página web “Skapate”
presentada por los diagramas de clase:
 Hotel
 Administrador
 Reporteingresos
 Reporte
 Reportehoteles
 Reporteagencias
 Consulta
 Agencia
 Paquete_viaje
 Reservación
 cliente

54


Aquí se muestra el diagrama de base datos de la pagina web “Skapate” la cual se
detalla en el siguiente apartado

55

DICCIONARIO DE DATOS

DISEÑO DE UNA BASE DE DATOS DE LA PAGINA
Empresa: SKAPATE Sistema: WEB SKAPATE

Nombre: TABLA CLIENTE Fecha: 13/Noviembre /2011

Tipo de tabla: Detalle Bytes/Fila:
Descripción:
INFORMACIÓN DEL CLIENTE

TIPO
No. T Campo Descripción Formato Reglas de
I y RELACIO Validación
P Tamaño N
o

1 P ID_CODIGO Clave referencia del X(5) M:1 Debe existir en esta tabla
cliente
2 E CLI_NOMBRE Nombre del cliente A(60) No puede ser nulo

3 E CLI_DOMICILIO Dirección cliente X(60) No puede ser nulo

4 E COL_TELEFONO Teléfono del cliente X(13) No puede ser nulo

5 E CLI_E-MAIL Cuenta de correo X(60) No puede ser nulo
electronico

Tipo: Formato:
P: Clave Primaria A: Alfabético F: Fecha
F: Clave Foránea N: Numérico Hora
E: Elemento de Dato X: Alfanumérico H: Memo
L: Lógico M: Imagen
I:
Realizado por Revisado por Aprobado por

ROGER CABRERA
ADRIÁN RODRÍGUEZ LIZAMA
DEYSI SANTAMARÍA MARTIN
GABRIEL GONOGORA
ERIKA CACERES

Fecha: Fecha: Fecha:

56



Nombre: TABLA RESERVACIÓN Fecha: 13/Noviembre /2011

Descripción:
INFORMACIÓN DE LAS RESERVACIONES

TIPO
P Tamaño N
o

1 P ID_RESERVACION Clave referencia de X M:1 Debe existir en esta tabla
la reservación
2 F ID_CLIENTE Clave de referencia X(5) No puede ser nulo
del cliente No puede ser nulo
3 E RES_FECHA Fecha de la F No puede ser nulo
reservación
4 F ID_PAQUETE_VIAJE Clave de referencia X(5) M:1 No puede ser nulo
del paquete

Tipo: Formato:
F: Clave Foránea N: Numérico H: Hora
E: Elemento de Dato X: Alfanumérico M: Memo
L: Lógico I: Imagen


ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


57



Nombre: TABLA AGENCIA Fecha: 13/Noviembre /2011

Descripción:
INFORMACIÓN DE LAS AGENCIAS

TIPO
P Tamaño N
o

1 P ID_AGENCIA
Clave referencia de X M:1 Debe existir en esta tabla
la reservación
2 E AGE_NOMBRE Nombre de la A(60) No puede ser nulo
agencia No puede ser nulo
3 E AGE_UBICACION Domicilio de la X(60) No puede ser nulo
Agencia
4 E AGE_TELEFONO Telefono de la X(14) No puede ser nulo
Agencia
5 E AGE_GERENTE Gerente de la X(60) No puede ser nulo
agencia
6 E AGE_REPRESENTA Representante legal X(60) No puede ser nulo
NTELEGAL de agencia

7 E AGE_EMPRESARIA Tipo se servicio X(20) No puede ser nulo
LPLUS Empresarial Plus

8 E AGE_E-MAIL Correo electrónico X(60) No puede ser nulo
de la agencia

Tipo: Formato:


ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


58



Nombre: TABLA PAQUETE VIAJE Fecha: 13/Noviembre /2011

Descripción:
INFORMACIÓN DE LOS PAQUETES DE VIAJE

TIPO
I y RELACIÓ Validación
P Tamaño N
o

1 P ID_PAQUETE_VIAJE Clave referencia del X(5) M:1 Debe existir en esta tabla
paquete de viaje
2 F ID_RESERVACION Clave de referencia X(5) M:1 No puede ser nulo
de reservación
3 F ID_CLIENTE Clave de referencia X(5) M:1 No puede ser nulo
del cliente
4 F ID_AGENCIA Clave de referencia X(5) M:1 No puede ser nulo
de la Agencia
5 F ID_HOTEL Clave de referencia X(5) M:1 No puede ser nulo
del hotel
6 E PAQ_DESTINO Destino del paquete X(40) No puede ser nulo
de viaje
7 E PAQ_PRECIO Precio del paquete N No puede ser nulo

Tipo: Formato:


ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


59



Nombre: TABLA HOTEL Fecha: 13/Noviembre /2011

Descripción:
INFORMACIÓN DE LOS HOTELES

TIPO
P Tamaño N
o

1 P ID_HOTEL Clave referencia del X(5) M:1 Debe existir en esta tabla
hotel
2 E HTL_NOMBRE Nombre del hotel X(60) No puede ser nulo

3 E HTL_TELEFONO Teléfono del hotel X(14) No puede ser nulo

4 E HTL_UBICACION Dirección del hotel X(5) No puede ser nulo

5 E HTL_RAZONSOCIAL Razon social del X(60) No puede ser nulo
hotel
6 E HTL_GERENTE Nombre del gerente A(60) No puede ser nulo

7 E HTL_REPRESENTA Nombre del A(60) No puede ser nulo
NTELEGAL representante legal

8 E HTL_MEMBRESIATI Tipo de membresia X(20) No puede ser nulo
PO

Tipo: Formato:


ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


60



Nombre: TABLA REPORTE Fecha: 13/Noviembre /2011

Tipo de tabla: Maestra Bytes/Fila:
Descripción:
INFORMACIÓN DE LOS HOTELES

TIPO
P Tamaño N
o

1 P ID_HOTELClave referencia del X(5) M:1 Debe existir en esta tabla
hotel
2 E ID_CONSULTA Clave de referencia X(5) M:1 No puede ser nulo
de consulta
3 E ID_REPORTEAGEN Clave de referencia X(5) M:1 No puede ser nulo
CIA de agencias
4 E M:1 No puede ser nulo
ID_REPORTEHOTE Clave de reporte de X(5)
5 E L los hoteles

6 E ID_HOTEL Clave de referencia X(5) M:1 No puede ser nulo
del hotel
7 E ID_INGRESO Clave de referencia X(5) M:1 No puede ser nulo
de ingreso
ID_AGENCIA Clave de referencia X(5) M:1 No puede ser nulo
8 E de agencia
ID_CLIENTE Clave de referencia X(5) M:1 No puede ser nulo
de cliente

Tipo: Formato:


ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


61



Nombre: TABLA CONSULTA Fecha: 13/Noviembre /2011

Tipo de tabla: Fuente Bytes/Fila:
Descripción:
INFORMACIÓN DE LAS CONSULTAS

TIPO
P Tamaño N
o

1 P ID_CONSULTA Clave de referencia X(5) M:1 Debe existir en esta tabla
de consulta
2 F ID_CLIENTE Clave de referencia X(5) M:1 No puede ser nulo
de cliente
de Agencia

Tipo: Formato:


ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


62



Nombre: TABLA REPORTE AGENCIA Fecha: 13/Noviembre /2011

Descripción:
INFORMACIÓN DE REPORTE DE AGENCIA

TIPO
P Tamaño N
o

1 P ID_REPORTEAGEN Clave de referencia X(5) M:1 Debe existir en esta tabla
CIA del reporte de la
agencia
de Agencia

Tipo: Formato:


ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


63



Nombre: TABLA REPORTE HOTEL Fecha: 13/Noviembre /2011

Descripción:
INFORMACIÓN DE REPORTE DE HOTEL

TIPO
P Tamaño N
o

1 P ID_REPORTEHOTE Clave de referencia X(5) M:1 Debe existir en esta tabla
L del reporte del hotel

2 F ID_HOTEL Clave de referencia X(5) M:1 No puede ser nulo
del hotel

Tipo: Formato:

ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


64



Nombre: TABLA REPORTE HOTEL Fecha: 13/Noviembre /2011

Descripción:
INFORMACIÓN DE REPORTE DE HOTEL

TIPO
P Tamaño N
o

1 P ID_INGRESO Clave de referencia X(5) M:1 Debe existir en esta tabla
del ingreso

2 F ING_INGRESOS Ingresos N No puede ser nulo

Tipo: Formato:

ROGER CABRERA
GABRIEL GONOGORA
ERIKA CACERES


65

especificaciones de diseño de software para una página de viajes

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à especificaciones de diseño de software para una página de viajes

Similaire à especificaciones de diseño de software para una página de viajes (20)

Dernier

Dernier (10)

especificaciones de diseño de software para una página de viajes