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

1

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

2

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

3

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

4

Información estadística de reservas tomadas, modificadas, canceladas y caducadas.” 1.1. Objetivos y restricciones de diseño 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

5

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 1.2. Definiciones, acrónimos y abreviaturas 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

http://es.wikipedia.org/wiki/UML

6

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

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software

7

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.

http://es.wikipedia.org/wiki/Inform%C3%A1tica

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

8

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.

9

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.

10

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.

11

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.

12

1.5. Estructura del documento 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.

1.2. Objetivos y restricciones de diseño

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.

1.3. Definiciones, acrónimos y abreviaturas

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.

1.5. Estructura del documento

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

2.1. Arquitectura lógica (descomposición en subsistemas)

En esta parte hablaremos de del conjunto de patrones y abstracciones

coherentes que proporcionan en el marco.

13

2.2. Arquitectura física (topología del sistema)

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.

3.1. Diseño del subsistema

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.

14

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.

4.1. Esquema Conceptual

En esta parte nos enfocaremos a hablar sobre la representación gráfica o

simbólica de los conceptos.

4.2. Esquema Implementable

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.

15

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.

16

2. Arquitectura del Sistema

2.1. Arquitectura lógica (descomposición en subsistemas) 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

17

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.

18

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

19

2.2. Arquitectura física (topología del sistema) 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

20

3. Diseño de los subsistemas 3.1. Diseño del subsistema 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”.

21

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.

22

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.

23

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.

24

1.3 Diagrama de clase del caso de uso reservaciones.

25

1.4 diagrama de secuencias del caso de uso reservaciones.

26

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

27

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.

28

2.3 Diagrama de clase del caso de uso reportes.

29

2.4 diagrama de secuencias del caso de uso reportes.

30

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.

31

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 ALTERNOS

No hay flujo alterno.

POSTCONDICIÓN

El administrador ha dado de alta a una agencia o un hotel.

CASO DE USO MODIFICAR CUENTA DE USUARIO.

ACTOR Administrador.

32


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

33


FLUJOS ALTERNOS

Flujo alterno A, “dar de baja a un usuario”.

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.


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.


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


Flujo alterno E, “cambiar la contraseña y/o nombre del usuario”.

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 usuario”.

34


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.

35

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

36

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

37

4 diseño del subsistema “pagos”.

4.1. vista de uso del subsistema de pagos.

38

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 ALTERNOS

No hay flujos alternos.

POSTCONDICIÓN

El hotel ha realizado el pago de su membresía.

http://www.eskapate.com/





39

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.






40

4.3 Diagrama de clase del caso de uso pagos.

41

4.4 diagrama de secuencias del caso de uso pagos.

44

5 diseño del subsistema “comunicaciones”.

5.1.vista de uso del subsistema comunicaciones.

45

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 ALTERNOS

No hay flujo alterno.

POSTCONDICIÓN

El Cliente ha realizado una consulta a una agencia sobre algún paquete.

46

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.

47

5.3 Diagrama de clase del caso de uso comunicaciones.

48

5.4 diagrama de secuencias del caso de uso comunicaciones.

50

6 diseño del subsistema “buscador”.

6.1. vista de uso del subsistema buscador.

51

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.

52

6.3. diagrama de clases del caso de uso buscador.

53

6.4. diagrama de secuencias del caso de uso buscador.

54

Diseño de la Base de Datos 4.1. Esquema Conceptual

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

55

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

56

DICCIONARIO DE DATOS

Empresa:

SKAPATE Sistema:

DISEÑO DE UNA BASE DE DATOS DE LA PAGINA WEB SKAPATE

Nombre: TABLA CLIENTE Fecha: 13/Noviembre /2011

Tipo de tabla: Detalle Bytes/Fila:

Descripción: INFORMACIÓN DEL CLIENTE

No.

T I

P o

Campo

Descripción

Formato y

Tamaño

TIPO

RELACIO

N

Reglas de Validación

1

2

3

4

5

P

E

E

E

E

ID_CODIGO

CLI_NOMBRE

CLI_DOMICILIO

COL_TELEFONO

CLI_E-MAIL

Clave referencia del cliente Nombre del cliente Dirección cliente Teléfono del cliente Cuenta de correo electronico

X(5) A(60) X(60) X(13) X(60)

M:1

Debe existir en esta tabla No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo

Tipo: Formato:

P: F:

E:

Clave Primaria Clave Foránea

Elemento de Dato

A: N:

X: L:

Alfabético Numérico

Alfanumérico Lógico

F:

H: M:

I:

Fecha Hora

Memo Imagen

Realizado por Revisado por Aprobado por

ROGER CABRERA

ADRIÁN RODRÍGUEZ LIZAMA DEYSI SANTAMARÍA MARTIN

GABRIEL GONOGORA ERIKA CACERES

Fecha: Fecha: Fecha:

57


Empresa:

SKAPATE Sistema:

DISEÑO DE UNA BASE DE DATOS DE LA PAGINA

WEB SKAPATE

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


Descripción: INFORMACIÓN DE LAS RESERVACIONES

No.

T I

P o

Campo

Descripción

Formato y

Tamaño

TIPO

RELACIO

N


1

2

3

4

P

F

E

F

ID_RESERVACION

ID_CLIENTE

RES_FECHA

ID_PAQUETE_VIAJE

Clave referencia de la reservación Clave de referencia del cliente Fecha de la reservación Clave de referencia del paquete

X X(5) F X(5)

M:1

M:1

Debe existir en esta tabla No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo

Tipo: Formato:

P: F:

E:


Elemento de Dato

A: N:

X:

L:


Alfanumérico

Lógico

F: H:

M:

I:

Fecha Hora

Memo

Imagen


ROGER CABRERA




58


Empresa:

SKAPATE Sistema:


Nombre: TABLA AGENCIA Fecha: 13/Noviembre /2011


Descripción: INFORMACIÓN DE LAS AGENCIAS

No.

T

I P

o

Campo

Descripción

Formato

y Tamaño

TIPO

RELACION

Reglas de

Validación

1

2

3

4

5

6

7

8

P

E

E

E

E

E

E E

ID_AGENCIA

AGE_NOMBRE

AGE_UBICACION

AGE_TELEFONO

AGE_GERENTE

AGE_REPRESENTANTELEGAL

AGE_EMPRESARIA

LPLUS

AGE_E-MAIL

Clave referencia de la reservación Nombre de la agencia Domicilio de la Agencia Telefono de la Agencia Gerente de la agencia Representante legal de agencia Tipo se servicio Empresarial Plus Correo electrónico de la agencia

X A(60) X(60) X(14) X(60) X(60) X(20) X(60)

M:1 Debe existir en esta tabla No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo

Tipo: Formato:

P:

F:

E:

Clave Primaria

Clave Foránea

Elemento de Dato

A:

N:

X: L:

Alfabético

Numérico


F:

H:

M: I:

Fecha

Hora

Memo Imagen


ROGER CABRERA ADRIÁN RODRÍGUEZ LIZAMA

DEYSI SANTAMARÍA MARTIN GABRIEL GONOGORA

ERIKA CACERES


59


Empresa:

SKAPATE Sistema:


WEB SKAPATE

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


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

No.

T I

P o

Campo

Descripción

Formato y

Tamaño

TIPO

RELACIÓ

N


1

2

3

4

5

6

7

P

F

F

F

F

E

E

ID_PAQUETE_VIAJE

ID_RESERVACION

ID_CLIENTE

ID_AGENCIA

ID_HOTEL

PAQ_DESTINO

PAQ_PRECIO

Clave referencia del paquete de viaje Clave de referencia de reservación Clave de referencia del cliente Clave de referencia de la Agencia Clave de referencia del hotel Destino del paquete de viaje Precio del paquete

X(5) X(5) X(5) X(5) X(5) X(40) N

M:1

M:1

M:1

M:1

M:1

Debe existir en esta tabla No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo

Tipo: Formato:

P:

F: E:

Clave Primaria

Clave Foránea Elemento de Dato

A:

N: X:

L:

Alfabético

Numérico Alfanumérico

Lógico

F:

H: M:

I:

Fecha

Hora Memo

Imagen


ROGER CABRERA




60


Empresa:

SKAPATE Sistema:


WEB SKAPATE

Nombre: TABLA HOTEL Fecha: 13/Noviembre /2011


Descripción: INFORMACIÓN DE LOS HOTELES

No.

T I

P o

Campo

Descripción

Formato y

Tamaño

TIPO

RELACIÓ

N


1

2

3

4

5

6

7

8

P

E

E

E

E

E

E E

ID_HOTEL

HTL_NOMBRE

HTL_TELEFONO

HTL_UBICACION

HTL_RAZONSOCIAL

HTL_GERENTE

HTL_REPRESENTANTELEGAL

HTL_MEMBRESIATI

PO

Clave referencia del hotel Nombre del hotel Teléfono del hotel Dirección del hotel Razon social del hotel Nombre del gerente Nombre del representante legal Tipo de membresia

X(5) X(60) X(14) X(5) X(60) A(60) A(60) X(20)

M:1

Debe existir en esta tabla No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo

Tipo: Formato:

P:

F: E:

Clave Primaria


A:

N: X:

L:

Alfabético


Lógico

F:

H: M:

I:

Fecha

Hora Memo

Imagen


ROGER CABRERA




61


Empresa:

SKAPATE Sistema:


Nombre: TABLA REPORTE Fecha: 13/Noviembre /2011

Tipo de tabla: Maestra Bytes/Fila:

Descripción: INFORMACIÓN DE LOS HOTELES

No.

T

I

P o

Campo

Descripción

Formato

y

Tamaño

TIPO

RELACIÓ

N

Reglas de

Validación

1

2

3

4

5

6

7

8

P

E

E

E

E

E

E E

ID_HOTEL

ID_CONSULTA

ID_REPORTEAGENCIA

ID_REPORTEHOTE

L

ID_HOTEL

ID_INGRESO

ID_AGENCIA

ID_CLIENTE

Clave referencia del hotel Clave de referencia de consulta Clave de referencia de agencias Clave de reporte de los hoteles Clave de referencia del hotel Clave de referencia de ingreso Clave de referencia de agencia Clave de referencia de cliente

X(5) X(5) X(5) X(5) X(5) X(5) X(5) X(5)

M:1

M:1

M:1

M:1

M:1

M:1

M:1

M:1

Debe existir en esta tabla No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo No puede ser nulo

Tipo: Formato:

P: F:

E:


Elemento de Dato

A: N:

X: L:



F: H:

M: I:

Fecha Hora

Memo Imagen



DEYSI SANTAMARÍA MARTIN



62


Empresa:

SKAPATE Sistema:


WEB SKAPATE

Nombre: TABLA CONSULTA Fecha: 13/Noviembre /2011

Tipo de tabla: Fuente Bytes/Fila:

Descripción: INFORMACIÓN DE LAS CONSULTAS

No.

T

I P

o

Campo

Descripción

Formato

y Tamaño

TIPO

RELACIÓN

Reglas de

Validación

1

2

3

P

F

F

ID_CONSULTA

ID_CLIENTE

ID_AGENCIA

Clave de referencia de consulta Clave de referencia de cliente Clave de referencia de Agencia

X(5) X(5) X(5)

M:1

M:1

M:1

Debe existir en esta tabla No puede ser nulo No puede ser nulo

Tipo: Formato:

P:

F: E:

Clave Primaria


A:

N: X:

L:

Alfabético


Lógico

F:

H: M:

I:

Fecha

Hora Memo

Imagen


ROGER CABRERA


GABRIEL GONOGORA

ERIKA CACERES


63


Empresa:

SKAPATE Sistema:


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


Descripción: INFORMACIÓN DE REPORTE DE AGENCIA

No.

T

I P

o

Campo

Descripción

Formato

y Tamaño

TIPO

RELACIÓN

Reglas de

Validación

1

2

P

F

ID_REPORTEAGENCIA

ID_AGENCIA

Clave de referencia del reporte de la agencia Clave de referencia de Agencia

X(5) X(5)

M:1

M:1

Debe existir en esta tabla No puede ser nulo

Tipo: Formato:

P: F:

E:


Elemento de Dato

A: N:

X: L:



F: H:

M: I:

Fecha Hora

Memo Imagen




ERIKA CACERES


64


Empresa:

SKAPATE Sistema:


WEB SKAPATE

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


Descripción: INFORMACIÓN DE REPORTE DE HOTEL

No.

T

I P

o

Campo

Descripción

Formato

y Tamaño

TIPO

RELACIÓN

Reglas de

Validación

1

2

P

F

ID_REPORTEHOTEL

ID_HOTEL

Clave de referencia del reporte del hotel Clave de referencia del hotel

X(5) X(5)

M:1

M:1


Tipo: Formato:

P:

F:

E:

Clave Primaria

Clave Foránea

Elemento de Dato

A:

N:

X: L:

Alfabético

Numérico


F:

H:

M: I:

Fecha

Hora

Memo Imagen




ERIKA CACERES


65


Empresa:

SKAPATE Sistema:


WEB SKAPATE

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


Descripción: INFORMACIÓN DE REPORTE DE HOTEL

No.

T

I P

o

Campo

Descripción

Formato

y Tamaño

TIPO

RELACIÓN

Reglas de

Validación

1

2

P

F

ID_INGRESO

ING_INGRESOS

Clave de referencia del ingreso Ingresos

X(5) N

M:1


Tipo: Formato:

P:

F:

E:

Clave Primaria

Clave Foránea

Elemento de Dato

A:

N:

X: L:

Alfabético

Numérico


F:

H:

M: I:

Fecha

Hora

Memo Imagen




ERIKA CACERES


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

Technology

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