Documento deEspecificaciones de Diseño de  Software para “Skapate”               Versión 1.0        18 de noviembre del 20...
Tabla de Contenido1. Introducción………………………………………………..... 31.1. Propósito del sistema1.2. Objetivos y restricciones de dise...
1. IntroducciónEl propósito de este documento es poder dar una visión detallada de cómofuncionara el sistema que se va a i...
Información estadística de reservas tomadas, modificadas, canceladas ycaducadas.”1.1.   Objetivos y restricciones de diseñ...
De igual manera especificamos que la base de datos SQL server podráencontrarse como alternativa en un servidor propio de l...
realizadas en un uso-caso, así como las distintas rutas que pueden irsedesencadenando en el uso-caso.Un diagrama de secuen...
errores), junto con sus respuestas y acciones. También ilustran qué eventospueden cambiar el estado de los objetos de la c...
Estado en un objeto:El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, elcomportamiento agrupa l...
Transición simple.- Una transición simple es una relación entre dos estadosque indica que un objeto en el primer estado pu...
Interacción.- Es el conjunto de mensajes intercambiados por los roles declasificador a través de los roles de asociación. ...
1.3.   ReferenciasPara realizar este proyecto nos basamos en las especificaciones que nos dio elLic. Augusto Moguel en las...
1.5. Estructura del documento1.1. Propósito del sistema   A continuación en esta parte hablaremos de cuál fue el propósito...
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,...
3.1.3.1.2. Diagrama de clase de caso de uso      Aquí se hablara de como se describen los procesos que antes      menciona...
4.3 Diccionario de DatosEn esta parte hablaremos de el conjunto de metadoatos que contiene lascaracterísticas lógicas y pu...
2.   Arquitectura del Sistema2.1. Arquitectura lógica (descomposición en subsistemas)El Sistema está conformado por los si...
Este componente se encargara de en listar los distintos productos y     servicios ofrecidos por las agencias y hoteles.  ...
Este es el Diagrama de 3 Capas de la página web “Skapate”   18
2.2. Arquitectura física (topología del sistema)Este diagrama describe como los usuarios a través de sus ordenadores acced...
3.   Diseño de los subsistemas3.1. Diseño   del subsistemaA continuación describiremos cada uno de los subsistemas que se ...
Diagrama de paquetes del caso de uso reservaciones.Para que el cliente realice una reservación tiene que visitar primero l...
1 diseño del subsistema “reservaciones”.     1.1. vista de uso del subsistema “reservaciones”.             Diagrama de paq...
1.2 escenario de casos de uso reservaciones.Caso de uso:          reservaciones.Actores:              Cliente, hotel, agen...
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...
2.2.   escenario de caso de uso de reportes.Caso de uso:           reportes.Actores:               Administrador.Descripci...
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 pa...
3.2 realización del caso de uso de administración.CASO DE USO           DAR DE ALTA.ACTOR                 AdministradorDES...
3.2 realización del caso de uso de administración.DESCRIPCIÓN            El administrador del sistema modifica una cuenta ...
3.2 realización del caso de uso de administración.FLUJOS                 Flujo alterno A, “dar de baja a un usuario”.ALTER...
3.2 realización del caso de uso de administración.                          5. Hacer clic en enviar.                      ...
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.DESCRI...
CASO DE USO       LA AGENCIA PAGA SU MEMBRESÍA.ACTOR             Agencia.DESCRIPCIÓN       La agencia paga su membresía pa...
4.3 Diagrama de clase del caso de uso pagos.   40
4.4 diagrama de secuencias del caso de uso pagos.   41
42
43
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.DESCR...
CASO DE USO       RESPONDER A CLIENTES.ACTOR             agenciaDESCRIPCIÓN       La agencia responde una consulta realiza...
5.3 Diagrama de clase del caso de uso comunicaciones.   47
5.4 diagrama de secuencias del caso de uso comunicaciones.   48
49
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                buscadorACTOR                      ClienteDESCRIPCIÓN...
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 Datos4.1. Esquema ConceptualEste es el modelo de conceptual del sistema de la página web “Skapate”pre...
4.2. Esquema ImplementableAquí se muestra el diagrama de base datos de la pagina web “Skapate” la cual sedetalla en el sig...
DICCIONARIO DE DATOS                                                                                        DISEÑO DE UNA ...
DICCIONARIO DE DATOS                                                                                        DISEÑO DE UNA ...
DICCIONARIO DE DATOS                                                                                        DISEÑO DE UNA ...
DICCIONARIO DE DATOS                                                                                        DISEÑO DE UNA ...
DICCIONARIO DE DATOS                                                                                        DISEÑO DE UNA ...
DICCIONARIO DE DATOS                                                                                    DISEÑO DE UNA BASE...
DICCIONARIO DE DATOS                                                                                       DISEÑO DE UNA B...
DICCIONARIO DE DATOS                                                                                       DISEÑO DE UNA B...
DICCIONARIO DE DATOS                                                                                       DISEÑO DE UNA B...
DICCIONARIO DE DATOS                                                                                       DISEÑO DE UNA B...
Próxima SlideShare
Cargando en…5
×

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

5.970 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
3 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
5.970
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
279
Comentarios
0
Recomendaciones
3
Insertados 0
No insertados

No hay notas en la diapositiva.

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

  1. 1. Documento deEspecificaciones 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 Cabrera1
  2. 2. Tabla de Contenido1. Introducción………………………………………………..... 31.1. Propósito del sistema1.2. Objetivos y restricciones de diseño1.3. Definiciones, acrónimos y abreviaturas1.4. Referencias1.5. Estructura del documento2. Arquitectura del Sistema ……………………………… 162.1. Arquitectura lógica (descomposición en subsistemas)2.2. Arquitectura física (topología del sistema)3. Diseño de los subsistemas…………………………… 203.1. Diseño del subsistema3.1.1. Vista de uso del subsistema3.1.2. Vista de datos del subsistema3.1.3. Realizaciones de Casos de Uso3.1.3.1. Realización del caso de uso <nombre caso de uso 1>3.1.3.1.1. Escenario del caso de uso3.1.3.1.2. Diagrama de clase del caso de uso3.1.3.1.3. Diagrama de secuencia detallado del caso de uso3.1.3.1.4. Interfaz gráfica de usuario del caso de uso3.1.3.1.5. Diagrama de navegación del caso de uso3.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 ……………………………. 544.1. Esquema Conceptual4.2. Esquema Implementable4.3. Diccionario de Datos 2
  3. 3. 1. IntroducciónEl propósito de este documento es poder dar una visión detallada de cómofuncionara el sistema que se va a implementar, especificando paso a paso elproceso de consulta y de cada privilegio que cuentan cada uno de los niveles deusuarios involucrados. Se brindara la información necesaria y apta para poderentender el funcionamiento del sistema y de cada una de sus partes, de igualmanera, se demostrara como se comportan las solicitudes exigidas al sistema yde 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 losprocesos de acceso de cada usuario.Este documento va dirigido al Lic. Augusto Moguel quien solicito la herramientay será quien valore que se cumplan todos los requerimientos y también es élquien 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 disponganel servicio ya que representarán a los usuarios finales del producto que porcierto resulta de vital importancia que entiendan el funcionamiento del procesoya que estos serán los principales usuarios del sistema.La estructura general de composición de esta herramienta constará de unapágina web en php con módulos y ventanas interactivas y botones, almacenadaen un hosting, enlazada a una base datos SQL alojada en un servidor bajoWindows Server 2008 perteneciente a la empresa y administrada por el hosting.Propósito del sistemaLa 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 necesariapara poder adquirir en el instante, cualquiera de los servicios de hoteleríadisponibles y como propósito secundario, nos permitirá una centradaadministración de las ventas, generación de comisiones y control de publicidad.El subsistema de igual manera generará información para la administración dela ocupación del hotel, sobre la disponibilidad y paquetes utilizados. Entre losprocesos 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 decré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 tengainformación de entrada, la que deberá ser:Información personal de los clientes. Los datos específicos de las reservas, estascontenidas al llenar un formulario. La información adicional de promocionespor 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 deuna reserva no cancelada 3
  4. 4. Información estadística de reservas tomadas, modificadas, canceladas ycaducadas.”1.1. Objetivos y restricciones de diseñoEl diseño en general deberá cumplir con el objetivo ya mencionado conanterioridad, el cual es crear una página web que englobe todos los servicios dehotelería y administre todos los paquetes y promociones existentes y así tenerun mejor control de las transacciones que se realicen. Podrán entrar a la páginaweb 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 generacomisiones, creara una cartera de clientes ampliando el mercado meta ysimplificar el acceso a los servicios que se brindan.Sin embargo es necesario contar con requerimientos específicos para suimplantación, como podemos mencionar:La empresa necesitará crear un dominio, un hosting donde se albergara lapágina web, un servidor donde se almacenara la base de datos y por ultimo unacertificado de seguridad SSL (El cual el trámite se encargara posteriormente laempresa ya que no lo incluye el proyecto.) para poder realizar transaccionesmonetarias y para mayor confianza por parte del cliente.Para poder implementar esta página web no es necesario que se cuente con unagran infraestructura. Por lo anterior se le sugiere la contratación de un terceroquien 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 labase de datos SQL Server 2008, se puede ejecutar en Sistemas OperativosWindows y Linux, al igual que visualizado en navegador Firefox, InternetExplorer , 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 descriptivosBarras de desplazamientoMenús InteractivosCuadros de alerta al realizar alguna selecciónImágenesCheckbox 4
  5. 5. De igual manera especificamos que la base de datos SQL server podráencontrarse como alternativa en un servidor propio de la empresa paraseguridad e integridad de la información.Con respecto a los requerimientos de hardware.:El servidor donde estará almacenada la información será proporcionada por elcliente, y debe cumplir con los siguientes requisitos mínimos:1. GB de Memoria Ram2. Disco duro de 250 GB3. Lector Cd-DVD1.2. Definiciones, acrónimos y abreviaturasIconix.- Es una metodología de desarrollo de software que es anterior tanto enel Rational Unified Process (RUP).A diferencia de los enfoques XP y Agile, Iconix proporciona requisito suficientey documentación de diseño, pero sin parálisis por análisis. El proceso de Iconixutiliza sólo cuatro diagramas UML basada en un proceso de cuatro pasos queconvierte 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, unmétodo para cerrar la brecha entre el análisis y el diseño. Análisis de robustezreduce la ambigüedad de las descripciones de casos de uso, asegurando quetodo está escrito en el contexto de un modelo de dominio que acompaña. Esteproceso 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 deanálisis y modelado de diseño. Sin embargo, el proceso puede ser utilizado sinmucha 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 querepresenta datos numéricos tabulados.Diagrama de actividades.- En el Lenguaje de Modelado Unificado, undiagrama de actividades representa los flujos de trabajo paso a paso de negocioy operacionales de los componentes en un sistema al igual que muestra el flujode control general este demuestra la serie de actividades que deben ser 5
  6. 6. realizadas en un uso-caso, así como las distintas rutas que pueden irsedesencadenando en el uso-caso.Un diagrama de secuencia muestra la interacción de un conjunto de objetosen 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 unasecuencia de interacciones que se desarrollarán entre un sistema y sus actoresen 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 elcomportamiento de un sistema mediante su interacción con los usuarios y/uotros sistemas. O lo que es igual, un diagrama que muestra la relación entre losactores y los casos de uso en un sistema.Relacion.- Una relación es una conexión entre los elementos del modelo, porejemplo la especialización y la generalización son relaciones. Los diagramas decasos de uso se utilizan para ilustrar los requerimientos del sistema al mostrarcó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 figuraDiagrama de estado.- Los diagramas de estado muestran el conjunto deestados por los cuales pasa un objeto durante su vida en una aplicación enrespuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o 6
  7. 7. errores), junto con sus respuestas y acciones. También ilustran qué eventospueden 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 seunen en sus puntos finales. Conceptualmente una ruta es una sola entidadtopológica, aunque sus segmentos se pueden manipular gráficamente. unsegemento no debería existir separado de su ruta. Las rutas siempre vanconectdas en ambos extremos.UML.- es un lenguaje para hacer modelos y es independiente de los métodos deanálisis y diseño. Existen diferencias importantes entre un método y un lenguajede modelado. Un método es una manera explícita de estructurar el pensamientoy 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 demodelado carece de estas instrucciones. Los métodos contienen modelos y esosmodelos son utilizados para describir algo y comunicar los resultados del usodel método.Diagrama de objetos.- Los diagramas de objetos son utilizados durante elproceso de Análisis y Diseño de los sistemas informáticos en la metodologíaUML.Objeto.- es una entidad discreta con límites bien definidos y con identidad, esuna unidad atómica que encapsula estado y comportamiento.Identificador de objeto (OID) .-es un identificador utilizado para nombrar unobjeto (compare URN). Estructuralmente, un OID consiste en un nodo en unespacio de nombres jerárquico asignado. Los sucesivos números de los nodos, apartir de la raíz del árbol, identificar a cada nodo de la árbol. Los diseñadorescrear nuevos nodos mediante el registro bajo la autoridad de registro del nodo. 7
  8. 8. Estado en un objeto:El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, elcomportamiento agrupa las competencias de un objeto y describe las acciones yreacciones de ese objeto. Las operaciones de un objeto son consecuencia de unestímulo externo representado como mensaje enviado desde otro objeto.Persistencia en un objeto.- La persistencia de los objetos designa la capacidad de unobjeto trascender en el espacio/tiempo, podremos después reconstruirlo, esdecir, cogerlo de memoria secundaria para utilizarlo en la ejecución(materialización del objeto). Los lenguajes no proponen soporte adecuado parala persistencia, la cual debería ser transparente, un objeto existe desde sucreación hasta que se destruya.Comunicación en un objeto.- Un sistema informático puede verse como unconjunto de objetos autónomos y concurrentes que trabajan de maneracoordinada en la consecución de un fin específico. El comportamiento global sebasa pues en la comunicación entre los objetos que la componen.Mensaje en un objeto.- El mensaje es el soporte de una comunicación quevincula dinámicamente los objetos que fueron separados previamente en elproceso de descomposición.Diagrama de clases.- El Diagrama de Clases es el diagrama principal para elanálisis y diseño. Un diagrama de clases presenta las clases del sistema con susrelaciones estructurales y de herencia. La definición de clase incluyedefiniciones para atributos y operaciones.Agregación.- La agregación representa una relación parte de entre objetos. EnUML se proporciona una escasa caracterización de la agregación. 8
  9. 9. Transición simple.- Una transición simple es una relación entre dos estadosque indica que un objeto en el primer estado puede entrar al segundo estado yejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condicionesson 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 causacambio de estado.Acciones.- Podemos especificar la solicitud de un servicio a otro objeto comoconsecuencia de la transición.Subestados.- Un estado puede descomponerse en subestados, con transicionesentre ellos y conexiones al nivel superior.Transacción Compleja.- Una transición compleja relaciona tres o másestados en una transición de múltiples fuentes y/o múltiples destinos.Transición a estados anidados.- Una transición de hacia un estadocomplejo (descrito mediante estados anidados) significa la entrada al estadoinicial del subdiagrama.Diagrama de interacción.- La vista de interacción describe secuencias deintercambios de mensajes entre los roles que implementan el comportamientode un sistema. Un rol clasificador, o simplemente "un rol", es la descripción deun 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 queinteractúan para implementar un cierto comportamiento dentro de un contexto. 9
  10. 10. Interacción.- Es el conjunto de mensajes intercambiados por los roles declasificador a través de los roles de asociación. Un mensaje es una comunicaiónunidireccional entre dos objetos,Patron.- Un patrón es una colaboración parametrizada, junto con las pautassobre cuándo utilizarlo. Un parámetro se puede sustituir por diversos valores,para producir distintas colaboraciones.Diagramas de despliegue.- Los Diagramas de Despliegue muestran ladisposición física de los distintos nodos que componen un sistema y el repartode los componentes sobre dichos nodos.Diagrama de componentes.- Los diagramas de componentes describen loselementos físicos del sistema y sus relaciones. Muestran las opciones derealización incluyendo código fuente, binario y ejecutable.Componente.- Es una parte física reemplazable de un sistema que empaquetasu implementación y es conforme a un conjunto de interfaces a las queproporciona su realización.Componente del código.- Un componente contiene el código para las clasesde implementación y otros elementos. Un componente de código fuente es unpaquete para el código fuente de las clases de implementación.Componente de identidad.- Un componente de identidad tiene identidad yestado. 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 otroscomponentes.Componente de estructura.- Ofrece un conjunto de elementos deimplementación, esto significa que el componente proporciona el código paralos elementos.Paquete.- Un paquete es una parte de un modelo. Cada parte del modelo debepertenecer a un paquete. Pero para ser funcional, la asignación debe seguir uncierto principio racional, tal como funcionalidad común, implementaciónrelacionada y punto de vista común. 10
  11. 11. 1.3. ReferenciasPara realizar este proyecto nos basamos en las especificaciones que nos dio elLic. Augusto Moguel en las entrevistas que tuvimos con el.En las citas el Lic. Moguel nos explicó las necesidades que buscaba satisfacer yel presupuesto con el que contaba para el proyecto también nos expreso quequiere 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 documentobrinde información necesaria y apta para poder entender el funcionamiento delsistema. De igual manera, nos pidió que se demostrara cómo se comportan lassolicitudes 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á unsistema de información y captura que tendrá como propósito fundamentalbrindarle al cliente toda la información necesaria para poder adquirir en elinstante, cualquiera de los servicios de hotelería disponibles y como propósitosecundario, 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
  12. 12. 1.5. Estructura del documento1.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. 12
  13. 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 subsistemasEn esta parte hablaremos de todas y cada una de los subsistemas desde susvista, las realizaciones, escenario, diagrama, interfaz grafica, diagrama denavegació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. 13
  14. 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 DatosEn esta parte hablaremos del diseño que se le dará a la base de datos quepertenecen a un mismo contexto y que están almacenados sistemáticamentepara 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.14
  15. 15. 4.3 Diccionario de DatosEn esta parte hablaremos de el conjunto de metadoatos que contiene lascaracterísticas lógicas y puntuales de los datos que se van a utilizar en el sistemaque se está programando. 15
  16. 16. 2. Arquitectura del Sistema2.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 16
  17. 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.17
  18. 18. Este es el Diagrama de 3 Capas de la página web “Skapate” 18
  19. 19. 2.2. Arquitectura física (topología del sistema)Este diagrama describe como los usuarios a través de sus ordenadores acceden ala página web www.skapate.com a través del servidor web Apache y el servidorde base de SQL Server 2008 19
  20. 20. 3. Diseño de los subsistemas3.1. Diseño del subsistemaA continuación describiremos cada uno de los subsistemas que se presentaronen el diagrama depaquetes en la sección: “arquitectura lógica del sistema”. El método para taldescripción es unadescripción de la funcionalidad del sistema mediante la vista de casos de usos,una descripcióndel modelo de datos que soporta, mostrados mediante una vista de datos y lainclusión de una serie de elementos de modelado que describen como los casosdeuso del sistema pueden ser Realizados.quedando la estructura de la siguiente forma:I. vista de uso del subsistema. Esta vista muestra la funcionalidad delsistema como espercibida por los usuariosfinales, analista y encargados de las pruebaspor medio de diagramas de paquetes.II. Realizaciones de Casos de Uso. En esta sección se detalla como cada unode los casos deuso 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
  21. 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 deproductos y servicios y posteriormente realizar el pago mediante el subsistemade pagos lo cualgenera 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 eldiagrama de paquetes en la sección: “arquitectura lógica del sistema”. El método paratal descripción es una descripción de la funcionalidad del sistema mediante la vista decasos 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 usuariosfinales, analista y encargados de las pruebaspor 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
  22. 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 pagomediante el subsistema de pagos lo cual genera un aviso del sistema a la agenciay al cliente. 22
  23. 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. 23
  24. 24. 1.3 Diagrama de clase del caso de uso reservaciones. 24
  25. 25. 1.4 diagrama de secuencias del caso de uso reservaciones. 25
  26. 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, losregistros de los datos de los usuarios de la página, el catálogo de productos yservicios y de las estadísticas 26
  27. 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”. 2. El sistema le preguntará si desea descargar el archivo o verlo. 3. Continuar con el punto 3 del flujo normal. Flujo alterno C, “El administrador desea realizar un reporte de los hoteles”. 4. hacer clic en el botón “hoteles”. 5. El sistema le preguntará si desea descargar el archivo o verlo. 6. Continuar con el punto 3 del flujo normal.Postcondición: El administrador ha generado un reporte. 27
  28. 28. 2.3 Diagrama de clase del caso de uso reportes. 28
  29. 29. 2.4 diagrama de secuencias del caso de uso reportes. 29
  30. 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 eincluso las del propio administrador de la página. 30
  31. 31. 3.2 realización del caso de uso de administración.CASO DE USO DAR DE ALTA.ACTOR AdministradorDESCRIPCIÓ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.ALTERNOSPOSTCONDICIÓ El administrador ha dado de alta a una agencia o un hotel.NCASO DE USO MODIFICAR CUENTA DE USUARIO.ACTOR Administrador. 31
  32. 32. 3.2 realización del caso de uso de administración.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
  33. 33. 3.2 realización del caso de uso de administración.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. 4. El sistema le regresará a la ventana para modificar las cuentas 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. 4. El sistema le regresará a la ventana para modificar las cuentas 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”. 5. El sistema le regresará a la ventana para modificar las cuentas 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
  34. 34. 3.2 realización del caso de uso de administración. 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
  35. 35. 3.3 Diagrama de clase del caso de uso administración. 35
  36. 36. 3.4 diagrama de secuencias del caso de uso de administración. 36
  37. 37. 4 diseño del subsistema “pagos”. 4.1. vista de uso del subsistema de pagos.37
  38. 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.comFLUJO 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.ALTERNOSPOSTCONDICIÓ El hotel ha realizado el pago de su membresía.N 38
  39. 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.comFLUJO 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
  40. 40. 4.3 Diagrama de clase del caso de uso pagos. 40
  41. 41. 4.4 diagrama de secuencias del caso de uso pagos. 41
  42. 42. 42
  43. 43. 43
  44. 44. 5 diseño del subsistema “comunicaciones”. 5.1.vista de uso del subsistema comunicaciones.44
  45. 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 No hay flujo alterno.ALTERNOSPOSTCONDICIÓ El Cliente ha realizado una consulta a una agencia sobre algúnN paquete. 45
  46. 46. CASO DE USO RESPONDER A CLIENTES.ACTOR agenciaDESCRIPCIÓ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
  47. 47. 5.3 Diagrama de clase del caso de uso comunicaciones. 47
  48. 48. 5.4 diagrama de secuencias del caso de uso comunicaciones. 48
  49. 49. 49
  50. 50. 6 diseño del subsistema “buscador”. 6.1. vista de uso del subsistema buscador.50
  51. 51. 6.2. escenario de casos de uso buscador.CASO DE USO buscadorACTOR ClienteDESCRIPCIÓ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 existenPOSTCONDICIÓN El cliente ha realizado una busqueda. 51
  52. 52. 6.3. diagrama de clases del caso de uso buscador.52
  53. 53. 6.4. diagrama de secuencias del caso de uso buscador.53
  54. 54. Diseño de la Base de Datos4.1. Esquema ConceptualEste 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
  55. 55. 4.2. Esquema ImplementableAquí se muestra el diagrama de base datos de la pagina web “Skapate” la cual sedetalla en el siguiente apartado 55
  56. 56. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA CLIENTE Fecha: 13/Noviembre /2011Tipo 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
  57. 57. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA RESERVACIÓN Fecha: 13/Noviembre /2011Tipo de tabla: Detalle Bytes/Fila: Descripción: INFORMACIÓN DE LAS RESERVACIONES TIPO No. T Campo Descripción Formato Reglas de I y RELACIO Validación 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: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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
  58. 58. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA AGENCIA Fecha: 13/Noviembre /2011Tipo de tabla: Detalle Bytes/Fila: Descripción: INFORMACIÓN DE LAS AGENCIAS TIPO No. T Campo Descripción Formato Reglas de I y RELACIO Validación 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: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 58
  59. 59. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA PAQUETE VIAJE Fecha: 13/Noviembre /2011Tipo de tabla: Detalle Bytes/Fila: Descripción: INFORMACIÓN DE LOS PAQUETES DE VIAJE TIPO No. T Campo Descripción Formato Reglas de 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: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 59
  60. 60. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA HOTEL Fecha: 13/Noviembre /2011Tipo de tabla: Detalle Bytes/Fila: Descripción: INFORMACIÓN DE LOS HOTELES TIPO No. T Campo Descripción Formato Reglas de I y RELACIÓ Validación 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: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 60
  61. 61. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA REPORTE Fecha: 13/Noviembre /2011Tipo de tabla: Maestra Bytes/Fila: Descripción: INFORMACIÓN DE LOS HOTELES TIPO No. T Campo Descripción Formato Reglas de I y RELACIÓ Validación 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: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 61
  62. 62. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA CONSULTA Fecha: 13/Noviembre /2011Tipo de tabla: Fuente Bytes/Fila: Descripción: INFORMACIÓN DE LAS CONSULTAS TIPO No. T Campo Descripción Formato Reglas de I y RELACIÓ Validación 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 3 F ID_AGENCIA Clave de referencia X(5) M:1 No puede ser nulo de Agencia Tipo: Formato: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 62
  63. 63. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA REPORTE AGENCIA Fecha: 13/Noviembre /2011Tipo de tabla: Fuente Bytes/Fila: Descripción: INFORMACIÓN DE REPORTE DE AGENCIA TIPO No. T Campo Descripción Formato Reglas de I y RELACIÓ Validación 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 2 F ID_AGENCIA Clave de referencia X(5) M:1 No puede ser nulo de Agencia Tipo: Formato: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 63
  64. 64. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA REPORTE HOTEL Fecha: 13/Noviembre /2011Tipo de tabla: Fuente Bytes/Fila: Descripción: INFORMACIÓN DE REPORTE DE HOTEL TIPO No. T Campo Descripción Formato Reglas de I y RELACIÓ Validación 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: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 64
  65. 65. DICCIONARIO DE DATOS DISEÑO DE UNA BASE DE DATOS DE LA PAGINA Empresa: SKAPATE Sistema: WEB SKAPATE Nombre: TABLA REPORTE HOTEL Fecha: 13/Noviembre /2011Tipo de tabla: Fuente Bytes/Fila: Descripción: INFORMACIÓN DE REPORTE DE HOTEL TIPO No. T Campo Descripción Formato Reglas de I y RELACIÓ Validación 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: P: Clave Primaria A: Alfabético F: Fecha F: Clave Foránea N: Numérico H: Hora E: Elemento de Dato X: Alfanumérico M: Memo L: Lógico I: 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: 65

×