Proyecto El Viejo Aeropuerto Ultima Entrega

PROYECTO “EL VIEJO AEROPUERTO”
TERCERA ENTREGA
Tutor
Diego Iván Oliveros Acosta
Integrantes
Jaime Andrés Infante Rojas
Luis Alexander Moreno Saavedra
Politécnico Grancolombiano
Estándar UML
Bogotá, Abril de 2017
TABLA DE CONTENIDO
Pag.
Introducción 2
Objetivo 3
Primera Entrega 4
1. Reformulación del problema 4
2. Actores 7
3. Tabla de Requerimientos Funcionales 8
4. Documento de Requerimientos no Funcionales 8
5. Casos de Uso 9
6. Diagrama Integrado de Casos de Uso 12
7. Escenarios de casos de Uso 12
Segunda Entrega 21
8. Definición de clases 21
9. Lista de palabras únicas candidatas a ser clases 21

10. Modelo de clases 22
11. Diccionario de clases 23
12. Modelo E-R (Entidad relación) 31
Tercera Entrega 32
13. Diagramas de secuencia 32
14. Diagramas de Navegación 40
15.Bosquejos de la página web 44
Bibliografía 48
Conclusiones
1
INTRODUCCIÓN
En esta entrega final se construirá el modelo dinámico para el sistema de

información del aeropuerto planteado en el proyecto, para este fin se utilizaran los
conceptos y herramientas adquiridos en el módulo “Estándar UML” por los
integrantes del grupo. La idea en esta tercera parte del proyecto es desarrollar los
diagramas de secuencia y construir los diagramas de navegación. Lo anterior
aunado a los elementos desarrolladas en las entregas anteriores dará como
resultado un modelo óptimo y claro que permita al desarrollador construir un
software ágil y eficiente que permita la administración del Viejo Aeropuerto.
2
OBJETIVO
El objetivo principal para la entrega final es realizar un modelo estructurado en

UML que abarque todos los contenidos vistos y asimilados durante el módulo,
este debe reunir los avances realizados en las entregas pasadas para a que por
medio de este completo modelo se le dé una solución de software eficaz e integral
a la problemática del viejo aeropuerto.
3
PRIMERA ENTREGA
1. REFORMULACIÓN DEL PROBLEMA

El cliente requiere el desarrollo de un sistema de información ágil y eficiente donde se
pueda recopilar y hacer buen uso de los datos de las aeronaves de un Viejo Aeropuerto,
que se encuentra ubicado en la ciudad Las Tres Palmeras, para tal fin el Cliente hace una
serie de requerimientos muy puntuales, en los que especifica qué información debe
albergar el sistema y que tipo de gestión se le debe dar a la misma en el sistema.
Los requerimientos del sistema son los siguientes:
a. El sistema debe albergar la información detallada de las aeronaves, sus

propietarios, los empleados del aeropuerto y los pilotos. Para esto se debe
plantear una serie de formularios para cada uno es estos elementos que permita al
administrador la creación, edición, consulta y eliminación lógica del sistema con la
respectiva información descrita a continuación. Se debe buscar minimizar el
número de formularios haciéndolos dinámicos para que el mismo formulario de
personas pueda perfilar a un empleado, propietario o un piloto solo seleccionando
la opción correcta.
➢ Información del Avión:
○ Número de registro.
○ Número de matrícula del avión
○ Modelo
○ Horas de vuelo
○ Mantenimiento
○ Guardado en Hangar Número
○ Capacidad de pasajeros
○ Peso que puede transportar en bodega
➢ Información del Hangar:
○ Número de Hangar
○ Localización
○ Capacidad (n) de Aviones
➢ Información del Propietario

4
○ Número de aviones
○ Modelo
○ Fecha de compra
○ Nombre completo del propietario o compañía
○ Número de documento (cédula o nit)
○ Teléfono
○ Dirección
➢ Información del Empleado
○ Número de servicio de mantenimiento (cada empleado presta un
servicio de mantenimiento al menos a un avión.)
○ Nombre completo
○ Número de documento
○ E.P.S.
○ A.R.L.
○ Teléfono
○ Dirección
○ Cargo.
○ Salario
○ Turno
➢ Información del piloto
○ Nombre completo
○ E.P.S
○ A.R.L
○ Salario
○ Turno
○ Tipo de avión que puede pilotear (comercial, privado, militar)
○ Número de licencia de vuelo
○ Vuelos programados
○ Vuelos realizados
○ Horas de vuelo
5
➢ Registro de mantenimientos programados de aviones
Para esto se debe realizar un formulario que pida la siguiente información.
○ Nombre de la persona que programa el mantenimiento

○ Fecha y hora para el mantenimiento
○ Número de hangar donde se realizará el mantenimiento
○ Técnico que realiza el mantenimiento
○ Número de horas empleadas en el trabajo
○ Tipo de trabajo realizado
➢ Registro del número de aviones reparados
Para esto se debe realizar un formulario que pida la siguiente información.
○ Número del registro de los aviones

○ Fecha del mantenimiento
○ Hora del mantenimiento
○ Trabajo realizado
○ Número de hangar
○ Nombre del técnico(s) que realiza(n) el mantenimiento
➢ Lista de chequeo de los mantenimientos.
Para esto se debe mostrar un reporte obtenido de la base de datos con la lista de
los mantenimientos realizados anteriormente permitiendo consultar por fecha, mes
y año.
○ Número del registro del avión

○ Fecha y hora de los mantenimientos
○ Trabajo realizado
○ Número de repuestos cambiados
○ Código del repuesto
○ Nombre del técnico o técnicos que realizaron el mantenimiento
Como la aplicación debe tener muchos usuarios concurrentes se requiere que esta tenga
una base de datos central a la que los diferentes usuarios se conecten simultáneamente,
6
para esto la mejor alternativa puede ser el desarrollo de una aplicación web con
arquitectura MVC que permite la mantenibilidad al estar separada en capas lógicas.
Se requiere que el sistema maneje un componente de autenticación que permita acceder

a los usuarios del sistema al contenido correspondiente a su rol, para esto se
implementará la autenticación existente en el servidor web.
Inicialmente aunque se use un modelo web en el desarrollo de la aplicación está

funcionara sólo dentro de la red local por lo que las consideraciones de seguridad no
hacen parte del alcance de la aplicación sino que hará uso de las condiciones seguras de
la red existente.
La concurrencia que se espera del sistema es de unos 75 usuarios conectados al mismo

tiempo.
2. ACTORES
Administrador Empleado Taller
7
3. TABLA DE REQUERIMIENTOS FUNCIONALES
# REQUERIMIENTO
RF01 Registrar personas
RF02 Registrar Pilotos
RF03 Registrar Mantenimientos programados de aviones
RF04 Registrar propietarios de aviones
RF05 Registrar empleados que hacen mantenimientos
RF06 Reportar lista de chequeo
RF07 Registrar cantidad de aviones reparados
RF08 Registrar personas que trabajan en el aeropuerto
4. DOCUMENTO DE REQUERIMIENTOS NO FUNCIONALES
Requisito: RNF01 Concurrencia

Descripción El sistema debe estar preparado para atender solicitudes de hasta
75 usuarios conectados al mismo tiempo
Tipo Rendimiento
Prioridad Alta
Requisito: RNF02 Mantenibilidad

Descripción La aplicación debe estar construida con buenas prácticas de
desarrollo buscando su mantenibilidad. Se debe garantizar que los
componentes tengan bajo acoplamiento
8
Tipo Escalabilidad
Prioridad Alta
Requisito: RNF03 Escalabilidad

Descripción La aplicación debe estar preparada para la posibilidad de que esta
crezca y estar lista para ser distribuida en múltiples servidores.
Tipo Escalabilidad
Prioridad Media
Requisito: RNF04 Rendimiento

Descripción La aplicación debe tener tiempos de respuesta adecuados por lo
que es importante garantizar que los tiempos de respuesta de la
base de datos sean adecuados y que el servidor web esté
optimizado
Tipo Rendimiento
Prioridad Alta
5. CASOS DE USO
RF01 Registrar Personas
9
RF02 Registrar Pilotos
RF03 Registrar Mantenimientos programados de aviones
RF04 Registrar propietarios de aviones
RF05 Registrar empleados que hacen mantenimientos
10
10
RF06 Reportar de lista de chequeo
RF07 Registrar Número de aviones reparados
RF08 Registrar personas que trabajan en el aeropuerto
11
11
6. DIAGRAMA INTEGRADO DE CASOS DE USO
7. ESCENARIOS DE CASOS DE USO
RF- 01 Registrar personas
Requisitos asociados n/a
Actores Administrador
Descripción Se debe recibir información del usuario para

crear el registro de una persona en el sistema
Precondición La persona no existe en el sistema
Secuencia Paso Acción

Normal
1 El administrador solicita al sistema iniciar
el registro de una persona
12
12
2 El sistema solicita los datos de la
persona
3 El sistema valida que los campos

requeridos estén completos y tengan el
formato esperado según las restricciones
respectivas
4 El sistema almacena los datos

proporcionados, y muestra un mensaje
de confirmación.
Postcondición La persona se crea en el sistema
Excepciones Paso Acción
3 Si los datos no son válidos o falta algún

campo requerido, se muestra un mensaje
de error.
RF- 02 Registrar de pilotos
Requisitos asociados RF-01

crear el registro de un piloto en el sistema
Precondición El piloto no existe en el sistema

Normal
el registro de un piloto

persona y los datos específicos de un
13
piloto

respectivas

de confirmación.
Postcondición El piloto se crea en el sistema

de error.
RF- 03 Registro de Mantenimientos programados de

aviones
Requisitos asociados N/A
Actores Empleado de Taller

crear el registro de mantenimiento programado
en el sistema
Precondición N/A

Normal
1 El Empleado de Taller solicita al sistema
14
iniciar el registro de mantenimiento
programado

mantenimiento

respectivas

de confirmación.
Postcondición El mantenimiento programado se crea en el

sistema

de error.
RF- 04 Registrar propietarios

crear el registro de un propietario de avión en el
sistema
Precondición El propietario no existe en el sistema

Normal
15
el registro de un propietario
2 El sistema solicita los siguientes datos de

la persona y los datos específicos de un
propietario así como los datos de los
aviones que posee

respectivas

de confirmación.
Postcondición El propietario se crea en el sistema

de error.
RF- 05 Registrar empleados que hacen mantenimiento

crear el registro de un empleado de
mantenimiento en el sistema
Precondición El empleado de mantenimiento no existe en el

sistema

Normal
16
el registro de un empleado de
mantenimiento

empleado de mantenimiento

respectivas

de confirmación.
Postcondición El empleado de mantenimiento se crea en el

sistema

de error.
RF- 06 Reportar lista de chequeo
17
crear el registro de un empleado de
mantenimiento en el sistema
Precondición se envían fechas para filtrar el reporte

Normal
1 El administrador solicita al sistema
mostrar la lista de chequeo de
mantenimientos
2 El sistema filtra los mantenimientos por

fecha.
3 El sistema muestra el resultado en

pantalla
Postcondición Se muestra el resultado en pantalla

de error.
2 Si no hay mantenimientos se muestra un

mensaje indicando eso.
RF- 07 Registrar Número de aviones reparados
18
crear el registro del número de aviones reparados
Precondición se envían fechas para filtrar el reporte

Normal
1 El administrador solicita al sistema
mostrar el reporte del número de aviones
reparados
2 El sistema filtra los mantenimientos por

fecha.
3 El sistema muestra el resultado en

pantalla
Postcondición Se muestra el resultado en pantalla

de error.
2 Si no hay mantenimientos se muestra un

mensaje indicando eso.
RF- 08 Registrar personas que trabajan en el

aeropuerto
19

crear el registro de una persona que trabaja en el
aeropuerto
Precondición El empleado del aeropuerto no existe en el

sistema

Normal
el registro de un empleado del aeropuerto

empleado del aeropuerto

respectivas

de confirmación.
Postcondición El empleado del aeropuerto se crea en el sistema

de error.
20
SEGUNDA ENTREGA
Modelo Estructural
8. Definición de clases
Partiendo del enunciado y subrayando los sustantivos candidatos a clases
“Un viejo aeropuerto de la ciudad “LAS TRES PALMERAS” , es ahora utilizado para mantener
la información de las aeronaves , sus propietarios , los empleados de los aeropuertos y los
pilotos . Cada avión dispone información como por ejemplo: un número de registro, tipo de
avión que está compuesto como mínimo por el modelo, capacidad de pasajeros y el peso que
puede transportar en bodega.
Los hangares están numerados, tienen una localización y tienen una determinada capacidad
de (n) aviones simultáneos. El modelo debe contemplar el control de la información de los
propietarios de las aeronaves (Un propietario puede ser categorizado como persona o una
compañía ) y los empleados encargados del mantenimiento de los aviones .
Un propietario puede tener al menos un avión y cada empleado presta un servicio de
mantenimiento al menos a un avión. Cada avión se somete a revisión cada cierto tiempo, por
lo que se lleva el registro de servicio del avión en el viejo aeropuerto, donde se anota la fecha
del mantenimiento, en número de horas empleadas en el trabajo.
Los pilotos son identificados por su número de licencia de vuelo tiene sus restricciones (piloto:
comercial, privado, militar, etc.) y están autorizados para pilotear un determinado tipo de avión
. Los empleados tienen como datos específicos el salario y el turno.
En general, cualquier persona que trabaje en el VIEJO AEROPUERTO o sea piloto de los
aviones que se arreglan en dichos hangares , debe tener una información estándar que es el
DNI (Documento Nacional de Identidad), el nombre, la dirección completa y al menos un
número de teléfono.”
9. Lista de palabras únicas candidatas a ser clases
aeropuerto aeronaves / avión

propietarios empleados
pilotos tipo de
avión hangares perso
na
compañía
mantenimiento / revisión / registro de servicio del avión licencia de vuelo
Al analizar esta lista se puede ver que al parecer la mayoría de palabras son candidatas
sólidas a ser clases. Pero hay algunas que no que serían buenas clases como por ejemplo:
Aeropuerto: no es buena idea tener la clase aeropuerto ya que por la característica del
proyecto solo existiría un aeropuerto el cual incluiría todas las demás clases por lo que puede
ser mejor omitir.
También hace falta definir un poco mejor la terminología para referirse a una reparación para
un avión ya que aunque se utilizan estos tres términos mantenimiento / revisión / registro de
servicio del avión es claro que se refieren básicamente a los mismo y como clases tendrán la
misma función. Por lo que la lista inicial de clases, ya que en el proceso de elaboración del
diagrama es posible que se definan algunas clases auxiliares que no están en esta lista, es la
siguiente
21
Aeronave
Propietario
Empleado
Piloto
TipoAvion
Hangar
Persona Empresa
Servicio
LicenciaVuelo
10. Modelo de clases
En este diagrama todas las clases exceptuando la enumeración que se incluyó son
persistentes. Se marcan todos los atributos como privados para garantizar el
encapsulamiento. Utilizando la estrategia de getters pero limitando los setters a métodos con
reglas que editan todo el objeto.
22
11. Diccionario de clases
Nombre Persona
Tipo Clase
Descripción define los atributos de todas las personas del sistema
Atributo tipo dato visibilidad valor inicial
documento long privado
nombre String privado
Apellido String privado
direccion String privado
telefono String privado

Tipo
Método visibilidad Descripción
retorno
EditarPersona(
String documento,
String nombre, Permite actualizar la
bool publico
String apellido, información de una Persona.
String dirección,
String telefono)
Retorna el valor encapsulado
getDocumento() String publico del documento para una
persona.
getNombre() String publico
del nombre para una persona.
getApellido() String publico
del apellido para una persona.
Retorna el valor encapsulado de
getDireccion() String publico
la dirección para una empresa.
getTelefono() String publico
del teléfono para una empresa.
Nombre Empresa
Tipo Clase
23
Descripción define los atributos de las empresas en el sistema que
pueden ser propietarias de un avión
Nit String privado
nombre String privado
direccion String privado
telefono String privado
Método Tipo retorno visibilidad Descripción
EditarEmpresa(
String nit,
Permite actualizar la
String nombre, bool publico
información de una empresa.
String dirección,
String telefono)
getNit() String publico
del nit para una empresa.
getNombre() String publico
del nombre para una empresa.
Retorna el valor encapsulado de
getDireccion() String publico
la dirección para una empresa.
getTelefono() String publico
del teléfono para una empresa.
24
Nombre Empleado
Tipo Clase
define los atributos Propios de los empleados del
Descripción
aeropuerto
FechaIngreso Date privado

Tipo
retorno
EditarEmpleado(
String documento,
String nombre,
Permite actualizar la información de
String apellido, bool publico
un empleado.
String dirección,
String teléfono,
Date fechaIngreso)
getFechaIngreso( Retorna el valor encapsulado de la
Date publico
Date fechaIngreso) fecha de ingreso para un empleado.
25
Nombre Propietario
Tipo Clase
Descripción
define los propietarios de los aviones estos pueden ser una empresa o
una persona se usa agregacion para definir esta dualidad
Aeronaves[] Arreglo privado

Aeronaves
PersonaPropietaria Persona privado Null
EmpresaPropietaria Empresa privado Null
Get Aeronaves( Permite obtener las aeronaves asociadas a un

Aeronave[] publico
String documento) propietario dado el documento.
AgregaAeronave(
bool Publico Permite asociar una aeronave a un propietario.
Aeronave ae)
EliminaAeronave(
Permite desasociar una aeronave de un
String bool Publico
propietario.
NumeroRegistro)
26
Nombre Piloto
Tipo Clase
Descripción Define los atributos de un piloto del aeropuerto
LicenciaVuelo LicenciaVuelo privado

EditarPiloto(
String documento,
String nombre,
String apellido, bool publico Permite editar la información de un piloto.
String dirección,
String teléfono,
LicenciaVuelo lv)
getLicenciaVuelo() LicenciaVuelo publico Obtiene la licencia de vuelo asociado al piloto.
Nombre Aeronave
Tipo Clase
Descripción define los atributos de las aeronaves del sistema

visibilid
Atributo tipo dato valor inicial
ad
NumeroRegistro String privado
Tipo TipoAvion privado

Tipo visibilid
Método Descripción
retorno ad
EditarAeronave( Permite editar la información de una
bool publico
TipoAvion ta) aeronave.
getNumeroRegistro(
String publico Obtiene el número de registro
)
GetTipo() TipoAvion publico Obtiene el tipo de avión
Nombre TipoAvion
Tipo Clase
27
Define el tipo de avión,
Descripción
modelo
Modelo String privado
Año String privado
CapacidadPasajeros int privado
PesoMaximo double privado

EditarTipoAvión(
String modelo,
int año, Permite editar la información de un tipo de
bool publico
int capacidad, avión.
int pesoMax
)
Obtiene el nombre del modelo del tipo de
getModelo() String publico
avión
getAño() int publico Obtiene el año del tipo de avión
getPeso() double publico Obtiene el peso del tipo de avión

Obtiene la capacidad de pasajeros del tipo
getCapacidad() int publico
de avión
28
Nombre LicenciaVuelo
Tipo Clase
Descripción define la licencia de vuelo
TipoLicencia int privado
TiposAvion Array de String privado

agregarTipoAvion(
bool publico Agregar un tipo de avión a la licencia
TipoAvion av)
editarTipoLicencia(
bool publico Permite editar el nombre de la licencia
String tipoLicencia)
getTipoLicencia() int publico Obtiene el tipo de licencia
Obtiene la lista de tipos de avión
GetTiposAvion() String[] publico
asociados a la licencia
Nombre Hangar
Tipo Clase
Descripción Define el hangar donde se reparan los aviones
Numero int privado
AvionesSimultaneos int privado

editarHangar(
Permite actualizar los
int numeroHangar, bool publico
valores del hangar
int aviones)
Obtiene el número del
getNumero() int publico
hangar
Obtiene la capacidad
getAvionesSimultaneos() int publico
máxima del hangar
Nombre Servicio
Tipo Clase
29
Descripción Define un servicio de mantenimiento
Fecha Date privado
HorasEmpleadas Int privado
Empleado Empleado privado
Aeronave Aeronave privado
Hangar Hangar privado
Descripcion String privado

Tipo
retorno
AgregarServicio(
Date fecha,
int horas,
Empleado e, bool publico Agrega un servicio al sistema
Aeronave a,
Hangar h,
String descripcion)
getFecha() Date publico Obtiene la fecha del servicio
Obtiene las horas que tomo el
geHoras() int publico
servicio
Obtiene el Empleado que realizo
getEmpleado() Empleado publico
el servicio
Obtiene la Aeronave que recibió
getAeronave () Aeronave publico
el servicio.
Obtiene el hangar donde se
getHangar() Hangar publico
realizó el servicio
30
12. Modelo E-R (Entidad relación)
31
TERCERA ENTREGA
Modelo Dinámico
13. Diagramas de secuencia
a)
32
b)
33
c)
34
d)
35
e)
36
f)
37
g)
38
h)
39
14. Diagramas de Navegación (actividad)
a) Registrar Piloto
b) Registrar Mantenimientos Programados
40
c ) Registrar Propietario
d) Registrar Empleado
41
e) Generar reporte de número de aviones reparados
f) Generar reporte de Lista de chequeo
42
g) Registrar empleado de mantenimiento
43
15. Bosquejos de la página web
A continuación se verán algunas capturas de la interfaz pero para su mejor apreciación

pueden ver el wireframe completo con algunas interacciones en
http://jaimeinfante.com/UML.
a) Inicio
b) Registro Empleado
44
c) Registro de Piloto
d) Registro de propietario (Persona)
45
e) Registro de Propietario (empresa)
f) Reportes
46
g) Resultado de reportes
Los dos reportes tienen la misma interfaz solo cambian los resultados
h) Registro de mantenimientos Programados
47
BIBLIOGRAFÍA
- DAVID AYCART PÉREZ. MARC GIBERT GINESTÀ. MARTÍN HERNÁNDEZ MATÍAS. 2007
Ingeniería del software en entornos de SL
- StarUML. http://staruml.io/
- Campus Virtual Politécnico Gran colombiano Modulo Estándar UML.

http://campusvirtual.poligran.edu.co/#/dash/aula
48
CONCLUSIONES
- En ocasiones durante el proceso de construcción de software no se tiene

en cuenta una reformulación del problema en un lenguaje más cercano al
mundo de los sistemas y durante el desarrollo de este proyecto se
evidenció que obviar este paso es un error grave durante el desarrollo del
software y esta afirmación tiene su explicación en que al reformular el
problema como requisito de la entrega se amplió un poco más el horizonte
de hacia dónde debería apuntar el proyecto en cuanto a sus requerimientos
y usabilidad.
- Al realizar un proyecto de esta naturaleza basado en los diferentes modelos
UML se evidencia la necesidad de hacer el mismo paso a paso como esta
descrito en la guía ya que por la falta de la realización correcta de uno de
los modelos del mismo se hace difícil integrar el proyecto y obtener un
resultado óptimo con miras al construcción del software. Lo anterior
convierte a UML en una herramienta poderosa para el posterior desarrollo
del software, eso sí utilizada en forma correcta y estructurada.
- Trabajar con UML para modelar las partes de la solución de software que
se está construyendo y después integrarlas le da al programador una
herramienta poderosa que le permite recrear los escenarios y llegar al
momento de la implementación con una idea clara de las funciones que
tiene el software y cómo estas funciones interactúan entre ellas y con los
actores involucrados.
- Los proyectos grupales ponen a prueba la capacidad organizativa y de
liderazgo de los miembros del grupo, pero al ser un proyecto para un aula
virtual la dificultad aumenta por el manejo de tiempo de cada uno de los
integrantes y las nuevas tecnologías de la información y comunicaciones
surgen como una solución efectiva para acortar las distancias y los tiempos
para poder aportar en tiempo real al proyecto desde cualquier lado. Sin
estas tecnologías sería imposible realizar un proyecto de calidad en el que
participaran todos los integrantes del grupo.

Proyecto El Viejo Aeropuerto Ultima Entrega

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto El Viejo Aeropuerto Ultima Entrega

Cargado por

Copyright:

Formatos disponibles

PROYECTO “EL VIEJO AEROPUERTO”

Diego Iván Oliveros Acosta

Jaime Andrés Infante Rojas

Luis Alexander Moreno Saavedra

9. Lista de palabras únicas candidatas a ser clases 21

En esta entrega final se construirá el modelo dinámico para el sistema de

El objetivo principal para la entrega final es realizar un modelo estructurado en

1. REFORMULACIÓN DEL PROBLEMA

Los requerimientos del sistema son los siguientes:

a. El sistema debe albergar la información detallada de las aeronaves, sus

➢ Información del Propietario

○ Nombre de la persona que programa el mantenimiento

○ Número del registro de los aviones

○ Número del registro del avión

Se requiere que el sistema maneje un componente de autenticación que permita acceder

Inicialmente aunque se use un modelo web en el desarrollo de la aplicación está

La concurrencia que se espera del sistema es de unos 75 usuarios conectados al mismo

Administrador Empleado Taller

RF01 Registrar personas

RF02 Registrar Pilotos

RF03 Registrar Mantenimientos programados de aviones

RF04 Registrar propietarios de aviones

RF05 Registrar empleados que hacen mantenimientos

RF06 Reportar lista de chequeo

RF07 Registrar cantidad de aviones reparados

RF08 Registrar personas que trabajan en el aeropuerto

4. DOCUMENTO DE REQUERIMIENTOS NO FUNCIONALES

Requisito: RNF01 Concurrencia

Requisito: RNF02 Mantenibilidad

Requisito: RNF03 Escalabilidad

Requisito: RNF04 Rendimiento

RF01 Registrar Personas

RF03 Registrar Mantenimientos programados de aviones

RF04 Registrar propietarios de aviones

RF05 Registrar empleados que hacen mantenimientos

RF07 Registrar Número de aviones reparados

RF08 Registrar personas que trabajan en el aeropuerto

7. ESCENARIOS DE CASOS DE USO

RF- 01 Registrar personas

Requisitos asociados n/a

Descripción Se debe recibir información del usuario para

Precondición La persona no existe en el sistema

Secuencia Paso Acción

3 El sistema valida que los campos

4 El sistema almacena los datos

Postcondición La persona se crea en el sistema

Excepciones Paso Acción

3 Si los datos no son válidos o falta algún

RF- 02 Registrar de pilotos

Requisitos asociados RF-01

Descripción Se debe recibir información del usuario para

Precondición El piloto no existe en el sistema

Secuencia Paso Acción

2 El sistema solicita los datos de la

3 El sistema valida que los campos

4 El sistema almacena los datos

Postcondición El piloto se crea en el sistema

Excepciones Paso Acción

3 Si los datos no son válidos o falta algún

RF- 03 Registro de Mantenimientos programados de

Requisitos asociados N/A

Actores Empleado de Taller

Descripción Se debe recibir información del usuario para