UNIVERSIDAD SAN PEDRO

FACULTAD DE INGENIERIA
CARRERA PROFESIONAL DE
INGENIERIA INFORMTICA Y DE SISTEMAS

CURSO:
PRACTICAS PRE PROFESIONALES I

TITULO DEL PROYECTO:

SISTEMA INFORMATICO WEB PARA LA RESERVA DE ASIENTOS Y CONTROL
DE ENCOMIENDAS.

AUTORES:
ASENCIOS SANCHEZ, JESUS
CASTILLO INFANTES, MIGUEL
GIRIO DIAZ, YEFRI

ASESOR:
ING. CIP MILTON CHUMBES CHAFALOTE

2015

Dedicatoria
Dedicamos
nuestros

este

proyecto

padres, quienes

lo largo de nuestras vida

a
a

han

velado por nuestro bienestar y

educacin siendo nuestro apoyo
en todo momento. Depositndose
entera confianza en cada reto que
se nos presentaba sin dudar ni un
solo

momento

en

inteligencia y capacidad.

nuestra

Agradecimiento
Un agradecimiento especial a la
EMPRESA

DE

TRANSPORTE

TURISMO BARRANCA quienes

con su ayuda desinteresada, nos
brindaron tiempo e informacin
para poder llevar a cabo este
humilde

trabajo.

Agradecemos

tambin a nuestra familia por

siempre
tanto

brindarnos
sentimental,

econmico.

su

apoyo,
como

INDICE
CAPTULO I: GENERALIDADES
1.1.

NOMBRE DE PROYECTO

1.2.

DESCRIPCION DEL PROYECTO

1.3.

LOGOTIPO DE LA ORGANIZACIN

1.4.

RAZON SOCIAL DE LA ORGANIZACIN:NOMBRE,DIRECCION,FONO,EMAIL

1.5.

DECRICPCION DE LA ORGANIZACION

1.6. SITUACION PROBLEMTICA

1.6.1.

DESCRIPCION DE LA ORGANIZACIN

1.6.2.

SELECCIN DEL PROBLEMA

1.6.3.

ANTECEDENTES DEL PROBLEMA

1.7. OBJETIVOS DEL PROYECTO

1.7.1.

OBJETIVO GENERAL

1.7.2.

OBJETIVO ESPECIFICO

1.8. JUSTIFICACION DEL PROYECTO

1.8.1.

JUSTIFICACION TECNICA

1.8.2.

JUSTIFICACION OPERATIVA

1.8.3.

JUSTIFICACION ECONOMICA

1.9. LIMITACIONES DEL PROYECTO

1.9.1.

LIMITACION CRONOLOGICA

1.9.2.

LIMITACION TECNOLOGICA

1.9.3.

LIMITACION TECNICA

CAPTULO II: MARCO TEORICO

CAPTULO III: APLICACIN DE LA METODOLOGIA RUP
3.1.

MODELAMIENTO DEL NEGOCIO

3.1.1.

PICTOGRAMAPROCESOS DE NEGOCIO

3.1.2.

REGLAS DE NEGOCIO

3.1.3.

VISION DEL NECOGIO

3.1.4.

MODELADO DE CASOS DE USO DEL NEGOCIO

3.1.5.

ESPECIFICACION DE CASOS DE USO DEL NEGOCIO

3.1.6.

DIAGRAMA DE ACTIVIDAD

3.1.7.

MODELO DE OBJETOS DE NECOGIO

3.1.8.
3.2.

MODELO DE DOMINIO

MODELO DE REQUERIMIENTOS
3.2.1.

MODELO DE CASOS DE USO DE REQUEMIENTOS DETALLADO

3.2.2.

DIAGRAMA DE CASOS DE USO DE REQUIRIMIENTOS

3.2.3.

MATRIZ DE PRIORIZACION DE CASOS DE USOS

3.2.4.

ESPECIFICACION DE CASOS DE USOS DE REQUIRIMIETOS

3.3.

ANALISIS
3.3.1.

DIAGRAMA DE COLABORACION

3.3.2.

DIAGRAMA DE CLASES ENTIDAD

3.3.3.

DIAGRAMA DE CLASES DE ANALISIS (BOUNDARY + CONTROL + ENTITIS)

3.3.4.

DIAGRAMA DE PAQUETES DE ANALISIS

3.4.

DISEO
3.4.1.

INTERFACES DE USUARIO

3.4.2.

DIAGRAMAS DE SECUENCIA DE DISEOS

3.4.3.

DIAGRAMA DE CLASES DE DISEO

3.4.4.

DIAGRAMA DE ESTADO (por los menos 3 clases)

3.4.5.

DIAGRAMA DE PAQUETES DE DISEO

3.4.6.

MODELO FISICO DE LA BASE DE DATOS RELACIONAL (RATIONAL)

3.4.7.

SCRIPT DE MIGRACION DE LA BASE DE DATOS A SQL SERVER 2000

3.4.8.

MODELO FISICO DE LA BASE DE DATOS RELACIONAL (SQL SERVER)

3.4.9.

MODELO FISICO DE LA BASE DE DATOS RELACIONAL (NORMALIZAD

3.5.

IMPLEMENTACION
3.5.1.

DIAGRAMA DE COMPONENTES (INDICAR LAS CLASES IMPLEMENTAD

POR CADA COMPONENTE)

3.5.2.
3.6.

DIAGRAMA DE DESPLIEGUE

PRUEBA
3.6.1.

PRUEBA DE LA CAJA NEGRA

CONCLUSIONES
RECOMENDACIONES
REFERENCIAS BIBLIOGRAFICAS Y/O ENLACES WEB
BIBLIOGRAFIA
APENDICES
- OTROS FORMATOS DE INFORMACION
ANEXOS
- COPIAS DE LOS DOCUMENTOS FUENTES ENCONTRADOS
- FOTOS

CAPTULO I
GENERALIDADES

NOMBRE DEL PROYECTO:

Sistema Informtico Web para la Reserva De Asientos y Control de Encomiendas.

DESCRIPCION DEL PROYECTO

Esta pgina web se desarrollara con la finalidad de poder administrar y controlar esto 2
aspectos:

Separacin de Pasajes
Control de Encomiendas
Control de Buses

LOGOTIPO DE LA ORGANIZACION

RAZON SOCIAL DE LA ORGANIZACIN

RUC: 20206315467

Razn Social: Emp. Transportes y Turismo Bca. S.A.

Nombre Comercial: Emp. Transp y Turismo Bca. S.A.

Tipo Empresa: Sociedad Annima

Fecha Inicio Actividades: 14 / Enero / 1994

Direccin Legal: Pj. Belisario Suarez Nro. 102 (a Dos Casas de la Sunarp Bca.)

Distrito / Ciudad: Barranca

Provincia: Barranca

Departamento: Lima

Telfonos: 2352466 - 2353549

ORGANIGRAMA

SITUACION PROBLEMATICA

DESCRIPCION DE LA ORGANIZACION
Turismo barranca queda ubicada en el Pj. Belisario Suarez Nro. 102 (a Dos
Casas de la Sunarp Bca).Es una empresa de servicio de transporte interprovincial de
pasajeros y carga que brinda sus servicios con altos estndares de calidad y
servicio al cliente.
Cuenta con un capital humano que rene las competencias por puesto de trabajo,
capacitado y motivado, el cual recibe capacitaciones en el desarrollo de sus
funciones,
integrando la seguridad y salud de trabajo.
los

El rea de ventas de pasaje se encarga de la expedicin de los boletos de viajes

usuarios.

El rea de encomiendas se encarga de la recepcin, registro, entrega y

almacenamiento de las encomiendas que remitan los usuarios dentro de la
ruta de operaciones de la Empresa.
Algunos procesos como separacin de pasaje y envi encomiendas se realizan
manualmente y hay prdida de tiempo a la hora de Registrar las fichas
constantemente.
SELECCION DEL PROBLEMA
El problema es la carencia de un sistema web que automatice los procesos de
separacin de pasaje y envi de encomienda los cuales presentan una prdida de
tiempo para el cliente.
ANTECEDENTES DEL PROBLEMA
Anteriormente se registraba la separacin de pasajes y envi de encomiendas
manualmente lo cual retardaba el proceso de dichas tareas.

JUSTIFICACION DEL PROYECTO

JUSTIFICACIN TECNICA
El Proyecto se realiza por la necesidad que tiene turismo barranca, ya que la
separacin de pasaje y encomienda es un poco fastidioso para el cliente
porque esto se realiza manualmente y algunos no le gusta esperar,
optimizando as los servicios que presta la empresa.
La aplicacin web, podr ser utilizada en cualquier plataforma de Sistema
operativo.

JUSTIFICACIN OPERATIVA

 Mantener Informacin consistente.

Reduccin del tiempo para la realizacin de los procesos que se hacan
manualmente.
Elevar reportes de informacin al administrador o al gerente general para
mejorar la toma de decisiones.
JUSTIFICACION ECONOMICA
El gerente general aprobar y designar presupuesto para el desarrollo de la
aplicacin web.

OBJETIVOS DEL PROYECTO

OBJETIVO GENERAL
Desarrollar un Sistema informtico Web para la reserva de pasajes y control
de encomienda de sus reas respectivamente de la Empresa Turismo
Barranca.
OBJETIVO ESPECIFICO
Recopilar y clasificar la informacin de la empresa Turismo Barranca.
Utilizar la metodologa RUP y UML (caso de uso, diagrama de
actividad,etc).
Implementar el Sistema informtico Web utilizando como lenguaje de
Desarrollo PHP y como Administrador de Base de Datos: MySQL.

LIMITACIONES DEL PROYECTO

LIMITACIN CRONOLGICA

Para el desarrollo de la pgina web denominado SISTUBA, hay una

limitacin en cuanto al tiempo porque solo se cuenta con 4 meses para la
presentacin del proyecto web.

LIMITACIN TECNOLGICA

Para poder mejorar la pgina web, la empresa necesita tener equipos de

ltima generacin para realizar un trabajo estable.

LIMITACIN TCNICA

Debido a que la pgina web se va avanzando a lo largo del semestre

acadmico, la falta de conocimientos, dificulta la eficiencia del proyecto, ya
que solo contamos con conocimientos adquiridos de los cursos enseados.

CAPITULO II
MARCO TERICO

METODOLOGIA DE DESARROLLO
Para este proyecto utilizaremos la metodologa Rational Unified Process (RUP).

Metodologa RUP
El Proceso Unificado de Rational, es un marco de desarrollo de software que se
caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser
iterativo e incremental. El refinamiento ms conocido y documentado del
Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos especficos. De la
misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento
particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho
motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

Principales Caractersticas
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu,
cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software

Estructura de la Metodologa RUP

El Rational Unified Process o Proceso Unificado de Rational. Es un proceso de
ingeniera de software que suministra un enfoque para asignar tareas y
responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar
la produccin de software de alta calidad que satisfaga la necesidad del usuario final
dentro de un tiempo y presupuesto previsible. Es una metodologa de desarrollo
iterativo enfocada hacia los casos de uso, manejo de riesgos y el manejo de la
arquitectura.
El RUP mejora la productividad del equipo ya que permite que cada miembro del
grupo sin importar su responsabilidad especfica acceda a la misma base de datos de
conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visin y
el mismo proceso acerca de cmo desarrollar software.

a) Fases de la Metodologa RUP

Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan
hacia la comprensin del problema y la tecnologa, la delimitacin del
mbito del proyecto, la eliminacin de los riesgos crticos,
establecimiento
de una base de inicio de la arquitectura.
alcance

Fase de Inicio: Esta fase tiene como propsito definir y acordar el

del proyecto con los patrocinadores, identificar los riesgos asociados al
proyecto, proponer una visin muy general de la arquitectura de software
y producir el plan de las fases y el de iteraciones posteriores.

Fase de elaboracin: En la fase de elaboracin se seleccionan los casos

de
uso que permiten definir la arquitectura base del sistema y se
desarrollaran en esta fase, se realiza la especificacin de los casos de uso
seleccionados y el primer anlisis del dominio del problema, se disea la
solucin preliminar.
Fase de Desarrollo: El propsito de esta fase es completar la
funcionalidad del sistema, para ello se deben clarificar los requerimientos
pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por
los
usuarios y se realizan las mejoras para el proyecto.

proveer

Fase de Cierre: El propsito de esta fase es asegurar que el software est

disponible para los usuarios finales, ajustar los errores y defectos
encontrados en las pruebas de aceptacin, capacitar a los usuarios y
el soporte tcnico necesario. Se debe verificar que el producto cumpla con
las especificaciones entregadas por las personas involucradas en el
proyecto.

(papel

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo

e incremental, estar centrado en la arquitectura y guiado por los casos de
uso. Incluye artefactos (que son los productos tangibles del proceso como
por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles
que desempea una persona en un determinado momento, una persona
puede desempear distintos roles a lo largo del proceso).

b) Especificacin de las Fases

Establece oportunidad y alcance.

Identifica las entidades externas o actores con las que se trata.
Identifica los casos de uso.

RUP comprende 2 aspectos importantes por los cuales se establecen las

disciplinas:
Proceso: Las etapas de esta seccin son:

Modelado de negocio.
Requisitos.
Anlisis y Diseo.
Implementacin.
Pruebas.
Soporte: En esta parte nos conseguimos con las siguientes etapas:

Gestin del cambio y configuraciones

Gestin del proyecto
Entorno
La estructura dinmica de RUP es la que permite que este sea un proceso
de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas
las 4 fases descritas anteriormente:

Inicio (Tambin llamado Incepcin).

Elaboracin.
Desarrollo (Tambin llamado Implementacin, Construccin).
Cierre (Tambin llamado Transicin).

c) Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza
una serie de artefactos que sirven para comprender mejor tanto el anlisis
como el diseo del sistema estos artefactos son los siguientes:
Inicio:

Documento Visin
Especificacin de Requerimientos Elaboracin:
Diagramas de caso de uso Construccin:
Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lgica:

Diagrama de clases.
Modelo E-R (Si el sistema as lo requiere).

Vista de Implementacin:

Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin

Vista Conceptual:

Modelo de dominio

Vista fsica:

Mapa de comportamiento a nivel de hardware.

La metodologa RUP tiene 6 principios clave:

1. Adaptacin del proceso: El proceso debe adaptarse a las
caractersticas de la organizacin para la que se est desarrollando
el software.
2. Balancear prioridades: Debe encontrarse un balance que satisfaga a
todos los inversores del proyecto.
3. Colaboracin entre equipos: Debe haber una comunicacin fluida
para coordinar requerimientos, desarrollo, evaluaciones, planes,
resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se entregan, aunque
sea de una forma interna, en etapas iteradas. En cada iteracin se
evaluar la calidad y estabilidad del producto y analizar la
opinin y sugerencias de los inversores.
5. Elevar el nivel de abstraccin: Motivar el uso de conceptos
reutilizables.

6. Enfocarse en la calidad: La calidad del producto debe verificarse en

cada aspecto de la produccin.
Disciplina de desarrollo de RUP
Determina las etapas a realizar durante el proyecto de creacin del
software.
Ingeniera o modelado del negocio: Analizar y entender las
necesidades del negocio para el cual se est desarrollando el
software.
Requisitos: Proveer una base para estimar los costos y tiempo de
desarrollo
del sistema.
Anlisis y diseo: Trasladar los requisitos analizados anteriormente a
un sistema automatizado y desarrollar una arquitectura para el
sistema.
Implementacin: Crear software que se ajuste a la arquitectura
diseada y
que tenga el comportamiento deseado.
Pruebas: Asegurarse de que el comportamiento requerido es correcto
y que todo lo solicitado est presente.
Despliegue: Producir distribuciones del producto y distribuirlo a los
usuarios.
Disciplina de soporte RUP
Determina la documentacin que es necesaria realizar durante el
proyecto.
Configuracin y administracin del cambio: Guardar todas las
versiones del proyecto.
Administracin del proyecto: Administrar los horarios y recursos
que se deben de emplear.
Ambiente: Administrar el ambiente de desarrollo del software.
Distribucin: Hacer todo lo necesario para la salida del proyecto.
Elementos del RUP
Actividades: Procesos que se han de realizar en cada etapa/iteracin.
Trabajadores: Personas involucradas en cada actividad del proyecto.
Artefactos: Herramientas empleadas para el desarrollo del proyecto.
Puede ser un documento, un modelo, un elemento del modelo.

Herramientas de Apoyo
Rational Rose (RUP)

Es una herramienta de Rational Software Corporation con el soporte de

UML. Rose posesionado por Rational Object est orientado a la Ingeniera
del software, es usado para el anlisis, modelado, diseo y construccin del
objeto orientado. Esta dentro de las herramientas de modelamiento visual
Soporte mltiple para el manejo del modelamiento de la arquitectura.
Para qu sirve?
Sirve para el anlisis y diseo de sistemas basados en objetos. Rose es usado
para modelar sistemas antes de llevar a cabo los trabajos de construccin.
Esta secuencia de desarrollo es importante para asegurar la consistencia
arquitectnica del sistema. Usando los modelos de Rational Rose apoya
tambin al planeamiento del negocio, a travs de representaciones que
facilitan a los usuarios el mejor entendimiento de los procesos del negocio
hacindolos ms eficientes. Incluye todos los diagramas de UML: actores,
casos de uso, objetos, clases, componentes y el despliegue de nodos en un
sistema. Los modelos Rose, describen con gran detalle lo que el sistema
incluir y cmo funcionar, para que as los diseadores puedan usar los
modelos como si fueran los planos de un sistema a ser construido (un plano
es una buena analoga para los modelos creados en Rose).
Ventajas:
Un diseo ms rpido: Las aplicaciones se crean a partir de
componentes ya existentes.
Mantenimiento ms sencillo: El enlace dinmico incrementa la
flexibilidad, permitiendo la adhesin de nuevas clases de objetos sin
modificar los actuales.
Caractersticas:
Mantiene la consistencia de los modelos del sistema software.
Generacin de documentacin automticamente.
Generacin de Cdigo a partir de los Modelos.
Ingeniera Inversa.
La generacin de cdigo Ada, ANSI C ++, C++, CORBA, Java y
Visual Basic, con capacidad de sincronizacin modelo - cdigo
configurables.
Soporte Enterprise Java Beans 2.0 Capacidad de anlisis de
calidad de cdigo.
El Add-In para modelado Web provee visualizacin, modelado y las
herramientas para desarrollar aplicaciones de Web.
Modelado UML para trabajar en diseos de base de datos, con
capacidad de representar la integracin de los datos y los
requerimientos de aplicacin a travs de diseos lgicos y fsicos.

 Capacidad de crear definiciones de tipo de documento XML (DTD)

para el uso en la aplicacin.
Integracin con otras herramientas de desarrollo de Rational.
Capacidad para integrarse con cualquier sistema de control de
versiones SCC-compliant, incluyendo a Rational Clear Case.
Publicacin web y generacin de informes para optimizar la
comunicacin dentro del equipo.
Sistemas Operativos y Plataformas de Hardware Apropiadas:

Windows XP
Windows 7
Windows 8

Rational Rose, es la mejor eleccin para el ambiente de modelado que

soporte la generacin de cdigo a partir de modelos en Ada, ANSI C++, C+
+, CORBA, Java/J2EE, Visual C++ y Visual Basic. Como todos
los dems productos Rational Rose, proporciona un lenguaje comn de
modelado para el equipo que facilita la creacin de software de calidad ms
rpidamente.
Lenguaje Unificado de Modelado (UML)
Un modelo UML est compuesto por tres clases de bloques de
construccin:
Elementos: Los elementos son abstracciones de cosas reales o ficticias
(objetos, acciones, etc.)
Relaciones: relacionan los elementos entre s.
Diagramas: Son colecciones de elementos con sus relaciones.
Un Diagrama es la representacin grfica de un conjunto de elementos con
sus relaciones. UML ofrece una amplia variedad de diagramas para
visualizar el sistema desde varias perspectivas.
a) Diagramas de Estructura.-Enfatizan en los elementos que deben existir
en el sistema modelado.
Diagrama de clases.-Es un tipo de diagrama esttico que describe la
estructura de un sistema mostrando sus clases, atributos y las
relaciones entre ellos. Los diagramas de clases son utilizados durante
el proceso de anlisis y diseo de los sistemas, donde se crea el
diseo
conceptual de la informacin que se manejar en el sistema, y
los componentes que se encargaran del funcionamiento y la relacin
entre uno y otro.

Representacin de:

Requerimientos en entidades y actuaciones.

La arquitectura conceptual de un dominio.
Soluciones de diseo en una arquitectura.
Componentes de software orientados a objetos.

El diagrama de clases incluye mucha ms informacin como la

relacin entre un objeto y otro, la herencia de propiedades de otro
objeto, conjuntos de operaciones/propiedades que son implementadas
para una interfaz grfica.
Diagrama de componentes.- Es un diagrama tipo del Lenguaje
Unificado de Modelado.
Un diagrama de componentes representa cmo un sistema de
software
es dividido en componentes y muestra las dependencias entre
estos componentes. Los componentes fsicos incluyen archivos, cabeceras,
bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los
diagramas de Componentes prevalecen en el campo de la arquitectura
de software pero pueden ser usados para modelar y documentar
cualquier arquitectura de sistema.
Debido a que los diagramas de componentes son ms parecidos a los
diagramas de casos de usos, stos son utilizados para modelar la vista
esttica y dinmica de un sistema. Muestra la organizacin y las
dependencias entre un conjunto de componentes. No es necesario que
un diagrama incluya todos los componentes del sistema,
normalmente
se realizan por partes. Cada diagrama describe un
apartado del sistema.
En l se situarn libreras, tablas, archivos, ejecutables y documentos
que formen parte del sistema.
Uno de los usos principales es que puede servir para ver qu
componentes pueden compartirse entre sistemas o entre diferentes
partes de un sistema.
Diagramas de objetos.- Son utilizados durante el proceso de
Anlisis
y Diseo de los sistemas informticos en la metodologa
UML.
Se puede considerar un caso especial de un diagrama de clases en el
que se muestran instancias especficas de clases (objetos) en un
momento particular del sistema. Los diagramas de objetos utilizan un
subconjunto de los elementos de un diagrama de clase. Los
diagramas de objetos no muestran la multiplicidad ni los roles, aunque su
notacin
es similar a los diagramas de clase.

de

Una diferencia con los diagramas de clase es que el compartimiento

arriba va en la forma Nombre de objeto:
Nombre de clase.
Por ejemplo, Miguel: Persona.

Diagrama de estructura compuesta.- Es un tipo de diagrama de

estructura esttica en el Lenguaje de Modelado Unificado (UML),
que muestra la estructura interna de una clase y las colaboraciones que
esta estructura hace posibles. Esto puede incluir partes internas, puertas
mediante las cuales, las partes interactan con cada una de las otras o
mediante las cuales, instancias de la clase interactan con las partes y
con el mundo exterior, y conectores entre partes o puertas. Una
estructura compuesta es un conjunto de elementos interconectados
que colaboran en tiempo de ejecucin para lograr algn propsito. Cada
elemento tiene algn rol definido en la colaboracin.
Las entidades de estructura compuesta claves identificadas en la
especificacin UML 2.0 son: clasificadores estructurados, partes,
puertas, conectores, y colaboraciones.
Parte.- Representa un rol jugado en tiempo de ejecucin por una
instancia de una clase o por una coleccin de instancias. La parte
puede
nombrar solamente un rol, una superclase abstracta, o puede
nombrar
una clase concreta especfica. La parte puede incluir un factor
de multiplicidad (cardinalidad).
Puerta.- Es un punto de interaccin que puede ser usado para
conectar
clasificadores estructurados con sus partes y con el ambiente.
Las puertas pueden opcionalmente especificar los servicios que proveen y
los servicios que requieren de otras partes del sistema.
Conector.- Un conector une dos o ms entidades, permitindoles
interactuar en tiempo de ejecucin. Un conector es representado por
una lnea que une una combinacin de partes, puertas y clasificadores
estructurados.
Colaboracin.- Es generalmente ms abstracta que un clasificador
estructurado. sta es mostrada como un valo sin relleno conteniendo
los roles que las instancias pueden jugar en la colaboracin.
Diagrama de Despliegue.- Es un tipo de diagrama del Lenguaje
Unificado de Modelado que se utiliza para modelar el hardware
utilizado en las implementaciones de sistemas y las relaciones entre
sus componentes.
Los elementos usados por este tipo de diagrama son nodos
(representados como un prisma), componentes (representados como
una caja rectangular con dos protuberancias del lado izquierdo) y
asociaciones.

si
y

En el UML 2.0 los componentes ya no estn dentro de nodos. En

cambio, puede haber artefactos u otros nodos dentro de un nodo. Este
tipo de diagrama debemos tambin aadir que no van a existir actores
para relacionarse con los nodos (no es un diagrama de casos de uso)
no que las relaciones que pueda haber siempre sern entre los nodos
por ejemplo con una base de datos.

Diagrama de Paquetes.- Muestra cmo un sistema est dividido en

agrupaciones lgicas mostrando las dependencias entre esas
agrupaciones. Dado que normalmente un paquete est pensado como
un directorio, los diagramas de paquetes suministran una
descomposicin de la jerarqua lgica de un sistema.
Los Paquetes estn normalmente organizados para maximizar la
coherencia interna dentro de cada paquete y minimizar el
acoplamiento
externo entre los paquetes. Con estas lneas maestras
sobre la mesa, los paquetes son buenos elementos de gestin. Cada
paquete puede
asignarse a un individuo o a un equipo, y las
dependencias entre ellos pueden indicar el orden de desarrollo
requerido.
b) Diagrama de Comportamiento.- Enfatizan en lo que debe suceder en el
sistema modelado.
Diagrama de actividades.- Representa los flujos de trabajo paso a
paso de negocio y operacionales de los componentes en un sistema.
Un
Diagrama de Actividades muestra el flujo de control general.
Es una forma especial de diagrama de estado usado para modelar una
secuencia de acciones y condiciones tomadas dentro de un proceso.
Diagrama de Casos de Uso.- Es una especie de diagrama de
comportamiento. UML mejorado El Lenguaje de Modelado
Unificado define una notacin grfica para representar casos de uso
llamada modelo de casos de uso. UML no define estndares para que
el formato
escrito describa los casos de uso, y as mucha gente no
entiende que
esta notacin grfica define la naturaleza de un caso de
uso; sin embargo una notacin grfica puede solo dar una vista general
simple
de un caso de uso o un conjunto de casos de uso.
Las tres relaciones principales entre los casos de uso son soportadas
por el estndar UML, el cual describe notacin grfica para esas
relaciones. Veamos una revisin de ellas a continuacin:
Inclusin (include o use).- Es una forma de interaccin o creacin,
un caso de uso dado puede "incluir" otro caso de uso. El primer caso de

uso a menudo depende del resultado del caso de uso incluido. Esto es
til para extraer comportamientos verdaderamente comunes desde
mltiples casos de uso a una descripcin individual, desde el caso de
uso. El estndar de Lenguaje de Modelado Unificado de OMG define
una notacin grfica para realizar diagramas de casos de uso, pero no
el formato para describir casos de uso. Mucha gente sufre la
equivocacin pensando que un caso de uso es una notacin grfica (o
es su descripcin). Mientras la notacin grfica y las descripciones
esto
no sirve.
Extensin (Extend).- Es otra forma de interaccin, un caso de uso
dado (la extensin) puede extender a otro. Esta relacin indica que el
comportamiento del caso de la extensin se utiliza en casos de uso,
un caso de uso a otro caso siempre debe tener extensin o inclusin. El
caso de uso extensin puede ser insertado en el caso de uso extendido
bajo ciertas condiciones. La notacin, es una flecha de punta abierta
con lnea discontinua, desde el caso de uso extensin al caso de uso
extendido, con la etiqueta extend. Esto puede ser til para lidiar
con
casos especiales, o para acomodar nuevos requisitos durante
el mantenimiento del sistema y su extensin.
"La extensin, es el conjunto de objetos a los que se aplica un
concepto. Los objetos de la extensin son los ejemplos o instancias
de los conceptos."
Generalizacin.- Es la actividad de identificar elementos en comn
entre conceptos y definir las relaciones de una superclase (concepto
general) y subclase (concepto especializado). Es una manera de
construir clasificaciones taxonmicas entre conceptos que entonces
se representan en jerarquas de clases. Las subclases conceptuales son
conformes con las superclases conceptuales en cuanto a la intencin
y extensin.
Diagramas de estado.- Muestran el conjunto de estados por los
cuales
pasa un objeto durante su vida en una aplicacin en respuesta
a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores),
junto
con sus respuestas y acciones. Tambin 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.
Al igual que otros diagramas, en los diagramas de estado pueden
aparecer notas explicativas y restricciones.

c) Diagrama de Interaccin.- Son un subtipo de diagramas de

comportamiento, que enfatiza sobre el flujo de control y de datos entre
los elementos del sistema modelado.
Diagrama de Secuencia.- Es un tipo de diagrama usado para modelar
interaccin entre objetos en un sistema segn UML.
Un diagrama de secuencia muestra la interaccin de un conjunto de
objetos en una aplicacin a travs del tiempo y se modela para cada caso
de uso. Mientras que el diagrama de casos de uso permite el modelado
de una vista business del escenario, el diagrama de secuencia contiene
detalles de implementacin del escenario, incluyendo los objetos y clases
que se usan para implementar el escenario, y mensajes intercambiados
entre los objetos.
Tpicamente se examina la descripcin de un caso de uso para
determinar qu objetos son necesarios para la implementacin del
escenario. Si se dispone de la descripcin de cada caso de uso como una
secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos
para descubrir qu objetos son necesarios para que se puedan seguir los
pasos. Un diagrama de secuencia muestra los objetos que intervienen en
el escenario con lneas discontinuas verticales, y los mensajes pasados
entre los objetos como flechas horizontales.
Diagrama de Colaboracin.- Modela las interacciones entre objetos o
partes en trminos de mensajes en secuencia. Los diagramas de
colaboracin representan una combinacin de informacin tomada desde
el diagrama de clases, secuencia, y diagrama de casos de uso
describiendo tanto la estructura esttica como el comportamiento
dinmico de un sistema.
Los diagramas de colaboracin y de secuencia describen informacin
similar, y con ciertas transformaciones, pueden ser transformados unos
en otros sin dificultad.
GESTOR DE BD:
MySQL es un sistema gestor de bases de datos relacionales rpido, slido y
flexible. Es idneo para la creacin de bases de datos con acceso desde pginas
web dinmicas, as como para la creacin de cualquier otra solucin que
implique el almacenamiento de datos, posibilitando realizar mltiples y rpidas
consultas. Est desarrollado en C y C++, facilitando su integracin en otras
aplicaciones desarrolladas tambin en esos lenguajes.
Es un sistema cliente/servidor, por lo que permite trabajar como servidor
multiusuario y de subprocesamiento mltiple, o sea, cada vez que se crea una
conexin con el servidor, el programa servidor establece un proceso para manejar
la solicitud del cliente, controlando as el acceso simultneo de un gran nmero

de usuarios a los datos y asegurando el acceso a usuarios autorizados solamente.

Es uno de los sistemas gestores de bases de datos ms utilizado en la actualidad,
utilizado por grandes corporaciones como Yahoo! Finance, Google, Motorola,
entre otras.
LENGUAJE DE PROGRAMACIN
PHP es un lenguaje de cdigo abierto muy popular, adecuado para desarrollo web
y que puede ser incrustado en HTML. Es popular porque un gran nmero de
pginas y portales web estn creadas con PHP. Cdigo abierto significa que es de
uso libre y gratuito para todos los programadores que quieran usarlo. Incrustado
en HTML significa que en un mismo archivo vamos a poder combinar cdigo
PHP con cdigo HTML, siguiendo unas reglas.
PHP se utiliza para generar pginas web dinmicas. Recordar que llamamos
pgina esttica a aquella cuyos contenidos permanecen siempre igual, mientras
que llamamos pginas dinmicas a aquellas cuyo contenido no es el mismo
siempre. Por ejemplo, los contenidos pueden cambiar en base a los cambios que
haya en una base de datos, de bsquedas o aportaciones de los usuarios, etc.
Cmo trabaja PHP? El lenguaje PHP se procesa en servidores, que son potentes
ordenadores con un software y hardware especial. Cuando se escribe una
direccin tipo http://www.aprenderaprogramar.com/index.php en un navegador
web como Internet Explorer, Firefox o Chrome, qu ocurre? Se envan los datos
de la solicitud al servidor que los procesa, rene los datos (por eso decimos que
es un proceso dinmico) y el servidor lo que devuelve es una pgina HTML
como si fuera esttica.
El esquema es: Peticin de pgina web al servidor --> El servidor recibe la
peticin, rene la informacin necesaria consultando a bases de datos o a otras
pginas webs, otros servidores, etc. --> El servidor responde enviando una pgina
web normal (esttica) pero cuya creacin ha sido dinmica (realizando
procesos de modo que la pgina web devuelta no siempre es igual).

En resumen:
Pginas estticas: Peticin --> Respuesta
Pginas dinmicas: Peticin --> Procesado y preparacin --> Respuesta

CAPITULO III
APLICACIN DE LA METODOLOGA

3.1.

MODELAMIENTO DEL NEGOCIO

3.1.1.

PICTOGRAMAPROCESOS DE NEGOCIO

REGLAS DE NEGOCIO

Reserva de pasaje
El usuario debe de presentarse una hora antes para poder canjear el cdigo
emitido por el sistema para poder obtener tu boleto de viaje, el pago ser
personal y no en el sistema.
Dar el tiempo lmite para poder canjear el cdigo, si el asiento se encuentra
disponible dar acceso al cliente
Reserva de encomienda
El cliente debe de llevar el producto a la misma agencia para su respectivo
peso, para as de acuerdo al peso pagar por la encomienda.

El peso lmite de carga de la unidad de transporte es de 5000 kg.

Control de buses
Si existe algn incidente en el trascurso del camino, mediante el sistema debe
de cubrirle el siguiente en la programacin.
VISION DEL NECOGIO

Ser la empresa de transporte interprovincial n 01 de pasajeros y de carga del

Per, abrir nuevas rutas en el ao 2019, por el norte del pas con nuevas
unidades que brinden una comodidad al cliente para las rutas largas.
MODELADO DE CASOS DE USO DEL NEGOCIO

ESPECIFICACION DE CASOS DE USO DEL NEGOCIO

Nombre del caso de uso

Actores

Reserva de pasaje
Cliente, secretaria

Resumen

El caso de uso permite al cliente realizar la reserva de pasaje

mediante la pgina web, donde el cual el sistema emitir un
cdigo para canjear por un boleto en la misma agencia.

Precondiciones

Presentar el cdigo y su DNI

Post condiciones

Ninguna

Nombre del caso de uso

Reserva de Encomienda

Actores

Cliente, terminalista

Resumen

El caso de uso permite al cliente reservar la encomienda

mediante la pgina web, luego ir a la misma agencia para el
respectivo peso de sus productos a enviar.

Precondiciones

Presentar cdigo, mas DNI

Post condiciones

Ninguna.

Nombre del caso de uso

Control de Buses

Actores

Administrador

Resumen

El caso de uso permite al administrador llevar un mejor control

de las unidades (buses) para realizar la programacin.

Precondiciones

Tener acceso a toda la informacin del sistema

Post condiciones

DIAGRAMA DE ACTIVIDAD
Reserva de pasaje

Reserva de encomienda

Ninguna.

Control de buses

MODELO DE OBJETOS DE NECOGIO

Separacin de Pasajes

R
Datos Personales

Usuario

Sistema

(f rom Actores )

Asientos

Reservas Encomiendas

Datos Personales
Sistema

V/R
Usuario
Encomiendas

(f rom Actores )

Terminalista-

Pago-

Control de Buses

V/R
Buses
R

Administrador

Sistema

(f rom Actores )

Horarios de salida

MODELO DE DOMINIO

CLIENTE

USUARIO-

Pasaje

SEPARACION

PROGRAMACION

DESTINO

DETALLE

BUS

ENCOMIENDA

CHOFER

MARCA

MODELO DE REQUERIMIENTOS
MODELO DE CASOS DE USO DE REQUEMIENTOS DETALLADO

GIRO

<<include>>

Registrar Buses

Ver Buses

<<include>>

.Administrador
<<include>>

Registrar Separacion de Pasajes

Ver Separacionde Pasajes

<<include>>
<<include>>

,Usuario

Registrar Usuario
<<include>>

.Terminalista

Registrar Encomiendas

MATRIZ DE PRIORIZACIN DE CASOS DE USO (CUN)

Ver Encomiendas

Reservar pasaje
Reservar
encomienda
Controlar de
buses

Suministro de
informacion
x
x

Manejo de base
de datos

Reserva se pasaje: el sistema debe de permitir el registro de nuevos

usuarios en la base de datos, los nuevos usuarios deben de ser
aprobados o rechazados por un moderador antes de poder realizar una
reserva de pasaje.
Reserva de encomienda: El sistema debe de permitir ingresar a
registrar sus datos personales, en los datos del producto no se ingresa el
peso porque el peso se realizara en la misma agencia para realizar el
pago.

3.3.

ANALISIS
3.3.1.

DIAGRAMA DE COLABORACION

Separacin de Pasajes

2: Verifica los horario de Viaje

3: Verifica asientos disponibles

1: Crea un usuario para ingresar la web

4: Se efectua la separacin de pasaje con el asiento disponible

: Usuario

: Sistema

Reservas Encomiendas
2: Verifica la Programacion5: Guarda Codigo de Reserva

7: Recpcionar el Pago

6: Realiza a pesar el producto

1: Ingresa al sistema
: Terminalista

8: Emite boleta

4: Registrar sua datos personales

: Sistema

3: Solicita reservar

: Usuario

Control de buses

2: Verifica los registros de llegada y salida de buses

3: Realiza la progrmacion semanal

1: Ingresa al sistema

: Administrador

: Sistema

DIAGRAMA DE CLASES ENTIDAD

cliente
id_cliente : int
cli_dni : varchar
cli_nombre : varchar
cli_apellido : varchar
cli_direccion : varchar
cli_telefono : varchar
cli_correo : i nt
cli_estado : int

pasaje
numpasaje : int
dni : int
nombre : varchar
apellido : varchar
origen : varchar
destino : int
pago : int

1..n

1..n

1..n
usuario

giro

separacion

id_usuario : int
usuario : varchar
clave : varchar
nombre : varchar
apellido : varchar 1
di reccion : varchar
telefono : int
ni vel : int

1..n

id_separacion : int
id_cliente : int
sep_fecha : Date
sep_hora : Time
id_programacion : int 1..n
id_usuario : int
sep_importe : int
id_detall e : int

Programacion

id_programacion : int(11)
pro_hora_salida : Ti me
pro_fecha_salida : Date
id_bus : int(11)
id_destino : int(11)

destino
1

1..n

id_destino : int
destino : varchar

1..n

1..n
1..n
encomienda

1
bus
id_bus : int
bus_placa : varchar
id_marca : int
bus_estado : varchar
id_chofer : int

1
detalle
id_detall e : int
Nasiento : i nt

1..n

1
chofer
id_chofer : int
cho_nombre : varchar

3.3.3.

1..n

idecom : int
receptor : varchar
enc_peso : int
id_destino : int
id_bus : int
codigoparareci bir : int
fecha : Date

1..n

1
marca
id_marca : int
marc_descripcion : varchar
marc_estado : varchar

DIAGRAMA DE CLASES DE ANALISIS (BOUNDARY + CONTROL + ENTITIS)

id_giro
nombre_p
gir_monen
gir_fecha
gir_hora
destino
gir_monto
gir_estado

Regis trar los buses

Regitrar la Programacion
de Salidas

Administrador-

Inicia sesion

Reportes de Buses

Reportes de
Programacion de Salidas

Regitrar Rutas

Reservar Encomienda

Us uario-

Inicia sesion

Separacion de pasajes

3.3.4.

DIAGRAMA DE PAQUETES DE ANALISIS

Separacion de
pasajes

Reservar
Encomiendas

Control de
buses

3.4.

DISEO

3.4.1.

INTERFACES DE USUARIO

INTRANET

BIENVENIDO AL INTRANET

SEPARACION DE

ENVIO DE

ENCOMIENDA

PASAJES

REPORTE DE
PASAJE

REPORTE DE
ENCOMIENDA

REPORTE SEPARACION DE
PASAJES

SALIDA DE BUSES

MODELO FISICO DE LA
BASE DE DATOS
RELACIONAL (RATIONAL)

SCRIPT DE MIGRACION DE LA BASE DE

A SQL SERVER 2000

CREATE TABLE T_chofer (

id_chofer INTEGER NOT NULL,
cho_nombre VARCHAR ( 1 ) NOT
NULL,
T_chofer_ID INTEGER NOT NULL,
CONSTRAINT PK_T_chofer38 PRIMARY KEY (T_chofer_ID)
);
CREATE TABLE T_cliente (
id_cliente INTEGER NOT NULL,

DATOS

cli_dni INTEGER NOT NULL,

cli_nombre VARCHAR ( 1 ) NOT NULL,
cli_apellido VARCHAR ( 1 ) NOT NULL,
cli_direccion VARCHAR ( 1 ) NOT NULL,
cli_telefono INTEGER NOT NULL,
cli_correo VARCHAR ( 1 ) NOT NULL,
cli_estado VARCHAR ( 1 ) NOT NULL,
T_cliente_ID INTEGER NOT NULL,
CONSTRAINT PK_T_cliente31 PRIMARY KEY (T_cliente_ID)
);
CREATE TABLE T_detalle (
id_detalle INTEGER NOT NULL,
Nasiento INTEGER NOT NULL,
T_detalle_ID INTEGER NOT NULL,
CONSTRAINT PK_T_detalle40 PRIMARY KEY (T_detalle_ID)
);
CREATE TABLE T_marca (
id_marca INTEGER NOT NULL,
marc_descripcion VARCHAR ( 1 ) NOT NULL,
marc_estado VARCHAR ( 1 ) NOT NULL,
T_marca_ID INTEGER NOT NULL,
CONSTRAINT PK_T_marca39 PRIMARY KEY (T_marca_ID)
);
CREATE TABLE T_encomienda (
idecom INTEGER NOT NULL,
receptor VARCHAR ( 1 ) NOT NULL,
enc_peso INTEGER NOT NULL,
id_destino INTEGER NOT NULL,
id_bus INTEGER NOT NULL,
codigopararecibir INTEGER NOT NULL,
fecha DATE NOT NULL,
T_encomienda_ID INTEGER NOT NULL,
T_bus_ID INTEGER,
T_destino_ID INTEGER,
CONSTRAINT PK_T_encomienda35 PRIMARY KEY (T_encomienda_ID)
);
CREATE INDEX TC_T_encomienda108 ON T_encomienda (T_destino_ID );
CREATE INDEX TC_T_encomienda109 ON T_encomienda (T_bus_ID );
CREATE TABLE T_bus (
id_bus INTEGER NOT NULL,
bus_placa INTEGER NOT NULL,
id_marca INTEGER NOT NULL,
bus_estado VARCHAR ( 1 ) NOT NULL,
id_chofer INTEGER NOT NULL,
T_bus_ID INTEGER NOT NULL,
T_chofer_ID INTEGER,
T_marca_ID INTEGER,
CONSTRAINT PK_T_bus34 PRIMARY KEY (T_bus_ID)
);
CREATE INDEX TC_T_bus106 ON T_bus (T_marca_ID );
CREATE INDEX TC_T_bus107 ON T_bus (T_chofer_ID );
CREATE TABLE T_usuario (

id_usuario INTEGER NOT NULL,

usuario VARCHAR ( 1 ) NOT NULL,
clave VARCHAR ( 1 ) NOT NULL,
nombre VARCHAR ( 1 ) NOT NULL,
apellido VARCHAR ( 1 ) NOT NULL,
direccion VARCHAR ( 1 ) NOT NULL,
telefono INTEGER NOT NULL,
nivel INTEGER NOT NULL,
T_usuario_ID INTEGER NOT NULL,
CONSTRAINT PK_T_usuario30 PRIMARY KEY (T_usuario_ID)
);
CREATE TABLE T_separacion (
id_separacion INTEGER NOT NULL,
id_cliente INTEGER NOT NULL,
sep_fecha DATE NOT NULL,
sep_hora TIME ( 2147483647 ) NOT NULL,
id_programacion INTEGER NOT NULL,
id_usuario INTEGER NOT NULL,
sep_importe INTEGER NOT NULL,
id_detalle INTEGER NOT NULL,
T_separacion_ID INTEGER NOT NULL,
T_usuario_ID INTEGER,
T_cliente_ID INTEGER,
T_cliente_T_cliente_ID INTEGER,
T_detalle_ID INTEGER,
CONSTRAINT PK_T_separacion32 PRIMARY KEY (T_separacion_ID)
);
CREATE INDEX TC_T_separacion102 ON T_separacion (T_detalle_ID );
CREATE INDEX TC_T_separacion101 ON T_separacion (T_usuario_ID );
CREATE INDEX TC_T_separacion100 ON T_separacion (T_cliente_ID );
CREATE INDEX TC_T_separacion99 ON T_separacion
(T_cliente_T_cliente_ID );
CREATE TABLE T_destino (
id_destino INTEGER NOT NULL,
destino VARCHAR ( 1 ) NOT NULL,
T_destino_ID INTEGER NOT NULL,
T_Programacion_ID INTEGER,
CONSTRAINT PK_T_destino36 PRIMARY KEY (T_destino_ID)
);
CREATE INDEX TC_T_destino110 ON T_destino (T_Programacion_ID );
CREATE TABLE T_Programacion (
id_programacion INTEGER NOT NULL,
pro_hora_salida TIME ( 2147483647 ) NOT NULL,
pro_fecha_salida DATE NOT NULL,
id_bus INTEGER NOT NULL,
id_destino INTEGER NOT NULL,
T_Programacion_ID INTEGER NOT NULL,
T_separacion_ID INTEGER,
T_bus_ID INTEGER,
T_bus_T_bus_ID INTEGER,
CONSTRAINT PK_T_Programacion33 PRIMARY KEY
(T_Programacion_ID)

);
CREATE INDEX TC_T_Programacion103 ON T_Programacion (T_bus_ID );
CREATE INDEX TC_T_Programacion105 ON T_Programacion
(T_bus_T_bus_ID );
CREATE INDEX TC_T_Programacion104 ON T_Programacion
(T_separacion_ID );
ALTER TABLE T_destino ADD CONSTRAINT FK_T_destino40 FOREIGN KEY
(T_Programacion_ID) REFERENCES T_Programacion (T_Programacion_ID)
ON DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_encomienda ADD CONSTRAINT FK_T_encomienda44 FOREIGN
KEY (T_destino_ID) REFERENCES T_destino (T_destino_ID) ON DELETE
NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_encomienda ADD CONSTRAINT FK_T_encomienda43 FOREIGN
KEY (T_bus_ID) REFERENCES T_bus (T_bus_ID) ON DELETE NO ACTION ON
UPDATE NO ACTION;
ALTER TABLE T_giro ADD CONSTRAINT FK_T_giro45 FOREIGN KEY
(T_destino_ID) REFERENCES T_destino (T_destino_ID) ON DELETE NO
ACTION ON UPDATE NO ACTION;
ALTER TABLE T_Programacion ADD CONSTRAINT FK_T_Programacion41
FOREIGN KEY (T_bus_ID) REFERENCES T_bus (T_bus_ID) ON DELETE NO
ACTION ON UPDATE NO ACTION;
ALTER TABLE T_Programacion ADD CONSTRAINT FK_T_Programacion39
FOREIGN KEY (T_separacion_ID) REFERENCES T_separacion
(T_separacion_ID) ON DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_Programacion ADD CONSTRAINT FK_T_Programacion42
FOREIGN KEY (T_bus_T_bus_ID) REFERENCES T_bus (T_bus_ID) ON
DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_separacion ADD CONSTRAINT FK_T_separacion38 FOREIGN
KEY (T_cliente_T_cliente_ID) REFERENCES T_cliente (T_cliente_ID)
ON DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_separacion ADD CONSTRAINT FK_T_separacion37 FOREIGN
KEY (T_cliente_ID) REFERENCES T_cliente (T_cliente_ID) ON DELETE
NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_separacion ADD CONSTRAINT FK_T_separacion36 FOREIGN
KEY (T_usuario_ID) REFERENCES T_usuario (T_usuario_ID) ON DELETE
NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_separacion ADD CONSTRAINT FK_T_separacion48 FOREIGN
KEY (T_detalle_ID) REFERENCES T_detalle (T_detalle_ID) ON DELETE
NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_bus ADD CONSTRAINT FK_T_bus47 FOREIGN KEY
(T_marca_ID) REFERENCES T_marca (T_marca_ID) ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE T_bus ADD CONSTRAINT FK_T_bus46 FOREIGN KEY
(T_chofer_ID) REFERENCES T_chofer (T_chofer_ID) ON DELETE NO
ACTION ON UPDATE NO ACTION;

CONCLUSIONES

Toda

recopilacin de la informacin para realizar el

proyecto fue gracias a los socios de la empresa que

amablemente nos brindaron, ya contamos con mucha
comunicaciones para poder obtener las informaciones
requeridas. Esto nos sirvi para una mejor formulacin
de nuestro proyecto.
Para platear los procesos del proyecto realizamos los
requerimientos que tiene la empresa en cuanto a sus
procesos actuales, por el cual optamos por los
procesos

de

reserva

de

pasajes

reserva

de

encomienda.
Los diseos de los procesos presentados en el
proyecto se desarrollaron con xito, gracias a los
programas utilizados, que fueron de mucha utilidad.
El anlisis y diseo desarrollado en el proyecto para
los procesos de reserva de pasaje

y encomienda

tendr la eficiencia en cuanto a negocio que tiene la

empresa turismo Barranca, tendra mejoras en cuanto
a sus servicios brindados al pblico en general.

RECOMENDACIONES

Las recomendaciones para la empresas de trasporte

que es muy beneficioso utilizar estos tipos de sistemas
web para para la mejora de su empresa ya que con los
procesos de reserva de pasajes y reserva estaras
brindando un mejor servicio al pblico, algo que el
pblico espera, tener comodidades y facilidades de
obtener los servicios de la empresa ya que desde su
casa podra realizar dichos procesos

REFERENCIAS BIBLIOGRAFICAS Y/O

ENLACES WEB
Autor

: Jennifer Niederst Robbins Learning web design

Editorial: OReilly
Autor

: Equipo vrtice Tcnicas avanzadas de diseo

Editorial: Editorial Vrtice

Autor

: Rebecca Murphey jQuery Fundamentals

Editorial: --Autor

: Shay Howe Guide to HTML & CSS

Editorial: --Autor

: Javier Eguiluz Introduccin a AJAX

Editorial: --Autor

: Desarrollo Web Diseo y Programacin de Pginas Web

Editor

: Miguel ngel Pedregosa Pareja

BIBLIOGRAFIA
http://www.universidadperu.com/empresas/emptransportes-turismo-barranca.php
http://www.monografias.com/trabajos5/insof/insof.shtml
http://docente.ucol.mx/sadanary/public_html/bd/cs.htm
http://www.ecured.cu/index.php/Sistema_Gestor_de_Base_de_Datos
http://www.aprenderaprogramar.com/index.php?option=com_content&id=492:iquees-php-y-ipara-que-sirve-un-potente-lenguaje-de-programacion-para-crearpaginas-web-cu00803b&Itemid=193
http://www.ittsabus.com/
http://www.floreshnos.net/
http://www.zarqun.com/2013/02/el-gran-libro-de-diseno-web-en-pdf/
http://www.lawebdelprogramador.com/foros/JQuery/1405129Exportar_a_excel_o_pdf_con_jquery.html
https://donestandares.wordpress.com/2011/09/05/generar-archivos-de-excel-y-worddesde-php-casi-por-arte-de-magia/

APENDICES
OTROS FORMATOS DE INFORMACION

ANEXOS

COPIAS DE LOS DOCUMENTOS FUENTES ENCONTRADOS

PERMISO

BOLETO DE VIAJE

-FOTOS

ASIENTO DE ESPERA

CAFETERIA

ENTRADA A LA VENTA DE PASAJES Y EMBARQUE