UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

FACULTAD DE INGENIERIA EN CIENCIAS DE LA

COMPUTACION Y TELECOMUNICACIONES

INGENIERÍA EN SISTEMAS

ARQUITECTURA DE SOFTWARE

“SOFTWARE DE GESTIÓN PARA LA PARROQUIA MARÍA

AUXILIADORA”

ESTUDIANTES:

 MELENDEZ MARTINEZ SERGIO DRISS 215049187

 ACOSTA GARCIA DARWIN 216077036

FECHA: 18/10/2023

1
 Contenido

1. Introducción.................................................................................................................4
2. Objetivos......................................................................................................................5
2.1. Objetivo general.......................................................................................................5
2.2. Objetivos específicos................................................................................................5
3. Captura de requisitos....................................................................................................6
3.1. Identificación de Actores y Casos de Uso................................................................6
3.1.1. Identificación del Listado de Actores...............................................................6
3.1.2. Identificación del Listado de Casos de Usos....................................................7
3.2. Detalle de Caso de Uso.........................................................................................7
CU1. Gestionar Persona......................................................................................................7
CU2. Gestionar Evento........................................................................................................9
Prototipo CU2.......................................................................................................................12
CU3. Gestionar Reservación..............................................................................................12
CU4. Gestionar Grupo.......................................................................................................14
CU5. Gestionar Inscripción................................................................................................17
4. Análisis.......................................................................................................................19
4.1. dentificación de los módulos..................................................................................19
4.2. Vista de los módulos..............................................................................................19
5. Diseño........................................................................................................................21
5.1. Diseño de la arquitectura........................................................................................21
5.1.1. Módulo Persona..............................................................................................21
5.1.2. Módulo eventos...............................................................................................21
5.1.3. Módulo grupos................................................................................................21
5.2. Diseño de la base de datos......................................................................................22
5.2.1. Diseño Conceptual..........................................................................................22
5.2.2. Diseño lógico..................................................................................................22
5.2.3. Diseño Físico...................................................................................................24
5.3. Diseño de detalle procedimental............................................................................26
5.3.1. CU1. Gestionar Persona..................................................................................26

2
5.3.2. CU2. Gestionar Evento...................................................................................29
5.3.3. CU3. Gestionar Reservacion...........................................................................32
5.3.4. CU4. Gestionar Grupo....................................................................................35
5.3.5. CU5. Gestionar Inscripcion.............................................................................38

3
 1. Introducción

Un patrón de arquitectura de software es un esquema genérico probado para solucionar un

problema particular recurrente que surge en un cierto contexto. Este esquema se especifica

describiendo las componentes, con sus responsabilidades, relaciones, y las formas en que

colaboran.

A partir de este concepto surgen distintas arquitecturas que permiten gestionar de una mejor

forma la estructura de un software, tales como la que se mostrará en este documento, en el

cual nos estaremos centrando en la arquitectura por capas, la cual por definición establece

que nos enseña a estructurar de tal forma que se separan las responsabilidades y se

administran las dependencias, es decir, cada capa tiene una responsabilidad específica.

El diseño más usado es conocido por estructurar el software en 3 capas, las cuales,

denominadas, capa de presentación, capa de negocio y la capa de los datos.

En la capa de presentación tenemos todo lo relacionado a la interfaz gráfica y métodos

auxiliares que conforman o permiten la visualización de la misma.

En la capa de negocio es donde se establecen todas las reglas que deben cumplirse, es la

capa intermedia y donde se determina si la información es correcta para pasar a la siguiente

capa.

La capa de datos se encarga de generar una relación con un almacén de datos y a su vez es

donde se establecen todas las comunicaciones con determinadas tablas de una base de

datos.

4
 2. Objetivos

2.1. Objetivo general

Desarrollar un software de gestión para la parroquia María Auxiliadora.

2.2. Objetivos específicos

 Recopilar información del proceso interno de una iglesia católica.

 Realizar la captura de requerimientos, identificando a los usuarios y casos de
uso a desarrollar de acuerdo a las expectativas del problema.
 Analizar y definir los módulos que encapsularán los distintos casos de uso que
conformarán el software.
 Diseñar el modelo conceptual, lógico y físico de la base de datos que pueda
soportar los requisitos del sistema.
 Realizar los distintos tipos de diseño que dispondrá el sistema de acuerdo a
cómo será desarrollado.
 Desarrollar interfaces de software intuitivas para los usuarios.

5
3. Captura de requisitos

3.1. Identificación de Actores y Casos de Uso

3.1.1. Identificación del Listado de Actores

Ilustración 1: Identificación de actores

ACTORES DESCRIPCIÓN

Actor Encargado de la administración total del

1. Administrador sistema.

6
 3.1.2. Identificación del Listado de Casos de Usos

CASOS DE USO

CU1. Gestionar Persona

CU2. Gestionar Evento

CU3. Gestionar Reservación

CU4. Gestionar Grupo

CU5. Gestionar Inscripción

3.2. Detalle de Caso de Uso

CU1. Gestionar Persona

NOMBRE Gestionar Persona

Se registrarán, modificarán o eliminarán las personas que interactúan con

DESCRIPCIÓN el software, así como también sus datos más relevantes para su posterior
seguimiento.
ACTORES Administrador

ACTOR
Administrador
INICIADOR

7
PRE CONDICION Sin precondición

FLUJO 1. LISTA DE PERSONAS

PRINCIPAL 1.1. El administrador podrá visualizar a las personas que se

encuentren registradas dentro del software, así como también
sus datos más sobresalientes.
2. REGISTRAR NUEVA PERSONA

2.1. El administrador ingresará a la vista de registrar persona y

rellenará el formulario con los datos correspondientes, posterior a
ello podrá guardar los datos.
- Datos

- Cédula.
- Nombre(s).
- Apellido Paterno.
- Apellido Materno.
- Género.
- Fecha de nacimiento.
- Dirección.
- Email.
- Teléfono.
- Checkbox (Tutor - Celebrante)
3. MOSTRAR DATOS DEL USUARIO

3.1. El Administrador podrá visualizar los datos de una persona en

específico, así como también existe la opción de editar la
información.
4. EDITAR PERSONA

4.1. El Administrador podrá realizar la modificación de los datos de

una persona.
5. ELIMINAR PERSONA

8
 5.1. El Administrador podrá eliminar una persona del software.

FLUJO  Campos requeridos.

EXEPCIONAL  Tipos de datos incorrectos.
POST
Sin postcondición.
CONDICION

Prototipo CU1

CU2. Gestionar Evento

9
NOMBRE Gestionar Evento

Se registrarán, modificarán o eliminarán los eventos y sus respectivos

DESCRIPCIÓN horarios que interactúan con el software, así como también sus datos más
relevantes para su posterior seguimiento.
ACTORES Administrador

ACTOR
Administrador
INICIADOR
PRE CONDICION Sin precondición

FLUJO 1. LISTA DE EVENTOS

PRINCIPAL - El administrador podrá visualizar los eventos disponibles

que se encuentren registrados dentro del software, así
como también sus datos más sobresalientes.
2 REGISTRAR NUEVO EVENTO

- El administrador ingresará a la vista de registrar evento y

rellenará el formulario con los datos correspondientes,
posterior a ello podrá guardar los datos.
3 Datos

- Nombre del evento.

- Lugar.
- Costo.
4 MOSTRAR DATOS DEL EVENTO

- El Administrador podrá visualizar los datos de un evento

en específico, así como también existe la opción de editar
la información, además se observará la lista de horarios del
evento.
5 EDITAR EVENTO

- El Administrador podrá realizar la modificación de los

10
 datos de un evento.
6 ELIMINAR EVENTO

- El Administrador podrá eliminar un evento del software.

7 REGISTRAR NUEVO HORARIO

- El administrador ingresará a la vista de registrar horario y

rellenará el formulario con los datos correspondientes,
posterior a ello podrá guardar los datos.
8 Datos

- Día.
- Hora de inicio.
- Hora Fin.
- Cupo.
- Celebrante.
9 ELIMINAR HORARIO

- El Administrador podrá eliminar un horario de evento del

software.

 Campos requeridos.
FLUJO  Tipos de datos incorrectos.
EXEPCIONAL  La eliminación de un evento no se podrá ejecutar si tiene horarios
asignados.
POST
Sin postcondición.
CONDICION

11
 Prototipo CU2

CU3. Gestionar Reservación

NOMBRE Gestionar Reservación

Se registrarán, visualizarán o eliminarán las personas que interactúan con

DESCRIPCIÓN el software, así como también sus datos más relevantes para su posterior
seguimiento.
ACTORES Administrador

12
ACTOR
Administrador
INICIADOR
PRE CONDICION Registro de eventos.

1. LISTA DE RESERVACIONES

a. El administrador podrá visualizar las reservaciones que se

encuentren registradas dentro del software, así como
también sus datos más sobresalientes.
2. REGISTRAR NUEVA RESERVA

a. El administrador ingresará a la vista de registrar reservación y

rellenará el formulario con los datos correspondientes, posterior a
ello podrá guardar los datos.
- Datos

- Fecha de emisión.
FLUJO
- Evento.
PRINCIPAL - Fecha de reservación.
- Horario.
- Costo.
- Detalle.
- Observación.
- Cliente.
3. MOSTRAR DATOS DE LA RESERVA

a. El Administrador podrá visualizar los datos de una reserva en

específico.
4. ELIMINAR RESERVA

a. El Administrador podrá eliminar una reserva del software.

FLUJO  Campos requeridos.

EXEPCIONAL  Tipos de datos incorrectos.

13
POST
Sin postcondición.
CONDICION

Prototipo CU3

CU4. Gestionar Grupo

14
NOMBRE Gestionar Grupo

Se registrarán, modificarán o eliminarán los grupos que interactúan con el

DESCRIPCIÓN software, así como también sus datos más relevantes para su posterior
seguimiento.
ACTORES Administrador

ACTOR
Administrador
INICIADOR
PRE CONDICION Sin precondición

FLUJO 1. LISTA DE GRUPOS

PRINCIPAL b. El administrador podrá visualizar los grupos que se

encuentren registradas dentro del software, así como
también sus datos más sobresalientes.
2. REGISTRAR NUEVO GRUPO

- El administrador ingresará a la vista de registrar grupo y rellenará

el formulario con los datos correspondientes, posterior a ello
podrá guardar los datos.
- Datos

- Nombre del grupo.

- Tutor.
- Fecha de inicio.
- Fecha fin.
- Costo.
- Lugar.
- Formas de aprobación (Asistencia - Notas).
3. MOSTRAR DATOS DEL USUARIO

- El Administrador podrá visualizar los datos de un grupo en

específico, así como también existe la opción de editar la
información.

15
 4. EDITAR GRUPO

- El Administrador podrá realizar la modificación de los datos de un

grupo.
5. ELIMINAR GRUPO

- El Administrador podrá eliminar un grupo del software.

 Campos requeridos.
FLUJO  Tipos de datos incorrectos.
EXEPCIONAL  No se puede eliminar un grupo vigente, el cual tengo alumnos
inscritos.
POST
Sin postcondición.
CONDICION

Prototipo CU4

16
CU5. Gestionar Inscripción

NOMBRE Gestionar Inscripción

Se registrarán, modificarán o eliminarán las inscripciones que interactúan

DESCRIPCIÓN con el software, así como también sus datos más relevantes para su
posterior seguimiento.
ACTORES Administrador

ACTOR
Administrador
INICIADOR
PRE CONDICION Registro de los grupos.

FLUJO 1. LISTA DE PERSONAS

PRINCIPAL - El administrador podrá visualizar las inscripciones de

alumnos que se encuentren registradas dentro del software,
así como también sus datos más sobresalientes.
2. REGISTRAR NUEVA PERSONA

1. El administrador ingresará a la vista de nueva inscripción y

rellenará el formulario con los datos correspondientes, posterior a
ello podrá guardar los datos.
- Datos

- Fecha de inscripción.

17
 - Grupo.
- Integrante.
3. MOSTRAR DATOS DE LA INSCRIPCIÓN

1. El Administrador podrá visualizar los datos de una inscripción en

específico, así como también existe la opción de editar la
información.
4. EDITAR INSCRIPCIÓN

1. El Administrador podrá realizar la modificación de los datos de

una inscripción.
5. ELIMINAR INSCRIPCIÓN

1. El Administrador podrá eliminar una inscripción del software.

FLUJO  Campos requeridos.

EXEPCIONAL  Tipos de datos incorrectos.
POST
Sin postcondición.
CONDICION

Prototipo CU5

18
 4. Análisis

4.1. dentificación de los módulos

4.2. Vista de los módulos

Módulo Persona

Módulo Eventos
19
Módulo Grupos

20
5. Diseño

5.1. Diseño de la arquitectura

5.1.1. Módulo Persona

5.1.2. Módulo eventos

5.1.3. Módulo grupos

21
 5.2. Diseño de la base de datos

5.2.1. Diseño Conceptual

5.2.2. Diseño lógico

Persona

apellido_ apellido_ nombre_ sexo direccion_

id_persona cedula
paterno materno persona persona
PK
telefono_ fecha_na tutor estado
mail_persona celebrante
persona cimiento

22
 Lugar

id_lugar nombre_lugar apto_reunion capacidad estado

PK

Evento

id_evento nombre_evento costo estado id_lugar

PK FK

Grupo

nombre_ fecha_inici fecha_fin check_asis check_no estado id_tutor id_lugar

id_grupo costo
grupo o tencia tas

PK FK FK

Horario_evento

id_horario hora_i hora aporte_vol cupo estado id_evento id_celebrante

dia
_evento nicio _fin untario
PK FK FK

Inscripción

id_inscrip fecha_inscrip nota nota nota_to estado estado_apro paga id_gru id_per
cion cion _1 _2 tal bacion da po sona
PK FK FK

Reservación

id_reserva observa fecha_rese estado pagada valor_pa fecha_e id_cliente id_horario

detalle
cion cion rvacion go mision _evento

PK FK FK

23
 5.2.3. Diseño Físico

create database project_software_architecture;

use project_software_architecture;

create table persona (

id_persona int PRIMARY KEY AUTO_INCREMENT,
cedula varchar (10) not null,
apellido_paterno varchar (20) not null,
apellido_materno varchar (20) not null,
nombre_persona varchar (20) not null,
sexo varchar (1),
direccion_persona varchar (255),
mail_persona varchar (45),
telefono_persona varchar (20),
fecha_nacimiento date,
celebrante boolean,
tutor boolean,
estado boolean
);

create table lugar (

id_lugar int PRIMARY KEY AUTO_INCREMENT,
nombre_lugar varchar (80) not null,
apto_reunion boolean not null,
capacidad int,
estado boolean not null
);

create table evento (

id_evento int PRIMARY KEY AUTO_INCREMENT,
id_lugar int not null,
nombre_evento varchar (45) not null,
costo decimal (10,0) not null,
estado boolean not null,
foreign key(id_lugar) references lugar(id_lugar)
);

create table grupo (

id_grupo int PRIMARY KEY AUTO_INCREMENT,
id_tutor int not null,
nombre_grupo varchar (20),
costo decimal (10,0),
id_lugar int,
fecha_inicio date,
fecha_fin date,
check_asistencia boolean not null,
24
 check_notas boolean not null,
estado boolean not null,
foreign key(id_tutor) references persona(id_persona),
foreign key(id_lugar) references lugar(id_lugar)
);

create table horario_evento (

id_horario_evento int PRIMARY KEY AUTO_INCREMENT,
dia int not null,
hora_inicio time not null,
hora_fin time not null,
aporte_voluntario boolean not null,
cupo int not null,
id_evento int not null,
estado boolean not null,
id_celebrante int not null,
foreign key(id_evento) references evento(id_evento),
foreign key(id_celebrante) references persona(id_persona)
);

create table inscripcion (

id_inscripcion int PRIMARY KEY AUTO_INCREMENT,
id_grupo int not null,
id_persona int not null,
fecha_inscripcion date not null,
nota_1 decimal (4,1),
nota_2 decimal (4,1),
nota_total decimal (4,1),
estado boolean not null,
estado_aprobacion varchar (20),
pagada boolean not null,
foreign key(id_grupo) references grupo(id_grupo),
foreign key(id_persona) references persona(id_persona)
);

create table reservacion (

id_reservacion int PRIMARY KEY AUTO_INCREMENT,
id_cliente int not null,
id_horario_evento int not null,
detalle varchar (45),
observacion varchar (255),
fecha_reservacion date not null,
estado boolean not null,
pagada boolean not null,
valor_pago decimal (10,0) not null,
fecha_emision date,
foreign key(id_cliente) references persona(id_persona),
25
 foreign key(id_horario_evento) references horario_evento(id_horario_evento)
);

5.3. Diseño de detalle procedimental

5.3.1. CU1. Gestionar Persona

26
Diagrama de secuencia

27
Diseños de interfaz

28
5.3.2. CU2. Gestionar Evento

29
Diagrama de secuencia

30
Diseños de interfaz

31
5.3.3. CU3. Gestionar Reservacion

32
Diagrama de secuencia

33
Diseños de interfaz

34
5.3.4. CU4. Gestionar Grupo

35
Diagrama de secuencia

36
Diseños de interfaz

37
5.3.5. CU5. Gestionar Inscripcion

38
Diagrama de secuencia

39
Diseños de interfaz

40