You are on page 1of 42

Contenido

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

PERFIL DEL PROYECTO

1. DEFINICION DEL PROBLEMA

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.

1.1. SITUACION PROBLEMTICA

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.

1.2. SOLUCION DESEADA

Proveer de un Sistema Mail para la reserva de canchas y un Servidor especificamente para la


recepcion de correos en la cual sera de ayuda para la institucion, y tanto clientes como personal de
la institucion puedan ver campeonatos, y ver canchas disponibles a reservar sin necesidad de salir
de sus casas.

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.

2.2. OBJETIVOS ESPECIFICOS

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:

Requisitos funcionales y no funcionales.

Lista actores y casos de uso.

Detalle de casos de uso.

Prototipos de los casos de uso de mayor prioridad.

Realizacin de casos de uso de prioridad alta, vista de anlisis.

Realizacin de casos de uso de prioridad alta, vista de diseo.

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:

Detalle y prototipos de casos de uso (completado)

Diagrama general de casos de uso.

Especificacin de la arquitectura (completada).

Realizacin de los casos de uso vista de anlisis (Diagrama de colaboracin).

Especificacin de la arquitectura (Diagrama de paquetes).

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:

Realizacin de casos de uso vista de anlisis (Terminado).

Realizacin de caso de uso vista de diseo (Terminado).

Implementacin de los subsistemas bajo la arquitectura definida.

Integracin del sistema.

Definicin del plan de pruebas.

Implementacin del plan de pruebas.

6
TECNOLOGIA WEB 2017

CAPITULO
II MARCO TEORICO

7
TECNOLOGIA WEB 2017

MARCO TEORICO

5. MARCO TEORICO
5.1. CORREO ELECTRONICO

El Correo Electrnico es un sistema que permite el envo/recepcin de mensajes a travs de internet. El


funcionamiento es similar al correo postal, con la comodidad que la entrega se efecta en el acto. La
comunicacin es sumamente rpida; podemos enviar correos electrnicos a personas que estn en la
otra parte del mundo en cuestin de segundos.
Principalmente se usa este nombre para denominar al sistema que provee este servicio en Internet,
mediante el protocolo SMTP, aunque por extensin tambin puede verse aplicado a sistemas anlogos
que usen otras tecnologas. Por medio de mensajes de correo electrnico se puede enviar, no solamente
texto, sino todo tipo de documentos digitales. Su eficiencia, conveniencia y bajo coste (casi nulo) estn
logrando que el correo electrnico desplace al correo ordinario para muchos usos habituales.

5.2. FUNCIONAMIENTO DEL 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

5.3. PROTOCOLO SMTP

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.

.3.1 Modo de Comunicacin SMTP

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

Ilustracin 8 Esquema de Funcionamiento de SMTP

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

5.4.1. MIME HEADERS

MIME-Version.-La presencia de este encabezado indica que el mensaje utiliza el formato


MIME. Su valor es tpicamente igual a "1.0"
Content-Type.-Este encabezado indica el tipo de medio que representa el contenido del
mensaje, consiste en un tipo: type y un subtipo: subtype.
Content-Transfer-Encoding.-El encabezado MIME content-transfer-encoding: indica el
mtodo que ha sido usado para representar datos binarios usando texto ASCII.
A continuacin el formato de un mensaje de correo electrnico por SMTP en formato MIME:
HELOvirtual.uagrm.edu.bo
MAILFROM:luisalbertov7@hotmail.es
RCPTTo:grupo10sa@ficct.uagrm.edu.bo
DATA
From:luisalbertov7@hotmail.es
To:grupo10sa@ficct.uagrm.edu.bo
Subject:TestdeEnvio
MimeVersion:1.0;
ContentType:text/html;charset="ISO88591";
ContentTransferEncoding:7bit;

<html>
<body>
<h2>EsteesunlinkalaUAGRM!</h2>
clickaqui!<ahref="http://www.uagrm.edu.bo">UAGRM</a>
</body>
</html>
.
QUIT

5.5. PROTOCOLO POP3

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:

El software de permitir Gestionar Campeonatos.


Se debe permitir Gestionar Empleaodos de la institucion.
Debe poder registrar clientes.
Gestionar Correos incluye el leer y enviar informacion.
Gestioan Tipos de canchas.
Gestionar las Canchas del sistema.
Se debe poder registrar la iluminacion de las canchas.
Registrar equipos por parte de los clientes
Debe ser capaz de generar reportes importantes de la institucion.

6.2. IDENTIFICAR ACTORES

Administrador.- Es quien supervisara todos los cambios en el sistema.

Empleado.- Encargado de gestionar las reservas y manejar el sistema de correos.

Cliente.-Es quien reserva canchas y registra equipos de futbol, asi tambien puede consultar
informacion sobre los campeonatos.

6.3. IDENTIFICAR CASOS DE USOS

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

CU4.-Gestionar Tipos de Canchas

17
TECNOLOGIA WEB 2017
CU5.-Gestionar Canchas

CU6.-Gestionar Correo(Leer, Enviar)

CU7.-Gestionar Iluminacion

CU8.-Gestionar Equipos

CU9.-Gestionar Reservas

6.4. PRIORIZACION DE CASOS DE USO

Nro. CASO DE USO PRIORIDAD

CU1. Gestionar Campeonato. Alta

CU2. Gestionar Empleado. Media

CU3. Gestionar Cliente. Alta

CU4. Gestionar Tipo Cancha. Media

CU5. Gestionar Cancha. Alta

CU6. Gestionar Correo (Leer, Enviar). Alta

CU7. Gestionar Iluminacion. Alta

CU8. Gestionar Equipo Alta

CU9. Gestionar Reserva Media

18
TECNOLOGIA WEB 2017

6.5. DETALLE DE CASOS DE USO

6.5.1 CU1 GESTIONAR CAMPEONATO

Caso de Uso Gestionar Campeonato


ID CU1
Descripcion Gestionar los campeonatos que existen en la institucion para que
puedan ser consultados por los clientes
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para el regitro.
Actores secundarios Empleado se encargara de introducir los datos proporcionados por
la institucion a la aplicacin.
Precondicin El Empleado debera estar previamente registrado en el sistema y
tener la respectiva autorizacion para registrar un campeonato.
Flujo Principal Accin de actor
El Empleado recibe un mail solicitando registrar, modificar o
eliminar algun EMPLEADO.
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
1. Adiciona, modifica o elimina el Campeonato
2. Elimina el correo.
Post Condicin Enviar mail

19
TECNOLOGIA WEB 2017
6.5.2 CU2 GESTIONAR EMPLEADO

Caso de Uso Gestionar Empleado


ID CU2
Descripcion Gestionar los empleados del sistema
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para el regitro.
Actores secundarios Administraodor se encargara de introducir los datos
proporcionados por la institucion a la aplicacin.
Precondicin El Adminstrador debera estar previamente registrado en el sistema
y tener la respectiva autorizacion para registrar a un empleado.
Flujo Principal Accin de actor
El Administrador recibe un mail solicitando registrar, modificar o
eliminar los empleados.
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
1. Adiciona, modifica o elimina los empleados
2. Elimina el correo.
Post Condicin Enviar mail

6.5.3 CU3 GESTIONAR CLIENTES

20
TECNOLOGIA WEB 2017

Caso de Uso Gestionar CLIENTEs


ID CU3
Descripcion Gestionar los clientes que existen de la institucion e
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para el regitro.
Actores secundarios El empleado se encargara de introducir los datos proporcionados
por la institucion a la aplicacin.
Precondicin El empleado debera estar previamente registrado en el sistema y
tener la respectiva autorizacion para registrar a un nuevo cliente.
Flujo Principal Accin de actor
El Empleado recibe un mail solicitando registrar, modificar o
eliminar los CLIENTES
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
1. Adiciona, modifica o elimina los CLIENTEs
2. Elimina el correo.
Post Condicin Enviar mail

6.5.4 CU4 GESTIONAR TIPO CANCHA

Caso de Uso Gestionar TIPO CANCHA


ID CU4
Descripcion Gestionar los tipos de canchas que existen en el sistema.
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para el regitro.
Actores secundarios El administrador se encargara de introducir los datos
proporcionados por la institucion a la aplicacin.
Precondicin El Administrador debera estar previamente registrado en el sistema
y tener la respectiva autorizacion para registrar a un nuevo grupo.
Flujo Principal Accin de actor
El Adminisrador recibe un mail solicitando registrar, modificar o
eliminar los tipos de canchas.
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
1. Adiciona, modifica o elimina los tipos de canchas
2. Elimina el correo. 21
Post Condicin Enviar mail
TECNOLOGIA WEB 2017
6.5.5 CU6 GESTIONAR CANCHA

Caso de Uso Gestionar CANCHA


ID CU5
Descripcion Gestionar las canchas existentes en la institucion
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para el regitro.
Actores secundarios El Administrador se encargara de introducir los datos
proporcionados por la institucion a la aplicacin.
Precondicin El Administrador debera estar previamente registrado en el sistema
y tener la respectiva autorizacion para registrar a un nuevo grupo.
Flujo Principal Accin de actor
El Administrador recibe un mail solicitando registrar, modificar o
eliminar las canchas.
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
1. Adiciona, modifica o elimina las CANCHAS
2. Elimina el correo.
Post Condicin Enviar mail

6.5.6 CU5 GESTIONAR CORREO (LEER, ENVIAR)

22
TECNOLOGIA WEB 2017

Caso de Uso Gestionar Correo (Leer, Enviar)


ID CU6
Descripcion Gestionar los Correos que se realizan para las operaciones.
Actores primarios La institucion sera el que solicite los correos.
Actores secundarios El Administrador se encargara de gestionar los correos
provenientes de los usuarios.
Precondicin El Administrador debera estar previamente registrado en el sistema
y tener la respectiva autorizacion para realizar la accion.
Flujo Principal Accin de actor
El Administrador puede enviar y leer un mail.
Respuesta del sistema
1. Lee el correo
2. Valida los datos
3. Enviar Respuesta

Post Condicin Enviar mail

6.5.7 CU7 GESTIONAR ILUMINACION

23
TECNOLOGIA WEB 2017

Caso de Uso Gestionar ILUMINACION


ID CU7
Descripcion Gestionar la ILUMINACION que existen en las canchas
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para el regitro.
Actores secundarios El Administrador se encargara de introducir los datos
proporcionados por la institucion a la aplicacin.
Precondicin El Administrador debera estar previamente registrado en el sistema
y tener la respectiva autorizacion para registrar a un nuevo grupo.
Flujo Principal Accin de actor
El Administrador recibe un mail solicitando registrar, modificar o
eliminar las iluminaciones
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
1. Adiciona, modifica o elimina las illuminaciones
2. Elimina el correo.
Post Condicin Enviar mail

6.5.8 CU8 GESTIONAR EQUIPOS

Caso de Uso GESTIONAR EQUIPOS


ID CU8
Descripcion Gestionar los Equipos de los campeonatos .
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para generar los reportes.
Actores secundarios El Empleado se encargara de introducir los datos proporcionados
por la institucion a la aplicacin.
Precondicin El Empleado debera estar previamente registrado en el sistema y
tener la respectiva autorizacion.
Flujo Principal Accin de actor
El empleado recibe un mail solicitando generar los reportes o
estadisticas del sistema.
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
3. Adiciona, modifica o elimina los equipos
4. Elimina el correo. 24
Post Condicin Enviar mail
TECNOLOGIA WEB 2017
6.5.9 CU8 GESTIONAR RESERVA

Caso de Uso GESTIONAR RESERVA


ID CU8
Descripcion Generar los Reportes y Esadisticas del sistema .
Actores primarios La institucion sera el que solicite y proporcione los datos
nesesarios para generar los reportes.
Actores secundarios El EMPLEADO se encargara de visualizar los reportes mediante
el servicio de correo.
Precondicin El cliente debera estar previamente registrado en el sistema.
Flujo Principal Accin de actor
El cliente recibe un mail solicitando generar los reportes o
estadisticas del sistema.
Respuesta del sistema
1. Lee el correo
2. Valida los datos
Si los datos son validados:
5. Adiciona, modifica o elimina la reserva
6. Elimina el correo.
Post Condicin Enviar mail

6.6. DIAGRAMA GENERAL DE CASOS DE USOS.

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

8. DISEO DEL SISTEMA


8.1. DISEO DE LA ARQUITECTURA FISICA

31
TECNOLOGIA WEB 2017

8.2. DISEO DE LA ARQUITECTURA LOGICA


8.2.1.PAQUETE ADMINISTRACION

8.2.2.PAQUETE TIPO CANCHA

32
TECNOLOGIA WEB 2017

8.3. DISEO DE LA INTERFAZ

33
TECNOLOGIA WEB 2017

34
TECNOLOGIA WEB 2017

8.4. DISEO DE LA BASE DE DATOS


8.4.1.DISEO CONCEPTUAL

35
TECNOLOGIA WEB 2017

Diseo Conceptual de la Base de Datos

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

Id_cliente nombre telefono


PK

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

8.4.2.2. ATRIBUTO DE LAS TABLAS

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

Pat_id FK Entero NO Codigo de CLIENTE


DELINCUENTE
ATRIBUTOS LLAVE TIPO DE DATOS AMPLITUD NULO DESCRIPCIN
Codigo del
Del_id PK Entero NO delincuente

38
TECNOLOGIA WEB 2017
Nombre del
Del_nombre Alfanumrico 50 caracteres NO delincuente
Carnet de identidad
Del_ci Alfanumerico 50 caracteres NO del delincuente

Del_alias Alfanumerico 50 caracteres NO Alias 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

Pat_id FK Entero NO Codigo de CLIENTE

Bibliografa

1) El correo electrnico [en lnea].[consulta: 6-Junio-2012]. Disponible


en:<http://www.elcorreoelectronico.com/>
2) Escuelas de sistemas informticos-Tercer curso de informtica tecnologas de la comunicacin
en internet [en lnea].[consulta: 6-Junio-2012]. Disponible
en:<www.falconmarbella.com/.../Punto_235_Correo_electronico.pdf>
3) Protocolos de mensajera (SMTP, POP3 e IMAP4) [en lnea].[consulta: 8-Junio-2012].
Disponible en:<ttp://es.kioskea.net/contents/internet/smtp.php3>

4) Wikipedia correo electrnico. [en lnea].[consulta: 29-mayo-2012]. Disponible en:<


http://es.wikipedia.org/wiki/Correo_electr%C3%B3nico >

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

You might also like