Embed Size (px)
Citation preview
UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA CIENCIAS FÍSICAS Y
MATEMÁTICA
CARRERA DE INGENIERÍA INFORMÁTICA
ANÁLISIS, DISEÑO DE UN SISTEMA WEB PARA LA GESTIÓN DEL
DEPARTAMENTO MÉDICO, CONTROL DE MEDICAMENTOS Y
SEGURIDADES PARA EL SISTEMA INTEGRAL DE LA CASA DE LA
CULTURA (CCE)
TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE
INGENIERO INFORMÁTICO
AUTOR: Mónica Catalina Jiménez Calle
TUTOR: Ing. Alicia Lorena Andrade Bazurto, MSc
QUITO – ECUADOR
2015
ii
DEDICATORIA
El presente proyecto de Tesis va dedicado a las personas que han estado
conmigo directa e indirectamente presentes, durante todos los aspectos de
mi vida.
A Dios
Por darme las fuerza, fortaleza y guiarme durante el transcurso de mi vida.
A mis Padres Blanca y Luís
A mis padres que me apoyando incondicionalmente durante toda mi vida
para logara mis metas y objetivos Gracias por sus consejos y ser una guía.
Gracias por enseñarme que con esfuerzo, dedicación, empeño y trabajo se
puede lograr muchas cosas.
A mis Hermanos Mario, Hendry, Michelle
Por estar a mí lado en todo este arduo trabajo y por brindarme su apoyo y
amistad.
A mi Novio Mario
A mí amando novio, por su paciencia, apoyo, comprensión y amor por estar
en conmigo en aquellos momentos en el que el estudio y trabajo ocuparon
mi tiempo. Gracias por ser parte de mi vida, te amo.
Mónica C. Jiménez
iii
AGRADECIMIENTO
Agradezco tanto a Dios por darme la sabiduría, las fuerzas y sobre todo la
paciencia para llegar a la culminación de este proyecto.
A mis padres por su apoyo, confianza, ayuda y sacrificio que tuvieron cada
día para poder brindarme lo necesario y enseñarme grandes valores.
Gracias por todo
A mis hermanos por ser el apoyo diario que tuve durante este proceso, por la
confianza que tuvieron en mí.
A mi querido novio Mario por estar a mí lado apoyando, bríndame su amor y
por tenerme paciencia en aquel momento que este proyecto ocuparon mi
tiempo.
Te agradezco mucho a mi ángel peludo por siempre estar junto a mi
cuando siempre quería llorar y tú me enseñaste con tu corazón puro y
sincero a comenzar a valorar las cosas más pequeñas del mundo.
A mi Tutor y Revisores, les agradezco por la ayuda que me brindaron y por
su guía durante este proyecto.
A mis amigos por brindarme su apoyo y guía durante todo este proyecto.
A todos un GRACIAS por estar conmigo y que Dios los Bendiga. Gracias.
iv
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL
Yo, Mónica Catalina Jiménez Calle en calidad de autor del trabajo de tesis
realizada sobre la “ANÁLISIS, DISEÑO DE UN SISTEMA WEB PARA LA
GESTIÓN DEL DEPARTAMENTO MÉDICO, CONTROL DE
MEDICAMENTOS Y SEGURIDADES PARA EL SISTEMA INTEGRAL DE
LA CASA DE LA CULTURA ECUATORIANA (CCE)", por la presente
autorizó a la, hacer uso de manera total o parcial del contenido de esta obra,
con fines estrictamente académicos o de investigación.
Los derechos que como autor me corresponda, con excepción de la
presente autorización seguirán vigentes a mi favor, de conformidad con lo
establecido en los artículos 5, 6, 8, 19 y demás pertinentes de la Ley de
Propiedad Intelectual y su Reglamento.
Quito, 20 del mayo de 2015
v
CERTIFICACIÓN DEL TUTOR
vi
INFORME FINAL DEL TUTOR
vii
APROBACIÓN DEL TRIBUNAL
viii
CALIFICACIÓN DEL TRABAJO DE GRADUACIÓN
ix
Contenido
DEDICATORIA ............................................................................................................................ii
AGRADECIMIENTO ................................................................................................................... iii
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL ........................................................................ iv
CERTIFICACION DEL TUTOR....................................................................................................... v
INFORME FINAL DEL TUTOR .................................................................................................... vi
APROBACIÓN DEL TRIBUNAL .................................................................................................. vii
CALIFICACIÓN DEL TRABAJO DE GRADUACIÓN ..................................................................... viii
CAPÍTULO 1 .............................................................................................................................. 1
1.1 Introducción ................................................................................................................ 1
1.2 Planteamiento del Problema .............................................................................. 1
1.3 Formulación del Problema.................................................................................. 3
1.4 Interrogantes de la Investigación ...................................................................... 3
1.5 Objetivos de la Investigación ............................................................................. 4
1.5.1 Objetivo General .............................................................................................. 4
1.5.2 Objetivos Específicos ...................................................................................... 4
1.6 Justificación .......................................................................................................... 5
1.7 Alcance .................................................................................................................. 6
1.8 Limitaciones .......................................................................................................... 7
CAPITULO 2 .............................................................................................................................. 9
2 REVISIÓN BIBLIOGRÁFICA ....................................................................................... 9
2.1 Antecedentes ........................................................................................................ 9
2.2 Metodología de Desarrolló ................................................................................. 9
2.2.1 Desarrollo iteractivo e incremental ............................................................. 10
2.2.2 Iteractivo+Incremetal ..................................................................................... 11
2.2.3 Ventajas del desarrollo iterativo e incremental ......................................... 13
2.3 Arquitectura N-CAPAS ..................................................................................... 13
2.4 Arquitectura JEE ................................................................................................ 15
2.4.1 Plataforma de Desarrollo JEE ..................................................................... 15
2.5 Herramientas ...................................................................................................... 17
2.5.1 JAVA ................................................................................................................ 17
2.5.2 Servidor de web Jboss ................................................................................. 19
2.5.3 Jboss Seam .................................................................................................... 20
x
2.5.4 Tecnología EJB .............................................................................................. 20
2.5.5 Eclipse IDE ..................................................................................................... 22
2.5.6 PostgreSQL .................................................................................................... 23
2.5.7 Richfaces ........................................................................................................ 25
2.5.8 iREPORT ............................................................................................................ 26
CAPITULO 3 ............................................................................................................................ 27
3 ESPECIFICACIÓN DE REQUERIMIENTOS .......................................................... 27
3.1 Propósito ............................................................................................................. 27
3.2 Descripción General .......................................................................................... 27
3.2.1 Perspectiva del Sistema ............................................................................... 27
3.2.2 Funcionalidades del Sistema ....................................................................... 27
3.3 Requerimientos .................................................................................................. 28
3.3.1 Requerimientos Funcionales ....................................................................... 28
3.3.2 Requerimientos No Funcionales ................................................................ 29
3.4 Casos de Uso ..................................................................................................... 30
3.4.1 OML (Open Modeling Languaje) ................................................................. 32
3.5 Caso de Uso Generales. .................................................................................. 32
3.5.1 Administración del Sistema Integral CCE ................................................. 32
3.5.2 Creación de la Historia Clínica .......................................................................... 34
3.5.3 Inventario de Medicamentos ........................................................................ 36
3.5.4 Reportes Enfermera ...................................................................................... 38
3.5.5 Gestión de Pacientes ........................................................................................ 40
3.5.6 Reportes Médicos ............................................................................................ 42
3.5.7 Interactivo de la enfermera .......................................................................... 43
3.5.8 Interactivo del Médico ................................................................................... 45
3.6 Diagrama de Secuencias.................................................................................. 47
3.6.1 Diagrama Secuencia de Ingreso al Sistema ............................................ 49
3.6.2 Diagrama Secuencia Creación de Ficha ................................................... 50
3.6.3 Inventario de Medicamento .......................................................................... 52
3.7 Ficha Médica ...................................................................................................... 54
3.7.1 Historial Médico ............................................................................................. 54
3.7.2 Diagnóstico y Tratamiento ........................................................................... 55
3.7.3 Reporte Médico .............................................................................................. 56
CAPIULO 4 .............................................................................................................................. 57
xi
4 DISEÑO, IMPLEMENTACION Y PRUEBAS .......................................................... 57
4.1 Modelo Orientado a Objetos del Sistema ...................................................... 57
4.2 Modelo de Base de datos del sistema ............................................................ 58
4.3 Diagrama de Clases .......................................................................................... 59
4.4 Diagrama de Componentes ...................................................................................... 65
4.5 Implementación ........................................................................................................ 66
4.5.1 Recursos requeridos ......................................................................................... 66
4.6 Plan de Pruebas ........................................................................................................ 67
4.7 Entrega del Aplicativo ............................................................................................... 69
CAPITULO 5 ............................................................................................................................ 70
5 CONCLUSIONES Y RECOMENDACIONES.......................................................... 70
5.1 Conclusiones ...................................................................................................... 70
5.2 Recomendaciones ............................................................................................. 71
5.3 Glosario de Términos ........................................................................................ 72
Bibliografía ....................................................................................................................... 79
6 ANEXOS .......................................................................................................................... 80
xii
Lista de Figuras
Figura 1. Desarrollo iterativo e incremental ................................................................... 10
Figura 2. Avance de desarrollo 1 ..................................................................................... 12
Figura 3. Avance de desarrollo 2 ..................................................................................... 12
Figura 4. Arquitectura N-Capas ....................................................................................... 14
Figura 5. Arquitectura N-Capas/3-Capas ....................................................................... 15
Figura 6.Arquitectura JEE ................................................................................................. 16
Figura 7. Arquitectura de Eclipse..................................................................................... 23
Figura 8. Diagrama OML .................................................................................................. 32
Figura 9. Caso de Uso. Administración de Sistema ..................................................... 33
Figura 10.Caso de Uso: Creación de historias clínicas ............................................... 35
Figura 11. Caso de Uso: Inventario de Medicamentos ................................................ 37
Figura 12. Caso de Uso: Reportes Enfermera .............................................................. 39
Figura 13. Caso de Uso: Gestión de pacientes ............................................................. 41
Figura 14. Cado de Uso: Reportes Médicos .................................................................. 42
Figura 15. Caso de Uso: Interactivo Enfermera ............................................................ 44
Figura 16. Caso de Uso: Interactivo Médico .................................................................. 46
Figura 17. Diagrama de Secuencia: Ingreso al sistema ............................................. 49
Figura 18. Diagrama de Secuencia: Paciente (CCE) ................................................... 50
Figura 19. Diagrama de Secuencia: Paciente particular.............................................. 51
Figura 20. Diagrama de Secuencia: Entrada Medicamento........................................ 52
Figura 21. Diagrama de Secuencia: Salida de Medicamento ..................................... 52
Figura 22. Diagrama de Secuencia: Kardex Medicamento ......................................... 53
Figura 23. Diagrama De Secuencia: Reportes Enfermera .......................................... 53
Figura 24. Diagrama de Secuencia: Historial Médico .................................................. 54
Figura 25. Diagrama de Secuencia: Diagnóstico y Tratamiento ................................ 55
Figura 26. Diagrama de Secuencia: Reportes Médico ................................................ 56
Figura 27. Modelo de Objetos .......................................................................................... 57
Figura 28. Diagrama de Base de Datos del Sistema ................................................... 58
Figura 29. Diagrama de Clases: Administración Usuarios .......................................... 60
Figura 30. Diagrama de Clases: Administración Roles................................................ 61
Figura 31. Diagrama de Clases: Roles Acceso ............................................................. 61
Figura 32. Diagrama de Clases: Entrada Medicamento .............................................. 62
Figura 33. Diagrama Clases: Inventario Medicamentos .............................................. 63
Figura 34. Diagrama Clases: Salida Medicamento ...................................................... 63
Figura 35. Diagrama Clases: Pacientes ......................................................................... 64
Figura 36.Diagrama de Componentes ............................................................................ 65
xiii
Lista de Tablas
Tabla 1. Administración del Sistema ................................................................................ 33
Tabla 2. Creación de Historias Clínicas........................................................................... 34
Tabla 3. Inventario de Medicamentos .............................................................................. 36
Tabla 4. Reportes Enfermera ............................................................................................ 38
Tabla 5. Gestión Pacientes ................................................................................................ 40
Tabla 6. Reportes Médicos ................................................................................................ 42
Tabla 7. Interactivo Enfermera .......................................................................................... 44
Tabla 8. Interactivo Médico ................................................................................................ 45
Tabla 9. Elementos diagrama de clases ......................................................................... 60
Tabla 10. Requerimientos de software ............................................................................ 66
Tabla 11. Requerimientos de hardware........................................................................... 66
Tabla 12.Funcionalidades al Sistema .............................................................................. 69
xiv
RESUMEN
“ANÁLISIS, DISEÑO DE UN SISTEMA WEB PARA LA GESTIÓN DEL
DEPARTAMENTO MÉDICO, CONTROL DE MEDICAMENTOS Y
SEGURIDADES PARA EL SISTEMA INTEGRAL DE LA CASA DE LA
CULTURA ECUATORIANA (CCE)"
El presente trabajo, trata sobre el desarrollo de un aplicativo WEB, el cual
automatiza el proceso de gestión de pacientes, historias clínicas, control de
medicamentos para el departamento médico y seguridades para el sistema
integral (CCE), mediante el uso de herramientas de software libre.
El mismo que permite realizar búsquedas rápidas, generar reportes de la
información.
El aplicativo se desarrolló con herramientas de software libre tales como
lenguaje de programación JAVA, motor de base de datos Postgres.
DESCRIPTORES GESTIÓN PACIENTES / JAVA / ADMINISTRACION DE USUARIOS
/KARDEX / INVENTARIO DE MEDICAMENTOS / HISTORIAL MEDICO
xv
ABSTRACT
“ANALYSIS, DESIGN OF A WEB SYSTEM FOR THE MANAGEMENT OF
THE MEDICAL DEPARTMENT, MEDICATION MONITORING AND
ASSURANCES FOR THE INTEGRAL SYSTEM OF CASA DE LA
CULTURA ECUATORIANA (CCE)”
The present work, it is about the development of a Web application, which
automates the process of patient management, medical histories, medication
monitoring for the medical department and assurances to the comprehensive
system (CCE), through the use of free software tools.
The same that allows you to perform quick searches, generate reports of the
information.
The application was developed with free software tools such as Java
programming language, database engine Postgres.
DESCRIPTORS
MANAGEMENT PATIENTS/ JAVA / USER ADMINISTRATION /KARDEX /
MEDICINES INVENTORY / MEDICAL HISTORY
xvi
CERTIFICADO DE TRADUCCIÓN DE RESUMEN.
Por este medio, Yo, Mayra Rosalía Shuguli López con cedula No.
1716425135 certifico que la traducción de español a ingles del resumen del
trabajo de graduación, previo a la obtención del título de ingeniero
informático del egresado Mónica Catalina Jiménez Calle, fue realizada por
mi persona.
Particular que informo para los fines pertinentes.
Atentamente.
Doc. Mayra Rosalía Shuguli López.
Traductor
xvii
1
CAPÍTULO 1
1.1 Introducción
La Casa de la Cultura Ecuatoriana1 (CCE) es una institución autónoma de
gestión cultural en la República del Ecuador. Funciona desde el año 1944 y
tiene su sede principal en la ciudad de Quito en la Avenida Patria entre las
avenidas 12 de Octubre y 6 de Diciembre, en pleno límite entre el sector
norte de la ciudad y el centro.
Cuenta además con sedes en casi todas las provincias del país. Tiene por
objeto coadyuvar al desarrollo de los derechos culturales y principios
programáticos, enmarcados en la política pública cultural del Estado
ecuatoriano (Art.3, Ley Orgánica de la Casa de la Cultura Ecuatoriana).
En la actualidad CCE maneja grandes volúmenes de datos, con la finalidad
de obtener la información requerida en tiempo real se ve la necesidad de
automatizar varios procesos mediante el desarrollo de una aplicación web
que permita mejorar la información generada por el Departamento Médico y
los módulos que conforman el Sistema Integral de Casa de la Cultura.
Las aplicaciones web nos ayudan a automatizar los procesos de las
organizaciones ya que nos brindar múltiples benéficos como la portabilidad
de acceder a la desde cualquier navegador, ahorro de tiempo, un consumo
bajo de recursos
Así pues, automatizar el Departamento Médico (CCE) se necesitan una
aplicación desarrollada bajo software libre como los son lenguaje de
programación JAVA y motor de base de datos Postgres SQL.
1.2 Planteamiento del Problema
La Casa de la Cultura Ecuatoriana (CCE) es una institución autónoma, la
cual se le ha encargado de promover, fomentar, investigar y difundir el arte,
ciencia y el patrimonio cultural del Ecuador.
1 Casa de la Cultura Ecuatoriana, Obtenidos el 21 de abril
2015http://es.wikipedia.org/wiki/Casa_de_la_Cultura_Ecuatoriana
2
La Casa de la Cultura Ecuatoriana en la actualidad está sistematizando
varios departamentos razón por la cual se necesita de un sistema integral
que consta de cuatro módulos:
Implantación de un Sistema para la Gestión Reliquias Ecuatorianas
que son Patrimonio de la Humanidad Almacenadas en las Bodegas y
Facturación de Obras Inéditas de Grandes Autores y Artistas
Ecuatorianos Forjados de la Cultura, Las Artes y de la Ciencias.
Análisis, diseño e implantación de un sistema para la gestión de la
cinemateca de la Casa de la Cultura Ecuatoriana.
Sistema para la gestión y reservación de salas, galerías, auditorios y
teatros de la Sede Nacional de Casa de la Cultura Ecuatoriana.
Análisis, diseño de un sistema web para la Gestión del departamento
médico, control de medicamentos y seguridades para el sistema integral de
la Casa de la Cultura Ecuatoriana.
En vista a que se va a desarrollar cuatro aplicativos para el Sistema Integral
de la Casa de la Cultura necesita un módulo para la gestión de la seguridad
que nos permita llevar un control de las personas que acceden y manipulan
la información existente cada uno de los departamentos para los cuales se
están realizando los diferentes sistemas en cuestión.
El Departamento Médico de la Casa de la Cultura Ecuatoriana está
constituido área médica y odontológica las cuales presenta una serie de
inconvenientes tales como:
Perdida de información.- Los datos de la historia clínica y los
resultados de exámenes es información confidencial y de vital
importancia, sin embargo es manipulada por varias personas,
archivada en lugares poco propicios, lo cual facilita su pérdida.
Falta de agilidad en la atención al paciente.- La historia clínica de
cada paciente está constituida por formularios que se llenan de
forma manual haciendo que este proceso sea demoroso.
3
Desconocimiento de medicamentos existentes.- El servicio médico y
odontológico maneja cierta cantidad de medicamentos los cuales son
contabilizados mediante kardex2 sin embargo este control no nos
permite conocer la cantidad de medicamentos que existen.
Por lo tanto se plantea desarrollar una solución informática a los problemas
anteriormente mencionados y así mejorar el funcionamiento de las
seguridades del Sistema Integral de Casa de la Cultura y Departamento
Médico.
1.3 Formulación del Problema
Cómo gestionar la seguridad del Sistema Integral de la Casa de la Cultura y
llevar un control sistemático de los medicamentos y fichas médicas del
Departamento Médico ya que la información de este centro médico
actualmente se lleva de forma manual.
Se desea desarrollar un aplicativo que brinde soporte al problema actual de
las seguridades y departamento médico, un SISTEMA WEB PARA LA
GESTION DEL DEPARTAMENTO MEDICO, CONTROL DE
MEDICAMENTOS Y SEGURIDADES PARA EL SISTEMA INTEGRAL DE
LA CASA DE LA CULTURA ECUATORIANA (CCE). Este aplicativo
permitirá agilizar los procesos que se manejan en este centro.
1.4 Interrogantes de la Investigación
Para la realización de este proyecto se ha establecido algunas preguntas
que nos van a ayudar a entender de mejor manera cual es el problema que
debemos resolver.
¿Es posible desarrollar un Sistema Integral conformado por varios
módulos para la Casa de la Cultura Ecuatoriana (CCE)?.
¿Se puede tener un módulo para la gestión de la seguridad para el
Sistema Integral de la Casa de Cultura?
2 Kárdex: es una herramienta que permite imprimir reportes con información resumida
acerca de las transacciones de inventario de su compañía
4
¿Es factible elaborar una herramienta que me permita automatizar la
información del Departamento Medico y Odontológico de la Casa de
Cultura Ecuatoriana?
¿La herramienta desarrollada ayudara a los médicos y pacientes del
Departamento Medico de la Casa de Cultura Ecuatoriana a mejorar
sus funciones?
¿Se puede conocer de manera efectiva la cantidad de medicamentos
con los que cuenta el dispensario médico?
1.5 Objetivos de la Investigación
1.5.1 Objetivo General
Proporcionar al Sistema Integral de la Casa de Cultura un módulo de
seguridades de acceso y ejecución de crear, borrar, actualizar para llevar un
control de las personas que acceden y manipulan la información y al
Departamento Médico un aplicativo que permita mejorar la administración y
la gestión de la información generada a través de un aplicativo en línea que
me permita optimizar y automatizar la información de esta dependencia
mediante el uso de herramientas de software libre.
1.5.2 Objetivos Específicos
Controlar mediante el módulo de seguridades que personas acceder
a los sistemas y a la información de cada uno de los departamentos.
Optimizar el proceso administrativo del Departamento Médico de la
Casa de la Cultura Ecuatoriana.
Realizar un control del inventario correspondiente a los medicamentos
con los que cuenta departamento.
Efectuar entrevistas con los usuarios para determinar los
requerimientos para poder realizar el aplicativo y elaborar los
respectivos manuales que correspondan al funcionamiento del
sistema en cuestión.
5
1.6 Justificación
Debido a que la información que maneja la Casa de la Cultura en sus
diferentes departamentos es importante se necesita establecer seguridades
a nivel de acceso y manipulación de la información para evitar el uso
inadecuado de la información.
Actualmente las personas que trabajan en el Departamento Medico están
conscientes de que deben contar con un sistema que les permita llevar un
mejor control en lo que concierne al manejo del historial de cada paciente y
llevar un inventario de los medicamentos con los que cuenta dicho
departamento.
Al realizar las entrevistas al personal de esta área se pudo identificar las
siguientes falencias:
Las fichas médicas de las pacientes se llevan de forma manual
produciendo que dicha información de cada uno de los pacientes se
pueda extraviar y dicha información no se la pueda encontrar de
forma rápida.
El registro de ingreso de medicamentos con los que cuenta el
Departamento Médico se lo lleva de forma manual provocando que no
se pueda conocer con certeza que medicamentos cuenta la unidad
médica.
Al momento de hablar de la automatización de los procesos administrativos
nos referimos en convertir las fichas médicas de cada paciente que se lleva
de forma manual a un sistema que me automatice la fichas médicas de los
pacientes permitiéndoles a los usuarios finales mejorar la calidad de servicio
en lo que concierne en las búsqueda del historial de los pacientes y llevar un
mejor control de la información.
El control de las medicinas con lo que cuenta el Departamento Médico en
estos momentos se los llevan kárdex 3y no les permite conocer con certeza
3 Kárdex: es una herramienta que permite imprimir reportes con información resumida
acerca de las transacciones de inventario de su compañía
6
con que cantidad de medicamentos cuenta su inventario lo que se quiere
automatizar en esta parte es que el manejo de kárdex permitiéndoles
conocer de forma precisa y efectiva los ingresos y egresos de cada uno de
los medicamentos.
1.7 Alcance
El propósito es de este proyecto es proporcionar a la Casa de la Cultura
Ecuatoriana un módulo de gestión de seguridades y al Departamento Médico
un sistema confiable y que sea fácil de usar para el usuario, que permita
mejorar la eficiencia mediante la automatización de historias clínicas de los
pacientes y llevar un mejor control de los medicamentos con los que cuenta
dicho departamento.
El sistema constará de lo siguiente:
MÓDULO DE SEGURIDADES
Administración de Usuarios
En la administración de usuarios permitirá la creación de usuarios,
editar usuarios, inactivar un usuario.
Los usuarios que van a acceder al sistema son:
Administrador
Usuarios
Administración de Roles
La administración de roles permitirá la creación de roles, editar roles,
inactivar un rol.
Administración de Permisos
La administración de permisos permitirá la creación de permiso, editar
permisos, inactivar un permiso.
7
MÓDULO DEL DEPARTAMENTO MÉDICO
Ingreso al Sistema
Previo al uso del sistema, el usuario deberá autenticarse para el
ingreso al mismo con su nombre de usuario y contraseña respectivo y
contará con las respectivas seguridades del caso.
Historial Clínica
La creación de la historia clínica de un paciente se da cuando este
llega por primera vez al Departamento Médico y se le registran sus
datos.
Medicina General y Odontología
Una vez que los datos de los pacientes han sido registrados ellos
podrá ser atenido en las siguientes áreas que brinda el Departamento
Médico (Medicina General, Odontología)
Control de Inventario de Medicamentos
El sistema de inventario de medicamentos estará a disposición del
médico, proporcionando unos reportes precisos de los medicamentos
con los que cuenta el Departamento Médico.
Generación de Reportes
El sistema permitirá la generación de los siguientes reportes:
La ficha médica del paciente del área de medicina general y
odontología.
Los reportes de inventario de medicamentos de entrada y
salida de los mismos.
1.8 Limitaciones
Tomando en cuenta los objetivos, y en base al desarrollo de la presente tesis
se consideraron las siguientes limitaciones:
8
La administración de usuarios, roles y permisos deberían ser
definidos por la Casa de Cultura Ecuatoriana.
Solo las personas que estén registradas en el módulo de seguridad
pueden acceder al sistema.
Los módulos que se van a desarrollar son :
Historial Clínico
Área de Medicina General
Área de Odontología
Inventario de Medicamentos
En lo referente al control de inventario de medicamento solo se va a
realizar un control con los medicamentos que cuenta el dispensario
médico no lo que concierne a los costos de cada uno los insumos.
El ingreso de la información al sistema no está incluido en la
realización del proyecto.
9
CAPITULO 2
2 REVISIÓN BIBLIOGRÁFICA
2.1 Antecedentes
Según las conversaciones mantenidas con el personal que labora en la
Casa de la Cultura ellos tienen la necesidad de contar con un aplicativo que
le permita gestionar la seguridad y mejorar el control de las historias clínicas
de los pacientes y el control del inventario de los medicamentos.
La Facultad de Ingeniería, percibiendo la ausencia de un sistema que
permita mejorar la seguridad del Sistema Integral de la Casa de la Cultura
Ecuatoriana y la gestión de la información que genera el Departamento
Médico facilitando un aplicativo que me permita solucionar los problemas
ya anteriormente mencionados.
Se considera como solución a este problema realizar un aplicativo web que
me permita gestionar la seguridad del Sistema Integral de Casa y
automatizar la parte administrativa en lo referente a las historias clínicas de
los pacientes y en cada una de las áreas en cuestión, llevar un mejor control
del inventario de medicamentos que tiene el Centro Médico.
Actualmente la informática forma parte de nuestras actividades diarias,
permitiendo desarrollar e implementar sistemas para dar solución a los
problemas que se presenta en el Departamento Medico y en las seguridades
del Sistema Integral de la Casa de Cultura.
Para ello se propone la investigación del presente proyecto de tesis, que
ayude al Sistema Integral y al Departamento Médico brindar un mejor
servicio a sus usuarios.
2.2 Metodología de Desarrolló
Para la elaboración del presente proyecto el modelo de procesos
seleccionado para la automatización del departamento médico, la seguridad
para el Sistema Integral la Casa de la Cultura es el Método Iterativo e
10
Incremental que es una combinación de ambos diseños para construir un
modelo de desarrollo.
2.2.1 Desarrollo iteractivo e incremental4
El desarrollo iterativo e incremental es un proceso de desarrollo de
software cíclico desarrollado en respuesta a la debilidad del modelo en
cascada. Empieza con una planificación inicial y termina con el despliegue,
con la iteración cíclica en el medio.
Para apoyar al desarrollo de proyectos por medio de este modelo se han
creado distintos frameworks, entornos de trabajo, como puede ser el
Rational Unified Process. El desarrollo incremental e iterativo es también
una parte esencial de un tipo de programación conocido como Extreme
Programming y los demás frameworks de desarrollo rápido de software.
El desarrollo iterativo e incremental es una parte esencial de RUP,
de DSDM, XP y generalmente de los marcos de trabajo de desarrollo de
software ágil.
Figura 1. Desarrollo iterativo e incremental
El desarrollo incremental es una estrategia programada y en etapas, en la
4 Desarrollo interactivo e incremental, Obtenida el 14 de abril 2015 desde
https://www.incibe.es/file/N85W1ZWFHifRgUc_oY8_Xg
11
que las diferentes partes del sistema se desarrollan en diferentes
momentos o a diferentes velocidades, y se integran a medida que se
completan.
El desarrollo iterativo es una estrategia de programación de reproceso en
la que el tiempo se separa para revisar y mejorar partes del sistema. Esto
no presupone desarrollo incremental, pero trabaja muy bien con él. Una
diferencia típica es que la salida de un incremento no está
necesariamente sujeta a más refinamiento, y sus pruebas o la
realimentación del usuario no se usa como entrada para revisar
los planes o especificaciones de los incrementos sucesivos. Por el
contrario, la salida de una iteración se examina para modificación, y
especialmente para revisar los objetivos de las sucesivas iteraciones.
Los dos términos se pusieron en práctica a mediados de los 90s. Los
autores del Proceso Unificado (UP) y el proceso unificado Rational (RUP)
seleccionaron el término desarrollo iterativo e iteraciones para hacer
referencia de forma general a cualquier combinación de desarrollo
incremental e iterativo. La mayoría de las personas que dicen desarrollo
iterativo quieren decir que hacen ambos desarrollo incremental e iterativo.
2.2.2 Iteractivo+Incremetal5
Aunque normalmente hablamos de iterativo e incremental (o incluso
sólo de iterativo), ello no quiere decir que ambos sean lo mismo. De
hecho, el desarrollo iterativo no implica, ni presupone el uso del incremental,
y viceversa. Para ver la diferencia, veamos la definición de cada tipo de ciclo
de vida:
El desarrollo incremental surge para eliminar los riesgos asociados
a construir productos software grandes o con alto grado de
complejidad. Se centra en desarrollar por partes el producto software,
5 Iteractivo+Incremental, Obtendia el 14 de abril 2015 desde http://asier-
ares.blogspot.com/2012/02/leccion-2-el-ciclo-de-vida-iterativo-e.html
12
para después integrarlas a medida que se completan. Un ejemplo de
un desarrollo puramente incremental puede ser la agregación de
módulos en diferentes fases. Gráficamente vemos como cada vez se
van añadiendo nuevas partes que se van integrando para formar el
producto final.
Figura 2. Avance de desarrollo 1
El desarrollo iterativo se centra en mejorar y revisar el producto ya
creado. En cada ciclo se revisa y mejora el trabajo. Un ejemplo de
desarrollo iterativo y no incremental es aquel basado en
refactorizaciones (te dejamos una pequeña introducción a la
refactorización), en el que cada ciclo mejorando más el producto. En
el ejemplo gráfico de abajo se puede apreciar que se trata de un
método de mejora a través de las sucesivas iteraciones. Es
importante señalar no hay adición de funcionalidades en el producto,
hay revisión y mejora.
Figura 3. Avance de desarrollo 2
De la unión del ciclo de vida iterativo y el incremental al final de cada
iteración se consigue una versión estable del software, añadiendo
además nuevas funcionalidades a las versiones anteriores. Así, el
producto software se desarrolla por incrementos en el que cada iteración
(incluida la primera) obtiene una versión operativa del producto, así el
13
sistema se desarrolla y mejora poco a poco y se obtiene un “feedback”
continuo por parte del cliente sobre un producto operativo.
2.2.3 Ventajas del desarrollo iterativo e incremental6
Reducción de riesgos basándose en una retroalimentación temprana.
Mayor flexibilidad para manejar cambios nuevos o modificaciones a
los mismos.
La complejidad nunca resulta abrumadora.
Se produce retroalimentación en una etapa temprana, porque la
implementación se efectúa rápidamente con una parte pequeña del
sistema.
Visión de avance en el desarrollo, viendo trabajo operativo real
desde etapas iniciales del ciclo de desarrollo.
Obtención del “feddback” del usuario sobre un prototipo
operativo, así puede orientar el desarrollo sí puede orientar el
desarrollo hacia el cumplimiento de sus necesidades, y realizar todas
las adaptaciones identificadas para cumplir con los objetivos
planteados.
Permite manejar el riesgo del proyecto, apuntando a la resolución
de los problemas por partes y no caer en la inanición del “súper
análisis “del producto.
El aprendizaje y experiencias del equipo iteración tras iteración
sobre un prototipo operativo, lo que mejora exponencialmente el
trabajo, aumenta la productividad y permite optimizar el proceso en
el corto plazo.
2.3 Arquitectura N-CAPAS7
La arquitectura de N-Capas es un estilo más que existe en la programación,
es importante en muchos aspectos principalmente porque nos permite en
6 Uml y los procesos de desarollo de software , Obtenida desde 14 de abril 2015
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rea_c_ji/capitulo3.pdf 7 Arquitectura N-capas y LinqToSQL ( Obtenido 14 de abril 2015)
http://www.nicholls.co/blog/post/Arquitectura-N-Capas-y-LinqToSQL
14
nuestros desarrollos separar la lógica de Acceso a Datos (Capa de Datos)
de la lógica del Negocio (Capa de Negocio) y a su vez de la lógica de Diseño
(Capa de Presentación). En definitiva estamos creando un sistema modular
(Cada capa solicita un servicio de la capa inferior) que es mucho más legible
y manejable, en donde cualquier capa puede ser modificada o reemplazada
y el sistema debe seguir funcionando normalmente.
Figura 4. Arquitectura N-Capas
Fuente: Internet
Este estilo de despliegue arquitectónico describe la separación de la
funcionalidad en segmentos separados de forma muy parecida al estilo de
capas, pero en el cual cada segmento está localizado en un computador
físicamente separado. Este estilo ha evolucionado desde la aproximación
basada en componentes generalmente usando métodos específicos de
comunicación asociados a una plataforma en vez de la aproximación basada
en mensajes.
15
Figura 5. Arquitectura N-Capas/3-Capas8
Fuente: Internet
2.4 Arquitectura JEE9
Java Platform, Enterprise Edition o Java EE (anteriormente conocido como
Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una
plataforma de programación parte de la Plataforma Java para desarrollar y
ejecutar software de aplicaciones en Lenguaje de programación Java con
arquitectura de N niveles distribuida, basándose ampliamente en
componentes de software modulares ejecutándose sobre un servidor de
aplicaciones. La plataforma Java EE está definida por una especificación
similar a otras especificaciones del Java Community Process (JCP), Java EE
es también considerada informalmente como un estándar debido a que los
suministradores deben cumplir ciertos requisitos de conformidad para
declarar que sus productos son conformes a Java EE; estandarizado por
The Java Community Process / (JCP).
2.4.1 Plataforma de Desarrollo JEE10
Es una plataforma de programación parte de la Plataforma Java para
desarrollar y ejecutar software de aplicaciones en el lenguaje de
programación Java. Permite utilizar arquitecturas de N capas distribuidas y
8 Arquitectura N-Capas/3-Capas .Obtenida 14 de abril 2015 desde
http://www.juanpelaez.com/geek-stuff/arquitectura/arquitectura-basada-en-capas/
9 Java EE, es una plataforma de programación. Obtenido 6 de julio 2013 desde
http://es.wikipedia.org/wiki/Java_EE 10
Java EE. Obtenida 14 de abril 20145 desde http://es.wikipedia.org/wiki/Java_EE
16
se apoya ampliamente en componentes de software modulares
ejecutándose sobre un servidor de aplicaciones.
Arquitectura JEE
Figura 6.Arquitectura JEE
Fuente: Internet
La arquitectura JEE implica un modelo de aplicaciones distribuidas en
diversas capas o niveles (tier).
La capa cliente admite diversas tipos de clientes (HTML, Applet,
aplicaciones Java, etc.).
La capa intermedia (middle tier) contiene subcapas (el contenedor
web y el contenedor EJB).
La tercera capa dentro de esta visión sintética es la de aplicaciones
'backend' como ERP, EIS, bases de datos, etc.
Un concepto clave de la arquitectura es el de contenedor, que en forma
genérica no es más que un entorno de ejecución estandarizado que
ofrece unos servicios por medio de componentes. Los componentes
17
externos al contenedor tienen una forma estándar de acceder a los
servicios de dicho contenedor, con independencia del fabricante.
2.5 Herramientas
2.5.1 JAVA
Java es un lenguaje de programación con el que podemos realizar cualquier
tipo de programa. En la actualidad es un lenguaje muy extendido y cada vez
cobra más importancia tanto en el ámbito de Internet como en la informática
en general.
Una de las principales características por las que Java se ha hecho muy
famoso es que es un lenguaje independiente de la plataforma. Eso quiere
decir que si hacemos un programa en Java podrá funcionar en cualquier
ordenador del mercado.
Características 11
Java es un lenguaje de programación de alto nivel que se caracteriza por
ser:
1.- Simple: Java es un lenguaje de programación “simple” que puede ser
programa sin extenso entrenamiento, mientras siga siendo adaptado a
prácticas actuales de software.
2.-Orientado a objetos: La programación en Java está diseñada para ser
orientada a objetos desde la raíz.
11
Java. Obtenido 9 de mayo 2014 desde http://www.javagratis.net63.net/que-es-java.html
18
3.- Multihilo: La capacidad multihilo de la tecnología Java proporciona el
significado de construir aplicaciones con muchos hilos (procesos)
concurrentes de actividad.
4.-Dinamico: El lenguaje y el sistema “run-time” son dinámicos en sus capas
de conexión. Las clases son conectadas solamente si sin necesarias.
5.- Arquitectura Neutral: Gracias a una máquina virtual se puede hacer
funcionar los programas en cualquier tipo de máquinas o hardware
(windows, mac,pdas,móviles…).
6.- Portable: Tus programas desarrollados en Java son los mismos en cada
plataforma, no hay incompatibilidades de tipo de datos entre arquitecturas de
hardware y software.
7.- Alto Rendimiento: Rendimiento es siempre una consideración. La
Plataforma Java logra un rendimiento superior adoptado un plan por el cual
el intérprete puede correr a toda velocidad sin necesidad de revisare el
entorno “run-time”. El recolector automático de basura corre como un
proceso o hilo de baja prioridad, asegurado una lata prioridad de que la
memoria esté disponible cuando sea requerida.
8.- Robusto: La programación en lenguaje de Java está diseñada para crear
software fiable. Provee un extenso chequeo en el tiempo de compilación,
seguido por un segundo nivel donde se verifica su funcionamiento (rum-
time).
9.- Seguro: La tecnología Java está diseñada para operar en entornos
distribuidos, lo cual significa que la seguridad es de extrema importancia.
Con características de seguridad diseñadas dentro del lenguaje y el “rum-
time system”, Java te permite contribuir aplicaciones que no pueden ser
invadidas desde afuera.
19
2.5.2 Servidor de web Jboss12
JBoss es un servidor de aplicaciones J2EE de código abierto implementado
en Java puro. Al estar basado en Java, JBoss puede ser utilizado en
cualquier sistema operativo que lo soporte. Los principales desarrolladores
trabajan para una empresa de servicios, JBoss Inc., adquirida por Red Hat
en Abril de 2006, fundada por Marc Fleury, el creador de la primera versión
de JBoss. El proyecto está apoyado por una red mundial de colaboradores.
Los ingresos de la empresa están basados en un modelo de negocio de
servicios. JBoss implementa todo el paquete de servicios de JEE. JBoss AS
es el primer servidor de aplicaciones de código abierto, preparado para la
producción y certificado J2EE 1.4, disponible en el mercado, ofreciendo una
plataforma de alto rendimiento para aplicaciones de e-business.
Combinando una arquitectura orientada a servicios revolucionaria con una
licencia de código abierto, JBoss AS puede ser descargado, utilizado,
incrustado y distribuido sin restricciones por la licencia. Por este motivo es la
plataforma más popular de middleware para desarrolladores, vendedores
independientes de software y, también, para grandes empresas.
Las características destacadas de JBoss incluyen:
Producto de licencia de código abierto sin coste adicional.
Cumple los estándares.
Confiable a nivel de empresa.
Incrustable, orientado a arquitectura de servicio.
Flexibilidad consistente.
12
BOSS, es un servidor de aplicaciones de código abierto implementado en JAVA. Obtenida e5 de
julio 2013 desde http://es.wikipedikia.org/wiki/JBoss
20
Servicios del middleware para cualquier objeto de Java.
2.5.3 Jboss Seam13
JBoss Seam fue un framework desarrollado por JBoss, una división de Red
Hat. El líder del proyecto era Gavin King, también autor del framework para
mapeo objeto relacional Hibernate. Combina a los 2 frameworks Enterprise
JavaBeans EJB3 y JavaServerFaces JSF. Se puede acceder a cualquier
componente EJB desde la capa de presentación refiriéndote a él mediante
su nombre de componente seam.
Seam introduce el concepto de contextos. Cada componente de Seam existe
dentro de un contexto. El contexto conversacional por ejemplo captura todas
las acciones del usuario hasta que éste sale del sistema o cierra el
navegador - inclusive puede llevar un control de múltiples pestañas y
mantiene un comportamiento consistente cuando se usa el botón de
regresar del navegador.
Es posible generar automáticamente una aplicación web de altas, bajas
cambio y modificaciones a partir de una base de datos existente utilizando
una herramienta de línea de comandos llamada seam-gen incluida con el
framework. El desarrollo WYSIWYG es facilitado a través del uso de las
JBoss Tools, que es un conjunto deplug-ins diseñados para el entorno
integrado de desarrollo Eclipse. Seam puede ser integrado con las
bibliotecas de componentes JSF JBoss RichFaces o con ICEsoft ICEFaces.
Ambas bibliotecas poseen soporte para AJAX.
2.5.4 Tecnología EJB
13
JBoss Seam, Obtenifo 9 de mayo desde http://es.wikipedia.org/wiki/JBoss_Seam
21
Los EJB proporcionan un modelo de componentes distribuido estándar del
lado del servidor. El objetivo de los EJB es dotar al programador de un
modelo que le permita abstraerse de los problemas generales de una
aplicación empresarial (concurrencia, transacciones, persistencia, seguridad,
etc.) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho
de estar basado en componentes permite que éstos sean flexibles y sobre
todo reutilizables.
No hay que confundir los Enterprise JavaBeans con los JavaBeans. Los
JavaBeans también son un modelo de componentes creado por Oracle - Sun
Microsystems para la construcción de aplicaciones, pero no pueden
utilizarse en entornos de objetos distribuidos al no soportar nativamente la
invocación remota (RMI).
Tipos de Enterprise JavaBeans
Existen tres tipos de EJBs:
EJB de Entidad (Entity EJBs): su objetivo es encapsular los objetos del lado
del servidor que almacena los datos. Los EJB de entidad presentan la
característica fundamental de la persistencia:
Persistencia gestionada por el contenedor (CMP): el contenedor
se encarga de almacenar y recuperar los datos del objeto de entidad
mediante el mapeo o vinculación de las columnas de una tabla de
la base de datos con los atributos del objeto.
Persistencia gestionada por el bean (BMP): el propio objeto
entidad se encarga, mediante una base de datos u otro mecanismo,
de almacenar y recuperar los datos a los que se refiere, por lo cual la
responsabilidad de implementar los mecanismos de persistencia es
del programador.
EJB de Sesión (Session EJBs): gestionan el flujo de la información en el
servidor. Generalmente sirven a los clientes como una fachada de los
servicios proporcionados por otros componentes disponibles en el servidor.
Puede haber dos tipos:
22
Con estado (stateful). En un bean de sesión con estado, las
variables de instancia del bean almacenan datos específicos
obtenidos durante la conexión con el cliente. Cada bean de sesión
con estado, por tanto, almacena el estado conversacional de un
cliente que interactúa con el bean. Este estado conversacional se
modifica conforme el cliente va realizando llamadas a los métodos de
negocio del bean. El estado conversacional no se guarda cuando el
cliente termina la sesión.
Sin estado (stateless). Los beans de sesión sin estado son objetos
distribuidos que carecen de estado asociado permitiendo por tanto
que se los acceda concurrentemente. No se garantiza que los
contenidos de las variables de instancia se conserven entre llamadas
al método.
EJB dirigidos por mensajes (Message-driven EJBs): son los únicos beans
con funcionamiento asíncrono. Usando el Java Messaging System (JMS), se
suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un
mensaje dirigido a dicho tema o cola. No requieren de su instanciación por
parte del cliente.
2.5.5 Eclipse IDE
Eclipse es una plataforma de desarrollo, diseñada para ser extendida de
forma indefinida a través deplug-ins. Fue concebida desde sus orígenes para
convertirse en una plataforma de integración de herramientas de desarrollo.
No tiene en mente un lenguaje específico, sino que es un IDE genérico,
aunque goza de mucha popularidad entre la comunidad de desarrolladores
del lenguaje Java usando el plug-in JDT que viene incluido en la distribución
estándar del IDE.
23
Arquitectura de Eclipse
Figura 7. Arquitectura de Eclipse
Fuente: Internet
Características
Permite desarrollar aplicaciones sencillas
Permite utilizar módulos o plugings de manera que puedan aumentar
sus funcionalidades.
Tiene compilación en tiempo real
Pruebas unitarias.
2.5.6 PostgreSQL14
PostgreSQL es un servidor de base de datos objetos-relacional libre, ya que
incluye características orientadas a objetos, como puede ser la herencia,
tipos de datos, funciones, restricciones, disparadores, reglas e integridad
transaccional, liberado bajo la licencia BSB.
Características
14 PostgreSQL. Obtenido 5 de julio 2013 desde
https://iessanvicente.com/colaboraciones/postgreSQL.pdf
24
Fácil de administrar
Multiplataforma
Soporte
Ahorro en costo de operación
Estabilidad y Confiabilidad
Herramientas Gráficas de diseño y volumen
Diseñado para ambientes de altos volúmenes de datos
Transacciones
Integridad referencial
Capacidad de replicación de datos
Extensible
Interfaz con diversos lenguajes de programación
Ventajas
Es un sistema de gestión de bases de datos relacionales Open
Source (de código abierto).
Puede operar sobre distintas plataformas incluyedo Linux, Unix,
MacOSX, Solaris y Windows.
Posee características de orientación de objetos, como la herencia
entre tablas.
La velocidad del motor de bases de datos ha sido incrementado
aproximadamente en un 20% a 40% y su tiempo de arranque ha
bajado al 80% desde la versión 6.0.
25
2.5.7 Richfaces15
RichFaces es una librería de componentes visuales para JSF, escrita en su
origen por Exa del y adquirida por Jboss. Además, RichFaces posee un
framework avanzado para la integración de funcionalidades Ajax en dichos
componentes visuales, mediante el soporte de la librería Ajax4JSF.
Son características de RichFaces las siguientes:
Se integra perfectamente en el ciclo de vida de JSF,
Incluye funcionalidades Ajax, de modo que nunca vemos el JavaScript
y tiene un contenedor Ajax propio,
Contiene un set de componentes visuales, los más comunes para el
desarrollo de una aplicación web rica (Rich Internet Application), con
un número bastante amplio que cubren casi todas nuestras
necesidades,
Soporta facelets,
Soporta css themes o skins, es un proyecto open source, activo y con
una comunidad también activa.
15
Richfaces , Obtenida 9 de mayo 2013 desde
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=richFacesJsfIntro
26
2.5.8 iREPORT16
iReport es una herramienta opensource construida por Jaspersoft; escrita en
java y basada en Netbeans que permite generar reportes haciendo uso de la
librería JasperReports de forma visual, gracias a esta herramienta
tendremos una interface gráfica que permitirá construir reportes de manera
más fácil y cómoda.
Características
Las características a mi juicio más destacadas de esta herramienta son:
Editor WYSIWYG.
Vista previa integrada (permite visualizar el reporte en diferentes
formatos a través del Preview).
Soporte completo a las etiquetas de la librería JasperReports.
Administración de errores.
Gráficas en HTML5.
Soporte para construcción de tablas anidadas.
Soporte para todas las bases de datos accesibles por JDBC.
Soporte de templates.
Librería de estilos.
Drag-and-drop sobre los componentes.
16
iReport, generación de reportes. Obtenida 9 de mayo 2014 desde http://camilo-rodriguez.com/que-es-ireport-designer-y-para-que-sirve/
27
CAPITULO 3
3 ESPECIFICACIÓN DE REQUERIMIENTOS
3.1 Propósito
Este capítulo tiene como objetivo presentar un documento en donde se van
a establecer los requerimientos funcionales y no funcionales que se tomaron
en cuenta para el desarrollo del aplicativo.
3.2 Descripción General
3.2.1 Perspectiva del Sistema
El aplicativo permitirá llevar un mejor control de los medicamentos e
historias clínicas de los pacientes del Departamento Médico, además dar al
acceso al sistema a los otros módulos que conforman el Sistema Integral de
la Casa de la Cultura.
El sistema debe permitir la generar los reportes que se consideren
necesarios.
3.2.2 Funcionalidades del Sistema
Ingreso de Información
El sistema permite ingresar datos (empleados, médicos, medicamentos,
pacientes) dependiendo de la tarea que se baja a realizar por el
administrador del sistema.
Salida de Información
El sistema almacena la información en la base de datos y lo procesa para
poder generar los reportes.
28
Seguridad
Para ingresar al sistema el usuario (administrador, empleado, médico) debe
primero loguearse, estos usuarios tendrán acceso solo a ciertas funciones
del sistema de acuerdo al rol que tiene asignado. Estos usuarios pueden
acceder al sistema desde cualquier máquina que tenga internet
3.3 Requerimientos
3.3.1 Requerimientos Funcionales17
Un requisito funcional define una función del sistema de software o sus
componentes. Una función es descrita como un conjunto de entradas,
comportamientos y salidas. Los requerimientos funcionales pueden ser:
cálculos, detalles técnicos, manipulación de datos y otras funcionalidades
específicas que se supone, un sistema debe cumplir. Los requerimientos de
comportamiento para cada requerimiento funcional se muestran en los casos
de uso. Son complementados por los requisitos no funcionales, que se
enfocan en cambio en el diseño o la implementación.
El sistema tienen los siguientes requerimientos funcionales:
Permitir el acceso a los módulos que forman parte del Sistema
Integral de la Casa de la Cultura
Permitir la creación de fichas médicas.
Permitir el registro de control de los medicamentos.
Generar reportes de las ficha médicas de los pacientes
Generación de reportes de inventario (entrada, salida y kardex de
medicamentos).
Impresión de cada uno de los reportes.
17
Requerimientos funcionales ,Obtenido el 14 de abril desde
http://es.wikipedia.org/wiki/Requisito_funcional
29
3.3.2 Requerimientos No Funcionales18
Un requisito no funcional o atributo de calidad es un requisito que especifica
criterios que pueden usarse para juzgar la operación de un sistema en lugar
de sus comportamientos específicos, ya que éstos corresponden a
los requisitos funcionales.
El sistema tiene los siguientes requerimientos no funcionales:
Seguridad
El sistema debe contar con autentificación para el ingreso de los
usuarios los mismos que solo pueden acceder a ciertas
funcionalidades dependiendo del rol que tenga asignado.
Interfaz de Usuario
El sistema debe ser amigable e intuitivo y debe estar enfocando al
usuario final, debe funcionar en los navegadores más utilizados y
debe cumplir con los estándares para el diseño de las pantallas.
Disponibilidad
Se debe contemplar de confiabilidad y consistencia de los
componentes del sistema en caso de algún
Mantenibilidad
Todo el sistema debe estar completamente documentado con sus
respectivos manuales.
Validación de Información
El sistema debe validar automáticamente la información solicitada en
los formularios de ingreso para realizar este proceso de validación se
tener en cuenta el tipo de dato con los que se va a llenar los campos
solicitados.
18
Requerimiento no funcionales, Obtenido el 14 de abril desde
http://es.wikipedia.org/wiki/Requisito_no_funcional
30
3.4 Casos de Uso
El diagrama de casos de uso representa la forma en como un Cliente (Actor)
opera con el sistema en desarrollo, además de la forma, tipo y orden en
como los elementos interactúan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicación.
Elementos
Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues
con esto se especifica que un Actor no necesariamente representa a una
persona en particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de
ventas en que el rol de Vendedor con respecto al sistema puede ser
realizado por un Vendedor o bien por el Jefe de Local
Caso de Uso:19
19
Caso de Uso, Obtenido el 18 de abril 2015 desde http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html
31
Es una operación/tarea específica que se realiza tras una orden de algún
agente externo, sea desde una petición de un actor o bien desde la
invocación desde otro caso de uso.
Relaciones:
Asociación
Es el tipo de relación más básica que indica la invocación desde un actor o
caso de uso a otra operación (caso de uso). Dicha relación se denota con
una flecha simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relación se denota
con una flecha punteada.
Generalización
Este tipo de relación es uno de los más utilizados, cumple una doble función
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o
de Herencia (<<extends>>).
Este tipo de relación está orientado exclusivamente para casos de uso (y no
para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características
que son similares en más de un caso de uso y no se desea mantener
copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y
32
3.4.1 OML (Open Modeling Languaje)20
OML defiende nuevos conceptos como invokes y del precedes. Estos
nuevos conceptos, toman la forma de estereotipo definido por el usuario en
los diagramas de caso de uso.
La idea de invoques está basada en que un caso de uso llama a otro caso
de uso, de la misma manera que una función principal llama a una
subfunción. Por otra parte, precedes es definido por OML para indicar que
caso de uso es precedido por otro dentro de una secuencia lógica en una
diagrama de caso de uso.
Figura 8. Diagrama OML
Fuente: Internet
3.5 Caso de Uso Generales.
3.5.1 Administración del Sistema Integral CCE
Definición:
20
Uses vs Extends, Obtenida 24 de abril 2015 desde
https://es.scribd.com/doc/216898810/power-point
Caso de Uso CU_001
Descripción Administración del Sistema
Actores Administrador
33
Tabla 1. Administración del Sistema
Fuente: Tesista
Representación:
Figura 9. Caso de Uso. Administración de Sistema Fuente: Tesista
Pre – Condición 1. Para que inicie el correcto funcionamiento del sistema se
deben realizar las siguientes acciones en la base de datos:
a. Crear un usuario, con los datos de la persona designada por la
Casa de la Cultura para que cuente con el rol de Administrador.
b. Crear un rol, en la tabla de Roles.
2. En la Tabla Usuario Roles, asignar el código de usuario y rol.
3. Para ingresar los datos del Usuario es necesario tener un
registro en la tabla Departamento tomando en cuenta a donde
pertenece el usuario designado para ser el Administrador del
Sistema.
4. En la tabla Departamento se debe llenar un solo campo:
a. Nombre.
34
3.5.2 Creación de la Historia Clínica
Definición:
Caso de Uso CU_002
Descripción Creación de Historias Clínica
Actores Enfermera
Pre – Condición El usuario a ingresar debe tener el permiso de acceso y el rol
respectivo, contrario se negará su ingreso.
Flujo Normal 1. El usuario (Enfermera) ingresa al sistema por medio de la
interfaz gráfica.
2. El sistema presenta la interfaz de login en donde se solicita
los siguientes datos:
Usuario
Contraseña
3. El usuario ingresa los datos solicitados.
4. Presiona el botón Acceder.
5. El sistema validará la información. ingresada
6. El sistema presenta las opciones que posee habilitadas para
su rol :
Crear fichas médicas
Generación de reportes de las fichas médicas
7. El usuario (Enfermera) debe verificar que el paciente es de
CCE o persona particular mediante en ingreso de la cédula.
8. Si el paciente es empleado CCE los datos solicitados en el
formulario se desplieguen en el mismo.
9. Si el paciente no se encuentra registrado en el
departamento médico se procede a llenar la información
requerida en el formulario.
10. Si los datos son correctos se oprime el botón de guardar
11. Los datos son guardados con éxito en la base de datos,
Flujo Alternativo Información ingresada no correcta:
1. Los datos de usuario y contraseña no coinciden con los datos
de la base de datos.
2. El usuario no tiene el permiso de acceso o rol necesario para
realizar la acción indicada.
3. La información ingresada de las personas en el formulario
de creación de fichas médicas deben ser correctos
(validación de valores).
4. Cancelación del proceso
Post- Condición Notificación que los datos han sido guardados en la base de
datos sin ningún problema
Tabla 2. Creación de Historias Clínicas
Fuente: Tesista
35
Representación:
Figura 10.Caso de Uso: Creación de historias clínicas
Fuente: Tesista
36
3.5.3 Inventario de Medicamentos
Definición:
Caso de Uso CU_003
Descripción Inventario de Medicamentos
Actores Enfermera
Pre – Condición El usuario a ingresar debe tener el permiso de acceso y el rol
respectivo, contrario se negará su ingreso.
Flujo Normal 1. El usuario (Enfermera) ingresa al sistema por medio de la
interfaz gráfica.
2.- El sistema presenta la interfaz de login en donde se solicita
los siguientes datos:
Usuario
Contraseña
1. El usuario ingresa los datos solicitados.
2. Presiona el botón Acceder.
3. El sistema validará la información. ingresada
4. El sistema presenta las opciones que posee habilitadas para
su rol :
Ingreso de Medicamentos
Salida de Medicamentos
Kardex Medicamentos
Generación de reportes
5. El usuario (enfermera) va a registrar el ingreso de los
medicamentos tomando en cuenta cantidad, precio, fecha
de vencimiento del producto.
6. El usuario(enfermera) va a registrar la salida de los
medicamentos sean estos por la entrega a los pacientes o
porque su fecha de vencimiento expiro
7. El usuario (enfermera) debe generar el kardex de
medicamentos que es un reporte para conocer la cantidad
de medicamentos con los que cuenta la unidad médica.
8. Debe generar los reportes de ingreso y egreso de
medicamentos que se consideren en el aplicativo
Flujo Alternativo Información ingresada no correcta:
1.- Los datos de usuario y contraseña no coinciden con los datos
de la base de datos-
2.- El usuario no tiene el permiso de acceso o rol necesario.
3.- La información ingresada de los medicamentos en el
formulario no son correctos (validación de valores).
4.- Cancelación del proceso
Post- Condición Notificación que los datos han sido guardados en la base de
datos sin ningún problema
Tabla 3. Inventario de Medicamentos
Fuente: Tesista
37
Representación:
Figura 11. Caso de Uso: Inventario de Medicamentos
Fuente: Tesista
38
3.5.4 Reportes Enfermera
Definición:
Caso de Uso CU_004
Descripción Reportes Enfermera
Actores Enfermera
Pre – Condición El usuario a ingresar debe tener el permiso de acceso y el rol
respectivo, contrario se negará su ingreso.
Flujo Normal 1. El usuario (Enfermera) ingresa al sistema por medio de la
interfaz gráfica.
2.- El sistema presenta la interfaz de login en donde se solicita
los siguientes datos:
Usuario
Contraseña
3.- El usuario ingresa los datos solicitados.
4.- Presiona el botón Acceder.
5.- El sistema validará la información. ingresada
6.-El sistema presenta las opciones que posee habilitadas para
su rol :
Generación de reportes
7.- El usuario (enfermera) puede imprimir los siguientes
reportes:
Listado de empleados CCE
Inventario de medicamentos ( ingreso, egreso, kardex)
Fichas médicas de los pacientes
Flujo Alternativo Información ingresada no correcta:
1.- Los datos de usuario y contraseña no coinciden con los datos
de la base de datos-
2.- El usuario no tiene el permiso de acceso o rol necesario.
Post- Condición El usuario debe tener acceso al módulo de reportes
Tabla 4. Reportes Enfermera
Fuente: Tesista
39
Representación:
Figura 12. Caso de Uso: Reportes Enfermera Fuente: Tesista
40
3.5.5 Gestión de Pacientes
Definición:
Caso de Uso CU_005
Descripción Gestión de Pacientes
Actores Médico
Pre – Condición El usuario a ingresar debe tener el permiso de acceso y el rol
respectivo, contrario se negará su ingreso.
Flujo Normal 1. El usuario (Enfermera) ingresa al sistema por medio de la
interfaz gráfica.
2.- El sistema presenta la interfaz de login en donde se solicita
los siguientes datos:
Usuario
Contraseña
3.- El usuario ingresa los datos solicitados.
4.- Presiona el botón Acceder.
5.- El sistema validará la información. ingresada
6.-El sistema presenta las opciones que posee habilitadas para
su rol :
Administrar historias clínicas (asignar diagnóstico y
tratamientos)
Generación de reportes
7.-El usuario ingresa al sistemas y busca la historia clínica de un
paciente sea es particular o empleado de CCE.
8.- El usuario ingresa a la historia clínica el diagnóstico y el
tratamiento que el paciente debe seguir
9.-El usuario debe continuar con la evolución de los pacientes
(diagnóstico y tratamiento)
9. -El usuario debe generar el reporte de la historia clínica si lo
considera necesaria.
Flujo Alternativo Información ingresada no correcta:
1.- Los datos de usuario y contraseña no coinciden con los datos
de la base de datos-
2.- El usuario no tiene el permiso de acceso o rol necesario.
3.- La información es buscada mediante el número de cedula
si no son correctos (validación de valores).
4.- Cancelación del proceso de búsqueda
Post- Condición Se busca la historia clínica mediante el número de cedula
Tabla 5. Gestión Pacientes
Fuente:Tesista
41
Representación:
Figura 13. Caso de Uso: Gestión de pacientes Fuente: Tesista
42
3.5.6 Reportes Médicos
Definición:
Caso de Uso CU_006
Descripción Reporte Médico
Actores Médico
Pre – Condición El usuario a ingresar debe tener el permiso de acceso y el rol
respectivo, contrario se negará su ingreso.
Flujo Normal 1. El usuario (médico) ingresa al sistema por medio de la
interfaz gráfica.
2.- El sistema presenta la interfaz de login en donde se solicita
los siguientes datos:
Usuario
Contraseña
3.-El usuario(médico) tiene busca al paciente por su número de
cedula .
4.- El usuario (médico) solo podrá imprimir:
Diagnostico paciente
Tratamiento paciente
Flujo Alternativo Información ingresada no correcta:
1.- Los datos de usuario y contraseña no coinciden con los datos
de la base de datos
2.-El usuario no tiene el permiso de acceso o rol necesario.
3.-La información del paciente debe ser buscada mediante el
número de cedula si no son correctos (validación de valores).
Post- Condición Se busca si el paciente existe o no existe
Tabla 6. Reportes Médicos
Fuente: Tesista
Figura 14. Cado de Uso: Reportes Médicos
Fuente: Tesista
43
3.5.7 Interactivo de la enfermera
Definición:
Caso de Uso CU_006
Descripción Interactivo Enfermera
Actores Enfermera
Pre – Condición El usuario a ingresar debe tener el permiso de acceso y el rol
respectivo, contrario se negará su ingreso.
Flujo Normal 1. El usuario (enfermera) ingresa al sistema por medio de la
interfaz gráfica.
2.- El sistema presenta la interfaz de login en donde se solicita
los siguientes datos:
Usuario
Contraseña
3.- El usuario (enfermera) maneja la administración de
pacientes :
Empleado CCE
Persona particular
En donde tiene las acciones de :
Buscar paciente
Modificar paciente
Guardar paciente
Eliminar paciente
Para la creación de las historias clínicas
4.- El usuario (enfermera) maneja la administración de
inventarios que consisten en la entrada y salida de los
medicamentos que tienen las siguientes acciones:
Buscar medicamento
Modificar medicamento
Guardar medicamento
Eliminar medicamento
Para la creación del inventario
5.- El usuario (enfermera) puede visualizar y imprimir los
reportes de:
Entrada ,Salida y Kardex de Medicamento
Historias Clínicas
Flujo Alternativo Información ingresada no correcta:
1.- Los datos de usuario y contraseña no coinciden con los datos
de la base de datos
2.-El usuario no tiene el permiso de acceso o rol necesario.
3.-La información del paciente debe ser buscada mediante el
número de cedula si no son correctos (validación de valores).
4.-La información de los medicamentos deber ser buscada por
el nombre el fármaco.
44
Post- Condición Se busca si el paciente existe o no existe
Tabla 7. Interactivo Enfermera
Fuente:Tesista
Representación:
Figura 15. Caso de Uso: Interactivo Enfermera
Fuente: Tesista
45
3.5.8 Interactivo del Médico
Definición:
Caso de Uso CU_007
Descripción Interactivo Médico
Actores Enfermera
Pre – Condición El usuario a ingresar debe tener el permiso de acceso y el rol
respectivo, contrario se negará su ingreso.
Flujo Normal 1. El usuario (médico) ingresa al sistema por medio de la
interfaz gráfica.
2.- El sistema presenta la interfaz de login en donde se solicita
los siguientes datos:
Usuario
Contraseña
3.- El usuario (médico) maneja la administración de pacientes :
Buscar paciente
Modificar paciente
Administrar Diagnostico
Buscar diagnostico
Modificar diagnostico
Eliminar diagnostico
Administrar Tratamiento
Buscar tratamiento
Modificar tratamiento
Eliminar tratamiento
Flujo Alternativo Información ingresada no correcta:
1.- Los datos de usuario y contraseña no coinciden con los datos
de la base de datos
2.-El usuario no tiene el permiso de acceso o rol necesario.
3.-La información del paciente debe ser buscada mediante el
número de cedula si no son correctos (validación de valores).
Post- Condición Se busca si el paciente existe o no existe
Tabla 8. Interactivo Médico
Fuente: Tesista
46
Representación:
Figura 16. Caso de Uso: Interactivo Médico Fuente: Tesista
47
3.6 Diagrama de Secuencias
El diagrama de Secuencia21, muestra gráficamente los eventos que originan
los actores dentro de un sistema y cómo se comunican (interactúan) entre
sí a lo largo del tiempo. Esta descripción es importante porque puede dar
detalle a los casos de uso, aclarándolos al nivel de mensajes. El diagrama
de secuencia es más adecuado para observar la perspectiva cronológica de
las interacciones, muestra la secuencia explícita de mensajes y son mejores
para especificaciones de tiempo real y para escenarios complejos. La
creación de los diagramas de secuencia forma parte de la investigación para
conocer el sistema, por lo que es parte del análisis del mismo
Rol de la Clase
El rol de la clase describe la manera en que un objeto se va a comportar en
el contexto. No se listan los atributos del objeto.
Activación
Los cuadros de activación representan el tiempo que un objeto necesita para
completar una tarea.
Mensajes
Los mensajes son flechas que representan comunicaciones entre objetos.
Las medias flechas representan mensajes asincrónicos. Los mensajes
21
Diagrama de Secuencias , Obtenido el 24 de abril 2015 des de http://jams001.blogspot.com/2012/09/diagrama-de-secuencia-y-colaboracion.html
48
asincrónicos son enviados desde un objeto que no va a esperar una
respuesta del receptor para continuar con sus tareas.
Líneas de Vida
Las líneas de vida son verticales y en línea de puntos, ellas indican la
presencia del objeto durante el tiempo.
Destrucción de Objetos
Los objetos pueden ser eliminados tempranamente usando una flecha
etiquetada "<>" que apunta a una X.
49
Loops
Una repetición o loop en un diagrama de secuencias, es representado como un rectángulo.
La condición para abandonar el loop se coloca en la parte inferior entre corchetes [ ].
3.6.1 Diagrama Secuencia de Ingreso al Sistema
Figura 17. Diagrama de Secuencia: Ingreso al sistema
Fuente: Tesista
50
3.6.2 Diagrama Secuencia Creación de Ficha
3.6.2.1 Paciente (Empleados CCE)
Figura 18. Diagrama de Secuencia: Paciente (CCE)
Fuente: Tesista
51
3.6.2.2 Paciente (Particular)
Figura 19. Diagrama de Secuencia: Paciente particular
Fuente: Tesista
52
3.6.3 Inventario de Medicamento
3.6.3.1 Entrada de Medicamento
Figura 20. Diagrama de Secuencia: Entrada Medicamento
Fuente: Tesista
3.6.3.2 Salida de Medicamento
Figura 21. Diagrama de Secuencia: Salida de Medicamento Fuente: Tesista
53
3.6.3.3 Kardex de Inventario
Figura 22. Diagrama de Secuencia: Kardex Medicamento
Fuente: Tesista
3.6.3.4 Reportes Enfermera
Figura 23. Diagrama De Secuencia: Reportes Enfermera Fuente: Tesista
54
3.7 Ficha Médica
3.7.1 Historial Médico
Figura 24. Diagrama de Secuencia: Historial Médico Fuente: Tesista
55
3.7.2 Diagnóstico y Tratamiento
Figura 25. Diagrama de Secuencia: Diagnóstico y Tratamiento
Fuente: Tesista
56
3.7.3 Reporte Médico
Figura 26. Diagrama de Secuencia: Reportes Médico
Fuente: Tesista
57
CAPIULO 4
4 DISEÑO, IMPLEMENTACION Y PRUEBAS
4.1 Modelo Orientado a Objetos del Sistema
Figura 27. Modelo de Objetos
Fuente: Tesista
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1 0..*
0..1
0..*
0..1
0..*
0..10.
.*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
MED
ICO
+ + + + + + + + +
ID_M
EDIC
OS
ID_E
STAD
O_C
IVIL
CEDU
LA
NOM
BRES
APEL
LIDO
_PAT
ERNO
APEL
LIDO
_MAT
ERNO
ESPE
CIAL
IDAD
TELE
FONO
DIRE
CCIO
N
: lon
g
: int
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
EMPL
EADO
+ + + + + + + + + +
ID_E
MPL
EADO
CEDU
LA
NOM
BRES
APEL
LIDO
_PAT
ERNO
APEL
LIDO
_MAT
ERNO
EMAI
L
TELE
FONO
DIRE
CCIO
N
GEN
ERO
ESTA
DO
: lon
g
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
ACCE
SO
+ + +
USUA
RIO
ESTA
DO
CONT
RASE
NA
: Stri
ng
: Stri
ng
: Stri
ng
TIPO
_PER
SONA
+ +
ID_T
IPO
TIPO
: lon
g
: Stri
ng
ROL�E
S_AC
CESO
+ +
ID_R
OLE
S_AC
CESO
ESTA
DO
: lon
g
: Stri
ng
ROLE
S
+ + +
ID_R
OL
ROL
DESC
RIPC
ION
: lon
g
: Stri
ng
: Stri
ng
PERM
ISO
+ +
ID_P
ERM
ISO
ESTA
DO
: lon
g
: Stri
ng
FUNC
IONE
S
+ +
ID_F
UNCI
ON
DESC
RIPC
ION
: Stri
ng
: Stri
ng
TIPO
_MED
ICAM
ENTO
+ +
ID_T
IPO
MED
ICAM
ENTO
TIPO
_MED
ICAM
ENTO
: lon
g
: Stri
ng
MED
ICAM
ENTO
S
+ + + + +
ID_M
EDIC
AMEN
TOS
NOM
BRE
DESC
RIPC
ION
CANT
IDAD
_MIN
IMA
ESTA
DO
: lon
g
: Stri
ng
: Stri
ng
: int
: Stri
ng
CARG
O
+ +
ID_C
ARG
O
NOM
BRE
: lon
g
: Stri
ng
DEPA
RTAM
ENTO
+ + +
ID_D
EPAR
TAM
ENTO
NOM
BRE
DESC
RIPC
ION
: lon
g
: Stri
ng
: Stri
ng
ESTA
DO_C
IVIL
+ +
ID_E
STAD
O_C
IVIL
ESTA
DO_C
IVIL
: lon
g
: Stri
ng
ENTR
ADAS
+ + + + +
ID_E
NTRA
DA
FECH
A_VE
NCIM
IENT
O
DESC
RIPC
ION
CANT
IDAD
COST
O
: lon
g
: Dat
e
: Stri
ng
: int
: dou
ble
SALI
DAS
+ + +
ID_S
ALID
A
CANT
IDAD
DESC
RIPC
ION
: lon
g
: int
: Stri
ng
CABE
CERA
_ENT
RADA
S
+ +
ID_C
AB_E
NTRA
DA
FECH
A_IN
GRE
SO
: lon
g
: Dat
e
CABE
CERA
_SAL
IDAS
+ +
ID_C
AB_S
ALID
A
FECH
A_EG
RESO
: lon
g
: Dat
e
PACI
ENTE
+ + +
ID_P
ACIE
NTE
FECH
A_AD
MIS
ION
ESTA
DO
: lon
g
: Dat
e
: Stri
ng
TIPO
_PAC
IENT
E
+ +
ID_T
IPO
PACI
ENTE
DESC
RIPC
ION
: lon
g
: Stri
ng
PART
ICUL
ARES
+ + + + + + + + + +
ID_P
ARTI
CULA
R
CEDU
LA
NOM
BRES
APEL
LIDO
_PAT
ERNO
APEL
LIDO
_MAT
ERNO
EMAI
L
TELE
FONO
DIRE
CCIO
N
GEN
ERO
ESTA
DO
: lon
g
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
HIST
ORI
AL_L
ABO
RAL
+ + + + + + +
ID_H
ISTO
RIAL
ABO
RAL
EMPR
ESA
ACT_
ECO
NOM
ICA
CARG
O
SECC
ION
TIEM
PO_A
NIO
TIEM
PO_M
ES
: lon
g
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: int
: int
HIST
ORA
L_CL
INIC
O
+ + + + + + + + + + + + + + + + + + + + + + + + +
ID_H
ISTO
RIAL
ID_P
ACIE
NTE
HIST
_CLI
AFIL
_IES
S
REF_
CASO
EMER
G
REF_
RELA
CIO
N
REF_
DIRE
CC
REF_
TELE
F
ESPE
C_EM
ERG
ESPE
C_EM
ERG
_H
ESPE
C_EM
ERG
_D
ESPE
C_EM
ERG
_M
ESPE
C_EM
ERG
_A
DENU
N_IN
M
DENU
N_ES
TAB
DENU
N_H
DENU
N_M
DENU
N_D
DENU
N_A
TEM
PERA
TURA
PULS
O
RESP
IRAC
ION
TENS
_ART
ERIA
L
CONC
EPTO
CONC
EPTO
_RES
TRIC
C
: lon
g
: int
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
ENFE
RMED
ADES
+ + +
ID_E
NFER
M
TIPO
DESC
RIP_
ENFE
RM
: lon
g
: Stri
ng
: Stri
ng
ANTE
CED_
PERS
ONA
L
+ + +
ID_A
NTEP
TIPO
DESC
RIP_
ANTP
: lon
g
: Stri
ng
: Stri
ng
HABI
TOS
+ + + + + + + + + + +
ID_H
ABIT
O
FUM
A
FUM
A_FR
EC
LICO
R
LICO
R_FR
EC
SUBS
TANC
IA
SUBS
T_CU
AL
SUBS
T_FR
EC
DEPO
RTE
DEP_
CUAL
DEP_
FREC
: lon
g
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
TIPO
_HIS
TORI
AL
+ +
ID_T
IPO
HIS
DESC
RIP_
TIPO
: lon
g
: Stri
ng
ANTE
CED_
FAM
IL
+ +
ID_A
NTEF
DESC
RIP_
ANTF
: lon
g
: Stri
ng
RECO
MEN
DACI
ONE
S
+ +
ID_R
ECO
M
DESC
RIP_
RECO
M
: lon
g
: Stri
ng
CUAD
RO_C
LINI
CO
+ +
ID_C
UADR
O
DESC
RIP_
CUAD
RO
: lon
g
: Stri
ng
IMPR
ESIO
N_CL
INIC
A
+ +
ID_I
MPR
CLIN
DESC
RIP_
IMPR
E
: lon
g
: Stri
ng
TRAT
AMIE
NTO
S
+ +
ID_T
RAT
DESC
RIP_
TRAT
: lon
g
: Stri
ng
DIAG
NOST
ICO
S
+ +
ID_D
IAG
DESC
RIP_
DIAG
: lon
g
: Stri
ng
TRAN
SFER
ENCI
AS
+ + + + + + + + + + + +
ID_T
RANS
F
TR_T
IPO
TR_L
UGAR
TR_H
ORA
TR_D
IA
TR_M
ES
TR_A
NIO
ESTA
DO
EST_
HORA
EST_
DIA
EST_
MES
EST_
ANIO
: lon
g
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
EVO
LUCI
ON
+ + + + +
ID_E
VOLU
CIO
N
FECH
A
HORA
NOTA
S
PRES
CRIP
CIO
N
: lon
g
: Dat
e
: Stri
ng
: Stri
ng
: Stri
ng
EXAM
EN_R
ESUL
T
+ + + +
ID_E
XRE
POSI
CIO
N
ESTA
DO
RESU
LTAD
O
: lon
g
: int
: Stri
ng
: Stri
ng
EXAM
EN_F
ISIC
O
+ + + + + + + + + + +
ID_E
XAM
EN
TA FC FR PESO
TALL
A
IMC
TEM
P
DIST
RO
ZURD
O
AMBI
DIES
TRO
: lon
g
: Stri
ng
: Stri
ng
: Stri
ng
: dou
ble
: dou
ble
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
PARA
MET
ROS
+ + +
id_p
aram
etro
para
met
ro
valo
r
: lon
g
: Stri
ng
: Stri
ng
PARA
CLIN
ICO
+ + + + + + + +
ID_P
ARAC
LI
DESC
RIPC
ION
DESC
RIPD
DESC
RIPM
DESC
RIPA
1
DESC
RIPA
2
ESTA
DOSN
RESU
LTAD
O
: lon
g
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
: Stri
ng
58
4.2 Modelo de Base de datos del sistema
Figura 28. Diagrama de Base de Datos del Sistema
Fuente: Tesista
FK_A
CCES
O_R
EFER
ENCE
_TIP
O_P
ER
FK_R
OLE
S_AC
_REF
EREN
CE_A
CCES
O
FK_P
ERM
ISO
_REF
EREN
CE_F
UNCI
ONE
FK_P
ERM
ISO
_REF
EREN
CE_R
OLE
SFK
_RO
LES_
AC_R
EFER
ENCE
_RO
LES
FK_A
CCES
O_R
EFER
ENCE
_EM
PLEA
DO
FK_A
CCES
O_R
EFER
ENCE
_MED
ICO
FK_E
MPL
EADO
_REF
EREN
CE_C
ARG
O
FK_E
MPL
EADO
_REF
EREN
CE_D
EPAR
TAM
FK_E
MPL
EADO
_REF
EREN
CE_E
STAD
O_C
FK_E
NTRA
DAS_
REFE
RENC
E_M
EDIC
AME
FK_S
ALID
AS_R
EFER
ENCE
_MED
ICAM
E
FK_M
EDIC
AME_
REFE
RENC
E_DE
PART
AM
FK_M
EDIC
AME_
REFE
RENC
E_TI
PO_M
ED
FK_E
NTRA
DAS_
REFE
RENC
E_CA
BECE
RA
FK_S
ALID
AS_R
EFER
ENCE
_CAB
ECER
A
FK_P
ACIE
NTE_
REFE
RENC
E_EM
PLEA
DO
FK_P
ACIE
NTE_
REFE
RENC
E_TI
PO_P
AC
FK_H
ISTO
RIA_
REFE
RENC
E_EM
PLEA
DOFK
_PAC
IENT
E_RE
FERE
NCE_
PART
ICUL
FK_E
NFER
MED
_REF
EREN
CE_H
ISTO
RAL
FK_A
NTEC
ED__
REFE
RENC
E_HI
STO
RAL
FK_H
ABIT
OS_
REFE
RENC
E_HI
STO
RAL
FK_A
NTEC
ED__
REFE
RENC
E_HI
STO
RAL
FK_R
ECO
MEN
D_RE
FERE
NCE_
HIST
ORA
L
FK_C
UADR
O_C
_REF
EREN
CE_H
ISTO
RAL
FK_I
MPR
ESIO
_REF
EREN
CE_H
ISTO
RAL
FK_T
RATA
MIE
_REF
EREN
CE_H
ISTO
RAL
FK_T
RANS
FER_
REFE
RENC
E_HI
STO
RAL
FK_D
IAG
NOST
_REF
EREN
CE_H
ISTO
RAL
FK_E
VOLU
CIO
_REF
EREN
CE_H
ISTO
RAL
FK_E
XAM
EN_F
_REF
EREN
CE_H
ISTO
RAL
FK_E
XAM
EN_R
_REF
EREN
CE_H
ISTO
RAL
FK_H
ISTO
RAL_
REFE
RENC
E_TI
PO_H
IS
FK_P
ARAC
LIN_
REFE
RENC
E_HI
STO
RAL
MED
ICO
ID_M
EDIC
OS
ID_E
STAD
O_C
IVIL
CEDU
LA
NOM
BRES
APEL
LIDO
_PAT
ERNO
APEL
LIDO
_MAT
ERNO
ESPE
CIAL
IDAD
TELE
FONO
DIRE
CCIO
N
...
SERI
AL
INT4
VARC
HAR(
14)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
<pk>
EMPL
EADO
ID_E
MPL
EADO
ID_C
ARG
O
ID_D
EPAR
TAM
ENTO
ID_E
STAD
O_C
IVIL
CEDU
LA
NOM
BRES
APEL
LIDO
_PAT
ERNO
APEL
LIDO
_MAT
ERNO
EMAI
L
TELE
FONO
DIRE
CCIO
N
GEN
ERO
ESTA
DO
...
SERI
AL
INT4
INT4
INT4
VARC
HAR(
14)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
100)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
1)
<pk>
<fk1
>
<fk2
>
<fk3
>
ACCE
SO
USUA
RIO
ESTA
DO
ID_T
IPO
ID_E
MPL
EADO
ID_M
EDIC
OS
CONT
RASE
NA
...
VARC
HAR(
50)
VARC
HAR(
50)
INT4
INT4
INT4
VARC
HAR(
150)
<pk>
<fk1
>
<fk2
>
<fk3
>
TIPO
_PER
SONA
ID_T
IPO
TIPO
SERI
AL
VARC
HAR(
70)
<pk>
ROL�E
S_AC
CESO
ID_R
OLE
S_AC
CESO
ID_R
OL
USUA
RIO
ESTA
DO
...
SERI
AL
INT4
VARC
HAR(
50)
VARC
HAR(
1)
<pk>
<fk2
>
<fk1
>
ROLE
S
ID_R
OL
ROL
DESC
RIPC
ION
SERI
AL
VARC
HAR(
50)
VARC
HAR(
50)
<pk>
PERM
ISO
ID_P
ERM
ISO
ID_F
UNCI
ON
ID_R
OL
ESTA
DO
...
SERI
AL
VARC
HAR(
20)
INT4
VARC
HAR(
1)
<pk>
<fk1
>
<fk2
>
FUNC
IONE
S
ID_F
UNCI
ON
DESC
RIPC
ION
VARC
HAR(
20)
VARC
HAR(
200)
<pk>
TIPO
_MED
ICAM
ENTO
ID_T
IPO
MED
ICAM
ENTO
TIPO
_MED
ICAM
ENTO
SERI
AL
VARC
HAR(
30)
<pk>
MED
ICAM
ENTO
S
ID_M
EDIC
AMEN
TOS
ID_D
EPAR
TAM
ENTO
ID_T
IPO
MED
ICAM
ENTO
NOM
BRE
DESC
RIPC
ION
CANT
IDAD
_MIN
IMA
ESTA
DO
SERI
AL
INT4
INT4
VARC
HAR(
30)
VARC
HAR(
150)
INT4
VARC
HAR(
1)
<pk>
<fk1
>
<fk2
>
CARG
O
ID_C
ARG
O
NOM
BRE
SERI
AL
VARC
HAR(
30)
<pk>
DEPA
RTAM
ENTO
ID_D
EPAR
TAM
ENTO
NOM
BRE
DESC
RIPC
ION
...
SERI
AL
VARC
HAR(
30)
VARC
HAR(
30)
<pk>
ESTA
DO_C
IVIL
ID_E
STAD
O_C
IVIL
ESTA
DO_C
IVIL
SERI
AL
VARC
HAR(
50)
<pk>
ENTR
ADAS
ID_E
NTRA
DA
ID_M
EDIC
AMEN
TOS
ID_C
AB_E
NTRA
DA
FECH
A_VE
NCIM
IENT
O
DESC
RIPC
ION
CANT
IDAD
COST
O
...
SERI
AL
INT4
INT4
DATE
VARC
HAR(
150)
INT4
DECI
MAL
(15,
2)
<pk>
<fk1
>
<fk2
>
SALI
DAS
ID_S
ALID
A
ID_M
EDIC
AMEN
TOS
ID_C
AB_S
ALID
A
CANT
IDAD
DESC
RIPC
ION
...
SERI
AL
INT4
INT4
INT4
VARC
HAR(
150)
<pk>
<fk1
>
<fk2
>
CABE
CERA
_ENT
RADA
S
ID_C
AB_E
NTRA
DA
FECH
A_IN
GRE
SO
SERI
AL
DATE
<pk>
CABE
CERA
_SAL
IDAS
ID_C
AB_S
ALID
A
FECH
A_EG
RESO
SERI
AL
DATE
<pk>
PACI
ENTE
ID_P
ACIE
NTE
ID_E
MPL
EADO
ID_T
IPO
PACI
ENTE
ID_P
ARTI
CULA
R
FECH
A_AD
MIS
ION
ESTA
DO
SERI
AL
INT4
INT4
INT4
TIM
ESTA
MP
VARC
HAR(
1)
<pk>
<fk1
>
<fk2
>
<fk3
>
TIPO
_PAC
IENT
E
ID_T
IPO
PACI
ENTE
DESC
RIPC
ION
SERI
AL
VARC
HAR(
30)
<pk>
PART
ICUL
ARES
ID_P
ARTI
CULA
R
CEDU
LA
NOM
BRES
APEL
LIDO
_PAT
ERNO
APEL
LIDO
_MAT
ERNO
EMAI
L
TELE
FONO
DIRE
CCIO
N
GEN
ERO
ESTA
DO
SERI
AL
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
100)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
1)
<pk>
HIST
ORI
AL_L
ABO
RAL
ID_H
ISTO
RIAL
ABO
RAL
ID_E
MPL
EADO
EMPR
ESA
ACT_
ECO
NOM
ICA
CARG
O
SECC
ION
TIEM
PO_A
NIO
TIEM
PO_M
ES
...
SERI
AL
INT4
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
VARC
HAR(
30)
INT4
INT4
<pk>
<fk>
HIST
ORA
L_CL
INIC
O
ID_H
ISTO
RIAL
ID_T
IPO
HIS
ID_P
ACIE
NTE
HIST
_CLI
AFIL
_IES
S
REF_
CASO
EMER
G
REF_
RELA
CIO
N
REF_
DIRE
CC
REF_
TELE
F
ESPE
C_EM
ERG
ESPE
C_EM
ERG
_H
ESPE
C_EM
ERG
_D
ESPE
C_EM
ERG
_M
ESPE
C_EM
ERG
_A
DENU
N_IN
M
DENU
N_ES
TAB
DENU
N_H
DENU
N_M
DENU
N_D
DENU
N_A
TEM
PERA
TURA
PULS
O
RESP
IRAC
ION
TENS
_ART
ERIA
L
CONC
EPTO
CONC
EPTO
_RES
TRIC
C
...
SERI
AL
INT4
INT4
VARC
HAR(
1)
VARC
HAR(
1)
VARC
HAR(
150)
VARC
HAR(
150)
VARC
HAR(
150)
VARC
HAR(
10)
VARC
HAR(
150)
VARC
HAR(
6)
VARC
HAR(
3)
VARC
HAR(
3)
VARC
HAR(
6)
VARC
HAR(
150)
VARC
HAR(
150)
VARC
HAR(
6)
VARC
HAR(
3)
VARC
HAR(
3)
VARC
HAR(
6)
VARC
HAR(
10)
VARC
HAR(
10)
VARC
HAR(
10)
VARC
HAR(
10)
VARC
HAR(
2)
VARC
HAR(
150)
<pk>
<fk>
ENFE
RMED
ADES
ID_E
NFER
M
ID_H
ISTO
RIAL
TIPO
DESC
RIP_
ENFE
RM
...
SERI
AL
INT4
VARC
HAR(
1)
VARC
HAR(
150)
<pk>
<fk>
ANTE
CED_
PERS
ONA
L
ID_A
NTEP
ID_H
ISTO
RIAL
TIPO
DESC
RIP_
ANTP
...
SERI
AL
INT4
VARC
HAR(
20)
VARC
HAR(
150)
<pk>
<fk>
HABI
TOS
ID_H
ABIT
O
ID_H
ISTO
RIAL
FUM
A
FUM
A_FR
EC
LICO
R
LICO
R_FR
EC
SUBS
TANC
IA
SUBS
T_CU
AL
SUBS
T_FR
EC
DEPO
RTE
DEP_
CUAL
DEP_
FREC
...
SERI
AL
INT4
VARC
HAR(
1)
VARC
HAR(
10)
VARC
HAR(
1)
VARC
HAR(
10)
VARC
HAR(
1)
VARC
HAR(
10)
VARC
HAR(
10)
VARC
HAR(
1)
VARC
HAR(
10)
VARC
HAR(
10)
<pk>
<fk>
TIPO
_HIS
TORI
AL
ID_T
IPO
HIS
DESC
RIP_
TIPO
SERI
AL
VARC
HAR(
150)
<pk>
ANTE
CED_
FAM
IL
ID_A
NTEF
ID_H
ISTO
RIAL
DESC
RIP_
ANTF
...
SERI
AL
INT4
VARC
HAR(
150)
<pk>
<fk>
RECO
MEN
DACI
ONE
S
ID_R
ECO
M
ID_H
ISTO
RIAL
DESC
RIP_
RECO
M
...
SERI
AL
INT4
VARC
HAR(
150)
<pk>
<fk>
CUAD
RO_C
LINI
CO
ID_C
UADR
O
ID_H
ISTO
RIAL
DESC
RIP_
CUAD
RO
...
SERI
AL
INT4
VARC
HAR(
150)
<pk>
<fk>
IMPR
ESIO
N_CL
INIC
A
ID_I
MPR
CLIN
ID_H
ISTO
RIAL
DESC
RIP_
IMPR
E
...
SERI
AL
INT4
VARC
HAR(
150)
<pk>
<fk>
TRAT
AMIE
NTO
S
ID_T
RAT
ID_H
ISTO
RIAL
DESC
RIP_
TRAT
...
SERI
AL
INT4
VARC
HAR(
150)
<pk>
<fk>
DIAG
NOST
ICO
S
ID_D
IAG
ID_H
ISTO
RIAL
DESC
RIP_
DIAG
...
SERI
AL
INT4
VARC
HAR(
150)
<pk>
<fk> TR
ANSF
EREN
CIAS
ID_T
RANS
F
ID_H
ISTO
RIAL
TR_T
IPO
TR_L
UGAR
TR_H
ORA
TR_D
IA
TR_M
ES
TR_A
NIO
ESTA
DO
EST_
HORA
EST_
DIA
EST_
MES
EST_
ANIO
...
SERI
AL
INT4
VARC
HAR(
15)
VARC
HAR(
150)
VARC
HAR(
6)
VARC
HAR(
3)
VARC
HAR(
3)
VARC
HAR(
6)
VARC
HAR(
6)
VARC
HAR(
6)
VARC
HAR(
3)
VARC
HAR(
3)
VARC
HAR(
6)
<pk>
<fk>
EVO
LUCI
ON
ID_E
VOLU
CIO
N
ID_H
ISTO
RIAL
FECH
A
HORA
NOTA
S
PRES
CRIP
CIO
N
...
SERI
AL
INT4
DATE
VARC
HAR(
6)
VARC
HAR(
200)
VARC
HAR(
200)
<pk>
<fk>
EXAM
EN_R
ESUL
T
ID_E
XRE
ID_H
ISTO
RIAL
POSI
CIO
N
ESTA
DO
RESU
LTAD
O
...
SERI
AL
INT4
INT4
VARC
HAR(
1)
VARC
HAR(
200)
<pk>
<fk>
EXAM
EN_F
ISIC
O
ID_E
XAM
EN
ID_H
ISTO
RIAL
TA FC FR PESO
TALL
A
IMC
TEM
P
DIST
RO
ZURD
O
AMBI
DIES
TRO
...
SERI
AL
INT4
VARC
HAR(
20)
VARC
HAR(
20)
VARC
HAR(
20)
DECI
MAL
(5,2
)
DECI
MAL
(5,2
)
VARC
HAR(
20)
VARC
HAR(
20)
VARC
HAR(
1)
VARC
HAR(
1)
VARC
HAR(
1)
<pk>
<fk>PA
RAM
ETRO
S
id_p
aram
etro
para
met
ro
valo
r
...
SERI
AL
VARC
HAR(
50)
VARC
HAR(
50)
<pk>
PARA
CLIN
ICO
ID_P
ARAC
LI
DESC
RIPC
ION
DESC
RIPD
DESC
RIPM
DESC
RIPA
1
DESC
RIPA
2
ESTA
DOSN
RESU
LTAD
O
ID_H
ISTO
RIAL
...
SERI
AL
VARC
HAR(
100)
VARC
HAR(
50)
VARC
HAR(
50)
VARC
HAR(
50)
VARC
HAR(
50)
VARC
HAR(
1)
VARC
HAR(
100)
INT4
<pk>
<fk>
59
4.3 Diagrama de Clases22
Un diagrama de clases sirve para visualizar las relaciones entre las clases
que involucran el sistema, las cuales pueden ser asociadas, de herencias,
de uso y de generación, ya que comparten los mismos atributos,
operaciones, métodos, relaciones y semántica; mostrando un conjunto de
elementos que son estáticos, como las clases y tipos junto con sus
contenidos y relaciones.
En la tabla que se detalla a continuación los componentes que se utilizan
para el diseño de un diagrama de clases
SÍMBOLO NOMBRE DESCRIPCIÓN
Nombre Nombre de la clase
Atributos Identifican las características propias de cada clase.
Métodos Son la forma en cómo ésta interactúa con su entorno.
Tipos de Atributos y Métodos
(+) Public Indica que el atributo o método será visible tanto dentro como fuera de la clase.
(-) Private Indica que el atributo o método sólo
será accesible desde dentro de la clase.
(#) Protected Indica que el atributo o método no será accesible desde fuera de la clase.
Tipos de Relaciones
Uno a muchos
Cero a uno a muchos
Uno a uno
(m) Número fijo
Herencia Indica que una subclase hereda los métodos y atributos especificados por una Super Clase.
Agregación Es una relación que compone objetos que son instancias de clases.
22
Diagrama de clases, Obtenida 4 de mayo 2015 desde
http://www.ecured.cu/index.php/Diagrama_de_Clase
60
Asociación Permite asociar objetos que colaboran entre sí.
Dependencia Es una relación, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase).
Tabla 9. Elementos diagrama de clases23
4.3.1.1 Diagrama de Clases Módulo de Seguridad
Figura 29. Diagrama de Clases: Administración Usuarios
Fuente: Tesista
23
http://www.dspace.uce.edu.ec/handle/25000/74/browse?type=author&order=ASC&rpp=20&value=Saltos+Cevallos%2C+Jorge+Luis
<<EJBLocal>>
adminUsuario
(controlador)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
begin ()
destroy ()
transmitir ()
cargar ()
nuevo ()
getListaTipo ()
setListaTipo (List<TipoPersona>
listaTipo)
getIdTipo ()
setIdTipo (int idTipo)
getListaMedicos ()
setListaMedicos (List<Medico>
listaMedicos)
getListaEmpleados ()
setListaEmpleados (List<Empleado>
listaEmpleados)
getIdTipoMedico ()
getIdTipoEmpleados ()
setIdTipoMedico (int idTipoMedico)
setIdTipoEmpleados (int idTipoEmpleados)
isEstadoEmp ()
isEstadoMed ()
setEstadoEmp (boolean estadoEmp)
setEstadoMed (boolean estadoMed)
getUsuario ()
getContrasenia ()
setUsuario (String usuario)
setContrasenia (String contrasenia)
getListaResultados ()
setListaResultados (List<Object[]>
listaResultados)
: void
: void
: void
: void
: void
: List<TipoPersona>
: void
: int
: void
: List<Medico>
: void
: List<Empleado>
: void
: int
: int
: void
: void
: boolean
: boolean
: void
: void
: String
: String
: void
: void
: List<Object[]>
: void
<<EJBSession>>
adminUsuariosBean
(controlador)
-
*
*
*
*
*
*
*
-
-
-
-
-
-
-
-
-
-
-
-
-
log
facesMessages
identity
admEmpresa
tipoSrv
medSrv
empSrv
accesoSrv
listaTipo
listaMedicos
listaEmpleados
listaResultados
listaUsuarioEmp
listaUsuarioMed
idTipo
idTipoMedico
idTipoEmpleados
estadoEmp
estadoMed
usuario
contrasenia
: Log
: FacesMessages
: Identity
: AdmEmpresa
: TipoPersonaServicio
: MedicoServicio
: EmpleadosServicio
: AccesoServicio
: List<TipoPersona>
: List<Medico>
: List<Empleado>
: List<Object[]>
: List<Object[]>
: List<Object[]>
: int
: int
: int
: boolean
: boolean
: String
: String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
begin ()
destroy ()
nuevo ()
cargar ()
transmitir ()
getListaTipo ()
setListaTipo (List<TipoPersona>
listaTipo)
getIdTipo ()
setIdTipo (int idTipo)
getListaMedicos ()
setListaMedicos (List<Medico>
listaMedicos)
getListaEmpleados ()
setListaEmpleados (List<Empleado>
listaEmpleados)
getIdTipoMedico ()
getIdTipoEmpleados ()
setIdTipoMedico (int idTipoMedico)
setIdTipoEmpleados (int idTipoEmpleados)
isEstadoEmp ()
isEstadoMed ()
setEstadoEmp (boolean estadoEmp)
setEstadoMed (boolean estadoMed)
getUsuario ()
getContrasenia ()
setUsuario (String usuario)
setContrasenia (String contrasenia)
getListaResultados ()
setListaResultados (List<Object[]>
listaResultados)
: void
: void
: void
: void
: void
: List<TipoPersona>
: void
: int
: void
: List<Medico>
: void
: List<Empleado>
: void
: int
: int
: void
: void
: boolean
: boolean
: void
: void
: String
: String
: void
: void
: List<Object[]>
: void
61
Figura 30. Diagrama de Clases: Administración Roles
Fuente: Tesista
Figura 31. Diagrama de Clases: Roles Acceso
Fuente: Tesista
<<EJBLocal>>
admRolesFunciones
(controlador)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
end ()
guardarFuncionRol ()
nuevo ()
begin ()
destroy ()
buscarFuncionRol ()
cambiarEstado (Object obj[])
getListaTabla ()
setListaTabla (List<Object[]>
listaTabla)
getIdRol ()
setIdRol (int idRol)
getListaRoles ()
setListaRoles (List<SelectItemObj>
listaRoles)
getIdFuncion ()
setIdFuncion (String idFuncion)
getPermiso ()
setPermiso (Permiso permiso)
getListaFunciones ()
setListaFunciones (List<SelectItemObj>
listaFunciones)
: void
: void
: void
: void
: void
: void
: void
: List<Object[]>
: void
: int
: void
: List<SelectItemObj>
: void
: String
: void
: Permiso
: void
: List<SelectItemObj>
: void
<<EJBSession>>
admRolesFuncionesBean
(controlador)
-
*
*
*
*
*
*
*
-
-
-
-
-
-
log
facesMessages
identity
credentials
autSrv
permisoSrv
rolesSrv
funcionSrv
idFuncion
idRol
permisos
listaRoles
listaFunciones
listaTabla
: Log
: FacesMessages
: Identity
: Credentials
: AutenticadorServicio
: PermisosServicio
: RolesServicio
: FuncionesServicio
: String
: int
: Permiso
: List<SelectItemObj>
: List<SelectItemObj>
: List<Object[]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
begin ()
destroy ()
nuevo ()
end ()
guardarFuncionRol ()
buscarFuncionRol ()
cambiarEstado (Object obj[])
getListaTabla ()
setListaTabla (List<Object[]>
listaTabla)
getIdRol ()
setIdRol (int idRol)
getListaRoles ()
setListaRoles (List<SelectItemObj>
listaRoles)
getIdFuncion ()
setIdFuncion (String idFuncion)
getPermiso ()
setPermiso (Permiso permiso)
getListaFunciones ()
setListaFunciones (List<SelectItemObj>
listaFunciones)
: void
: void
: void
: void
: void
: void
: void
: List<Object[]>
: void
: int
: void
: List<SelectItemObj>
: void
: String
: void
: Permiso
: void
: List<SelectItemObj>
: void
<<EJBLocal>>
rolesAccesoUsuario
(controlador)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
begin ()
destroy ()
transmitir ()
nuevo ()
cambiarEstado (int idRolesAcceso)
getListaResultados ()
setListaResultados (List<Object[]>
listaResultados)
getListaRoles ()
getListaAcceso ()
setListaRoles (List<Roles> listaRoles)
setListaAcceso (List<Acceso>
listaAcceso)
getIdAccesoSelecc ()
getIdRolesSelecc ()
setIdAccesoSelecc (
String idAccesoSelecc)
setIdRolesSelecc (int idRolesSelecc)
: void
: void
: void
: void
: void
: List<Object[]>
: void
: List<Roles>
: List<Acceso>
: void
: void
: String
: int
: void
: void
<<EJBSession>>
rolesAccesoUsuarioBean
(controlador)
-
*
*
*
*
*
*
-
-
-
-
-
log
facesMessages
identity
admEmpresa
accesoSrv
rolesSrv
rolesAccesoSrv
listaRoles
listaAcceso
idAccesoSelecc
idRolesSelecc
listaResultados
: Log
: FacesMessages
: Identity
: AdmEmpresa
: AccesoServicio
: RolesServicio
: RolesAccesoServicio
: List<Roles>
: List<Acceso>
: String
: int
: List<Object[]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
begin ()
destroy ()
nuevo ()
transmitir ()
cambiarEstado (int idRolesAcceso)
getListaResultados ()
setListaResultados (List<Object[]>
listaResultados)
getListaRoles ()
getListaAcceso ()
setListaRoles (List<Roles> listaRoles)
setListaAcceso (List<Acceso>
listaAcceso)
getIdAccesoSelecc ()
getIdRolesSelecc ()
setIdAccesoSelecc (
String idAccesoSelecc)
setIdRolesSelecc (int idRolesSelecc)
: void
: void
: void
: void
: void
: List<Object[]>
: void
: List<Roles>
: List<Acceso>
: void
: void
: String
: int
: void
: void
62
4.3.1.2 Módulo de Inventario
Figura 32. Diagrama de Clases: Entrada Medicamento
Fuente: Tesista
<<EJBLocal>>
EntradaAdmin
(controlador)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
begin ()
destroy ()
remove ()
agregar ()
guardar ()
nuevabuscar ()
init ()
buscar ()
obtenerNombreMedicamento (
int idMedicamento)
editarEntrada (Entradas e, int index)
eliminarEntrada (Entradas e)
getNumeroEntrada ()
getMedicamentos ()
getFechaIngreso ()
getFechaVencimiento ()
getDescripcion ()
getCantidad ()
setNumeroEntrada (int numeroEntrada)
setMedicamentos (int medicamentos)
setFechaIngreso (Date fechaIngreso)
setFechaVencimiento (
Date fechaVencimiento)
setDescripcion (String descripcion)
setCantidad (int cantidad)
getListarMedicamentos ()
setListarMedicamentos (List<
Medicamentos> listarMedicamentos)
getListaEntradas ()
setListaEntradas (List<Entradas>
listaEntradas)
getListaEntradasRemove ()
setListaEntradasRemove (List<Entradas>
listaEntradasRemove)
isPermiteBuscar ()
setPermiteBuscar (boolean permiteBuscar)
getCosto ()
setCosto (BigDecimal costo)
getIdEntrada ()
setIdEntrada (int idEntrada)
getIndex ()
setIndex (int index)
: void
: void
: void
: void
: void
: void
: void
: void
: String
: void
: void
: int
: int
: Date
: Date
: String
: int
: void
: void
: void
: void
: void
: void
: List<Medicamentos>
: void
: List<Entradas>
: void
: List<Entradas>
: void
: boolean
: void
: BigDecimal
: void
: int
: void
: int
: void
<<EJBSession>>
EntradaAdminBean
(controlador)
*
*
*
-
-
-
-
-
-
-
-
-
-
-
-
-
srvEntrada
entradaSrv
facesMessages
numeroEntrada
medicamentos
fechaIngreso
fechaVencimiento
descripcion
costo
cantidad
listarMedicamentos
listaEntradas
listaEntradasRemove
permiteBuscar
idEntrada
index
: ServicioEntrada
: EntradasServicio
: FacesMessages
: int
: int
: Date
: Date
: String
: BigDecimal
: int
: List<Medicamentos>
: List<Entradas>
: List<Entradas>
: boolean
: int
: int
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
begin ()
init ()
buscar ()
validador ()
agregar ()
guardar ()
editarEntrada (Entradas e, int index)
eliminarEntrada (Entradas e)
nuevabuscar ()
obtenerNombreMedicamento (
int idMedicamento)
destroy ()
remove ()
getNumeroEntrada ()
getMedicamentos ()
getFechaIngreso ()
getFechaVencimiento ()
getDescripcion ()
getCantidad ()
setNumeroEntrada (int numeroEntrada)
setMedicamentos (int medicamentos)
setFechaIngreso (Date fechaIngreso)
setFechaVencimiento (
Date fechaVencimiento)
setDescripcion (String descripcion)
setCantidad (int cantidad)
getListarMedicamentos ()
setListarMedicamentos (List<
Medicamentos> listarMedicamentos)
getListaEntradas ()
setListaEntradas (List<Entradas>
listaEntradas)
getListaEntradasRemove ()
setListaEntradasRemove (List<Entradas>
listaEntradasRemove)
isPermiteBuscar ()
setPermiteBuscar (boolean permiteBuscar)
getCosto ()
setCosto (BigDecimal costo)
getIdEntrada ()
setIdEntrada (int idEntrada)
getIndex ()
setIndex (int index)
: void
: void
: void
: void
: void
: void
: void
: void
: void
: String
: void
: void
: int
: int
: Date
: Date
: String
: int
: void
: void
: void
: void
: void
: void
: List<Medicamentos>
: void
: List<Entradas>
: void
: List<Entradas>
: void
: boolean
: void
: BigDecimal
: void
: int
: void
: int
: void
63
Figura 33. Diagrama Clases: Inventario Medicamentos
Fuente: Tesista
Figura 34. Diagrama Clases: Salida Medicamento
Fuente: Tesista
<<EJBLocal>>
InventarioAdmin
(controlador)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
generarReporteKardex ()
begin ()
buscar ()
destroy ()
remove ()
getIdProducto ()
getTotalEntrada ()
getTotalSalida ()
getTotalInventario ()
setIdProducto (Integer idProducto)
setTotalEntrada (Integer totalEntrada)
setTotalSalida (Integer totalSalida)
setTotalInventario (
Integer totalInventario)
getListaProductos ()
setListaProductos (List<Medicamentos>
listaProductos)
getListaInventario ()
setListaInventario (List<
DatosInventario> listaInventario)
: void
: void
: void
: void
: void
: Integer
: Integer
: Integer
: Integer
: void
: void
: void
: void
: List<Medicamentos>
: void
: List<DatosInventario>
: void
<<EJBSession>>
InventarioAdminBean
(controlador)
*
*
*
-
-
-
-
-
-
srvInventario
reportExporter
srvSalida
idProducto
totalEntrada
totalSalida
totalInventario
listaProductos
listaInventario
: ServicioInventario
: ReportExporter
: ServicioSalida
: Integer
: Integer
: Integer
: Integer
: List<Medicamentos>
: List<DatosInventario>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
begin ()
destroy ()
remove ()
iniciar ()
buscar ()
generarReporteKardex ()
getIdProducto ()
getTotalEntrada ()
getTotalSalida ()
getTotalInventario ()
setIdProducto (Integer idProducto)
setTotalEntrada (Integer totalEntrada)
setTotalSalida (Integer totalSalida)
setTotalInventario (
Integer totalInventario)
getListaProductos ()
setListaProductos (List<Medicamentos>
listaProductos)
getListaInventario ()
setListaInventario (List<
DatosInventario> listaInventario)
: void
: void
: void
: void
: void
: void
: Integer
: Integer
: Integer
: Integer
: void
: void
: void
: void
: List<Medicamentos>
: void
: List<DatosInventario>
: void
<<EJBLocal>>
SalidaAdmin
(controlador)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
begin ()
destroy ()
remove ()
agregar ()
guardar ()
nuevabuscar ()
init ()
buscar ()
obtenerNombreMedicamento (
int idMedicamento)
editarSalida (Salidas e, int index)
eliminarSalida (Salidas e)
getNumeroSalida ()
getMedicamentos ()
getFechaEgreso ()
getDescripcion ()
getCantidad ()
setNumeroSalida (int numeroSalida)
setMedicamentos (int medicamentos)
setFechaEgreso (Date fechaEgreso)
setDescripcion (String descripcion)
setCantidad (int cantidad)
getListarMedicamentos ()
setListarMedicamentos (List<
Medicamentos> listarMedicamentos)
getListaSalidas ()
setListaSalidas (List<Salidas>
listaSalidas)
getListaSalidasRemove ()
setListaSalidasRemove (List<Salidas>
listaSalidasRemove)
isPermiteBuscar ()
setPermiteBuscar (boolean permiteBuscar)
getIndex ()
setIndex (int index)
getIdSalida ()
setIdSalida (int idSalida)
: void
: void
: void
: void
: void
: void
: void
: void
: String
: void
: void
: int
: int
: Date
: String
: int
: void
: void
: void
: void
: void
: List<Medicamentos>
: void
: List<Salidas>
: void
: List<Salidas>
: void
: boolean
: void
: int
: void
: int
: void
<<EJBSession>>
SalidaAdminBean
(controlador)
*
*
*
*
*
-
-
-
-
-
-
-
-
-
-
-
srvSalida
srvEntrada
salidaSrv
entradaSrv
facesMessages
numeroSalida
medicamentos
fechaEgreso
descripcion
cantidad
listarMedicamentos
listaSalidas
listaSalidasRemove
permiteBuscar
idSalida
index
: ServicioSalida
: ServicioEntrada
: SalidasServicio
: EntradasServicio
: FacesMessages
: int
: int
: Date
: String
: int
: List<Medicamentos>
: List<Salidas>
: List<Salidas>
: boolean
: int
: int
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
begin ()
init ()
buscar ()
validador ()
agregar ()
guardar ()
editarSalida (Salidas s, int index)
eliminarSalida (Salidas s)
nuevabuscar ()
obtenerNombreMedicamento (
int idMedicamento)
destroy ()
remove ()
getNumeroSalida ()
getMedicamentos ()
getFechaEgreso ()
getDescripcion ()
getCantidad ()
setNumeroSalida (int numeroSalida)
setMedicamentos (int medicamentos)
setFechaEgreso (Date fechaEgreso)
setDescripcion (String descripcion)
setCantidad (int cantidad)
getListarMedicamentos ()
setListarMedicamentos (List<
Medicamentos> listarMedicamentos)
getListaSalidas ()
setListaSalidas (List<Salidas>
listaSalidas)
getListaSalidasRemove ()
setListaSalidasRemove (List<Salidas>
listaSalidasRemove)
isPermiteBuscar ()
setPermiteBuscar (boolean permiteBuscar)
getIndex ()
setIndex (int index)
getIdSalida ()
setIdSalida (int idSalida)
: void
: void
: void
: void
: void
: void
: void
: void
: void
: String
: void
: void
: int
: int
: Date
: String
: int
: void
: void
: void
: void
: void
: List<Medicamentos>
: void
: List<Salidas>
: void
: List<Salidas>
: void
: boolean
: void
: int
: void
: int
: void
64
4.3.1.3 Módulo Ficha Médica
Figura 35. Diagrama Clases: Pacientes
Fuente: Tesista
PacienteAdm
(controlador)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
destroy ()
remove ()
begin ()
transmitir ()
buscar ()
init ()
getTipoPersona ()
setTipoPersona (String tipoPersona)
getTipoCedula ()
setTipoCedula (String tipoCedula)
getCedula ()
setCedula (String cedula)
getNombre ()
setNombre (String nombre)
getApellidosP ()
setApellidosP (String apellidosP)
getApellidosM ()
setApellidosM (String apellidosM)
getFechaNacimiento ()
setFechaNacimiento (
Date fechaNacimiento)
getGenero ()
setGenero (String genero)
getDireccion ()
setDireccion (String direccion)
getTelefono ()
setTelefono (String telefono)
getIdEstadoCivil ()
setIdEstadoCivil (Integer idEstadoCivil)
getP ()
setP (DatosPaciente p)
getEmail ()
setEmail (String email)
: void
: void
: void
: void
: void
: void
: String
: void
: String
: void
: String
: void
: String
: void
: String
: void
: String
: void
: Date
: void
: String
: void
: String
: void
: String
: void
: Integer
: void
: DatosPaciente
: void
: String
: void
<<EJBSession>>
PacienteAdmBean
(controlador)
*
*
-
-
-
-
-
-
-
-
-
-
-
-
-
facesMessages
srvPaciente
tipoPersona
tipoCedula
cedula
nombre
apellidosP
apellidosM
fechaNacimiento
genero
direccion
telefono
idEstadoCivil
p
: FacesMessages
: ServicioPaciente
: String
: String
: String
: String
: String
: String
: Date
: String
: String
: String
: Integer
: DatosPaciente
: String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
<<Implement>>
begin ()
init ()
destroy ()
remove ()
transmitir ()
reverso (DatosPaciente o)
buscar ()
getTipoPersona ()
setTipoPersona (String tipoPersona)
getTipoCedula ()
setTipoCedula (String tipoCedula)
getCedula ()
setCedula (String cedula)
getNombre ()
setNombre (String nombre)
getApellidosP ()
setApellidosP (String apellidosP)
getApellidosM ()
setApellidosM (String apellidosM)
getFechaNacimiento ()
setFechaNacimiento (
Date fechaNacimiento)
getGenero ()
setGenero (String genero)
getDireccion ()
setDireccion (String direccion)
getTelefono ()
setTelefono (String telefono)
getIdEstadoCivil ()
setIdEstadoCivil (Integer idEstadoCivil)
getP ()
setP (DatosPaciente p)
getEmail ()
setEmail (String email)
: void
: void
: void
: void
: void
: void
: void
: String
: void
: String
: void
: String
: void
: String
: void
: String
: void
: String
: void
: Date
: void
: String
: void
: String
: void
: String
: void
: Integer
: void
: DatosPaciente
: void
: String
: void
65
4.4 Diagrama de Componentes24
Se utilizan para modelar la vista estática de un sistema. Muestra la
organización y las dependencias entre un conjunto de componentes. No es
necesario que un diagrama incluya todos los componentes del sistema,
normalmente se realizan por partes. Cada diagrama describe un apartado
del sistema.
Figura 36.Diagrama de Componentes
Fuente: Tesista
24
Diagrana de Componentes, Obtenida 08 de mayo 2015 http://programacion.net/articulo/introduccion_a_uml_181/6
Ing
reso
al
Sis
tem
a
Re
gis
tro
de
Ro
les
Re
gis
tro
Em
ple
ad
os
CC
E
Re
gis
tro
s
Usu
ari
os
Re
gis
tro
En
ferm
era
Re
gis
tra
r M
ed
ica
me
nto
En
tra
da
de
Me
dic
am
en
to
Sa
lid
a d
e
Me
dic
am
en
to
Re
gis
tro
de
Mé
dic
os
Re
gis
tra
r
Pa
cie
nte
Re
gis
tra
Fic
ha
Mé
dic
a
Re
gis
tar
Esp
ecia
lid
ad
Re
gis
tar
Dia
gn
ost
ico
y
Tra
tam
ien
to
Re
gis
tra
r E
vo
lucio
n P
acie
nte
66
4.5 Implementación
4.5.1 Recursos requeridos
Software Base del Aplicativo
La tabla que se detalla a continuación nos muestra los requerimientos mínimos que
el sistema necesita para plan de pruebas.
Tipo Elementos de Software
Sistema Operativo Windows 7
Navegador Web Internet Explorer 8 o superior
Servidor de Aplicaciones
Jboss 5.1
Servidor de Base de datos
Postgres 9.3
Tabla 10. Requerimientos de software
Hardware Base del Sistema:
La tabla que se detalla a continuación nos muestra los recursos del
sistema para e l plan de pruebas.
Recurso Cantidad Tipo
Disco 10 GB espacio
Memoria 2 GB
Procesador Intel Core 2 DUO
Pc Usuarios
Internet Explorer 8 o superior
Tabla 11. Requerimientos de hardware
67
4.6 Plan de Pruebas
El plan de pruebas del Sistema web para la gestión del Departamento
Médico, control de medicamentos y Seguridad para el Sistema Integral de la
Casa de la cultura (CCE) tiene como objetivo:
Identificar las pruebas que se realizara al aplicativo.
Conocer los posibles problemas en el funcionamiento del sistema
El desarrollo del plan de prueba va dirigido a las personas encargadas de
realizar la verificación funcional del sistema.
La siguiente tabla que se detalla a continuación, nos permite visualizar las
funcionalidades que van a ser probadas en cada uno de los módulos de la
aplicación desarrollada.
MÓDULO REQUISITOS FUNCIONALIDADES A PROBAR
SEGURIDAD
Roles
Crear rol
Buscar rol
Editar rol
Cancelar acción
Funciones
Crear funciones
Buscar funciones
Editar funciones
Cancelar acción
Gestión de Usuario
Seleccionar tipo de persona
Seleccionar nombre empleado
Crear usuario
Crear contraseña
Conceder roles a un
usuario
Seleccionar usuario
Seleccionar rol asignado
Cambiar de estado
Asignación de funciones a roles
Seleccionar rol
Seleccionar funciones
DATOS
PERSONAS
Estado Civil
Crear estado civil
Buscar estado civil
Editar estado civil
Cancelar acción
Crear departamento
Buscar departamento
68
Departamento Editar departamento
Cancelar acción
Cargo
Crear cargo
Buscar cargo
Editar cargo
Cancelar acción
Empleado
Crear empleado
Buscar empleado
Editar empleado
Cancelar acción
Médico
Crear medico
Buscar medico
Editar medico
Cancelar acción
INVENTARIO
Tipo medicamento
Crear tipo medicamento
Buscar tipo de medicamento
Editar tipo de medicamento
Cancelar acción
Medicamento
Crear departamento
Buscar medicamento
Editar medicamento
Cancelar acción
Entrada
Medicamentó
Crear entrada medicamento
Buscar entrada de medicamento
Editar entrada medicamento
Cancelar acción
Salida
Medicamentó
Crear salida de medicamento
Buscar salida de medicamento
Editar empleado salida de medicamento
Cancelar acción
Kardex
Medicamentó
Buscar medicamento
Generar reporte
Salir
FICHAS MEDICAS
Gestión Pacientes
Ingresar número de cédula
Buscar paciente
Paciente CCE la información se visualiza
Paciente particular se llenan los datos
Crear historia clínicas
Seleccionar especialidad
Seleccionar paciente
Llenar datos paciente
Guardar Datos
69
REPORTES
Generador de
Reportes
Reportes de Empleados
Reportes de Inventario
Reporte de la historias médicas
Tabla 12.Funcionalidades al Sistema
4.7 Entrega del Aplicativo
Manual de Instalación
EL manual de instalación de todos los programas que se utilizaron para el
desarrollo del aplicativo se encuentra en los Anexo.
Manual Técnico
El manual técnico donde se describe todas configuraciones para subir el
sistema se encuentra en la parte de Anexos.
Manual de Usuario
El manual de usuario donde se explica el funcionamiento correcto del
sistema se encuentra en los Anexos.
70
CAPITULO 5
5 CONCLUSIONES Y RECOMENDACIONES
5.1 Conclusiones
El desarrollo de este proyecto de tesis permitió al departamento
médico (CCE) contar un sistema que le permita mejorar la búsqueda
de las historias clínicas de los pacientes, llevar el control del
inventario de medicamentos.
El sistema cuenta con un módulo de reportes el cual es de mucha
ayuda ya que les permite tener la información del inventario de
medicamentos e historias clínicas de manera rápida y segura.
El sistema desarrollado se encamino a implementar solamente lo que
usuario solicitó que se realizara en el aplicativo.
El uso de la metodología iteractivo e incremental nos ayudó ir
mejorando cado uno de los módulo entregados en el aplicativo a los
usuarios finales.
Finalmente podemos concluir que el sistema desarrollado cumple los
requisitos solicitados por el departamento médico (CCE) ya que se
trabajó en conjunto con las personas involucradas en todas las etapas
de desarrollo.
71
5.2 Recomendaciones
Mayor participación de los usuarios en las diferentes etapas del
proceso de desarrollo del aplicativo para que se realice una adecuada
validación de los datos ingresados
Dado que el departamento médico (CCE) lleva a cabo más proceso
se sugiere la creación de un módulo de reservación de citas médicas
(medicina general y odontología) ya este módulo no se contempló en
tesis.
Para que los usuarios del sistema puedan adaptarse de manera
rápida se aconseja que se le facilite el manual de usuario, con lo cual
podrá hacer un mejor uso de la herramienta
Capacitar a los usuarios finales sobre el uso del sistema desarrollado
para que puedan manipularlo con facilidad y rapidez.
Se recomienda el uso de herramientas de software para evitar los
costos adicionales de licenciamiento.
Se recomienda la contratación de una persona para dar soporte y
mantenimiento del sistema desarrollado, esta persona tendrá el rol de
administración y debe tener conocimiento de informática.
72
5.3 Glosario de Términos
A
Applet: Es un componente de una aplicación que se ejecuta en el contexto
de otro programa, por ejemplo en un navegador web. El applet debe
ejecutarse en un contenedor, que le proporciona un programa anfitrión,
mediante un plugin,1 o en aplicaciones como teléfonos móviles que soportan
el modelo de programación por "applets".
Ajax: Es una técnica de desarrollo web para crear aplicaciones interactivas o
RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente,
es decir, en el navegador de los usuarios mientras se mantiene la
comunicación asíncrona con el servidor en segundo plano.
API: Es un conjunto de funciones que permite al programador acceder a
servicios de una aplicación a través del uso de un lenguaje de programación.
Una API ofrece al programador un cierto nivel de abstracción que enmascara
la complejidad de acceso a un sistema o aplicación, proponiéndole un
conjunto de funciones de las cuales sólo se conocen los parámetros y
los valores devueltos.
B
Base de Datos: Una base de datos es un “almacén” que nos permite
guardar grandes cantidades de información de forma organizada para que
luego podamos encontrar y utilizar fácilmente.
C
Casa de la Cultura Ecuatoriana(CCE): Es una institución autónoma, y se
puede decir que la de mayor antigüedad, a la cual se le ha encargado la
tarea de preservar, promover, fomentar, investigar, y difundir el arte, ciencia
y el patrimonio cultural del Ecuador.
73
E
EJB: Son una de las API que forman parte del estándar de construcción de
aplicaciones empresariales J2EE (ahora JEE 6.0) de
Oracle Corporation (inicialmente desarrollado por Sun
Microsystems). Su especificación detalla cómo los servidores de
aplicaciones proveen objetos desde el lado del servidor
ERP: Los sistemas de planificación de recursos empresariales son sistemas
de información gerenciales que integran y manejan muchos de los negocios
asociados con las operaciones de producción y de los aspectos de
distribución de una compañía en la producción de bienes o servicios
EIS: Un Sistema de Información para Ejecutivos o Sistema de Información
Ejecutiva es una herramienta software, basada en un DSS, que provee a los
gerentes de un acceso sencillo a información interna y externa de su
compañía, y que es relevante para sus factores clave de éxito.
F
Framework: Es un conjunto estandarizado de conceptos, prácticas y
criterios para enfocar un tipo de problemática particular que sirve como
referencia, para enfrentar y resolver nuevos problemas de índole similar.
Facelets: Es un sistema de código abierto de plantillas web bajo la Licencia
Apache y la tecnología de controlador de JavaServer Faces (JSF)
H
HTML: Siglas de HyperText Markup Language («lenguaje de marcas de
hipertexto»), hace referencia al lenguaje de marcado para la elaboración de
páginas web. Es un estándar que sirve de referencia para la elaboración de
páginas web en sus diferentes versiones, define una estructura básica y un
código (denominado código HTML) para la definición de contenido de una
página web, como texto, imágenes, videos, entre otros.
74
Hibernate: Es una herramienta de Mapeo objeto-relacional (ORM) para la
plataforma Java (y disponible también para .Net con el nombre de
NHibernate) que facilita el mapeo de atributos entre una base de datos
relacional tradicional y el modelo de objetos de una aplicación, mediante
archivos declarativos (XML) o anotaciones en los beans de las entidades
que permiten establecer estas relaciones.
I
Internet: Es un conjunto descentralizado de redes de comunicación
interconectadas que utilizan la familia de protocolos TCP/IP, lo cual garantiza
que las redes físicas heterogéneas que la componen funcionen como una
red lógica única, de alcance mundial.
J
Java Servlet: Los servlets son objetos que corren dentro y fuera del
contexto de un contenedor de servlets (ej: Tomcat) y extienden su
funcionalidad.
JavaServer Faces: Es una tecnología y framework para aplicaciones Java
basadas en web que simplifica el desarrollo de interfaces de usuario en
aplicaciones Java EE.
JEE: Es una plataforma de programación parte de la Plataforma Java para
desarrollar y ejecutar software de aplicaciones en el lenguaje de
programación Java, además de conectar servidores de aplicaciones y
sistemas de información empresarial (EIS) como parte de soluciones de
integración de aplicación de empresa (EAI).
JVM: Es una máquina virtual de proceso nativo, es decir, ejecutable en una
plataforma específica, capaz de interpretar y ejecutar instrucciones
expresadas en un código binario especial (el bytecode Java), el cual es
generado por el compilador del lenguaje Java.
K
75
Kardex: Es más que un registro de manera organizada de la mercancía que
se tiene en un almacén. Para hacerlo, es necesario hacer un inventario de
todo el contenido, la cantidad, un valor de medida y el precio unitario.
También se pueden clasificar los productos por sus características comunes.
L
Loguearse: “Loguearse” o “identificarse” es la acción de introducir nuestras
claves de usuario (nombre de usuario y contraseña) en una página web para
acceder a nuestra zona personal. Esta acción se dice que “abre una sesión
de usuario”, de la cual podemos salir en todo momento pulsando en un
enlace “desconectar” o “cerrar sesión”.
O
Open Source: Es la expresión con la que se conoce al software distribuido y
desarrollado libremente. Se focaliza más en los beneficios prácticos (acceso
al código fuente) que en cuestiones éticas o de libertad que tanto se
destacan en el software libre.
OML (Open Modeling Languaje): Defiende nuevos conceptos como invokes
y del precedes. Estos nuevos conceptos, toman la forma de estereotipo
definido por el usuario en los diagramas de caso de uso.
P
PDF (portable document format, formato de documento portátil): Es un
formato de almacenamiento de documentos digitales independiente de
plataformas de software o hardware. Este formato es de tipo
compuesto (imagen vectorial, mapa de bits y texto).
Persistencia: Se entiende por persistencia (en programación) como la
acción de preservar la información de un objeto de forma permanente
(guardar), pero a su vez también se refiere a poder recuperar la información
del mismo (leer) para que pueda ser nuevamente utilizada. En el caso de
persistencia de objetos la información que persiste en la mayoría de los
76
casos son los valores que contienen los atributos en ese momento, no
necesariamente la funcionalidad que proveen sus métodos.
Plug-ins: Es una aplicación que se relaciona con otra para aportarle
una función nueva y generalmente muy específica. Esta aplicación
adicional es ejecutada por la aplicación principal e interactúan por medio de
la API.
M
Modelo Orientado a Objetos: Una base de datos orientada a objetos es
una base de datos que incorpora todos los conceptos importantes del
modelo de objetos: Encapsulación, Herencia y Polimorfismo.
Modelo de base de datos: Es un conjunto que nos permite describir los
datos, las relaciones que existen entre ellos y las restricciones de
consistencia.
R
RMI (Java Remote Method Invocation): Es un mecanismo ofrecido
por Java para invocar un método de manera remota. Forma parte del
entorno estándar de ejecución de Java y proporciona un mecanismo simple
para la comunicación de servidores en aplicaciones distribuidas basadas
exclusivamente en Java.
RUP: El Proceso Racional Unificado (Rational Unified Process en inglés,
habitualmente resumido como RUP) es un proceso de desarrollo de software
desarrollado por la empresa Rational Software, actualmente propiedad
de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis, diseño, implementación
y documentación de sistemas orientados a objetos.
S
Servidor de aplicación: Un servidor de aplicaciones es un software que
proporciona aplicaciones a los equipos o dispositivos cliente, por lo general a
77
través de Internet y utilizando el protocolo http. Los servidores de aplicación
se distinguen de los servidores web por el uso extensivo del contenido
dinámico y por su frecuente integración con bases de datos.
Sistema Operativo: Es el software básico de una computadora que provee
una interfaz entre el resto de programas del ordenador, los dispositivos
hardware y el usuario.
SQL (Lenguaje de consulta estructurado o structured query language):
Es un lenguaje declarativo de acceso a bases de datos relacionales que
permite especificar diversos tipos de operaciones en ellas. Una de sus
características es el manejo del álgebra y el cálculo
relacional que permiten efectuar consultas con el fin de recuperar de
forma sencilla información de interés de bases de datos, así como hacer
cambios en ella.
T
Template: Es un conjunto de archivos que determinan la estructura y el
aspecto visual de un sitio web, y tiene como ventaja principal disminuir
tiempos y costos de desarrollo.
U
UML (Unified Modeling Language): Es el lenguaje de modelado de
sistemas de software más conocido y utilizado en la actualidad; está
respaldado por el OMG (Object Management Group). Es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema. UML ofrece
un estándar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y compuestos reciclados.
W
78
Workspace-eclipse: Es un directorio en el que se van abriendo todos los
proyectos en los que trabajamos.
Web: Es una colección de páginas de internet relacionadas y comunes a un
dominio de Internet o subdominio en la World Wide Web en Internet . Una
página web es un documento HTML/XHTML que es accesible generalmente
mediante el protocolo HTTP de Internet.
X
XHTML (eXtensible HyperText Markup Language): Es básicamente HTML
expresado como XML válido. Es más estricto a nivel técnico, pero esto
permite que posteriormente sea más fácil al hacer cambios o buscar errores
entre otros. En su versión 1.0, XHTML es solamente la versión XML de
HTML, por lo que tiene, básicamente, las mismas funcionalidades, pero
cumple las especificaciones, más estrictas, de XML.
XML (Extensible Markup Language): Es una especificación/lenguaje de
programación desarrollada por el W3C (World Wide Web Consortium). XML
es una versión de SGML (Standard Generalized Markup Language),
diseñado especialmente para los documentos de la web. Permite que los
diseñadores creen sus propias etiquetas, permitiendo la definición,
transmisión, validación e interpretación de datos entre aplicaciones y entre
organizaciones.
XP: La Programación Extrema es una metodología ligera de desarrolla de
software que se basa en la simplicidad, la comunicación y la realimentación
o reutilización del código desarrollado.
79
Bibliografía
1. CASA DE LA CULTURA –QUITO, Obtenido desde
http://www.quitoadventure.com/espanol/relax-ecuador/lugares-turisticos-
quito/teatros-musica/casa-cultura-ecuatoriana-quito.html
2. KARDEX, Obtenido desde
http://criolloamanda95.blogspot.com/2012/11/kardex.html
3. POSTGRESQL , Obtenidos desde
https://iessanvicente.com/colaboraciones/postgreSQL.pdf
4. JBOSS, Obtenido desde http://es.wikipedikia.org/wiki/JBoss
5. METODOLOGÍA DE DESARROLLO DE SOFTWARE, Obtenida desde
http://es.scribd.com/doc/12983329/Metodologia-de-Desarrollo-de-Software
6. UML Y LOS PROCESOS DE DESAROLLO DE software , Obtenida
desde
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rea_c_ji/capitulo3.pdf
7. GUIA DE INGENIERIA DE SOFTWARE, Obtenida desde
https://www.incibe.es/file/N85W1ZWFHifRgUc_oY8_Xg
8. JAVA, Obtenido desde http://www.javagratis.net63.net/que-es-
java.html
9. ENTERPRISE JAVABEANS Obtenida dese
http://es.wikipedia.org/wiki/Enterprise_JavaBeans
10. RICHFACES, Obtenida desde
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=richFaces
JsfIntro
11. REQUISITOS NO FUNICIONALES, Obtenida desde
http://es.wikipedia.org/wiki/Requisito_no_funcional
12. REQUESITOS FUNCIONALES, Obtenida desde
http://es.wikipedia.org/wiki/Requisito_funcional
13. DIAGRAMAS UML, Obtenida desde
http://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.p
80
6 ANEXOS
