SISTEMA DE ADMINISTRACIÓN DE INFORMACIÓN PARA LAS IGLESIAS EN EL ECUADOR.

(1)

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Técnica Particular de Loja

ESCUELA DE SISTEMAS INFORMÁTICOS Y COMPUTACIÓN

MODALIDAD ABIERTA Y A DISTANCIA

SISTEMA DE ADMINISTRACIÓN DE INFORMACIÓN

PARA LAS IGLESIAS EN EL ECUADOR.

TESIS DE GRADO PREVIA A LA OBTENCIÓN DEL TITULO DE INGENIERO EN

SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN.

AUTOR:

PLUA AGUIRRE CARLOS ALBERTO.

DIRECTOR:

ING. GUIDO RIOFRÍO C.

SUB-CENTRO REGIONAL

VILLAFLORA-QUITO

(2)

ii DEDICATORIA

“Dedico este trabajo a mi padre Franklin, que aún sin

estar físicamente en este mundo, siempre me hizo sentir

con su presencia divina que estaría conmigo hasta

llegar al final de este reto. A mi esposa Amanda y a mis

hijos Salvatore y Josué, por todo su apoyo

incondicional y su paciencia. A mi madre Lolita por

acoger con mucho cariño la misión que mi Padre le

entregara de ver a su hijo graduado. A mis hermanos y

(3)

iii AGRADECIMIENTOS

Primero un agradecimiento muy especial a Dios, a mi esposa Amanda y a mis dos hijos, Salvatore y Josué sin los cuales no hubiera tenido la fuerza y la motivación para continuar. Al gran corazón de la Ing. Nathaly Montoya, Directora de Diseño del departamento de Tecnología de Correos del Ecuador, quién gentil y generosamente me ayudó a reestructurar el proyecto. Al Ing. Byron Quintuña, al cual agradezco toda su paciencia y asesoría en cuanto a la implementación del proyecto. A mi madre Lolita por su apoyo y sus oraciones, y a toda mi familia en especial mis hermanos Frank, Patty, Pol, Poly, Tanny, Efraín, Kiki y Anita; al P.Nicolás Dousdebès C., quien fuera párroco de la parroquia Nuestra Señora de La Paz; porque cuando la administró, supo darme toda la apertura, confianza, colaboración y el apoyo en recursos tanto económico como de tiempo, dentro de las horas de trabajo para poder finalizar esta tesis, sin olvidar al actual párroco P.Carlos Vela A., quien siguió con la misma línea de apoyo. A mis padres políticos Marcelo y Evita por todo el ánimo, motivación, y ayuda para poder continuar. También un agradecimiento muy en especial al Ing. Guido Riofrío, por toda su paciencia, guía, dirección y consejo durante todo el desarrollo del proyecto desde el comienzo hasta el final del mismo. Por último un agradecimiento muy especial a la Universidad Técnica Particular de Loja, la cual a través de su Modalidad Abierta, permite a las personas que por alguna razón o motivo no pueden asistir de manera presencial a la universidades, alcanzar este sueño grande de ser profesional, por ende superarnos como personas y aportar al desarrollo de nuestro país.

(4)

iv CERTIFICACIÓN

Ingeniero:

Guido Riofrío Calderón. DIRECTOR DE TESIS

C E R T I F I C A:

Que el presente trabajo de investigación, previo a la obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, ha sido dirigido, supervisado y revisado en todas sus partes, por lo mismo, cumple con los requisitos legales exigidos por la Universidad Técnica Particular de Loja, quedando autorizada su presentación.

Loja, 06 de junio del 2011

(5)

v AUTORÍA.

El presente proyecto de tesis con cada una de sus observaciones, análisis, evaluaciones, conclusiones y recomendaciones emitidas, es de absoluta responsabilidad del autor.

Además, es necesario indicar que la información de otros autores empleada en el presente trabajo está debidamente especificada en fuentes de referencia y apartados bibliográficos.

. . . .. . . . . . . . .

(6)

vi CESIÓN DE DERECHOS.

El autor, declara estar de acuerdo con la disposición del Estatuto Orgánico de la Universidad Técnica Particular de Loja en su Art. 67, en el cual se enuncia lo siguiente: “Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través o con el apoyo financiero académico o institucional (operativo) de la

Universidad”.

. . . .. . . . . . . . .

(7)

SUMARIO DE CONTENIDOS

Dedicatoria ... ii

Agradecimiento ... iii

Certificación ... iv

Autoría ... v

Cesión de Derechos ... vi

Resumen ... 12

Introducción ... 13

Capítulo Uno: ... 15

1.0 Descripción del Problema ... 16

1.1 Problema ... 16

1.2 Alcance ... 16

1.3 Hipótesis ... 17

1.4 Objetivo General ... 17

1.5 Objetivos Específicos ... 17

1.6 Selección de metodología de desarrollo ... 17

1.7 Metodología de desarrollo ... 18

1.8 Justificación de selección de Herramientas de desarrollo... 18

1.8.1 Eclipse ... 19

1.8.2 MySQL ... 19

1.8.3 Java ... 20

(8)

1.8.5 Selección del ambiente de desarrollo ... 21

1.8.5.1 Herramienta para el Modelamiento ... 22

1.8.5.2 Power Designer versión 12.1 ... 22

1.8.5.3 Servidor de aplicaciones web JBoss 5.1 ... 22

1.9 Fase de Iniciación ... 23

1.10 Diagramas del Proceso de Negocio ... 23

1.11 Visión del Proyecto ... 28

1.12 Especificación de Requerimientos ... 28

1.12.1 Perspectiva del Sistema ... 28

1.12.2 Funciones Básicas del Sistema ... 28

1.12.3 Identificación de los actores y sus características ... 29

1.12.4 Requisitos Específicos ... 30

1.12.4.1 Requisitos de las interfaces externas ... 30

1.12.5 Especificación de requisitos funcionales ... 32

1.13 Análisis ... 33

1.5 Arquitectura candidata para el desarrollo del Sistema ... 33

Capítulo Dos: Fase de Elaboración ... 35

2.1 Modelo conceptual de la base de datos ... 36

2.2 Diagrama de Clases ... 38

2.3 Diagramas de Clases de Dominio ... 39

2.4 Diagramas de Secuencia ... 45

2.6 Modelo de despliegue... 65

2.7 Arquitectura del Sistema ... 66

2.7.1 Estructura de la aplicación ... 67

(9)

3.1 Fase de Construcción ... 69

3.1.1 El diseño lógico de la base de datos ... 70

3.1.2 Modelo Físico ... 70

3.1.3 El catálogo del sistema ... 72

Capítulo Cuatro: Fase de Transición ... 80

4.1 Manual de usuario ... 81

4.2 Manual de Programador ... 81

4.2.1 Estándares de Programación ... 81

4.2.2 Diccionario de Programación ... 84

4.3 Plan de Pruebas ... 88

4.3.1 Diseño de Pruebas del Sistema ... 88

4.3.2 Pruebas de Unidad ... 88

4.3.2.1 Módulo 1: Administración del Sistema ... 89

4.3.2.2 Módulo 2: Personas ... 91

4.3.2.3 Módulo 3: Grupos ... 93

4.3.2.4 Módulo 4: Eventos ... 94

4.3.2.5 Módulo 5: Recaudaciones ... 95

4.3.3 Pruebas Integrales ... 96

4.3.3.1 Caso de prueba de integración: Registrar Inscripciones... 96

4.3.3.2 Caso de prueba de integración: Registrar Reservaciones ... 98

4.3.3.3 Caso de prueba de integración: Gestionar Docencia ... 99

4.3.4 Pruebas de Aceptación ... 100

4.4 Informe de Pruebas... 100

Capítulo Cinco: Conclusiones y Recomendaciones ... 101

(10)

5.2 Recomendaciones ... 104

Bibliografía ... 105

Anexos ... 107

Anexo 1: Diagramas y documentación de Casos de Uso ... 108

1.1 Diagrama de caso de uso: Ingresar al Sistema ... 109

1.2 Diagrama de caso de uso: Gestionar Datos Generales ... 111

1.3 Diagrama de caso de uso: Gestionar Tutores ... 114

1.4 Diagrama de caso de uso: Gestionar Celebrantes ... 115

1.5 Diagrama de caso de uso: Gestionar Lugares ... 118

1.6 Diagrama de caso de uso: Gestionar Jerarquías ... 120

1.7 Diagrama de caso de uso: Ingresar parámetros de cursos ... 122

1.8 Diagrama de caso de uso: Gestionar usuario SAP y permisos ... 124

1.9 Diagrama de caso de uso: Editar usuario SAP registrados... 126

1.10 Diagrama de caso de uso: Gestionar Grupos ... 128

1.11 Diagrama de caso de uso: Modificar Grupos ... 130

1.12 Diagrama de caso de uso: Inscribir a una persona ... 132

1.13 Diagrama de caso de uso: Modificar Inscripciones ... 135

1.14 Diagrama de caso de uso: Gestionar Docencia ... 137

1.15 Diagrama de caso de uso: Registrar asistencias ... 139

1.16 Diagrama de caso de uso: Registrar Notas ... 140

1.17 Diagrama de caso de uso: Generar reporte de Grupos ... 144

1.18 Diagrama de caso de uso: Crear Eventos ... 146

1.19 Diagrama de caso de uso: Modificar Eventos registrados... 149

1.20 Diagrama de caso de uso: Reservar Evento ... 151

(11)

1.22 Diagrama de caso de uso: Generar reporte de eventos ... 155

1.23 Diagrama de caso de uso: Registrar Personas ... 157

1.24 Diagrama de caso de uso: Modificar personas ... 158

1.25 Diagrama de caso de uso: Generar reporte de personas ... 161

1.26 Diagrama de caso de uso: Registrar Familias ... 163

1.27 Diagrama de caso de uso: Modificar Familias Registradas... 165

1.28 Diagrama de caso de uso: Generar reporte de familias ... 168

1.29 Diagrama de caso de uso: Generar recibo de pago ... 170

1.30 Diagrama de caso de uso: Generar comprobante de egreso ... 172

1.31 Diagrama de caso de uso: Anular los recibos de pago ... 174

1.32 Diagrama de caso de uso: Generar reporte de caja ... 177

Anexo 2: Rational Unified Process (RUP)-Compendio ... 179

Anexo 3: Sistema de Administración Parroquial (SAP)-Manual de Usuario ... 182

Anexo 4: Modelo de Encuesta empleado para determinar el Nivel de aceptación del Sistema de Administración ... 205

Anexo 5: Informe de resultados de pruebas ... 214

(12)

Sistema de Administración de Información para las Iglesias Resumen

12 RESUMEN

El presente trabajo analiza el campo de los Sistemas de Información, específicamente los “Sistemas Integrados de Información” el cual hay que implementarlo en una organización de carácter religioso y sin fines de lucro. El mismo se desarrolló en la parroquia Nuestra Señora de La Paz en Quito y tiene como objetivo diseñar e implementar el Sistema Integrado de Administración con el fin de realizar la sistematización de la Gestión Administrativa a través del enfoque de análisis y diseño orientado a objetos. Se puede decir que los Sistemas de Información ayudan a que las organizaciones se desempeñen con eficiencia y efectividad, mediante la estructura modular que procure hacer más fácil su comprensión y permite que las modificaciones, ajustes o actualizaciones sean más fáciles de implementar.

El proceso de desarrollo del software fue basado en la metodología RUP1_{, el cual se abarcó desde la fase de}

Iniciación que incluye los diagramas de Proceso de Negocio, Visión del Proyecto, Especificación de Requerimientos, Diagramas de caso de casos de uso y Casos de Uso, culminando la fase con la Arquitectura Candidata para el desarrollo del sistema. Continuamos con la fase de Elaboración, en la cual describimos el Modelo Conceptual de la BDD, Diagrama de Clases, el Diagrama de Clases de Dominio, Diagramas de Secuencia, el Modelo de Despliegue, la Arquitectura del Sistema y la Estructura de la Aplicación. Seguimos con la Fase de Construcción en la cual en base al Modelo Conceptual, consecuentemente en base este modelo, obtenemos el Diseño Lógico de la base de datos, el Modelo Físico y el Catálogo del Sistema. En la Fase de Transición tenemos el Manual del Usuario, el Manual del Programador, el Plan de Pruebas del Sistema. Para finalizar agregamos las Conclusiones, Recomendaciones, Bibliografía y Anexos.

Como resultado tenemos el Sistema de Administración en la cual se aplicaron diversos tipos de técnicas de captación y procesamiento de la información, entre las cuales se encuentran: entrevista, análisis de documentación y bibliografía, así como también el análisis y diseño orientado a objetos.

1

(13)

Sistema de Administración de Información para las Iglesias Introducción

13

(14)

Sistema de Administración de Información para las Iglesias Introducción

14 INTRODUCCIÓN

En la actualidad las organizaciones y empresas deben adaptarse a nuevos esquemas, para ser más eficientes y eficaces. Para lograrlo, sus directivos deben diseñar una estructura que permita alcanzar los objetivos y cumplir metas, las cuales se especifican en la misión y visión de la empresa. Uno de los elementos que contribuyen a alcanzar los objetivos, son los Sistemas de Información los cuales permitan contar con información rápida, veraz y oportuna.

La clave del éxito reside en la capacidad para que todos los elementos de una organización funcionen de manera coordinada en la consecución de objetivos fijados. Por ello se debe disponer de una información adecuada para actuar y tomar decisiones; es decir, las organizaciones deben crear Sistemas de Información apropiados para el manejo eficaz de la información.

Ante las modificaciones del entorno y el nivel de los requerimientos y nuevas exigencias de la realidad actual, la Institución se ha visto en la necesidad de incluirse en las nuevas metodologías de mejora, a través del análisis y diseño orientado a objetos, como solución permanente, integral y sistemática a las deficiencias e insuficiencias de la gestión actual.

Además se busca por medio del desarrollo del Sistema Integrado de Información Parroquial, la eficiencia la cual debe caracterizarse por brindar servicios de elevado nivel en el marco de un riguroso control del uso de los recursos acorde con las normas y regulaciones vigentes que garanticen un eficiente uso de los mismos.

(15)

Sistema de Administración de Información para las Iglesias Capítulo 1

15

Capítulo Uno:

(16)

16 1.0 Descripción del Problema.

Al constatar la actual situación, factores tales como la planificación de los recursos, la reorganización de la información, han hecho muy vulnerable la Gestión Administrativa y de recursos. Ante las modificaciones del entorno, el nivel de los requerimientos y nuevas exigencias dispuestas por la Curia Diocesana de Quito, ente regulador de las Iglesias en el Ecuador, el Estado quién a través de la nueva propuesta de la ‘Ley de Cultos’ y la Ley de Régimen Tributario Interno, obliga a transparentar la información referente a la administración de recursos manejados por la Iglesia Ecuatoriana. La Institución manifiesta un pobre papel de capacidad en la planificación y el análisis de financiero, en el control de los recursos y falta de integrabilidad de los procesos de sistemas, procedimientos y de regulaciones internas, dispuestas por la realidad actual.

1.1 Problema.

Haciendo una evaluación inter-institucional se ha concluido que la actual forma de la organización no responde a las exigencias, debido a que no existe un mecanismo o proceso que garantice la sistematización de funciones de acuerdo a un modelo ajustado a las exigencias y dinámicas actuales, que asegure el control del uso de los recursos financieros y de información con eficiencia, rapidez y efectividad.

1.2 Alcance.

Desarrollar e implantar un Sistema Integrado de Gestión que comprenda los siguientes módulos:

1. Módulo de Administración, que permitirá administrar los parámetros y las configuraciones generales del sistema.

2. Módulo de Recaudaciones, que permitirá administrar la información de pagos de reservaciones e inscripciones

3. Módulo de Eventos, permitirá administrar y consultar la reservación de eventos y reservas planificadas.

4. Módulos de Grupos, el cual permitirá llevar un control de los cursos impartidos en la parroquia.

5. Módulos de Personas, permitirá administrar la información de feligreses de la parroquia y sus respectivas familias.

(17)

17 1.3 Hipótesis.

El cumplimiento de las exigencias que la actual Gestión Administrativa impone, demandan de un proceso de sistematización, el cual, a través de una estrategia de desarrollo iterativo, busca la eficiencia y eficacia, mediante el enfoque en los procesos. 1.4 Objetivo General

Diseñar e implementar un Sistema Integrado de Administración con el fin de garantizar la automatización de procesos.

1.5 Objetivos Específicos

1. Definir el alcance, contenido y tendencias del Sistema Administrativo Parroquial.

2. Diseñar el Sistema Integrado de Administración mediante un análisis y posterior diseño orientado a objetos.

3. Evaluar el desempeño del Sistema. 1.6 Selección de la metodología de desarrollo.

La aplicación de metodologías de ingeniería de software hace que el desarrollo de los proyectos informáticos llegue a ser exitoso desde los distintos enfoques entre los cuales tenemos negocio, sencillez, funcionalidad y capacidad de soporte.

Estas metodologías consisten en un conjunto de procedimientos, técnicas, y ayudas a la documentación, los cuales llevan a cabo una serie de procesos comunes que son guías para lograr los objetivos independientes de cómo hayan sido diseñadas. Su aplicación supone una gran carga, pero la no aplicación podría conllevar los siguientes problemas:

 Incertidumbre en resultados.  El no detectar errores a tiempo.

 Agregar nuevas herramientas que afectaría en forma significativa el proceso.  Reformas en la organización.

 Variación de resultados o alcance del proyecto.

Por otro lado la aplicación de una metodología completa proporciona:  Estimación de costos.

 Medidas y métricas.

(18)

18  Una dirección más clara en cuanto a las entregas de la construcción del

producto.

 Descripciones de los roles y programas de entrenamiento detallados.  Proyectos de referencia totalmente trabajados.

 Técnicas para adaptarse al método.

En la selección del método priman algunos factores primordiales entre los cuales podemos mencionar: el tipo de proyectos, qué cultura existe en la empresa, y qué herramientas nos pueden facilitar la adopción de la metodología elegida. Entre las metodologías modernas para el desarrollo de Sistemas de Información tenemos la que es Orientada a Objetos, la cual tiene un nuevo enfoque en la Ingeniería del Software y se aplica cuando se requiere solucionar problemas de negocio en los que tanto los procesos como los datos son más complejos.

1.7 Metodología del Desarrollo.

El proceso de desarrollo a emplearse es RUP, que junto con UML2_{constituyen la} metodología a emplearse en este proyecto.

“UML es un lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software” (BJR, 1997). “Es un sistema notacional (que, entre otras cosas, incluye el significado de sus notaciones) destinado a los sistemas de modelado que utilizan conceptos orientados a objetos”. (Larman, 1999)

“La metodología RUP se describe normalmente en tres perspectivas:

1. Una perspectiva dinámica que muestra las fases del modelo sobre el tiempo. 2. Una perspectiva estática que muestra las actividades del proceso que se

representan.

3. Una perspectiva práctica que sugiere buenas prácticas a utilizar durante el proceso”. (Sommerville, 2005).

1.8 Justificación de selección de Herramientas de Desarrollo.

Para el desarrollo del presente proyecto se ha elegido una arquitectura Web, las herramientas preseleccionadas son las que se presentan en las Tablas 1.1 tanto para aplicación como para base de datos:

2

(19)

19 Tabla 1.1. Selección de las herramientas para el desarrollo del proyecto.

1.8.1 Eclipse.

Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma, ideal para el desarrollo de nuestro proyecto, puesto que nos permite utilizar todos los elementos como JE55, Hibernate, RichFaces, DynamicJasper, entre otros. Es típicamente utilizada para el desarrollo de IDE3_{de Java llamado Java Development Toolkit (JDT), compilador} (ECJ), el cual forma parte de Eclipse, en el mismo se emplea módulos los cuales proporcionan todo tipo de funcionalidad como por ejemplo: se incluye las herramientas de desarrollo de Java como un compilador de Java interno y un modelo completo de los archivos fuente de Java, con lo cual se permite técnicas avanzadas de refactorización y análisis de código. Entre sus principales características tenemos:

 Integración con Hibernate.  La compilación en tiempo real.  Tiene pruebas unitarias JUnit.  Control de versiones con CVS.

 Asistentes (wizards) para la creación del proyectos, clases, tests, etc.  Refactorización.

 Integración con Ant.

1.8.2 MySQL.

MySQL es el sistema de Gestión de Base de Datos más popular del mundo de código abierto, ya que entre sus características tenemos su gran rendimiento, alta fiabilidad, ahorro de costes y de fácil manejo. Para nuestro caso, entre las ventajas que tenemos de utilizar MySQL, tenemos4_:

 Soporte a multiplataforma.  Procedimientos almacenados.  Cursores

 Vistas actualizables  Modo Strict

3

Entorno Integrado de Desarrollo por sus siglas en Inglés 4

http://www.mysql.com/why-mysql/

HERRAMIENTA TIPO

Eclipse 3.0 JAVA: JEE5 Front End/Aplicación

(20)

20

 INFORMATION_SCHEMA

 Soporte a VARCHAR.

 Motores de almacenamiento independientes (MyISAM para lecturas rápidas, InnoDB, para transacciones e integridad referencial entre otras.

1.8.3 Java

Java es un lenguaje de programación orientado a objetos y fue escogido por nuestro proyecto fue basado en el entorno JE55. Fue creado por Sun Microsystems a principios de los años 90’s. En la actualidad Sun Microsystems liberó la mayor parte de tecnologías Java bajo licencia GNU GPL, teniendo la mayoría de programas Java de forma libre, salvo ciertos programas. Sus características que derivan en gran medida del lenguaje C++, hacen que se lo escoja como lenguaje adecuado para la codificación de nuestro proyecto, entre las cuales podemos destacar:

 Lenguaje orientado a objetos.  Multiplataforma.

 Se puede ejecutar código en sistemas remotos de forma segura.

1.8.4 JEE55_.

Es un framework de programación, el cual pone a disposición del programador un conjunto de API’s6_{, con las que se puede desarrollar aplicaciones empresariales; los} mismos, requieren altos niveles de confiabilidad, seguridad y rendimiento. En la actualidad existe una elevada tendencia de migrar actuales sistemas de la arquitectura Cliente-Servidor, hacia la Web, para lo cual resulta imprescindible contar con las herramientas de software que puedan transparentar al máximo la comunicación con las redes y medios de persistencia, así el desarrollador se puede concentrar en implementar las reglas del negocio.

5

Java Enterprise Edition versión 5 6

(21)

21 Fig. 1.1 Modelo de Aplicación Multicapa según JEE.7

JEE5 surgió de la necesidad de mejorar lo que su predecesora J2EE nos ofrecía como un alto nivel de complejidad y el tiempo que desarrollo. Ahora como vemos en la figura 1.3 la arquitectura JEE5 permite implementar servicios como aplicaciones multicapa las cuales nos brindan escalabilidad, accesibilidad y manejabilidad, las cuales son requisitos indispensables para el desarrollo a nivel empresarial, ya que este modelo divide el trabajo para implementar el servicio en varias capas: la lógica del negocio, presentación a ser implementada por el desarrollador y los servicios estándar del sistema.

1.8.5 Selección del ambiente de desarrollo.

Para la correcta configuración del ambiente de desarrollo y ejecución, así como para la gestión de documentación y agilidad en implantación se requieren las herramientas adicionales que se listan en la Tabla 1.3.

Tabla 1.2 Ambiente de desarrollo del proyecto

7

http://www.apuntesdejava.com/2007_11_01_archive.html

HERRAMIENTA VERSIÓN DESCRIPCIÓN

Jdk 1.6u24 Java Development Kit

JBoss 5.1 Servidor Web

Astah Community 6.4 Herramienta de Modelado UML

Dreamweaver 8.0 Editor de Páginas Web

Power Designer 12.1 Modelamiento de la Base de

(22)

22 1.8.5.1 Herramienta para el Modelamiento.

Para modelar los diferentes diagramas necesarios para el diseño del sistema se ha seleccionado Astah Community versión 6.4, la cual es una herramienta libre de modelamiento UML que soporta un diseño de software orientado a objetos.

Características:

Algunas de sus principales características son:

 Soporta la creación de los diagramas estándar de UML 1.4 y parcialmente los de UML 2.0.

 Permite importar y exportar archivos Java, haciendo que los paquetes, clases, atributos, operaciones y relaciones se generen a partir de las fuentes de código Java que se han importado.

 Crea automáticamente los diagramas de clase con la información del modelo de la base de datos.

 Se puede crear documentos o Javadocs, exportando a HTML los diferentes archivos.

 Se puede exportar los diferentes diagramas a archivos de imágenes .png o .jpeg.

1.8.5.2 Power Designer versión 12.1.

Por su fácil manejo para modelar el ambiente de organización y por permitirnos generar los scripts para cada motor de base datos, fue seleccionada esta herramienta.

1.8.5.3 Servidor de aplicaciones web JBoss 5.1.

(23)

23

(24)

24 1.9

Fase de Iniciación.

En esta fase, el proceso para obtener tener una visión clara del negocio, las necesidades que deben ser atendidas por el sistema y definir los límites del proyecto es necesario realizar una serie de actividades, las cuales mencionamos a continuación:

1.10 Diagramas del Proceso de Negocio.

“Para conseguir sus objetivos una institución o empresa organiza sus actividades por medio de un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una colección de datos que son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo trabajadores o empleados) participan de acuerdo a un flujo de trabajo determinado. Además estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan las políticas y la estructura de información de la empresa. Por lo tanto la finalidad del diagrama de negocio es describir cada proceso del negocio, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas del negocio”8_.

8

(25)

(26)

(27)

(28)

28 1.11 Visión del Proyecto.

“Ser el sistema líder en eficiencia y calidad en el manejo trámites eclesiásticos, que brinde soporte y apoyo a todas las parroquias a nivel nacional”.

1.12 Especificación de Requerimientos.

1.12.1 Perspectiva del Sistema.

Este proyecto tiene por objeto crear un Sistema de Administración que se utilizará para la Gestión Administrativa, en los cuales incluimos los siguientes aspectos:

Administración del sistema en el cual se permite la gestión de acceso, configuración y parámetros del sistema.

Grupos en el cual se lleva a cabo la gestión de grupos que se imparten en la parroquia, específicamente se pueden registrar nuevos grupos, registro de inscripciones de participantes, generando un recibo de pago, además se puede llevar a cabo control de asistencia y registrar notas de los participantes de los grupos.

Eventos permite la gestión de eventos, en los cuales tenemos registro de reservas de eventos, permitiendo la generación de un comprobante de pago.

Recaudaciones en el cual se registran los recibos de pago que se generan tanto en inscripciones en grupos como en reserva de eventos. También permite conocer los ingresos y egresos generados durante un período de tiempo determinado.

Feligrés donde se lleva a cabo el registro de las personas que utilizan los servicios parroquiales y también permitir el registro de sus familias.

1.12.2 Funciones Básicas del Sistema.

En la siguiente tabla clasificamos las funciones básicas en la siguiente categoría de función:

MODULO FUNCIÓN

Administración Ingresar al Sistema.

Gestionar datos generales. Registrar Tutores. Registrar Celebrantes.

Registrar Lugares. Registrar Jerarquías. Ingresar Parámetros. Gestionar usuario SAP y permisos.

Grupos Registrar nuevo grupo

Modificar grupos Registrar nueva inscripción

(29)

29

Registrar notas. Generar reporte de grupos.

Eventos Registrar nuevo Evento.

Modificar eventos. Reservar evento

Generar listado de reservaciones registradas. Generar reporte de eventos

Personas Registrar nueva Personas

Modificar personas registradas Registrar nueva Familia Modificar familias registradas

Generar reporte de personas Generar reporte de familias

Recaudaciones Generar reporte de caja

Generar nuevo recibo de pago Generar comprobante de egreso.

Generar reporte de caja.

Tabla 1.3 Funciones Básicas del Sistema.

1.12.3 Identificación de los actores y sus características.

 Usuario SAP9_:_{Representa a todas las personas que utilizan el sistema con} cuenta creada para cada uno de ellos.

 Administrador: Encargado de gestionar la información de los usuarios, los parámetros de grupos y eventos, así como emitir los reportes que se generan, producto de las reservas e inscripciones realizadas según un período de tiempo.  Secretario: Es el encargado de realizar las inscripciones y reservaciones de

eventos.

 Tutor: Es el encargado de gestionar e impartir los cursos, esto implica que debe evaluar a los estudiantes según su asistencia y sus calificaciones.

9

(30)

30 1.12.4 Requisitos Específicos.

1.12.4.1 Requisitos de las interfaces externas.

Módulo de Administración del Sistema.

Requerimiento funcional:

 Deberá permitir el acceso de los usuarios, verificando sus datos ingresados y permitiendo acceder a los distintos módulos validando su acceso.

 El sistema deberá permitir al administrador ingresar, actualizar y eliminar los datos de la institución en la cual se desempeña, validando sus datos antes de registrarlos en los reportes y recibos de pago.

 El sistema deberá permitir al administrador ingresar, actualizar y eliminar los registros de los tutores quienes se encargarán de la gestión de docencia de los grupos.

 El sistema deberá permitir al administrador ingresar, actualizar y eliminar los registros de celebrantes los cuales se encargarán de presidir las celebraciones y eventos que se realizan dentro de la parroquia.

 El sistema deberá permitir al administrador ingresar, actualizar y eliminar los registros de los lugares en los cuales se realizarán los eventos y los cursos planificados dentro de la parroquia.

 El sistema deberá permitir al administrador ingresar, actualizar y eliminar registros de las jerarquías que existen dentro de una familia y cada uno de sus integrantes.

 El sistema deberá permitir al administrador ingresar, actualizar y eliminar registros de los parámetros de los grupos, para poderlos aprobar.

 El sistema deberá permitir al administrador ingresar, actualizar y eliminar a los usuarios SAP con sus respectivos permisos y funciones.

Módulo de Grupos.

Requerimientos funcionales:

(31)

31  El sistema deberá permitir al secretario crear, actualizar y eliminar los registros de las inscripciones de las personas a los grupos que existen y se imparten en la parroquia.

 El sistema deberá permitir al secretario registrar los ingresos que se realizan por concepto de inscripciones en grupos.

 El sistema deberá permitir al tutor registrar, actualizar o eliminar los registros de asistencia de cada estudiante que participan en los cursos.

 El sistema deberá permitir al tutor registrar, actualizar o eliminar los registros de notas de cada estudiante que participan en los cursos de la parroquia.

 El sistema deberá permitir al administrador emitir reportes de los grupos y el estado de aprobación de cada uno de sus estudiantes que pertenecen a dichos grupos.

Módulo de Eventos

Requerimientos funcionales.

 El sistema deberá permitir al administrador crear, actualizar o eliminar los eventos que se realizan en la parroquia y deberá validar sus datos antes de registrarlos, actualizarlos o eliminarlos en la base de datos.

 El sistema deberá permitir al secretario crear, actualizar o eliminar las reservaciones de eventos y deberá validar antes de registrar, actualizar o eliminar en la base de datos.

 El sistema deberá permitir al administrador gestionar reportes de cada uno de los eventos y sus respectivas reservaciones.

Módulo de Personas.

Requerimientos funcionales

 El sistema deberá permitir al secretario crear, actualizar o eliminar los registros de las personas y sus respectivas familias, las cuales interactúan y participan en las actividades que se desarrollan en la parroquia.

(32)

32 Módulo de Recaudaciones

Requerimientos funcionales

 El sistema deberá permitir al administrador, generar un reporte de caja diario, concerniente a las actividades que realiza la parroquia.

 El sistema deberá permitir al administrador reimprimir un recibo de pago por petición del cliente.

 El sistema deberá permitir al administrador, generar un comprobante de egreso cuando una situación así lo amerite.

1.12.5 Especificación de requisitos funcionales.

(33)

33 1.13 Análisis

Ver Anexo 1

1.14 Arquitectura candidata para el desarrollo del Sistema.

Para el mantenimiento y escalabidad del proyecto, es aplicar una arquitectura basada en el patrón MVC (Model-View-Controller) el cual tiene las siguientes características: un sistema típico de información que incluya una interfaz gráfica del usuario y acceso a base de datos, tiene un diseño arquitectónico de varios niveles o capas, las cuales estudiamos a continuación:

 Presentación.- Corresponde a la interfaz de usuario para la captura de datos de entrada y presentación de resultados.

 Capa del negocio.- Contiene los procesos del negocio

 Capa de Datos.- Entrega y almacena los datos previamente almacenados para ser procesados

 Almacenamiento: un mecanismo persistente de almacenamiento. (Gestor de Datos).

(34)

34 Presentación

……… ….

Lógica de aplicación.

-Capa del Negocio

……… …..

-Capa de Datos

……… …..

Almacenamiento

Figura 1.6 Arquitectura del Sistema

Sistema de Administración SAP -- _X

ELEGIR SERVICIO

TOTAL

OFRECIDO

CANTIDAD

SALDO

Guardar Salir

Reservaciones Inscripciones

Intermediariode-Basededatos

Administradorde-Seguridad

(35)

35

(36)

36 2.1 Modelo conceptual de la base de datos.

(37)

Si

st

ema de A

dm in ist rac ión de I n formac ión para las Ig les ia s C apí tu lo 2 37 F ig . 2 .1 Mo delo co nce ptu al de la base de dato s. persona_grupo grupo_horario persona_inscripcion Relationship_5 grupo_inscripcion evento_horario persona_horario_evento lugar_evento familia_miembro jerarquia_miembro persona_miembro horario_evento_reservacion persona_reservacion persona_comprobante comprobante_detalle persona_usuario usuario_perfil perfil_usuario lugar_grupo madre_familia padre_familia persona id_persona cedula apellido_paterno apellido_materno nombre_persona sexo direccion_persona mail_persona telefono_persona fecha_nacimiento celebrante tutor estado <pi> Integer

Variable characters (10) Variable characters (20) Variable characters (20) Variable characters (20) Variable characters (1) Variable characters (255) Variable characters (45) Variable characters (20) Date Boolean Boolean Boolean <M> id_persona <pi> lugar id_lugar nombre_lugar apto_reunion capacidad estado <pi> Integer

Variable characters (80) Boolean Integer Boolean <M> id_lugar <pi> grupo id_grupo nombre_grupo costo fecha_inicio fecha_fin check_asistencia check_notas estado <pi> Integer

Variable characters (20) Decimal (6,2) Date Date Boolean Boolean Boolean <M> id_grupo <pi> horario id_horario hora_inicio hora_fin dia <pi> Integer Time Time Integer <M> id_horario <pi> asistencia id_asistencia fecha_asistencia asiste atraso <pi> Integer Date Boolean Boolean <M> id_asistencia <pi> inscripcion id_inscripcion fecha_inscripcion nota1 nota2 nota_total estado estado_aprobacion pagada <pi> <Undefined> <Undefined> <Undefined> <Undefined> <Undefined> Boolean <Undefined> <Undefined> <M> id_inscripcion <pi> familia id_familia direccion_familia tipo_union telefono_familia estado <pi> Integer

Variable characters (255) Variable characters (20) Variable characters (20) Boolean <M> id_familia <pi> evento id_evento nombre_evento estado <pi> Integer

Variable characters (45) Boolean <M> id_evento <pi> horario_evento id_horario_evento dia hora_inicio hora_fin costo aporte_voluntario cupo estado <pi> Integer Integer Time Time Decimal (6,2) Boolean Integer Boolean <M> id_horario_evento <pi> jerarquia id_jerarquia nombre_jerarquia sexo estado <pi> Integer

Variable characters (45) Variable characters (1) Boolean

<M>

id_jerarquia <pi>

miembro id_miembro <pi> <Undefined> <M> id_miembro <pi> reservacion id_reservacion detalle observacion fecha_reservacion estado pagada valor_pago fecha_emision <pi> <Undefined> <Undefined> <Undefined> <Undefined> Boolean <Undefined> <Undefined> <Undefined> <M> id_reservacion <pi> comprobante id_comprobante anulado costo_total egreso fecha_comprobante total_letras <pi> Integer Boolean Decimal (6,2) Boolean Date

Variable characters (45) <M> id_comprobante <pi> detalle_comprobante id_detalle_comprobante costo descripcion <pi> Integer Decimal (6,2) Variable characters (200)

<M> id_detalle_comprobante <pi> iglesia id_iglesia nombre_iglesia zona ruc_iglesia direccion_iglesia telefono <pi> Integer

Variable characters (40) Variable characters (40) Variable characters (15) Variable characters (80) Variable characters (20)

<M> id_iglesia <pi> parametro id_parametro nombre_perfil valor descripcion etiqueta <pi> Integer

Variable characters (45) Variable characters (15) Variable characters (200) Variable characters (45)

<M> id_parametro <pi> perfil id_perfil nombre_perfil descripcion <pi> Integer

Variable characters (45) Variable characters (200)

<M> id_perfil <pi> usuario_perfil id_usuario_perfil estado <pi> Integer Boolean <M> id_usuario_perfil <pi> usuario id_usuario username clave activado <pi> Integer

Variable characters (20) Variable characters (20) Boolean

<M>

(38)

38

2.2 Diagrama de Clases

(39)

39 2.3 Diagramas de Clases del Dominio.

Fig. 2.3 DCD-Ingresar Sistema.

(40)

40 Fig. 2.5 DCD- Gestionar Datos Generales

(41)

41 Fig. 2.7 DCD- Gestionar Inscripciones

(42)

42 Fig. 2.9 DCD- Crear Eventos

(43)

43 Fig. 2.11 DCD- Registrar Personas

(44)

(45)

(46)

46 Fig. 2.15 Ingresar Sistema.

Fig. 2.16 Gestionar Datos Generales.

(47)

47 Fig. 2.18 Gestionar Celebrantes.

(48)

48 Fig. 2.20 Gestionar Jerarquías.

(49)

49 Fig. 2.22 Crear Nuevo Usuario

(50)

(51)

51 Fig. 2.25 Crear Nuevo Grupo.

(52)

(53)

(54)

54 Fig. 2. 29 Registrar asistencias.

(55)

55 Fig. 2. 31 Registrar notas.

(56)

(57)

(58)

58 Fig. 2. 35 Buscar Reservaciones.

(59)

59 Fig. 2. 37 Registrar Personas.

(60)

60 Fig. 2. 39 Reporte de Personas.

(61)

(62)

(63)

(64)

64 Fig. 2. 44 Generar Nuevo Comprobante de Egreso.

(65)

65 Fig. 2. 46 Generar reporte de caja.

2.6 Modelo de despliegue.

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

(66)

66 2.7 Arquitectura del Sistema.

El modelo conceptual del desarrollo para la aplicación del Sistema de Administración, al tratar de integrar a una base de datos, comienza a tener un tamaño excesivo; advertimos entonces la necesidad de dividir sus elementos en subconjuntos más pequeños.

Organizar los elementos en paquetes ofrece la ventaja de separar los elementos detallados en abstracciones más amplias, lo cual brinda soporte a una vista de nivel superior y permite contemplar el modelo en agrupamientos más simples. Podemos concebir la arquitectura global del sistema como si estuviera compuesta de particiones verticales y horizontales. Los paquetes del modelo conceptual, en caso de usarse en el diseño, pueden considerarse particiones de la capa de los objetos del dominio, los cuales mencionamos a continuación:

 Paquete Básico

 Paquete de Modelo de Datos  Paquete Controlador de Datos  Paquete de Vistas.

(67)

67 Fig. 2.48 Arquitectura de la aplicación.10

El cliente es el computador que esté incorporado en la red de la institución o empresa y tiene acceso a la Web mediante un navegador de internet como: firefox, explorer, Netscape, etc. En el Servidor está alojada la aplicación y es el encargado de ejecutar el servidor de aplicaciones. Por último tenemos el Servidor de base de datos quién se encargará de la persistencia de los datos a través de un gestor de base de datos.

En cuanto a lo que respecta del modelo MVC, en la capa Vista (View) es la que contiene las páginas HTML que aparecen en el navegador del cliente. En la capa Controlador (Controller), está implementada la lógica del negocio, en esta de incluyen también los eventos de las páginas, servicios para ejecutar lógica y DAO como medio de acceso a la persistencia. Finalmente tenemos la capa Modelo (Model), la cual contiene a las Entidades las cuales tienen la tarea de mapearse con la base de datos.

2.7.1 Estructura de la aplicación.

A continuación detallamos los componentes de una aplicación Web desarrollada en JEE5, el fin es demostrar cómo funciona la aplicación desde el punto de vista de la programación.

10

(68)

68 La especificación JEE define los siguientes componentes: − Las aplicaciones clientes y los applets son componentes que se ejecutan en el lado del cliente. − Los componentes java servlet y los JSP’s son componentes web que se ejecutan en el lado del servidor − Los Enterprise Java Beans (EJB) son componentes de negocio que se ejecutan en el servidor de aplicación, destinados al desarrollo y despliegue de aplicaciones empresariales. [11].

Fig. 3.2 Contenido de una aplicación Web JEE5.12

[11]

http://www.slideshare.net/jcrubio/curso-ejb3 12

http://bibdigital.epn.edu.ec/handle/15000/2615

ear.file

J2EE

J2EE App.DD

.jar file

J2EE App.Client

Java App

.jar file

Enterprise Bean

EJB DD

EJB Class

Remote

Home

.war file

Web

Web Comp. DD

JSP File

Servlet Class

GIF File

(69)

69

(70)

70

3.1 Fase de Construcción.

Una vez concluidos los diagramas de clases de diseño y destinados al ciclo de desarrollo actual en la aplicación del Sistema de Administración, dispondremos de suficientes detalles para generar un código que utilizaremos en la capa del dominio de los objetos.

Los artefactos UML creados en la fase de diseño-los diagramas de colaboración y las clases de diseño-servirán de entrada en el proceso de generación del código. 3.1.1 El diseño lógico de la base de datos.

“El diseño lógico es el proceso de construir un modelo de datos utilizados en una empresa basado en un modelo de datos específico (como por ejemplo el modelo de datos relacional), pero de forma independiente de cualquier SGBD concreto y de otras consideraciones físicas” (Connolly, 2005). El diseño lógico de la base de datos traduce el modelo conceptual de los datos a un modelo lógico de datos de la organización. Presentamos el modelo lógico global para nuestro sistema de Administración13_:

3.1.2 Modelado Físico

El paso de un modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo características como:

 Conocimiento a fondo de los tipos de objetos (elementos) soportados  Detalles acerca del indexamiento, integridad referencial, restricciones,

tipos de datos, etc

 Detalles y variaciones de las versiones  Parámetros de configuración

 Data Definition Language (DDL).

Como se comentó en el modelado lógico el paso de convertir el modelo a tablas hace que las entidades pasen a ser tablas (más las derivadas de las relaciones) y los atributos se convierten en las columnas de dichas tablas. A continuación presentamos nuestro modelo físico:

13

(71)

Si

st

ema de A

(72)

72 3.1.3 El catálogo del sistema.

Es uno de los componentes fundamentales de un SGBD. Contiene ‘datos acerca de los datos’ o metadatos. El catálogo debe ser accesible a los usuarios. El IRDS 14_es un estándar ISO que define una serie de métodos de acceso para diccionario de datos. Esto permite compartir los diccionarios y transferirlos de un sistema a otro. Mostramos el diccionario de datos para nuestra aplicación:

Asistencia

Campo Tipo Nulo Predeterminado Enlaces a

id_asistencia int(10) No

id_inscripcion int(10) No inscripcion ->

id_Inscripcion

fecha_asistencia date No

asiste tinyint(1) Sí NULL

atraso tinyint(1) Sí NULL

Tabla 3.1 Descripción de la tabla Asistencia.

Comprobante

id_comprobante int(11) No

anulado tinyint(1) No

costo_total decimal(6,2) Sí NULL

egreso tinyint(1) No

fecha_comprobante date No

total_letras varchar(150) Sí NULL

id_cliente int(10) No persona ->

id_persona

Tabla 3.2 Descripción de la tabla Comprobante.

14

(73)

73 Detalle de Comprobante

id_detalle_comproban

te int(11) No

costo decimal(6,2) Sí NULL

descripcion varchar(255) Sí NULL

id_comprobante int(11) No comprobante ->

id_comprobante

Tabla 3.3 Descripción de la tabla Detalle de Comprobante

Evento

id_evento int(10) No

id_lugar int(10) No lugar -> id_lugar

nombre_evento varchar(45) No

estado tinyint(1) No

Tabla 3.4 Descripción de la tabla Evento

Familia

id_familia int(10) No

id_padre int(10) Sí NULL persona ->

id_persona

id_madre int(10) Sí NULL persona ->

id_persona direccion_famili

a varchar(255) No

tipo_union varchar(20) No

telefono_familia varchar(20) Sí NULL

(74)

74 Grupo

id_grupo int(10) No

id_tutor int(10) No persona ->

id_Persona

nombre_grupo varchar(20) Sí NULL

costo decimal(10,0) Sí NULL

id_lugar int(10) Sí NULL lugar -> id_lugar

fecha_inicio date Sí NULL

fecha_fin date Sí NULL

check_asistencia tinyint(1) No

check_notas tinyint(1) No

Tabla 3.6 Descripción de la tabla Grupo

Horario

id_horario int(10) No

id_grupo int(10) No grupo -> id_grupo

hora_inicio time No

hora_fin time No

dia int(10) No

(75)

75 Horario Evento

id_horario_evento int(10) No

dia int(10) No

hora_inicio time No

hora_fin time No

costo decimal(10,0) No

aporte_voluntario tinyint(1) No

cupo int(10) No

id_evento int(10) No evento -> id_evento

id_celebrante int(10) No persona ->

id_persona

personal bit(1) Sí NULL

Tabla 3.8 Descripción de la tabla Horario Evento.

Iglesia

Campo Tipo Nulo Predeterminado

id_iglesia int(10) No

zona varchar(40) No

nombre_iglesia varchar(40) No

ruc_iglesia varchar(15) Sí NULL

direccion_iglesia varchar(80) Sí NULL

telefono varchar(20) Sí NULL

(76)

76 Inscripción

id_inscripcion int(10) No

id_grupo int(10) No grupo -> id_grupo

id_persona int(10) No persona ->

id_Persona

fecha_inscripcion date No

nota_1 decimal(4,1) Sí NULL

nota_2 decimal(4,1) Sí NULL

nota_total decimal(4,1) Sí NULL

estado_aprobacion varchar(20) Sí NULL

pagada tinyint(1) No

Tabla 3.10 Descripción de la tabla Inscripción.

Jerarquía

id_jerarquia int(10) No

nombre_jerarquia varchar(45) No

sexo varchar(1) No

Tabla 3.11 Descripción de la tabla Jerarquía.

Lugar

id_lugar int(10) No

nombre_lugar varchar(80) No

apto_reunion tinyint(1) No

capacidad int(10) Sí NULL

(77)

77 Miembro

id_miembro int(10) No

id_familia int(10) No familia -> id_familia

id_persona int(10) No persona -> id_Persona

id_jerarquia int(10) No jerarquia -> id_jerarquia

Tabla 3.13 Descripción de la tabla Miembro.

Parámetro

id_parametro int(10) No

nombre varchar(30) No

valor varchar(15) No

descripcion varchar(150) Sí NULL

etiqueta varchar(45) No

Tabla 3.14 Descripción de la tabla Parámetro.

Perfil

id_perfil int(10) No

nombre_perfil varchar(45) No

descripcion varchar(200) No

(78)

78 Persona

id_persona int(10) No

apellido_paterno varchar(20) No

apellido_materno varchar(20) No

nombre_persona varchar(20) No

sexo varchar(1) Sí NULL

direccion_persona varchar(255) Sí NULL

email_persona varchar(45) Sí NULL

telefono_persona varchar(20) Sí NULL

celebrante tinyint(1) Sí NULL

tutor tinyint(1) Sí NULL

fecha_nacimiento datetime Sí NULL

cedula varchar(10) No

Tabla 3.16 Descripción de la tabla Persona.

Reservación

id_reservacion int(10) No

id_cliente int(10) No persona ->

id_persona

id_horario_evento int(10) No horario_evento ->

id_horario_evento

detalle varchar(45) Sí NULL

observacion varchar(255) Sí NULL

fecha_reservacion date No

pagada tinyint(1) No

valor_pago decimal(10,0) No

fecha_emision date Sí NULL

(79)

79 Usuario

id_usuario int(10) No

username varchar(20) No

clave varchar(20) No

id_persona int(10) No persona -> id_persona

activado tinyint(1) No

Tabla 3.18 Descripción de la tabla Usuario.

Usuario perfil

id_usuario int(10) No

username varchar(20) No

clave varchar(20) No

id_persona int(10) No persona -> id_persona

activado tinyint(1) No

(80)

Sistema de Información para las Iglesias Capítulo 4

80

(81)

81 4.1 Manual de Usuario.15

4.2 Manual de Programador.

4.2.1 Estándares de Programación.

En la implementación se deberán utilizar los siguientes estándares de programación, los cuales han sido establecidos en base a común acuerdo del equipo; para hacer que la aplicación sea fácilmente mantenible y escalable.

 Para las EJBs

Nombre descriptivo con el primer carácter de todas las palabras en mayúsculas y los otros caracteres con minúsculas y finaliza con la palabra Controller. En caso de que el nombre descriptivo contenga más de una palabra el inicio de la siguiente palabra será en mayúscula también y el nombre se debe escribir de corrido sin guiones ni espacios.

Ejemplo:

- NombreController

- NombreDescriptivoControlador - NombreDescriptivoServicio

 Para las Clases que contienen funciones

Nombre descriptivo con el primer carácter de todas las palabras en mayúsculas y los otros caracteres con minúsculas y finaliza con la palabra Class. En caso de que el nombre descriptivo contenga más de una palabra el inicio de la siguiente palabra será en mayúscula también y el nombre se debe escribir de corrido sin guiones ni espacios.

Ejemplo:

- NombreClass

- NombreDescriptivoClass

 Para las Clases de mapeo a la base de datos

Nombre descriptivo con el primer carácter de todas las palabras en mayúsculas y los otros caracteres con minúsculas. En caso de que el nombre descriptivo contenga más de una palabra el inicio de la siguiente palabra será en mayúscula también y el nombre se debe escribir de corrido sin guiones ni espacios.

Ejemplo:

- Nombre

15

(82)

82

- NombreDescriptivo

 Para los métodos y funciones de las Clases

Nombre descriptivo en minúsculas. En caso de que el nombre descriptivo contenga más de una palabra el inicio de la siguiente palabra será en mayúscula y el nombre se debe escribir de corrido sin guiones ni espacios.

Ejemplo:

- nombre

- nombreDescriptivo

 Para las variables y parámetros de los métodos y funciones:

Ejemplo:

- nombreVariable

- nombreParametro

 Para las pantallas o xHtml

Ejemplo:

- nombre

- nombreDescriptivo

 Para los controles se debe utilizar el prefijo del control y a continuación el nombre

C

Coonnttrrool l PPrreeffiijjoo PPrreeffiijjoo++NNoommbbrre e

T

TeexxttBBoox x TTxxtt ttxxttNNoommbbrree B

Buuttttoon n BBttnn bbttnnNNoommbbrree L

LiissttBBoox x CCmmbb ccmmbbNNoommbbrree C

Chheecckkbbooxx CChhkk cchhkkNNoommbbrree R

RaaddiiooBBuuttttoonn OOpptt ooppttNNoommbbrree

(83)

83 Para el resto de controles se utilizará el formato de métodos y funciones definido anteriormente.

 Para la Base de Datos

- Tabla: Para la tabla se utilizara el nombre de la entidad todo en minúsculas y de

contener más de una palabra se separará cada palabra con un sub-guión.

- Atributos: Para las columnas se utilizara un nombre descriptivo en minúsculas.

Ejemplo:

o Tabla: forma_de_pago o Atributo: nombre_atributo

- Funciones: se utilizará el mismo formato de funciones y métodos definidos anteriormente.

 Para los comentarios

- Para creación de base de datos

/*=====================================================*/ /* DBMS name: Nombre físico */

/* Author: Autor(es) */

/* Created on: fecha y hora de creación */ /*=====================================================*/

- Para creación de funciones

/*=====================================================*/ /*=====================================================*/ /*

PAR ENTRADA: Nombres de los parámetros recibidos PAR SALIDA: Nombre de los parámetros de salida CREADOR: Autor(es)

/*=====================================================*/ /*==================== DESCRIPCION ===================*/

/*Descripción */