Professional Documents
Culture Documents
INTRODUCCION...................................................................................................................................1
CAPITULO I............................................................................................................................................2
1. DEFINICION DEL PROBLEMA.....................................................................................................3
1.1. SITUACION PROBLEMTICA...............................................................................................3
1.2. SOLUCION DESEADA.............................................................................................................3
2. OBJETIVOS......................................................................................................................................4
2.1. OBJETIVO GENERAL..............................................................................................................4
2.2. OBJETIVOS ESPECIFICOS......................................................................................................4
3. METODOLOGIA..............................................................................................................................4
3.1. INICIO........................................................................................................................................4
3.2. ELABORACION........................................................................................................................5
3.3. CONSTRUCCION......................................................................................................................6
CAPITULO II..........................................................................................................................................7
5. MARCO TEORICO...........................................................................................................................8
5.1. CORREO ELECTRONICO........................................................................................................8
5.2. FUNCIONAMIENTO DEL CORREO ELECTRONICO..........................................................8
5.3. PROTOCOLO SMTP................................................................................................................10
5.3.1 Modo de Comunicacin SMTP.........................................................................................10
5.4. MIME........................................................................................................................................11
5.4.1. MIME HEADERS.............................................................................................................12
5.5. PROTOCOLO POP3.................................................................................................................12
5.6. SENDMAIL..............................................................................................................................14
CAPITULO III.......................................................................................................................................16
6. CAPTURA DE REQUISITOS DEL SISTEMA..............................................................................17
6.1. REQUISITOS FUNCIONALES...............................................................................................17
6.2. IDENTIFICAR ACTORES.......................................................................................................17
6.3. IDENTIFICAR CASOS DE USOS..........................................................................................17
6.4. PRIORIZACION DE CASOS DE USO...................................................................................18
6.5. DETALLE DE CASOS DE USO..............................................................................................19
6.5.1 CU1 GESTIONAR CAMPEONATO................................................................................19
6.5.2 CU2 GESTIONAR EMPLEADO......................................................................................20
6.5.3 CU3 GESTIONAR CLIENTES........................................................................................21
6.5.4 CU4 GESTIONAR TIPO CANCHA.................................................................................21
6.5.5 CU6 GESTIONAR CANCHA..........................................................................................23
6.5.6 CU5 GESTIONAR CORREO (LEER, ENVIAR)............................................................23
6.5.7 CU7 GESTIONAR ILUMINACION................................................................................25
6.5.8 CU8 GESTIONAR EQUIPOS..........................................................................................26
6.5.9 CU8 GESTIONAR RESERVA..........................................................................................26
6.6. DIAGRAMA GENERAL DE CASOS DE USOS....................................................................27
CAPITULO IV.......................................................................................................................................29
7. ANALISIS DE LA ARQUITECTURA...........................................................................................30
7.1. ANALISIS DE PAQUETES.....................................................................................................30
7.1.1. PAQUETE ADMINISTRACION......................................................................................30
7.1.2. PAQUETE RESERVA.......................................................................................................30
CAPITULO V.........................................................................................................................................32
8. DISEO DEL SISTEMA................................................................................................................33
8.1. DISEO DE LA ARQUITECTURA FISICA..........................................................................33
8.2. DISEO DE LA ARQUITECTURA LOGICA........................................................................33
8.2.1. PAQUETE ADMINISTRACION......................................................................................33
8.2.2. PAQUETE TIPO CANCHA..............................................................................................33
8.3. DISEO DE LA INTERFAZ....................................................................................................34
8.4. DISEO DE LA BASE DE DATOS........................................................................................37
8.4.1. DISEO CONCEPTUAL.................................................................................................37
8.4.2. DISEO LOGICO.............................................................................................................37
Bibliografa..............................................................................................................................................41
TECNOLOGIA WEB 2017
INTRODUCCION
En los establecimientos donde se reserven canchas sintticas requieren un sistema para administrar la
reserva de sus canchas a sus clientes para un mejor control y funcionamiento del negocio y para la
comodidad de los clientes que requieren hacer sus reservaciones.
Una de las mayores dificultades que encuentran los aficionados al ftbol es encontrar una cancha para
jugar con su grupo de amigos. Igualmente, muchos de los establecimientos que prestan este servicio
an no cuentan con suficientes herramientas tecnolgicas que faciliten la reserva a los usuarios y
tambin no cuentan con una buena organizacin al momento de realizar los campeonatos.
Los usuarios que asisten a las canchas alquiladas, no obtienen una informacin fcilmente para la
eleccin de las canchas disponibles, por lo que los lleva a realizar varias llamadas para saber horarios
disponibles, precio, ubicacin y tipo de cancha, aparte ponerse de acuerdo con los dems jugadores del
equipo o ya sea su rival se les hace ms complicado y pierden tiempo y dinero por el uso de las
llamadas.
Para la reserva de las canchas se necesita depositar una parte del costo del alquiler para la seguridad del
dueo del complejo deportivo, esto hace que sea necesario q una persona vaya y cancele ese monto, lo
que muchas veces no es posible ir hasta el mismo complejo y les dificulta la reserva.
Con este proyecto se pretende ayudar a mejorar el servicio que brindan estos establecimientos a sus
clientes brindndoles una aplicacin que les ayude a registrar las reservas a sus clientes(que no sea
necesario que el cliente valla al establecimiento o llame para saber si hay canchas disponibles y pueda
fijarse que horarios estn disponibles y que das) y tambin para que puedan hacer los
campeonatos(que los clientes puedan saber cundo se va a hacer un campeonato, y detalles de tal
campeonato como ser:precio de inscripcin,premios,dia del campeonato,tipo de campeonato,ect)
1
TECNOLOGIA WEB 2017
CAPITULO
I PERFIL DEL PROYECTO
2
TECNOLOGIA WEB 2017
Una de las mayores dificultades que encuentran los aficionados al ftbol es encontrar una cancha
para jugar con su grupo de amigos. Igualmente, muchos de los establecimientos que prestan este
servicio an no cuentan con suficientes herramientas tecnolgicas que faciliten la reserva a los
usuarios y tambin no cuentan con una buena organizacin al momento de realizar los
campeonatos.
Los usuarios que asisten a las canchas alquiladas, no obtienen una informacin fcilmente para la
eleccin de las canchas disponibles, por lo que los lleva a realizar varias llamadas para saber
horarios disponibles, precio, ubicacin y tipo de cancha, aparte ponerse de acuerdo con los dems
jugadores del equipo o ya sea su rival se les hace ms complicado y pierden tiempo y dinero por el
uso de las llamadas.
Para la reserva de las canchas se necesita depositar una parte del costo del alquiler para la seguridad
del dueo del complejo deportivo, esto hace que sea necesario q una persona vaya y cancele ese
monto, lo que muchas veces no es posible ir hasta el mismo complejo y les dificulta la reserva.
En la actualidad se las personas que buscan una cancha para hacer deporte debe ir fisicamente al
establecimiento para poder hacer la reserva, y no tienen la seguridad de encontrar una cancha
disponible,ademas de no poder existir un lugar en donde ver los campeonatos disponibles e
infomacion al respecto.
3
TECNOLOGIA WEB 2017
2. OBJETIVOS
2.1. OBJETIVO GENERAL
Desarrollar un Sistema Mail para la Reserca de Canchas y un Servidor para recepcion de correos.
Definir los requerimientos del sistema realizando entrevistas a los funcionarios que operan en la
institucion.
Preparar un correcto analisis de los requerimientos identificados con el proposito de identificar
las funciones que deben implementarse en el proceso de desarrollo de software.
Dise ar la base de datos acorde a los requisitos previamente requeridos
Implementar el sistema en base a las especificaciones del diseo utilizando el lenguaje de
programacion java y organizando en paquetes.
Analizar las fuentes de informacin del proceso de desarrollo con correo electrnico, as como
tambin los requerimientos para el desarrollo del mismo.
Realizar todas las pruebas necesarias para garantizar la funcionalidad y cumplimiento de los
requerimientos del sistema y una mejor experiencia del usuario.
3. METODOLOGIA
La metodologa escogida para el proyecto es el Proceso Unificado de Desarrollo de Software
(PUDS), debido a que es un conjunto de actividades necesarias para transformar los requisitos de
un usuario en un sistema de software, el proceso unificado es ms que un simple proceso; es un
marco de trabajo genrico que puede utilizarse para una gran variedad de sistemas software.
[ CITATION Jac98 \l 1033 ]
Adems, el proceso unificado est basado en componentes, lo cual quiere decir que el software que
se desarrolla ser un sistema de componentes interconectados. El proceso unificado utiliza el
Lenguaje Unificado de Modelado UML para preparar todos los esquemas de un sistema software.
Se implementara esta metodologa dando mayor importancia en las fases que se indicaran a
continuacin:
4
TECNOLOGIA WEB 2017
3.1. INICIO
En la fase de inicio se tomara el tiempo necesario para recolectar la informacin necesaria acerca de
las empresas que trabajan con alquileres de canchas y se tratara de entender la mayora del proceso
de negocio.
Tambin se pondr nfasis en el flujo de trabajo: Captura de Requisitos, se buscara definir los
requisitos funcionales de manera puntual y sin ambigedad, se detallara la mayora de los
requerimientos tomando en cuenta la prioridad, tambin se desarrollaran algunos prototipos.
Resultado esperado:
3.2. ELABORACION
En esta fase se nos centraremos en especificar todos los casos de uso de manera puntual y sin
ambigedad, se detallara cada requerimiento de forma que no quede dudas sobre el proceso,
tambin se terminaran los prototipos.
Se buscara empezar con el diseo del sistema, identificando los paquetes con todos sus
requerimientos y sus dependencias, tambin se realizaran los esquemas de algunos casos de uso
para ir conociendo la interaccin que tendr el sistema.
Resultado esperado:
5
TECNOLOGIA WEB 2017
Realizacin de caso de uso (prioridad media) vista de diseo (Diagrama de clases dinmicas y de
secuencia).
3.3. CONSTRUCCION
El objetivo a seguir en esta fase ser llevar al sistema a una operatividad inicial poniendo un
nfasis total en el flujo de trabajo: Implementacin y un cierto grado en prueba. Con el fin de poder
evidenciar la funcionalidad del sistema.
Resultado esperado:
6
TECNOLOGIA WEB 2017
CAPITULO
II MARCO TEORICO
7
TECNOLOGIA WEB 2017
MARCO TEORICO
5. MARCO TEORICO
5.1. CORREO ELECTRONICO
El correo electrnico gira alrededor del uso de las casillas de correo electrnico. Cuando se enva un
correo electrnico, el mensaje se enruta de servidor a servidor hasta llegar al servidor de correo
electrnico del receptor. Ms precisamente, el mensaje se enva al servidor del correo electrnico
(llamado MTA, del ingls Mail TransportAgent [Empleado de Transporte de Correo]) que tiene la tarea
de transportarlos hacia el MTA del destinatario. En Internet, los MTA se comunican entre s usando el
protocolo SMTP, y por lo tanto se los llama servidores SMTP (o a veces servidores de correo saliente).
Luego el MTA del destinatario entrega el correo electrnico al servidor del correo entrante (llamado
MDA, del ingls Mail DeliveryAgent [Empleado de Entrega de Correo]), el cual almacena el correo
electrnico mientras espera que el usuario lo acepte. Existen dos protocolos principales utilizados para
recuperar un correo electrnico de un MDA:
POP3 (Post Office Protocol [Protocolo de Oficina de Correo]), el ms antiguo de los dos, que
se usa para recuperar el correo electrnico y, en algunos casos, dejar una copia en el servidor.
IMAP (Internet Message Access Protocol [Protocolo de Acceso a Mensajes de Internet]), el cual
se usa para coordinar el estado de los correos electrnicos (ledo, eliminado, movido) a travs
8
TECNOLOGIA WEB 2017
de mltiples clientes de correo electrnico. Con IMAP, se guarda una copia de cada mensaje en
el servidor, de manera que esta tarea de sincronizacin se pueda completar.
Por esta razn, los servidores de correo entrante se llaman servidores POP o servidores IMAP, segn
el protocolo usado.
Ilustracin 7 Grafica
del Servidor POP
Usando una
analoga del
mundo real, los
MTA actan
como la oficina
de correo (el rea
de clasificacin y
de transmisin, que se encarga del transporte del mensaje), mientras que los MDA actan como casillas
de correo, que almacenan mensajes (tanto como les permita su volumen), hasta que los destinatarios
controlan su casilla. Esto significa que no es necesario que los destinatarios estn conectados para
poder enviarles un correo electrnico.
Para evitar que cualquiera lea los correos electrnicos de otros usuarios, el MDA est protegido por un
nombre de usuario llamado registro y una contrasea.
La recuperacin del correo se logra a travs de un programa de software llamado MUA (Mail
UserAgent [Empleado Usuario de Correo]).
Cuando el MUA es un programa instalado en el sistema del usuario, se llama cliente de correo
electrnico (tales como Mozilla Thunderbird, Microsoft Outlook, Eudora Mail, Incredimail o Lotus
Notes).
Cuando se usa una interfaz de web para interactuar con el servidor de correo entrante, se llama correo
electrnico.
9
TECNOLOGIA WEB 2017
El significado de las siglas de SMTP es Protocolo Simple de Transmisin de Correo ("Simple Mail
Transfer Protocol", RFC 821). Este protocolo es el estndar de Internet para el intercambio de
correo electrnico. SMTP necesita que el sistema de transmisin ponga a su disposicin un canal de
comunicacin fiable y con entrega ordenada de paquetes, con lo cual, el uso del protocolo TCP (puerto
25) en la capa de transporte, es lo adecuado. Para que dos sistemas intercambien correo mediante el
protocolo SMTP, no es necesario que exista una conexin interactiva, ya que este protocolo usa
mtodos de almacenamiento y reenvo de mensajes.
Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP, el emisor (servidor
que inicia la sesin SMTP) establece una conexin con el receptor (servidor que recibe peticin de
establecer sesin SMTP). Esta conexin es unidireccional, es decir, el emisor puede enviar correo al
receptor, pero durante esa conexin, el receptor no puede enviar correo al emisor. Si el receptor tiene
que enviar correo al emisor, tiene que esperar a que finalice la conexin establecida y establecer otra en
sentido contrario, cambiando los papeles de emisor y receptor. Una vez establecida la conexin, el
emisor enva comandos y mensajes.
Por lo tanto, el diseo de SMTP se basa en el siguiente modelo de comunicacin:
1. Como respuesta a una solicitud de un usuario de enviar un correo electrnico, el emisor
SMTP establece una conexin con el receptor SMTP. El receptor SMTP debe ser el destinatario
ltimo del correo o un intermediario. Para ello el emisor genera los comandos SMTP en formato
ASCII y los enva al receptor y el receptor genera las respuestas a los comandos enviados por el
emisor.
2. Una vez establecido el canal de transmisin, el emisor enva el comando MAIL para
indicando que l es el emisor del correo. Si el receptor puede aceptar correo responde con el
comando OK.
3. El emisor enva el comando RCPT identificando el destinatario del correo. Si el receptor
puede aceptar correo para ese destino responde con una respuesta OK; si no, responde
rechazando el correo para ese destino.
4. Una vez negociado el destino, el emisor comienza a enviar datos (cabeceras y cuerpo),
terminando con una secuencia especial. Si el receptor ha procesado correctamente los datos,
responde con el comando OK.
10
TECNOLOGIA WEB 2017
5.4. MIME
- Internet Mail Extensions o MIME (en espaol "extensiones multipropsito de correo de internet") son
una serie de convenciones o especificaciones dirigidas al intercambio a travs de Internet de todo tipo
de archivos (texto, audio, vdeo, etc.) de forma transparente para el usuario. Una parte importante del
MIME est dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y
alfabetos.
Prcticamente todos los mensajes de correo electrnico escritos por personas en Internet y una
proporcin considerable de estos mensajes generados automticamente son transmitidos en formato
MIME a travs de SMTP. Los mensajes de correo electrnico en Internet estn tan cercanamente
asociados con el SMTP y MIME que usualmente se les llama mensaje SMTP/MIME
MIME est especificado en seis RequestforComments o RFC (en espaol "solicitud de comentarios):
RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2077
Los tipos de contenido definidos por el estndar MIME tienen gran importancia tambin fuera del
contexto de los mensajes electrnicos. Ejemplo de esto son algunos protocolos de red tales como HTTP
de la Web. HTTP requiere que los datos sean transmitidos en un contexto de mensajes tipo e-mail
aunque los datos pueden no ser un e-mail propiamente dicho.
En la actualidad ningn programa de correo electrnico o navegador de Internet puede considerarse
completo si no acepta MIME en sus diferentes facetas (texto y formatos de archivo).
El protocolo SMPT soporta solo caracteres ASCII de 7 bit (vase tambin 8BITMIME). Esto limita los
mensajes de correo electrnico, ya que incluyen solo caracteres suficientes para escribir en un nmero
reducido de lenguajes, principalmente Ingls. Otros lenguajes basados en el Alfabeto latino es
adicionalmente un componente fundamental en protocolos de comunicacin como HTTP, el que
requiere que los datos sean transmitidos como un e-mail aunque los datos pueden no ser un e-mail
propiamente dicho. Los clientes de correo y los servidores de correo convierten automticamente desde
y a formato MIME cuando envan o reciben (SMTP/MIME) e-mails.
11
TECNOLOGIA WEB 2017
<html>
<body>
<h2>EsteesunlinkalaUAGRM!</h2>
clickaqui!<ahref="http://www.uagrm.edu.bo">UAGRM</a>
</body>
</html>
.
QUIT
El protocolo POP (Protocolo de oficina de correos), como su nombre lo indica, permite recoger el
correo electrnico en un servidor remoto (servidor POP). Es necesario para las personas que no estn
permanentemente conectadas a Internet, ya que as pueden consultar sus correos electrnicos recibidos
sin que ellos estn conectados.
Existen dos versiones principales de este protocolo, POP2 y POP3, a los que se le asignan los puertos
109 y 110 respectivamente, y que funcionan utilizando comandos de texto radicalmente diferentes.
Al igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con comandos de
texto enviados al servidor POP. Cada uno de estos comandos enviados por el cliente (validados por la
cadena CR/LF) est compuesto por una palabra clave, posiblemente acompaada por uno o varios
12
TECNOLOGIA WEB 2017
argumentos, y est seguido por una respuesta del servidor POP compuesta por un nmero y un mensaje
descriptivo.
A continuacin se brinda un resumen de los principales comandos POP3:
COMANDO DESCRIPCIN
USER Este comando permite la autenticacin. Debe estar seguido del
nombre de usuario, es decir, una cadena de caracteres que
identifique al usuario en el servidor. El comando USER debe
preceder al comando PASS.
PASS El comando PASS permite especificar la contrasea del usuario
cuyo nombre ha sido especificado por un comando USER previo.
STAT Informacin acerca de los mensajes del servidor
RETR Nmero del mensaje que se va a recoger
DELE Nmero del mensaje que se va a eliminar
LIST [msg] Nmero del mensaje que se va a mostrar
NOOP Permite mantener la conexin abierta en caso de inactividad
TOP Comando que muestra n lneas del mensaje, cuyo nmero se da en
<messageID><n>
el argumento. En el caso de una respuesta positiva del servidor,
ste enviar de vuelta los encabezados del mensaje, despus una
lnea en blanco y finalmente las primerasn lneas del mensaje.
UIDL [msg] Solicitud al servidor para que enve una lnea que contenga
informacin sobre el mensaje que eventualmente se dar en el
argumento. Esta lnea contiene una cadena de caracteres
denominada uniqueidentifierlisting (lista de identificadores
nicos) que permite identificar de manera nica el mensaje en el
servidor, independientemente de la sesin. El argumento opcional
es un nmero relacionado con un mensaje existente en el servidor
POP, es decir, un mensaje que no se ha borrado.
QUIT El comando QUIT solicita la salida del servidor POP3. Lleva a la
eliminacin de todos los mensajes marcados como eliminados y
enva el estado de esta accin.
Por lo tanto, el protocolo POP3 administra la autenticacin utilizando el nombre de usuario y la
contrasea. Sin embargo, esto no es seguro, ya que las contraseas, al igual que los correos
electrnicos, circulan por la red como texto sin codificar (de manera no cifrada). En realidad, segn
RFC 1939, es posible cifrar la contrasea utilizando un algoritmo MD5 y beneficiarse de una
autenticacin segura. Sin embargo, debido a que este comando es opcional, pocos servidores lo
implementan. Adems, el protocolo POP3 bloquea las bandejas de entrada durante el acceso, lo que
significa que es imposible que dos usuarios accedan de manera simultnea a la misma bandeja de
entrada.
13
TECNOLOGIA WEB 2017
5.6. SENDMAIL
Es un MTA (Empleado de transporte de correo), que es el programa que se encarga de mover el correo
de una mquina a otra.
Sendmail lleva incorporado aliasing y fordwarding, rutado automtico hacia puertas de enlace, y una
configuracin flexible. Es una solucin potente para cualquier entorno.
Sendmail es el Empleado de transporte de correo ms comn de Internet (en los sistemas UNIX).
Aunque acta principalmente como MTA, tambin puede ser utilizado como MUA (aunque no posee
interfaz de usuario). Las misiones bsicas de Sendmail son las siguientes:
Recogida de mails provenientes de un Mail UserAgent (MUA) como pueden ser elm, Eudora o
pine; o provinientes de un Mail TransportAgent (MTA) como puede ser el propio Sendmail.
Eleccin de la estrategia de reparto de los mails, basndose en la informacin de la direccin del
destinatario contenida en la cabecera:
Si el mail es local en nuestro sistema, enviar el mail al programa de reparto local de
mails
Si el mail no es local, Sendmail utilizar el DNS de nuestro sistema para determinar el
host al que debe ser enviado el mail. Para transferir el mensaje.
IniciarunasesinSMTPconel MTAde dicho host.
Si no es posible mandar el mail a su destino (porque la maquina receptora esta
desconectada, o va muy lenta), Sendmail almacenar los mails en una cola de correo, y
volver a intentar el envo del mail un tiempo despus. Si el mail no puede ser enviado
tras un tiempo raCANCHAble, el mail ser devuelto a su autor con un mensaje de error.
Sendmail debe garantizar que cada mensaje llegue correctamente a su destino, o si hay
error este debe ser notificado (ningn mail debe perderse completamente).
Reformatear el mail antes de pasarlo a la siguiente mquina, segn unas reglas de reescritura.
Segn el tipo de conexin que poseamos con una determinada mquina, o segn el Empleado de
transporte al que vaya dirigido el mail, necesitaremos cambiar los formatos de las direcciones del
remitente y del destinatario, algunas lneas de la cabecera del mail, o incluso puede que
necesitemos aadir alguna lnea a la cabecera. Sendmail debe realizar todas estas tareas para
conseguir la mxima compatibilidad entre usuarios distintos.
14
TECNOLOGIA WEB 2017
Otra funcin muy importante de Sendmail es permitir el uso de "alias" entre los usuarios del
sistema; lo que nos permitir (entre otras funciones) crear y mantener listas de correo entre
grupos.
Ejecucin como Empleado de usuario (MUA). Aunque no posee interfaz de usuario, Sendmail
tambin permite el envo directo de mails a travs de su ejecutable.
Todas estas caractersticas y muchas otras que posee el Sendmail deben ser configuradas y variarn de
unos sistemas a otros. Para configurarlas hacemos uso del fichero de configuracin de Sendmail. La
revisin y modificacin de este fichero es bastante complicada y necesita de una serie de conocimientos
previos.
15
TECNOLOGIA WEB 2017
CAPITULO
IIICAPTURA DE REQUISITOS
16
TECNOLOGIA WEB 2017
CAPTURA DE REQUISITOS
6. CAPTURA DE REQUISITOS DEL SISTEMA
6.1. REQUISITOS FUNCIONALES
Los requisitos funcionales que se presentaran a continuacion son aquellos que debe proporcionar el
software donde se puede ver y apreciar como reaccionara ante la entrada de datos y que hacer con
los mismos los cuales se describiran a continuacion:
Cliente.-Es quien reserva canchas y registra equipos de futbol, asi tambien puede consultar
informacion sobre los campeonatos.
Los siguientes casos de uso identificados son los que se deben desarrollar en el transcurso del
desarrollo del software los cuales detallaremos a continuacion.
CU1.-Gestionar Campeonatos
CU2.-Gestionar Empleados
CU3.-Gestionar Clientes
17
TECNOLOGIA WEB 2017
CU5.-Gestionar Canchas
CU7.-Gestionar Iluminacion
CU8.-Gestionar Equipos
CU9.-Gestionar Reservas
18
TECNOLOGIA WEB 2017
19
TECNOLOGIA WEB 2017
6.5.2 CU2 GESTIONAR EMPLEADO
20
TECNOLOGIA WEB 2017
22
TECNOLOGIA WEB 2017
23
TECNOLOGIA WEB 2017
25
TECNOLOGIA WEB 2017
26
TECNOLOGIA WEB 2017
CAPITULO
IV ANALISIS
27
TECNOLOGIA WEB 2017
ANALISIS
7. ANALISIS DE LA ARQUITECTURA
7.1. ANALISIS DE PAQUETES
7.1.1.PAQUETE ADMINISTRACION
28
TECNOLOGIA WEB 2017
7.1.2.PAQUETE RESERVA
29
TECNOLOGIA WEB 2017
30
TECNOLOGIA WEB 2017
CAPITULO
V DISEO
31
TECNOLOGIA WEB 2017
32
TECNOLOGIA WEB 2017
33
TECNOLOGIA WEB 2017
34
TECNOLOGIA WEB 2017
35
TECNOLOGIA WEB 2017
8.4.2.DISEO LOGICO
8.4.2.1. MAPEO DE TABLAS
CAMPEONATO
Id_campeonato precio Fecha_inicio dias
PK F.K F.K
EMPLEADO
Id_empleado nombre telefono
PK
CLIENTE
36
TECNOLOGIA WEB 2017
TIPO CANCHA
ID_tipo_canchax tipo
PK
CANCHA
Id_cancha nombre precio ubicacion estado
PK
ILUMINACION
Id_iluminacion CANCHA estado Id_cancha estado
PK FK
CAMPEONATO
TIPO DE
ATRIBUTOS LLAVE AMPLITUD NULO DESCRIPCIN
DATOS
Codigo del Tipo de
Den_id PK Entero NO CAMPEONATO
Nombre del Tipo de
Den_descripcion Alfanumrico 50 caracteres NO CAMPEONATO
Codigo del
Ciu_id FK Entero NO ILUMINACION
Codigo del
Ofi_id FK Entero NO CANCHA
EMPLEADO
TIPO DE
ATRIBUTOS LLAVE AMPLITUD NULO DESCRIPCIN
DATOS
Codigo del
Deli_id PK Entero NO EMPLEADO
37
TECNOLOGIA WEB 2017
Nombre del
Deli_nombre Alfanumerico 50 caracteres NO EMPLEADO
Descripcion del
Deli_descripcion Alfanumerico 50 caracteres NO EMPLEADO
CLIENTE
TIPO DE
ATRIBUTOS LLAVE AMPLITUD NULO DESCRIPCIN
DATOS
Codigo del
Den_id FK Entero NO CAMPEONATO
Codigo del
Deli_id FK Entero NO EMPLEADO
ILUMINACION
TIPO DE
ATRIBUTOS LLAVE AMPLITUD NULO DESCRIPCIN
DATOS
Codigo del
Ciu_id PK Entero NO ILUMINACION
Carnet de identidad
Ciu_ci Entero NO del ILUMINACION
Nombre del
Ciu_nombre Alfanumerico 50 caracteres NO ILUMINACION
CANCHA
ATRIBUTOS LLAVE TIPO DE DATOS AMPLITUD NULO DESCRIPCIN
Codigo del
Ofi_id PK Entero NO CANCHA
Nombre del
Ofi_nombre Alfanumrico 50 caracteres NO CANCHA
Ofi_grado Alfanumerico 50 caracteres NO Grado del CANCHA
Correo del
Ofi_correo Alfanumerico 50 caracteres NO CANCHA
38
TECNOLOGIA WEB 2017
Nombre del
Del_nombre Alfanumrico 50 caracteres NO delincuente
Carnet de identidad
Del_ci Alfanumerico 50 caracteres NO del delincuente
Codigo de
Den_id FK Entero NO CAMPEONATO
CLIENTE
TIPO DE
ATRIBUTOS LLAVE AMPLITUD NULO DESCRIPCIN
DATOS
Pat_id PK Entero NO Codigo de CLIENTE
Modelo de
Pat_modelo Alfanumerico 50 caracteres NO CLIENTE
CANCHA
TIPO DE
ATRIBUTOS LLAVE AMPLITUD NULO DESCRIPCIN
DATOS
Codigo de la
Zon_id PK Entero NO CANCHA
Nombre de la
Zon_nombre Alfanumrico 50 caracteres NO CANCHA
Ubicacin de la
Zon_ubicacion Alfanumerico 50 caracteres NO CANCHA
Bibliografa
39
TECNOLOGIA WEB 2017
5) El correo electrnico origen y funcionamiento [en lnea].[consulta: 29-mayo- 2012]. Disponible
en:< http://www.tecnocosas.es/el-correo-electronico-origen-y-funcionamiento >
6) Historia del correo electrnico [en lnea].[consulta: 1-junio-2012]. Disponible en:<
http://www.maestrosdelweb.com/editorial/emailhis >
7) Wikipedia- Multipurpose_Internet_Mail_Extensions. [en lnea].[consulta: 3-junio-2012].
Disponible en:<http://es.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions >
8) Instalacin de un servidor de correo send mail. [en lnea].[consulta: 3-junio-2012]. Disponible
en:< http://www.cybercursos.net >
9) Wikipedia- NetBeans. [en lnea].[consulta: 3-junio-2012]. Disponible en:<
es.wikipedia.org/wiki/NetBeans>
40