Embed Size (px)
Citation preview
UNIVERSIDAD DE LAS TUNASFACULTAD DE CIENCIAS TÉCNICASDEPARTAMENTO DE INFORMÁTICA
SISTEMA DE CONTROL DE MEDICAMENTOS HOSPITALARIOS
TRABAJO DE DIPLOMA PARA OPTAR POR EL TÍTULO DEINGENIERO INFORMÁTICO
AUTOR: Daimara Rodríguez Leyva
TUTOR: Dr.C. David Mario Morales Rey
CONSULTANTES: Ing. Alejandro Toledo González
Ing. Feisy Pérez Amores
Las Tunas, mayo de 2013
DEDICATORIA
A Dios que me ha dado sabiduría en todo tiempo.
En especial a mi esposo Juan Rafael Pino por ayudarme siempre.
A mi madre Nelvis y a mi padrastro Martín.
A mi familia por darme su apoyo incondicional.
A mi tutor David, consultantes Alejandro Toledo, Feisy y profesores que me dieron su
gran ayuda.
Agradecimientos
A Dios y mi familia.A mi esposo Juan.A mi madre Nelvis y a mi padrastro Martín.A mis consultantes Alejandro Toledo y Feisy Pérez por su apoyoincondicional.A mi tutor David.A todo el que confió en mí.A todo el que me ayudó, en algún momento.A los que me tendieron su mano, y a los que me la negaron también.A todos, gracias.
DECLARACIÓN DE AUTORÍA
Declaro que soy el único autor de este trabajo y autorizo a la Facultad de Ciencias
Técnicas así como al Departamento de Informática para que hagan el uso que
estimen pertinente con este trabajo.
Para que así conste firmo la presente a los ___ días del mes de ___________ de
________.
______________ ______________ Firma del Autor Firma del Tutor
OPINIÓN DEL TUTOR DEL TRABAJO DE DIPLOMA
Título: Sistema de Control de Medicamentos HospitalariosAutor: Daimara Rodríguez Leyva
El tutor David Mario Morales Rey del presente Trabajo de Diploma considera quedurante su ejecución el estudiante mostró las cualidades que a continuación sedetallan.
Por todo lo anteriormente expresado considero que el estudiante está apto paraejercer como Ingeniero Informático; y propongo que se le otorgue al Trabajo deDiploma la calificación de .
__________________ _______________Firma Fecha
RESUMEN
En el marco de la salud en Cuba, el Hospital General Docente Doctor Ernesto
Guevara de la Serna de la provincia Las Tunas, en el área de la Farmacia Interna –
Almacén de Medicamentos y con el propósito de prestar un mejor servicio en la
distribución de medicamentos que son dispensados a las distintas salas para la
atención a pacientes hospitalizados y para el control de su existencia, como también
para los pedidos, sucedía que cada vez que una de estas áreas procesaba la
información o realizaba una solicitud para la obtención de la información deseada,
tenían que hacer el proceso de forma manual y estaba sujeta a distintos errores o
falta de control de esta actividad, lo que proporcionaba el desvío y falta de control de
éstos recursos.
Se decidió elaborar un sistema informático, para elevar la calidad de los servicios,
tener un mejor control de los distintos movimientos que se realizan en el almacén, así
como los destinos de éstos y los pedidos que se realicen a la Empresa
Comercializadora de Medicamentos (EMCOMED) de manera rápida y correcta,
permitiendo la rapidez en la obtención de la información deseada.
Con la realización de este sistema se le proporcionó a esta entidad un programa que
permite un mejor procesamiento de las informaciones que se controlan, garantizando
una mayor seguridad en los datos que se manejan y almacenan. De esta forma se
produce un mayor rendimiento del colectivo que manipulaba de forma manual estas
informaciones. También benefició a la parte directiva del hospital, brindando
información fiable para la toma de decisiones. Puede ser explotado en PC con la
siguiente configuración: Pentium II (o superior) con 128 MB de RAM sobre Windows,
HD 80 GB.
ÍNDICE
INTRODUCCIÓN------------------------------------------------------------------------------------------1
CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA ---------------------------------------------------5
Introducción ---------------------------------------------------------------------------------------------------- 5
1.1 Realización del control de medicamentos hospitalarios y pedidos en la Farmacia Interna -Almacén de Medicamentos.---------------------------------------------------------------------------------- 5
1.2 Sistemas para realizar el Control de Medicamentos Hospitalarios. ----------------------------- 9
1.3 Metodologías, Lenguajes y Herramientas utilizadas. --------------------------------------------- 111.3.1 Lenguajes. ------------------------------------------------------------------------------------------------------------ 111.3.2 Herramientas.--------------------------------------------------------------------------------------------------------- 141.3.3 Sistemas Gestores de Base de Datos ----------------------------------------------------------------------------- 151.3.4 Patrón CRUD--------------------------------------------------------------------------------------------------------- 161.3.5 Metodologías. ------------------------------------------------------------------------------------------------------- 16
Conclusiones parciales--------------------------------------------------------------------------------------- 17
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA. ------------------------------------------ 18
Introducción --------------------------------------------------------------------------------------------------- 18Objeto de Automatización ------------------------------------------------------------------------------------------------ 18
2.1 Modelado del Negocio ----------------------------------------------------------------------------------- 182.1.1 Actores del Negocio------------------------------------------------------------------------------------------------- 182.1.2 Definición de Caso de Uso----------------------------------------------------------------------------------------- 19
2.1.2.1 Casos de Uso del Negocio ------------------------------------------------------------------------------ 192.1.2.2 Diagrama de caso de uso del negocio --------------------------------------------------------------- 19
2.1.3 Descripción textual de los casos de uso del negocio.---------------------------------------------------------- 20
2.2 Flujo de Requerimientos. ------------------------------------------------------------------------------- 242.2.1 Requisitos Funcionales. -------------------------------------------------------------------------------------------- 242.2.3 Requisitos no funcionales. ---------------------------------------------------------------------------------------- 262.2.3 Actores del sistema y su justificación. --------------------------------------------------------------------------- 272.2.4 Casos de uso del sistema. ------------------------------------------------------------------------------------------ 28
2.2.4.1 Diagrama de casos de uso del sistema.------------------------------------------------------------- 292.2.5 Descripción textual de los casos de uso del sistema. ---------------------------------------------------------- 30
2.3 Flujo de Diseño.------------------------------------------------------------------------------------------- 382.3.1 Diagrama de Clases del Diseño ----------------------------------------------------------------------------------- 392.3.2 Diagrama de secuencia.--------------------------------------------------------------------------------------------- 412.3.3 Diagrama de clases persistentes. ---------------------------------------------------------------------------------- 472.3.4 Modelo de Datos. ---------------------------------------------------------------------------------------------------- 492.3.5 Modelo de Despliegue. --------------------------------------------------------------------------------------------- 49
2.4 Flujo de Implementación.------------------------------------------------------------------------------- 492.4.1 Modelo de Componentes. ------------------------------------------------------------------------------------------ 49
2.4.1.1 Diagrama de la arquitectura del sistema. ----------------------------------------------------------- 492.4.1.2 Diagramas de componentes de los casos de usos más importantes. ---------------------- 51
Conclusiones parciales--------------------------------------------------------------------------------------- 52
CAPÍTULO 3. IMPLEMENTACIÓN DEL SISTEMA.------------------------------------------- 53
Introducción --------------------------------------------------------------------------------------------------- 53
3.1 Aspectos relativos a la implementación del sistema.----------------------------------------------- 53
3.2 Diseño de la interfaz. ------------------------------------------------------------------------------------ 53
3.3 Forma general y principios en que se basa el sistema de ayuda. -------------------------------- 54
3.4 Forma general y principios de la protección y seguridad.---------------------------------------- 54
3.5 Forma general del tratamiento de errores.---------------------------------------------------------- 55
Conclusiones parciales--------------------------------------------------------------------------------------- 55
CONCLUSIONES---------------------------------------------------------------------------------------- 56
RECOMENDACIONES -------------------------------------------------------------------------------- 57
BIBLIOGRAFÍA ----------------------------------------------------------------------------------------- 58
ANEXOS --------------------------------------------------------------------------------------------------- 60
Anexo #1. Descripción textual del caso de uso del sistema Gestionar Salida de Medicamentos.------------------------------------------------------------------------------------------------------------------- 60
Anexo #2. Diagramas de secuencias del CUS_Gestionar Salida de Medicamentos -------------- 65
Anexo #3. Modelo de Datos. -------------------------------------------------------------------------------- 69
1
INTRODUCCIÓN
En el ámbito de la salud en Cuba, el Hospital General Docente Doctor Ernesto
Guevara de la Serna de la provincia Las Tunas, en el área de la Farmacia Interna –
Almacén de Medicamentos y con la intención de prestar un mejor servicio en la
distribución de medicamentos, que son dispensados a las distintas salas para la
atención a pacientes hospitalizados y para el control de su existencia, como también
para los pedidos, sucede que cada vez que una de estas áreas procesa la
información o realiza una solicitud para la obtención de la información deseada, tiene
que hacer el proceso de forma manual, lo cual atrasa la actividad cuando en muchos
de los casos no se puede perder tiempo, o está sujeta a distintos errores en los datos
de las informaciones que se llevan o falta de control de esta actividad. Todo ésto da
lugar a un descontrol en la información, duplicidad y la no actualización, lo que
proporciona el desvío y descontrol de éstos recursos, provocando pérdidas
económicas al estado y que los medicamentos no lleguen en tiempo y forma a los
pacientes.
En la actualidad existe un sistema informático implementado, pero no cumple
eficientemente con todos los requisitos, como una correcta creación de pedidos,
entradas y salidas de medicamentos, etc. Por lo que se ha continuado realizando
dichos procesos de forma manual, al no satisfacer al usuario con el producto
informático entregado.
Se decide para elevar la calidad de los servicios, elaborar un sistema informático
que cumpla con todos los requisitos para tener un mejor control de las distintas
operaciones de entrada y salida que se realizan en el almacén, así como los destinos
de éstos y los pedidos que se realicen a la Empresa Comercializadora de
Medicamentos (EMCOMED) de manera rápida y correcta, logrando establecer un
sistema de control y organización de la información general en la actividad de
medicamentos en el hospital.
La utilidad de un Sistema de Control de Medicamentos Hospitalarios que realice con
eficiencia y calidad el control de los medicamentos hospitalarios posee importancia
vital para el personal farmacéutico y en especial para el responsable del Almacén de
2
Medicamentos de dicho hospital, lo que contribuye a prestar un mejor servicio en la
distribución de medicamentos y control de su existencia, destinos y los pedidos de
éstos, que son dispensados a las distintas salas para la atención a pacientes
hospitalizados, contribuyendo a elevar la calidad de vida y salud de los mismos, y
evitar el desvío de éstos recursos.
Con la realización de esta aplicación se le proporciona a esta entidad un programa
que le permitirá un mejor procesamiento de las informaciones que controlan en dicha
área, garantizando una mayor seguridad con toda esta información almacenada. De
esta forma se produce un mayor rendimiento del colectivo que manipula de forma
manual estas informaciones, satisface las necesidades de esta área, lo que beneficia
a la parte directiva del hospital brindándole información fiable para la toma de
decisiones. Ello permite una correcta organización, eliminándose un grupo de
registros y controles manuales que demoran la gestión de la actividad en los
momentos actuales. Las personas que controlan esta información son: responsable
de Almacén de Medicamentos, técnica en informática, jefe de farmacia y el
informático encargado de recibir el pedido en EMCOMED.
En el proceso de realización del control de éstos recursos y los pedidos de los
mismos, en el Almacén de Medicamentos del Hospital General Docente Dr. Ernesto
Guevara de la Serna de la provincia Las Tunas, se detectaron varias deficiencias:
1. Errores en la realización del informe de recepción, donde se refleja la
cantidad de medicamentos que entra de EMCOMED.
2. Error en la información de los movimientos que se hacen mediante los valesde transferencia, para dar salida del almacén a la Farmacia Interna, ya sea
porque mandan un medicamento y no lo reflejan en el vale o mandan de más
o de menos a lo que está escrito en el vale.
3. No se refleja en muchas ocasiones la existencia real de cada medicamento,
por lo que proporciona un descuadre en los saldos.
4. Incorrecto cálculo de los máximos y mínimos de cada medicamento a tener el
almacén, lo que provoca que a la hora de realizar el pedido a EMCOMED no
se pida lo que realmente necesita tener el hospital para un mejor servicio o se
pediría de más, lo que ocasionaría excesivos gastos innecesarios al país.
3
El hecho de que la realización del control de medicamentos hospitalarios se realice
de forma manual auxiliándose del actual sistema informático ineficiente, para realizar
solamente el archivo del pedido, trae consigo otras dificultades como son:
1. Demora en darle entrada o salida a los medicamentos del almacén a la
farmacia, ya que el actual programa no tiene un sistema de búsqueda para
agilizar este proceso, por lo que sigue haciéndose de forma manual.
2. Mucho tiempo empleado en la confección de los pedidos.
3. Interfaz inadecuada, en el actual sistema, ya que no le da facilidades al
usuario para evitar equivocaciones en los distintos procesos que se realizan,
en especial, en la realización del archivo de pedidos.
4. Poca funcionalidad en lo que realmente se necesita para satisfacer las
necesidades de esta área.
Tomando en consideración lo expresado con anterioridad arribamos al siguiente
Problema Científico: La carencia de un software de propósito general, que realice
con eficiencia y calidad el control de los medicamentos hospitalarios y un correcto
pedido de los mismos atenta contra la buena marcha de los procesos que se realizan
en la Farmacia Interna – Almacén de Medicamentos, del Hospital General Docente
Dr. Ernesto Guevara de la Serna.
Este problema se enmarca en el Objeto de Estudio: proceso de control, recepción y
realización de pedidos de medicamentos hospitalarios.
Objetivo: implementar un sistema para el control de medicamentos hospitalarios y
realización de pedidos de los mismos, con una adecuada interfaz y facilidades para
el usuario en el área Farmacia Interna – Almacén de Medicamentos.
Campo de Acción: proceso de control de medicamentos hospitalarios, recepción y
pedidos de los mismos, en el área de la Farmacia Interna – Almacén de
Medicamentos del Hospital General Docente Doctor Ernesto Guevara de la Serna.
El problema detectado y el objetivo formulado permiten declarar la siguienteidea a defender: La elaboración informatizada del Sistema de Control de
Medicamentos Hospitalarios permite un mejor control de los mismos y realización de
pedidos de forma adecuada.
4
Tareas de la Investigación:
Estudio de resoluciones, instrucciones, manuales, normativas, etc., sobre
temas de inventarios o medios de rotación, en la parte de medicamentos
hospitalarios.
Estudio de los sistemas de control de medicamentos hospitalarios existentes
en el área nacional e internacional.
Estudio del lenguaje de programación, herramientas, metodología y sistema
gestor de base de datos a utilizar.
Análisis, diseño e implementación del Sistema de Control de Medicamentos
Hospitalarios en el área de la Farmacia Interna – Almacén de Medicamentos.
Lo que nos lleva a utilizar los siguientes métodos científicos:
Teóricos:
Histórico-Lógico: se emplea para hacer una búsqueda exhaustiva sobre
Sistemas Informáticos que resuelvan problemas semejantes al planteado.
Análisis y Síntesis: se realiza para resumir los aspectos más importantes de la
literatura y las fuentes consultadas, vinculadas con el problema tratado.
Inducción-deducción: Se emplea durante todas las etapas de la investigación
para relevar la relación entre lo particular y lo general, y viceversa.
Sistémico-estructural: Se emplea en la elaboración del sistema para la gestión
de la información, así como para abordar todos los procesos involucrados en
la temática estudiada.
Empíricos:
Revisión documental: Se emplea para la recopilación de la información
necesaria respecto al objeto de estudio de la investigación.
Entrevista: Se emplea en la recopilación de información mediante una
conversación profesional para lograr mejores resultados en la misión.
5
CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Introducción
En el presente capítulo se realiza una breve explicación de los controles que se
realizan a los medicamentos hospitalarios, así como de los pedidos de los mismos.
Se analizan algunas aplicaciones existentes y otras con problemas encontrados en
su funcionalidad e interfaz. Se describe la metodología, lenguaje y herramientas para
la realización del software. Todo esto posibilita una mejor comprensión de lo
expuesto en el problema.
1.1 Realización del control de medicamentos hospitalarios y pedidos en laFarmacia Interna - Almacén de Medicamentos.En el área Farmacia Interna - Almacén de Medicamentos del Hospital General
Docente Doctor Ernesto Guevara de la Serna de la provincia Las Tunas, se realiza el
control de medicamentos con respecto a su existencia y los movimientos que tengan
los mismos, así como también de la documentación necesaria para el manejo de los
datos de dichos recursos, lo que permite realizar un correcto pedido a EMCOMED,
según el máximo y mínimo de existencia que tenga cada uno de los medicamentos,
para garantizar la salud de los pacientes y un adecuado control económico.
El proceso de este control se inicia mediante una correcta recepción de los
medicamentos que se plasman en el informe mediante la factura y su conteo físico,
que realiza el responsable del Almacén de Medicamentos. Este informe derecepción incluye código de cada medicamento, nombre, unidad de medida,
cantidad, precio, importe, saldo e importe total. Además se recogerán los
movimientos de entradas, salidas y saldo de cada medicamento en las tarjetas de
estibas, estas se deben mantener actualizadas permanentemente.
Existen dos tipos de recepción de medicamentos:
Recepción preliminar.
Recepción detallada.
Recepción preliminar: la recepción preliminar es la que se realiza en el momento
de recibir los productos de los suministradores en presencia del transportista o
persona que realiza la entrega, durante la cual se verifican: identificación y
6
documentación recibida del suministrador, correspondencia entre la cantidad de
bultos o paquetes recibidos y la reflejada en la factura, conduce o nota de envío,
proveniente del suministrador e integridad física del envío, en el cual se comprobará
que los bultos o paquetes que se reciben estén en buen estado, correctamente
sellados y no presenten señales de haber sido abiertos o dañados.
Recepción detallada: se establece con carácter obligatorio la recepción detallada en
el término de las 48 horas inmediatas posteriores a la preliminar, con excepción de
los productos de frío y desabastecidos a los cuales se les hará de inmediato. En la
recepción detallada se cumplirá la “recepción a ciegas”, que consiste en la apertura
de todos y cada uno de los bultos o paquetes recibidos para verificar el surtido, la
cantidad y la calidad de lo recibido, para posteriormente comprobar su coincidencia
con lo que aparece registrado por el almacén suministrador en la factura. Esta
revisión es la más importante (Cuba. Ministerio de Salud Pública 2006, p. 27).
Una vez hecha la recepción detallada, dichos productos forman parte del inventario
de la unidad procediendo a la ubicación en el almacén según los procedimientos
para el almacenamiento. Además se realiza el informe del inventario de
medicamentos una vez al mes para un alto control de su existencia.
Otro de los controles se lleva en el libro de vencimientos, éste se emplea para que
los medicamentos roten, es decir, se le vaya dando salida por el lote con la fecha
más próxima a vencer, por lo que evita que éstos se venzan por lento movimiento al
no darle prioridad. Además para un mejor control de esta actividad una vez al mes se
realiza un informe de próximos a vencer en los siguientes tres meses.
Además, se realiza el control de medicamentos retenidos, ya sea por sospecha de
mala calidad, errores en los datos rotulados, etc. El proceso se inicia cuando llega
una orden de retención que emite EMCOMED, mediante el “plan de aviso”, donde
se informa el nombre genérico y/o comercial del medicamento, presentación, lote y
vencimiento, así como la causa. Luego se aparta la cantidad que el almacén de
medicamentos tenga de existencia del lote señalado y se registra en el libro decontrol de retenidos. Luego, mediante otro plan de aviso se ordena la liberación
por estar todo normal o retirada y destrucción de la cantidad del medicamento antes
retenido.
7
Cuando ocurren roturas en los medicamentos por mala manipulación de los mismos
o al vencerse se realizan ajustes mediante la rebaja en la tarjeta de estiba de la
cantidad que se vio afectada, actualizando el saldo.
El farmacéutico debe elaborar un vale de solicitud de entrega de medicamentos al
almacén, donde se plasma el código de cada medicamento, nombre, unidad de
medida y cantidad. Luego el responsable del almacén de acuerdo a la existencia
que tenga de los mismos procede a realizar la salida a la Farmacia Interna mediante
el vale de transferencia y rebajando dicha cantidad de la tarjeta de estiba. Dicho
vale debe tener código de cada medicamento, nombre, unidad de medida, cantidad,
precio y saldo. Todos estos son documentos legales que tienen gran importancia
para tener el control de medicamentos que solicita la Farmacia Interna al almacén y
las salidas que este le da a los mismos.
Para confeccionar el pedido de medicamentos primeramente se debe de tener un
máximo y mínimo de existencia de cada medicamento en el almacén, esto se obtiene
mediante el chequeo que el responsable del mismo realiza cada seis meses, es
decir, dos veces al año, procediendo a su correcto cálculo.
Metodología para el cálculo de los máximos y mínimos: para una mejor
interpretación del contenido de esta metodología se relacionan a continuación las
definiciones de los términos fundamentales.
Máximos Y Mínimos: constituye un procedimiento por el cual las farmacias
controlan sus necesidades de abastecimiento en dependencia del consumo, con el
objetivo de garantizar la disponibilidad de los productos farmacéuticos de forma
eficaz y eficiente. Las cifras Máximo y Mínimo constituyen sus dos componentes
fundamentales.
Máximo: es la cantidad máxima de un producto de que deberá disponer la
farmacia, por lo que también constituye el volumen máximo que pudiera pedir de un
producto en específico en el caso de que su existencia fuera cero.
Mínimo: es la cifra que indica cuando se debe realizar la solicitud de un
medicamento al almacén suministrador, previendo que no caiga en falta durante el
proceso de suministro. Cuando el período de abastecimiento de una farmacia sea de
8
7 a 10 días, el Mínimo es el 60 % del Máximo y si el período de abastecimiento es
de 15 a 30 días el Mínimo es el 80 %.
Consumo: es la salida que tuvo un producto en un período de tiempo prefijado,
destinada a satisfacer las necesidades de consumo de los pacientes. Otros acápites
como traslado, pérdidas por vencimiento y mal estado, no se incluyen en él.
Días Abastecidos: representa el total de días en que el producto estuvo presente
en la farmacia durante un período de tiempo determinado.
Norma de Abastecimiento: cantidad óptima de días en existencia que deben tener
los productos en la farmacia para garantizar que éstos no se terminen durante el
ciclo de despacho de los pedidos por parte de la Droguería según la frecuencia de
abastecimiento.
Procedimiento: Para calcular el máximo de existencia que debe tener cada
medicamento se aplica la siguiente fórmula:
entoAbastecimideNormasAbastecidoDías
ConsumoMáximo *
Donde, el Máximo es igual al consumo del medicamento en un período de seis meses
(Consumo) dividido entre los días que estuvo abastecido en ese período (Días
Abastecidos) por la norma de abastecimiento (Norma de Abastecimiento) que representa
la cantidad óptima de días en existencia que deben tener los productos en la
farmacia, según la frecuencia de abastecimiento.
Para calcular el consumo de cada medicamento en un período de seis meses se
aplica la siguiente fórmula:
Consumo = Existencia Inicial + Entradas – Existencia Final
Donde, Consumo es igual a la existencia inicial del medicamento (Existencia Inicial)
más la suma de las cantidades de las entradas (Entradas) menos la existencia final
(Existencia Final) en un período de seis meses.
Para calcular los días que estuvo abastecido cada medicamento en un período de
seis meses se aplica la siguiente fórmula:
Días Abastecidos = Días del Período – Días en Falta
9
Donde, Días Abastecidos son igual a los días del período de seis meses, igual a 180
días (Días del Período) menos los días que estuvo en falta este recurso en ese
período (Días en Falta).
La Norma de Abastecimiento varía según la frecuencia de pedido establecido.
Frecuencia del pedido Norma de Abastecimiento
Semanal 30 días
Decenal 40 días
Quincenal 45 días
Mensual 60 días
(Cuba. Ministerio de Salud Pública 2006, p. 88, 89, 91).
En este caso el responsable de almacén realiza el pedido cada 15 días. El mínimo de
existencia de cada medicamento es el 80 % del máximo de existencia.
El resultado obtenido, le proporciona al responsable de almacén tener los máximos y
mínimos de existencia de cada medicamento actualizados para luego, según la
existencia actual del medicamento, se pide si está por debajo o igual al mínimo de
existencia a completar el máximo. Todo esto permite realizar un correcto pedido,
evitando que no se pida de más, lo cual provoca que los medicamentos se venzan,
por lento movimiento, además del sobre abastecimiento, ocasionando pérdidas
económicas al estado, como también si se pide de menos ocasiona que los
medicamentos no lleguen en tiempo y forma a los pacientes hospitalizados, lo cual
atenta contra la salud de los mismos.
1.2 Sistemas para realizar el Control de Medicamentos Hospitalarios.Existe una gran cantidad de sistemas idóneos para realizar el Control de
Medicamentos Hospitalarios de acuerdo a las particularidades de cada institución de
salud que lo utilizan.
MAZ Matepss nº 11: integra el control de medicamentos en su gestión hospitalaria
con Microsoft. Es un sistema de gestión interna de historiales clínicos y
asignación/consumo de medicamentos. Se basa en las tecnologías Microsoft
Windows Server y BizTalk Server junto con la migración de sus aplicativos a .NET.
Su objetivo es la integración de la aplicación de gestión hospitalaria con los
dispensadores de medicamentos recién adquiridos como Pyxis, de la empresa
10
Cardinal Health, y Kardex. La automatización y control del almacén de
medicamentos, pues, se estableció en dos niveles: las operaciones de despacho
(entradas y salidas del almacén, inventario, etc.), y la integración con los sistemas de
gestión de expedientes que alcanza a los servicios de planta y quirófanos. El
resultado obtenido es un sistema de control de medicamentos totalmente
automatizado (MAZ integra el control de medicamentos en su gestión hospitalaria
con Microsoft)
xHosp: es un sistema de información hospitalario para el apoyo operacional y el
control administrativo integral de un hospital o clínica. Una de sus principales
funciones es que incluye el control de farmacias para llevar a cabo la entrada de
medicamentos y suministros así como el despacho de estos artículos a pacientes,
hacia las diferentes áreas hospitalarias o la transferencia de artículos entre las
distintas farmacias dentro del hospital. Fue diseñado desde su inicio como un
sistema modular y escalable, con interfaz de usuario gráfica y amigable, capacidad
de compartir la información con otras aplicaciones de Windows como Word, Excel o
Access entre otras (xHosp - Sistema integral para la administración hospitalaria)
Control de Materiales Hospitalarios: este Sistema, asociado a una red, automatiza
el control de inventario de los medicamentos, materiales de curación y todo tipo de
materiales existentes en: Almacén Central, Almacén de la Farmacia y el Almacén del
Centro Quirúrgico, así como en cualquier otro tipo de almacén. Facilita la operación
de los mismos, así como el control de los consumos de los distintos centros de costo
con que cuenta el Hospital, como elemento vital para el funcionamiento del mismo y
el conocimiento del nivel de gastos a los distintos niveles de gerencia (Control de
materiales hospitalarios)
Los sistemas informáticos antes referidos como MAZ Matepss nº 11 y xHosp son
comercializados con un precio muy elevado, por lo cual nuestro país no puede
adquirirlos para poder implementarlos en nuestros hospitales. También no se ajustan
a la política de nuestro país de emigrar a software libre. Otro como Control deMateriales Hospitalarios de nuestro país no está en uso por su desactualización.
En el año 2012 en EMCOMED de Las Tunas fue creada una aplicación de escritorio:
Sistema de Pedidos, que proporciona la realización del control de medicamentos y
11
el pedido de los mismos para el área de la Farmacia Interna - Almacén de
Medicamentos del Hospital Provincial.
Esta aplicación presenta muchas deficiencias que dificultan el control adecuado de
medicamentos y la realización correcta de los pedidos:
Demora en darle entrada o salida a los medicamentos del almacén a la farmacia,
ya que el actual programa no tiene un sistema de búsqueda para agilizar este
proceso, por lo que sigue haciéndose de forma manual.
Mucho tiempo empleado en la confección de los pedidos.
Interfaz inadecuada, en el actual sistema, ya que no le da facilidades al usuario
para evitar equivocaciones en los distintos procesos que se realizan, en especial,
en la realización del archivo de pedidos.
Poca funcionalidad en lo que realmente se necesita para satisfacer las
necesidades de esta área.
1.3 Metodologías, Lenguajes y Herramientas utilizadas.1.3.1 Lenguajes.En la actualidad existe una gran cantidad de lenguajes de programación orientados
al desarrollo de aplicaciones de escritorio como C++, JAVA, C#, C, Delphi, Pascal
entre otros, con diversas características útiles para que el programador valore y
decida cuál de ellos es la opción más apropiada a la hora de desarrollar un sistema
informático que cumpla con eficiencia sus objetivos.
Para exponer de los lenguajes de programación más conocidos su estado, será
realizada una breve comparación entre algunos de ellos. La intención de este análisis
es tomar la mejor elección del lenguaje que se ajuste al problema que se desea
solucionar.
C++: es un lenguaje de programación de propósito general basado en el C. Diseñado
a mediados de los años 1980 por Bjarne Stroustrup. La intención de su creación fue
el extender al exitoso lenguaje de programación C con mecanismos que permitan la
manipulación de objetos, además de añadirle cualidades y características de las que
carecía.
Las ventajas del C y C++ es que puede reutilizar código en forma de librerías de
usuario. Con la excepción del ensamblador, generan los programas más compactos
12
y rápidos. El código es transportable, es decir, un programa ANSI en C o C++ podrá
ejecutarse en cualquier máquina y bajo cualquier sistema operativo. Tienen más de
30 años de vida, y no parece que su uso se debilite demasiado. Sistemas operativos
como Linux, Unix o incluso Windows se escriben casi por completo en C. Existe una
inmensa comunidad de programadores alrededor de todo el mundo. Con tan gran
cantidad de personas aprendiendo y programando, el programador no tendrá
ninguna dificultad para encontrar ayuda y recursos accesibles en Internet. En caso
de que el programador original falte podrán hacerse modificaciones cuando el
desarrollo del programa esté finalizado, o se haya dejado a medias, sin ninguna
dificultad.
C#: el lenguaje de programación C#, es uno de los últimos lenguajes salidos al
mercado. Según sus creadores, C# se encuentra basado en los lenguajes C/C++,
Visual Basic y Java. Al igual que el resto, presenta ventajas y desventajas que
ameritan ser analizadas. En teoría, C# se encuentra diseñado con el objetivo de ser
portable a cualquier sistema operativo o computadora. En la práctica, solo Windows
está disponible. Microsoft promete realizar esfuerzos en este sentido pero hasta el
momento nada en concreto se ha logrado.
Debido al poco tiempo de nacido que tiene C#, aún no se ha solidificado una
comunidad de programadores lo suficientemente poderosa. Resulta difícil encontrar
en Internet recursos disponibles escritos en este lenguaje. Además, a pesar que
Microsoft publicó de forma gratis la plataforma .NET – la cual cuenta con el
compilador y herramientas necesarias para el desarrollo de aplicaciones en C# –, el
entorno visual para la escritura de programas en este lenguaje es necesario pagarlo
a altos precios.
Debido a la gran cantidad de características adicionales que presenta el C#, resulta
un lenguaje sumamente complejo de aprender – pero nunca tan complejo como
resulta el C / C++. No obstante, debido a las similitudes en el código, programadores
de Java y C++ encontrarán muy fácil esta tarea (Sánchez 2009)
Java: según Zukowski (Zukowski 2006, p. 51): Java es uno de los lenguajes que ha
ganado renombre en la programación moderna. Al igual que C / C++, cuenta con una
inmensa comunidad de programadores alrededor del mundo. Con Java pueden ser
13
creadas poderosas aplicaciones, sitios Web o pequeños programas (conocidos como
applets) que pueden ser corridos en Internet.
Java es un lenguaje de programación basado en las fortalezas y debilidades del C++.
Al igual que el Visual Basic, el Java aísla al programador de los detalles respecto al
hardware y memoria de la computadora. Como resultado, los programas escritos en
Java serán mucho más seguros que sus equivalentes escritos en C / C++.
Java utiliza un mecanismo llamado recolector de basura (garbage collector) para
eliminar los objetos creados por el programador en la memoria de la computadora.
Esto trae consigo que no existan desbordes de memoria (como en C / C++), y que el
código sea mucho más limpio y fácil de escribir.
De la misma forma que C / C++, Java se encuentra diseñado con el objetivo de
brindar una plataforma de libre distribución para la creación de aplicaciones. Todo lo
contrario a Visual Basic, por el que hay que pagar determinada cantidad de dinero
para su adquisición. En Internet puede encontrarse un gran número de entornos de
programación libre de impuestos para el desarrollo de programas en Java.
A pesar de sus grandes ventajas, Java también cuenta con un número de
desventajas que deberán ser analizadas en el momento de tomar una decisión. Por
ejemplo, los programas en Java tienden a ser mucho más lentos que sus
equivalentes escritos en otros lenguajes de programación. Además, al igual que el C
/ C++, Java es un lenguaje con una curva de aprendizaje bastante elevada.
Teóricamente los programas escritos utilizando Java podrán ser ejecutados en
cualquier entorno, pero en realidad, el programador deberá realizar pruebas a la
aplicación en cada nueva plataforma para asegurarse que esto sea así, lo que trae
consigo una gran pérdida de tiempo el cual pudiera ser aprovechado en la mejora y
actualización del código fuente (Sánchez 2009)
¿Por qué C++? Al ser analizadas las características generales de los lenguajes de
programación y las posibilidades de uso de cada uno de ellos acordamos usar C++
por el uso fácil de desarrollo de programas a través del uso de técnicas orientadas a
objeto, brinda una poderosa herramienta conceptual para utilizar en el proceso de
desarrollo, así como un eficiente medio de implementar el diseño de software.
Además por tener eficiencia del nivel de máquina y porque brinda un medio para
14
mejoras en la reutilización de componentes y empaquetarlos de forma tal que son
incorporados simplemente en los sistemas según se necesiten y nos ayuda al
desarrollo y mantenimiento de la aplicación informática.
UML: Es un lenguaje que proporciona un vocabulario y reglas que se centran en la
representación conceptual y física de un sistema, y que indican cómo crear y leer
modelos bien formados. Incluye aspectos conceptuales tales como procesos de
negocios y funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y componentes de
software reutilizables. Es un lenguaje gráfico para visualizar, especificar y
documentar cada una de las partes que comprende el desarrollo de software,
utilizado para la construcción de aplicaciones basadas en conceptos orientados a
objetos.
1.3.2 Herramientas.Rational Rose: Es una herramienta CASE (Computer – Arded Software
Engineering), traducido al español como Ingeniería Asistida por Computadora,
desarrollada por Rational Corporation basada en el Lenguaje Unificado de
Modelación (UML), es una herramienta para el despliegue, diseño, construcción,
pruebas y administración de proyectos en el proceso de desarrollo de software.
Realiza el modelado visual, forma parte de un conjunto más amplio de herramientas
que todas juntas abarcan el ciclo de vida del desarrollo de software. Rational Rose es
considerado una de las mejores herramientas para traducir requisitos de alto nivel a
una arquitectura basada en componentes.
C++ Builder: es un entorno de desarrollo rápido de aplicaciones en lenguaje C++
para Windows inicialmente propiedad de la empresa Borland, y actualmente de la
empresa Embarcadero, quien compró de Borland la división Codegear encargada del
producto. Combina la biblioteca Visual Component Library y el IDE escrito en Delphi
con un compilador de C++. Incluye herramientas que permiten desarrollo visual de
arrastrar-y-soltar componentes sobre la aplicación e incorpora constructor de interfaz
gráfica WYSIWYG en su IDE.
15
1.3.3 Sistemas Gestores de Base de DatosUn Sistema Gestor de Base de Datos (SGBD) es una aplicación que organiza el
almacenamiento de datos. Un SGBD es un tipo de software muy específico,
dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que
la utilizan. Controla la creación, mantenimiento y uso de las estructuras de base de
datos de almacenamiento de las organizaciones y de sus usuarios finales.
PostgreSQL: es un popular Sistema de Gestión de Base de Datos relacional
orientada a objetos y libre. Dirigido por una comunidad de desarrolladores y
organizaciones comerciales las cuales trabajan en su desarrollo, esta comunidad es
denominada el PGDG (PostgreSQL Global Development Group). Este potente gestor
incorpora una amplia variedad de tipos de datos, presenta una alta concurrencia e
implementa ciertas características orientadas a objetos, es además muy seguro,
multiplataforma y robusto.
Microsoft SQL Server: es un Sistema de Gestión de Bases de Datos desarrollado
por Microsoft basado en el modelo relacional, y sus lenguajes de consulta son
TransactSQL y ANSI SQL. Entre sus características más importantes están que
posee soporte para transacciones, así como procedimientos almacenados, tiene una
gran escalabilidad, seguridad y estabilidad, también incluye un poderoso entorno
gráfico para la administración y permite trabajar en modo cliente- servidor, donde los
datos se guardan en las bases de datos que están en el servidor y los clientes solo
pueden acceder a las mismas (Pérez 2011, p. 4 - 5)
MySQL: es un Sistema de Gestión de Base de Datos relacional, multihilo y
multiusuario. Por una parte se ofrece bajo la GNU GPL (GNU General Public
Licence) para todos los usos compatibles con esta licencia, pero las empresas que
deseen insertarlo en productos privados deben comprar a los dueños una licencia
que permita este tipo de uso. Todo lo contrario de Apache, donde la aplicación es
desarrollada por varias personas y el copyright del código está en manos del autor
individual (Pérez 2011, p. 5)
¿Por qué PostgreSQL? Al ser analizadas las características de los SGBD decidimos
utilizar PostgreSQL, ya que presenta una licencia de código abierto, se puede
programar funciones y procedimientos en diferentes lenguajes de una forma
16
dinámica, presenta un proceso de instalación / mantenimiento medio, tiene vistas
actualizables. Además, posee índices funcionales o índices basados en funciones.
1.3.4 Patrón CRUD: CRUD (create, read, update, y delete) significan “crear, leer,
actualizar y borrar”. Estas son las 4 operaciones básicas que toda base de datos
provee para realizar cualquier operación. Las operaciones significan:
Crear es “hacer persistente un objeto específico en la base de datos”. Una
operación de crear finaliza cuando otro proceso puede leer información del
objeto.
Leer es “recuperar un objeto especifico de la base de datos”. La operación de
leer es la misma operación que cuando realizamos una consulta.
Actualizar es “modificar un objeto especifico del grupo de objetos de la base
de datos”.
Borrar es “remover un objeto del grupo de objetos de la base de datos”.
1.3.5 Metodologías.La Ingeniería de software es una disciplina que contiene el proceso, los métodos y
las herramientas para el desarrollo de un sistema informático. El proceso de
desarrollo del software define el conjunto de actividades precisas para convertir los
requisitos de los usuarios en el conjunto seguro y resistente de artefactos que
componen un producto software. Por lo que es necesario especificar metodologías
para guiar el proceso de desarrollo de un producto de software. Las metodologías se
definen por pasos a seguir para que se cumpla un objetivo. Entre las metodologías
para el desarrollo de software más usadas actualmente encontramos: FDD (Feature
Driven Development), XP (eXtreme Programing), MSF (Microsoft Solution Features),
ADOSI, ERICSON, OBJECTORY (Object Factory), RUP (Rational Unified Process).
Por las características de este sistema se decide usar la metodología AM-RUP.
AM (Modelado Ágil): es una metodología para el modelado efectivo de sistemas de
software, una serie de prácticas, guiadas por principios y valores que pueden ser
aplicados por profesionales de software. Es una estrategia de modelado (de clases,
de datos, de procesos) pensada para contrarrestar la sospecha de que los métodos
ágiles no modelan y no documentan. Su objetivo es orientar el modelado de una
manera efectiva y ágil.
17
RUP (Proceso Unificado de Desarrollo): es un proceso de desarrollo de software
que garantiza la elaboración de todas las fases de un sistema orientado a objetos.
Está basado en componentes e interfaces bien definidas, y junto con el Lenguaje
Unificado de Modelado (UML), constituye la metodología estándar más utilizada para
el análisis, implementación y documentación de sistemas orientados a objetos.
Además define “quién” está haciendo “qué”, “cuándo” y “cómo” para alcanzar un
determinado objetivo. Sus principales características son: dirigido por casos de usos,
centrado en la arquitectura, iterativo e incremental.
AM-RUP: AM se combina con RUP debido a que permite hacer más ligeros los
procesos que usa este último. RUP es un proceso para describir el sistema
caracterizado por ser iterativo e incremental, donde cada fase se desarrolla en
iteraciones donde se involucran actividades de todos los flujos de trabajo, centrado
en la arquitectura que muestra la visión común del sistema completo en la que el
equipo de proyecto y los usuarios deben estar de acuerdo; dirigido por caso de uso,
ya que estos reflejan lo que los usuarios futuros necesitan y desean. Esta unión
preserva las características esenciales de RUP, pero con la diferencia que las partes
opcionales del RUP fueron obviadas, surgiendo como resultado un proceso muy
simple que cumple con los principios fundamentales de la metodología RUP.
Conclusiones parcialesEn este capítulo se abordaron los procesos de las actividades que se realizan en el
área de la Farmacia Interna – Almacén de Medicamentos en el Hospital General
Docente Doctor Ernesto Guevara de la Serna de la provincia de Las Tunas, para el
control de los medicamentos y los pedidos de los mismos. Además se analizaron
algunas aplicaciones existentes en el área nacional e internacional. Se exponen los
argumentos que definen la metodología, el lenguaje y las herramientas utilizadas,
basadas en las necesidades y los recursos disponibles.
18
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA.IntroducciónEn el presente capítulo se presenta el modelado de negocio, requerimientos, diseño
e implementación del sistema atendiendo a la metodología AM-RUP, definida en el
capítulo anterior.
Objeto de AutomatizaciónEl proceso a automatizar es el control, recepción y realización de pedidos de
medicamentos hospitalarios en el Hospital General Docente Doctor Ernesto Guevara
de la Serna de la provincia Las Tunas. El mismo se desarrolla mediante los distintos
informes para el manejo de datos referente a este tema, mediante los distintos
movimientos que tengan los mismos y un correcto cálculo de máximos y mínimos de
existencia de los mismos, para un correcto pedido a EMCOMED.
2.1 Modelado del NegocioUn proceso de negocio es un conjunto de tareas relacionadas lógicamente realizadas
para lograr un resultado de negocio definido. El modelo del negocio tiene como
objetivo describir los procesos, existentes u observados, con el propósito de
comprenderlos.
2.1.1 Actores del NegocioUn actor del negocio es cualquier individuo, grupo, organización, entidad, máquina o
sistema de información externos; con los que el negocio interactúa. Lo que se
modela como actor es el rol que se juega cuando se interactúa con el negocio para
beneficiarse de sus resultados.
En el sistema propuesto, interviene 1 actor principal, el Farmacéutico. En la
siguiente tabla se da una breve descripción de las funciones que realiza este sujeto.
Ver tabla 1Tabla 1. Justificación del actor del negocio
Actor del Negocio Justificación
Farmacéutico El farmacéutico es el que inicia todas
las acciones que dan comienzo a los
procesos del negocio analizados,
19
controla y pide medicamentos al
almacén, es el principal beneficiado
con el resultado de dichos procesos
de negocio.
2.1.2 Definición de Caso de Uso“Un caso de uso es un documento narrativo que describe la secuencia de eventos de
un actor (agente externo) que utiliza un sistema para completar un proceso.” (Álvarez
2000, p. 48)
Otra definición para describir mejor un caso de uso sería:
“Un caso de uso es una sucesión de transacciones realizada por un sistema que
rinde un resultado mensurable de valores para un actor particular.” (Quatrani 1999, p.
23)
2.1.2.1 Casos de Uso del Negocio
Controlar Medicamento.
Pedir Medicamento.
Pedir Medicamento a EMCOMED.
2.1.2.2 Diagrama de caso de uso del negocioUn diagrama de casos de uso del negocio representa gráficamente a los procesos
del negocio y su interacción con los actores del negocio. Ver Figura 1
20
Controlar Medicamento
(from Casos de Usos)
Pedir Medicamento
(from Casos de Usos)
Farmacéutico
(from Actores)
Pedir Medicamento a EMCOMED
(from Casos de Usos)
<<extend>>
Figura 1. Diagrama de caso de uso del negocio
2.1.3 Descripción textual de los casos de uso del negocio.Tabla 2. Descripción textual del caso de uso del negocio Controlar Medicamento.Nombre del Caso de Uso CUN_Controlar Medicamento
Actores Farmacéutico (inicia).Trabajadores Especialista.
Almacenero.Propósito Permite el control de los medicamentos.Resumen El caso de uso se inicia cuando el farmacéutico llega al Almacén
de Medicamentos, es atendido por el Especialista, el cual leproporciona varios informes realizados por el almacenero, segúnlo que solicite el Farmacéutico para el control de estos recursos,finalizando así el caso de uso.
Curso normal de los eventosAcciones del Actor Respuesta del proceso de
negocio
21
1 El Farmacéutico llega al almacén y solicitauno o varios tipos de informes.
5 El Farmacéutico firma cada informe.
7 El Farmacéutico recibe el informe o losinformes y se marcha.
2 El Especialista busca el informe olos informes realizados por elalmacenero, según lo solicitado porel farmacéutico.3 El Especialista imprime el informeo los informes.4 El Almacenero firma cadainforme.
6 El Especialista guarda copia decada informe y entrega informe alfarmacéutico.
Curso alternativo de los eventos.
Prioridad AltaMejoras Se logra un control más rápido y automatizado de los
medicamentos.
Tabla 3. Descripción textual del caso de uso del negocio Pedir Medicamento.
Nombre del Caso de Uso CUN_Pedir Medicamento
Actores Farmacéutico (inicia).Trabajadores Almacenero.Propósito Permitir al farmacéutico recibir los medicamentos pedidos al
almacén.Resumen El caso de uso se inicia cuando el Farmacéutico llega al
Almacén de Medicamentos, hace un pedido de dichos recursos,este es atendido por el Almacenero, el cual procede a la entrega,finalizando así el caso de uso.
Curso normal de los eventosAcciones del Actor Respuesta del proceso de
negocio
22
1 El Farmacéutico llega al Almacén deMedicamentos, hace el pedido de dichosrecursos que esté igual o por debajo delmínimo de existencia en la farmacia, medianteun vale de solicitud de entrega al almacén.
6 El Farmacéutico firma el vale detransferencia.
8 El Farmacéutico recibe el vale detransferencia, los medicamentos y se marcha.
2 El Almacenero recibe el pedido.3 El Almacenero rebaja lacantidad pedida del medicamentode la tarjeta de estiba.4 El Almacenero hace un vale detransferencia según la cantidadpedida de cada medicamento.5 El Almacenero imprime el valede transferencia y lo firma.
7 El Almacenero guarda copia delvale de transferencia y entrega elvale y los medicamentos alFarmacéutico.
Curso alternativo de los eventos.3.1 Si el saldo o existencia delmedicamento solicitado está encero o si la cantidad solicitada esmayor que la existencia en elalmacén se realiza el pedido delmismo a EMCOMED.Procediendo a la entrega de loque queda en el almacén(Continuando en el CUNExtendido Pedir Medicamento aEMCOMED).
Prioridad AltaMejoras Se logra un pedido más rápido y automatizado.Caso de usoasociado
CUN_Pedir Medicamento a EMCOMED (Extendido)
23
Tabla 4. Descripción textual del caso de uso del negocio Pedir Medicamento a EMCOMED(Extendido).Nombre del Caso de Uso CUN_Pedir Medicamento a EMCOMED
(Extendido)Actores Farmacéutico (inicia).Trabajadores Almacenero.Propósito Permitir realizar un correcto pedido para abastecer el Almacén
de Medicamentos.Resumen El caso de uso se inicia cuando el Farmacéutico llega al
almacén, solicita varios medicamentos, este es atendido por elalmacenero, el cual verifica que su existencia está en cero o enbaja cobertura, por lo que realiza el pedido de dichos recursosde acuerdo al máximo y mínimo de existencia que tenga cadauno a EMCOMED para su abastecimiento finalizando así el casode uso.
Curso normal de los eventosAcciones del Actor Respuesta del proceso de
negocio1 El Farmacéutico llega al almacén, realiza lasolicitud de entrega de varios medicamentos,mediante el vale.
4 El Farmacéutico se marcha.
2 El Almacenero recibe el vale desolicitud de entrega demedicamentos.3 El Almacenero verifica que suexistencia está en cero o en bajacobertura y se lo informa alFarmacéutico.
5 El Almacenero realiza el pedidode los medicamentos que esténpor debajo o igual al mínimo deexistencia a completar el máximoa EMCOMED, cada 15 días.
Curso alternativo de los eventos.
Prioridad AltaMejoras Se logra un pedido más rápido, adecuado y automatizado.
24
2.2 Flujo de Requerimientos.Un requisito es una condición o capacidad que necesita un usuario para resolver un
problema o lograr un objetivo. Condición o capacidad que tiene que ser alcanzada o
poseída por un sistema o componente de un sistema para satisfacer un contrato,
estándar, u otro documento impuesto formalmente.
2.2.1 Requisitos Funcionales.Los requisitos funcionales son capacidades o condiciones que el sistema debe
cumplir. Las actividades a automatizar en la realización de los Casos de Uso del
Negocio constituyen el punto de partida de los requisitos funcionales del sistema.
Requisitos Funcionales:
1. Autenticar usuarioRF 1.1 Registrar usuario
2. Gestionar usuarioRF 2.1 Crear usuario
RF 2.2 Modificar usuario
RF 2.3 Eliminar usuario
RF 2.4 Mostrar listado de usuarios
3. Gestionar ProvinciaRF 3.1 Crear Provincia
RF 3.2 Modificar Provincia
RF 3.3 Eliminar Provincia
RF 3.4 Mostrar Listado de Provincias
4. Gestionar MunicipioRF 4.1 Crear Municipio
RF 4.2 Modificar Municipio
RF 4.3 Eliminar Municipio
RF 4.4 Mostrar Listado de Municipios
5. Gestionar EntidadRF 5.1 Crear Entidad
RF 5.2 Modificar Entidad
RF 5.3 Eliminar Entidad
25
RF 5.4 Mostrar Listado de Entidades
6. Gestionar MedicamentoRF 6.1 Crear Medicamento
RF 6.2 Modificar Medicamento
RF 6.3 Eliminar Medicamento
RF 6.4 Mostrar Listado de Medicamentos
RF 6.5 Imprimir Listado de Medicamentos
7. Gestionar Entrada de MedicamentosRF 7.1 Crear Entrada de Medicamentos
RF 7.2 Modificar Entrada de Medicamentos
RF 7.3 Eliminar Entrada de Medicamentos
RF 7.4 Mostrar Listado de Entradas de Medicamentos
RF 7.5 Buscar Entrada de Medicamentos
8. Gestionar Salida de MedicamentosRF 8.1 Crear Salida de Medicamentos
RF 8.2 Modificar Salida de Medicamentos
RF 8.3 Eliminar Salida de Medicamentos
RF 8.4 Mostrar Listado de Salidas de Medicamentos
RF 8.5 Buscar Salida de Medicamentos
9. Gestionar Ajuste de MedicamentosRF 9.1 Crear Ajuste de Medicamentos
RF 9.2 Modificar Ajuste de Medicamentos
RF 9.3 Eliminar Ajuste de Medicamentos
RF 9.4 Mostrar Listado de Ajustes de Medicamentos
RF 9.5 Buscar Ajuste de Medicamentos
10.Retener Lote de MedicamentoRF 10.1 Transferir Lote de Medicamento a Retenido
RF 10.2 Transferir Retenido a Lote de Medicamento
11.Gestionar PedidoRF 11.1 Crear Pedido
RF 11.2 Mostrar Listado de Pedidos
26
RF 11.3 Visualizar Pedido
RF 11.4 Buscar Pedido
12.Analizar Máximos y MínimosRF 12.1 Calcular Máximos y Mínimos
RF 12.2 Mostrar Resultado
13.Generar reportes
RF 13.1 Generar Listado de Datos de los Medicamentos
RF 13.2 Imprimir Listado de Datos de los Medicamentos
RF 13.3 Generar Inventario de Medicamentos
RF 13.4 Imprimir Inventario de Medicamentos
14.Visualizar TrazasRF 14.1 Visualizar Trazas
RF 14.2 Buscar Trazas
15.Buscar MedicamentoRF 15.1 Buscar Medicamento
2.2.3 Requisitos no funcionales.Los requisitos no funcionales son propiedades o cualidades que el producto debe
tener. Características que hacen al producto atractivo, usable, rápido o confiable.
Requerimientos de apariencia o interfaz externa: El sistema debe ser fácil de
usar, legible y profesional. La interfaz debe ser sencilla y fácil de entender,
manteniendo una misma línea de principio a fin.
Requerimientos de Hardware: Se debe disponer de una máquina, con
procesador Pentium II (o superior) con 128 MB de RAM como mínimo sobre
Windows, HD 80 GB o mayor.
Requerimientos de Software: El software fue realizado en el lenguaje de
programación C++ Builder 2010, por lo que se debe disponer el SistemaOperativo Windows.
Requerimientos de Seguridad:Confidencialidad: La información manejada por el sistema está protegida de acceso
no autorizado y divulgación.
27
Integridad: La información manejada por el sistema es objeto de cuidadosa
protección contra la corrupción y estados inconsistentes, de la misma forma será
considerada igual a la fuente o autoridad de los datos.
Disponibilidad: Al usuario autorizado se le garantiza el acceso a la información y que
los dispositivos o mecanismos utilizados para lograr la seguridad no ocultaran o
retrasaran al mismo la obtención de los datos deseados en un momento dado.
Usabilidad: El sistema podrá ser usado por el almacenero, jefe de almacén y
técnica en informática o especialista del Almacén de Medicamentos del Hospital
General Docente Dr. Ernesto Guevara de la Serna y el informático encargado de
recibir el pedido en EMCOMED. El sistema debe ser fácil de usar de manera que
tenga gran aceptación entre los usuarios.
Rendimiento: En general el sistema debe ser rápido y responder en un tiempo
adecuado como para clasificarlo como interactivo.
Soporte: Fácil instalación, pruebas y mantenimiento. El sistema debe contar con
un manual de usuario. De esta manera el usuario se sentirá más seguro y tendrá
una guía de ayuda además del administrador.
2.2.3 Actores del sistema y su justificación.Los actores del sistema son personas (u otros sistemas) que eran trabajadores en el
Negocio. También pueden ser actores del negocio que interactúan de alguna forma
con el sistema. Por lo general estimulan el sistema con eventos de entradas o
reciben algo de él. O sea, es un rol de un usuario, que puede intercambiar
información. Puede ser un recipiente pasivo de información.Tabla 5. Actores del sistema y su justificación.
Actores del Sistema Justificación
Especialista Es el encargado de introducir
correctamente los datos de cada
medicamento al sistema y efectúa las
nuevas entradas, salidas, ajustes,
realiza las retenciones de lotes de los
mismos, el análisis de máximos y
28
mínimos, así como los distintos
reportes, por lo que actualiza la Base
de Datos.
Jefe de Farmacia Es el encargado de realizar las
modificaciones o eliminaciones de las
entradas, salidas y ajustes de
medicamentos, por lo que actualiza la
Base de Datos.
Almacenero Es el encargado de realizar los
pedidos de medicamentos en el
sistema para su posterior envío a
EMCOMED.
Administrador Informático calificado que se
encargará de gestionar los distintos
tipos de usuarios, la entidad, provincia
y municipio a que pertenecen.
Gestor Gestor generalizado, puede ser el Jefe
de Farmacia o el Especialista.
Usuario Usuario generalizado, puede ser elAdministrador, el Jefe de Farmacia,
Especialista o Almacenero.
2.2.4 Casos de uso del sistema.Los casos de uso se utilizan para obtener información de como debe trabajar el
sistema, son artefactos narrativos que describen mediante acciones y reacciones, el
29
comportamiento del sistema desde el punto de vista del usuario. Los casos de usos
definidos son los siguientes:
Autenticar usuario
Gestionar usuario
Gestionar Provincia
Gestionar Municipio
Gestionar Entidad
Gestionar Medicamento
Gestionar Entrada de Medicamentos
Gestionar Salida de Medicamentos
Gestionar Ajuste de Medicamentos
Retener Lote de Medicamento
Analizar Máximos y Mínimos
Gestionar Pedido
Generar reportes
Visualizar Trazas
Buscar Medicamento
2.2.4.1 Diagrama de casos de uso del sistema.Un diagrama de caso de uso del sistema es un modelo de las funciones deseadas
para el sistema y su entorno, y sirve como contrato entre el cliente y los
desarrolladores. Representa gráficamente a los procesos y su interacción con los
actores. Se utiliza como entrada esencial para las actividades de análisis, diseño y
prueba. Ver Figura 2
30
Autenticar usuario
(from Autenticar usua...
Usuario
(from Actors)
Gestionar Prov incia
(from Gestionar Provin...
Gestionar Municipio
(from Gestionar Munici...
Gestionar usuario
(from Gestionar usua...
Gestionar Entidad
(from Gestionar Enti...
Administrador
(from Actors)
Visualizar Trazas
(from Visualizar Trazas)
Buscar Medicamento
(from Buscar Medicame...
Gestionar Pedido
(from Gestionar Ped...
Almacenero
(from Actors)
<<include>>
Especialista
(from Actors)
Gestionar Medicamento
(from Gestionar Medicame...
<<include>>
Gestionar Entrada de Medicamentos
(from Gestionar Entrada de Medicamen...
<<include>>
Gestionar Salida de Medicamentos
(from Gestionar Salida de Medicamen...
<<include>>
Gestionar Ajuste de Medicamentos
(from Gestionar Ajuste de Medicamen... <<include>>
Retener Lote de Medicamento
(from Retener Lote de Medicame...
Analizar Máximos y Mínimos
(from Analizar Máximos y Míni...
Gestor
(from Actors)
Generar reportes
(from Generar repor...
Jef e de Farmacia
(from Actors)
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Figura 2 Diagrama de caso de uso del sistema.
2.2.5 Descripción textual de los casos de uso del sistema.Ver Anexo #1Tabla 6. Descripción textual del caso de uso del sistema Gestionar Entrada de Medicamentos
Nombre del Caso de Uso CUS_Gestionar Entrada de Medicamentos
Actores Generalizado: Gestor, Especializados: Especialista, Jefe deFarmacia
Propósito Realizar entradas de medicamentos.
31
Resumen El CUS se inicia cuando el Gestor desea dar una nuevaentrada de medicamentos, mostrar listado de entradas, buscarentrada de medicamentos, pero modificar o eliminar solo lopuede realizar el Jefe de Farmacia y termina luego que elsistema permite realizar cualquiera de estas opciones.
Referencias RF 7.1, RF 7.2, RF 7.3, RF 7.4, RF 7.5, CUS_BuscarMedicamento (Incluido), CUS_Autenticar usuario (Incluido)
Pre-condiciones Que el usuario haya accedido al sistema.Pos-condiciones (-).
Curso Normal de los EventosAcciones del Actor Respuesta del Sistema1. El Gestor selecciona el menú“Gestión”.
2. El sistema le muestra la opción: Movimientos de Productos: Nueva Entrada de Medicamentos. Mostrar Listado de Entradas de
Medicamentos. Buscar Entrada de Medicamentos. Modificar Entrada de Medicamentos. Eliminar Entrada de Medicamentos.
1. Si el Gestor selecciona la opción:Nueva Entrada de Medicamentos,ir a la sección “Nueva Entrada deMedicamentos”.
2. Si el Gestor selecciona la opción:Mostrar Listado de Entradas deMedicamentos, ir a la sección“Mostrar Listado de Entradas deMedicamentos”.
32
3. Si el Gestor selecciona la opción:Buscar Entrada de Medicamentos,ir a la sección “Buscar Entrada deMedicamentos”.
4. Si el Gestor selecciona la opción:Modificar Entrada deMedicamentos, ir a la sección“Modificar Entrada deMedicamentos”.
5. Si el Gestor selecciona la opción:Eliminar Entrada de Medicamentos,ir a la sección “Eliminar Entrada deMedicamentos”.
Sección “Nueva Entrada de Medicamentos”1. El Gestor selecciona la opción“Movimientos de Productos”.
2. El sistema habilita los campos, muestrael listado de todos los medicamentos,llamando al CUS_Buscar Medicamento.
3. El Gestor presiona el botón“Adicionar”.
4. El sistema habilita los campos de lainterfaz Adicionar.
5. El Gestor introduce el número yfecha de entrada.6. El Gestor introduce código onombre del medicamento para subúsqueda.
7. El sistema devuelve los registros quecoincidan con los datos introducidos.
8. El Gestor selecciona elmedicamento a dar entrada.
9. El sistema muestra los datos delmedicamento seleccionado.
10. El Gestor introduce cantidad, lotey vencimiento del medicamento,realizando la misma acción para cadauno de los mismos a dar entrada ypresiona el botón “Aceptar”.
33
11. El sistema verifica validez de los datosintroducidos.12. El sistema verifica que no exista elnúmero de la entrada de medicamentosen la Base de Datos.13. El sistema capta los datosintroducidos y los inserta en la Base deDatos.
Curso Alternativo de los Eventos11.1 Al existir campos vacíos, muestra unmensaje de error y regresa a la acción #9. ( Ver Curso Normal de Eventos)10.1 AL existir el número de la entrada demedicamentos en la Base de Datos,muestra un mensaje de error y regresa ala acción # 3. ( Ver Curso Normal deEventos)
Sección “Modificar Entrada de Medicamentos”1. El Jefe de Farmacia selecciona laopción “Movimientos de Productos”.
2. El sistema muestra el listado y labúsqueda por número de entrada demedicamentos.
3. El Jefe de Farmacia introduce elnúmero de la entrada para subúsqueda.
4. El sistema devuelve los registros quecoincidan con los datos introducidos.
5. El Jefe de Farmacia selecciona laentrada de medicamentos a modificary presiona el botón “Modificar”.
6. El sistema habilita los campos amodificar.
7. El Jefe de Farmacia modifica losdatos en los campos y presiona elbotón “Guardar”.
8. El sistema verifica validez de los datosintroducidos en los distintos campos.
34
9. El sistema guarda los datosmodificados en los campos y actualiza laBase de Datos.
Curso Alternativo de los Eventos8.1 Al existir campos vacíos, muestra unmensaje de error y regresa a la acción #7. ( Ver Curso Normal de Eventos)
Sección “Eliminar Entrada de Medicamentos”1. El Jefe de Farmacia selecciona laopción “Movimientos de Productos”.
2. El sistema muestra el listado y labúsqueda por número de entrada demedicamentos.
3. El Jefe de Farmacia introduce elnúmero de la entrada a eliminar parasu búsqueda.
4. El sistema devuelve los registros quecoincidan con los datos introducidos.
5. El Jefe de Farmacia selecciona laentrada de medicamentos a eliminar ypresiona el botón “Eliminar”.
6. El sistema muestra un mensaje paraconfirmar si desea realmente eliminarlo.
7. El Jefe de Farmacia aceptaeliminarlo.
8. El sistema elimina el registro de laentrada de medicamentos y actualiza laBase de Datos.
Curso Alternativo de los Eventos
7.1 El Jefe de Farmacia oprime elbotón “No”.
7.2 El sistema regresa a la acción # 2. (Ver Curso Normal de Eventos)
Sección “Mostrar Listado de Entradas de Medicamentos”1. El Gestor selecciona la opción“Movimientos de Productos”
2. El sistema muestra el listado deentradas de medicamentos.
Curso Alternativo de los Eventos
35
Sección “Buscar Entrada de Medicamentos”1. El Gestor selecciona la opción“Movimientos de Productos”.
2. El sistema muestra el listado y labúsqueda por número de entrada demedicamentos, mediante un edit.
3. El Gestor introduce en el edit eldato que identifica la entrada demedicamentos (número de la entrada)para su búsqueda.
4. El sistema verifica que exista el númerode la entrada de medicamentos en laBase de Datos.5. El sistema devuelve los registros quecoincidan con los datos introducidos.
Curso Alternativo de los Eventos4.1 Al no existir el registro de la entradaen la Base de Datos, muestra un mensajede error. (Ver # 2 del Curso Normal deEventos)
Tabla 7. Descripción textual del caso de uso del sistema Gestionar Pedido
Nombre del Caso de Uso CUS_Gestionar Pedido
Actores Almacenero.Propósito Realizar pedido de medicamentos.Resumen El CUS se inicia cuando el Almacenero desea realizar un
nuevo pedido de medicamentos, visualizar pedido, mostrarlistado de los documentos de pedidos o buscar pedido ytermina luego que el sistema permite realizar cualquiera deestas opciones.
Referencias RF 11.1, RF 11.2, RF 11.3, RF 11.4, CUS_BuscarMedicamento (Incluido)
Pre-condiciones Que el usuario haya accedido al sistema.Pos-condiciones (-).
Curso Normal de los EventosAcciones del Actor Respuesta del Sistema
36
1. El Almacenero selecciona elmenú “Pedidos”.
2. El sistema le muestra la opción: Pedidos de Medicamentos: Nuevo Pedido. Visualizar Pedido. Mostrar Listado de Pedidos. Buscar Pedido.1. Si el Almacenero selecciona la
opción: Nuevo Pedido, ir a la sección“Nuevo Pedido”.
2. Si el Almacenero selecciona laopción: Visualizar Pedido, ir a lasección “Visualizar Pedido”.
3. Si el Almacenero selecciona laopción: Mostrar Listado de Pedidos,ir a la sección “Mostrar Listado dePedidos”.
4. Si el Almacenero selecciona laopción: Buscar Pedido, ir a lasección “Buscar Pedido”.
Sección “Nuevo Pedido”1. El Almacenero selecciona la opción“Pedidos de Medicamentos”.
2. El sistema habilita los campos, muestrael listado de todos los medicamentos,llamando al CUS_Buscar Medicamento.
3. El Almacenero presiona el botón“Adicionar”.
4. El sistema habilita los campos de lainterfaz Adicionar.
5. El Almacenero introduce número yfecha del pedido.6. El Almacenero desea verificar quela existencia por medicamento estébien, por lo que introduce código onombre del medicamento para subúsqueda.
7. El sistema devuelve los registros quecoincidan con los datos introducidos.
37
8. El Almacenero presiona el botón“Proponer”.
9. El sistema realiza la selección de cadamedicamento que su existencia esté igualo por debajo del mínimo y realiza uncálculo a completar al máximo ya definido,generando la cantidad a pedir, guardandoel resultado en la Base de Datos.
10. El Almacenero presiona el botón“Exportar”.
11. El sistema genera un archivo con elpedido realizado para su posterior envíopor e-mail a EMCOMED.
Curso Alternativo de los Eventos
Sección “Visualizar Pedido ”1. El Almacenero selecciona la opción“Pedidos de Medicamentos”.
2. El sistema muestra el listado y labúsqueda por intervalo de fechas derealizados los pedidos de medicamentos.
3. El Almacenero introduce la primeray segunda fecha.
4. El sistema solicita los pedidos demedicamentos realizados en ese períodoa la Base de Datos.5. El sistema muestra todos los pedidosde medicamentos del período buscado.
6. El Almacenero selecciona el pedidoa visualizar y presiona el botón “Ver”.
7. El sistema muestra el pedidoseleccionado.
Curso Alternativo de los Eventos
38
Sección “Mostrar Listado de Pedidos de Medicamentos”1. El Almacenero selecciona la opción“Pedidos de Medicamentos”.
2. El sistema muestra el listado depedidos.
Curso Alternativo de los Eventos
Sección “Buscar Pedido”1. El Almacenero selecciona la opción“Pedidos de Medicamentos”.
2. El sistema muestra la búsqueda paraun intervalo de fechas.
3. El Almacenero introduce la primeray segunda fecha para la búsqueda depedidos de medicamentos realizadasen ese intervalo de tiempo.
4. El sistema verifica que exista o existanpedidos en ese período en la Base deDatos.5. El sistema devuelve los registros quecoincidan con los datos introducidos.4. El sistema solicita los pedidos demedicamentos realizados en ese períodoa la Base de Datos.5. El sistema muestra todos los pedidosde medicamentos del período buscado.
Curso Alternativo de los Eventos4.1 Al no existir el registro del pedido en laBase de Datos, muestra un mensaje deerror. (Ver # 2 del Curso Normal deEventos)
2.3 Flujo de Diseño.El flujo de diseño tiene como propósito modelar el sistema y encontrar su forma para
que soporte todos los requisitos. Crear una entrada apropiada y un punto de partida
para actividades de implementación. En este modelo son utilizados los diagramas de
secuencia y diagramas de clases del diseño correspondientes a los casos de usos
seleccionados en el modelado del sistema.
39
2.3.1 Diagrama de Clases del DiseñoSon diagramas de estructura estática que muestran las clases del sistema y sus
interrelaciones. Son utilizados tanto para mostrar lo que el sistema puede hacer
(análisis), como para mostrar cómo puede ser construido (diseño). Un diagrama de
clases muestra un conjunto de clases, interfaces y colaboraciones, así como sus
relaciones.
A continuación se muestra alguno de los diagrama de clases del diseño de los casos
de usos más importantes:
CUS_Gestionar Entrada de Medicamentos
CE_entrada_detalle
codcup : integeridentrada : integercantidad : integer
(f rom Clases Persistentes)
CE_medicamentos
idcodcup : integerproducto : varcharmaximo : integerminimo : integerexistencia : integeridformfarma : integernrolote : varcharidalm : varcharexistini : integerexistfinal : integerconsumo : integerdiasabast : integernormaabast : integerprecio : real
(f rom Clases Persistentes)
n
1
n
1
CE_entrada
identrada : integernrodoc : integerfecha : dateexistant : integerexistact : integeriddestino : integer
Crear Entrada()Modificar Entrada()Eliminar Entrada()Buscar Entrada()Mostrar Entrada()
(f rom Clases Persistentes)
n1
n1
CI_PrincipalCC_Entrada
CI_Modificar Entrada de Medicamentos
CI_Eliminar Entrada de Medicamentos
CI_Mostrar Entradas de Medicamentos
CI_Nueva Entrada de Medicamentos
Figura 3. Diagrama de Clases del Diseño del CUS_Gestionar Entrada de Medicamentos
40
CUS_Gestionar Salida de Medicamentos
CE_salida_detalle
codcup : integeridsalida : integercantidad : integer
(f rom Clases Persistentes)
CE_salida
idsalida : integernrodoc : integerfecha : dateexistant : integerexistact : integeriddestino : integer
Crear Salida()Modificar Salida()Eliminar Salida()Buscar Salida()Mostrar Salida()
(f rom Clases Persistentes)
n1
n1
CE_medicamentos
idcodcup : integerproducto : varcharmaximo : integerminimo : integerexistencia : integeridformfarma : integernrolote : varcharidalm : varcharexistini : integerexistfinal : integerconsumo : integerdiasabast : integernormaabast : integerprecio : real
(f rom Clases Persistentes)
n
1
n
1
CI_Principal CC_Salida
CI_Eliminar Salida deMedicamentos
CI_Modificar Salida deMedicamentosCI_Mostrar Salida de Medicamentos
CI_Nueva Salida deMedicamentos
Figura 4. Diagrama de Clases del Diseño del CUS_Gestionar Salida de Medicamentos
CUS_Gestionar Pedido de Medicamentos
CI_Principal
CE_pedido_detalle
numped : integercodcup : integercantidad : integer
(f rom Clases Persistentes)
CI_ Visualizar Pedido
CE_ pedidos
numped : integerfecha : date
Crear Pedido()Mostrar Pedidos()Visualizar Pedido()Buscar Pedido()
(f rom Clases Persistentes)
1n
1n
CE_medicamentos
idcodcup : integerproducto : varcharmaximo : integerminimo : integerexistencia : integeridformfarma : integernrolote : varcharidalm : varcharexistini : integerexistfinal : integerconsumo : integerdiasabast : integernormaabast : integerprecio : real
(f rom Clases Persistentes)
n
1
n
1
CC_Pedido
CI_Mostrar Pedidos
CI_Nuevo Pedido
Figura 5. Diagrama de Clases del Diseño del CUS_Gestionar Pedido.
41
2.3.2 Diagrama de secuencia.Muestran interacciones ordenadas en una secuencia de tiempo y los objetos que
participan. Ver Anexo #2.Figura 6 Diagramas de secuencias del CUS_Gestionar Entrada de MedicamentosCrear Entrada de Medicamentos
: Gestor : CI_Principal : CI_Nuev a Entrada deMedicamentos
: CC_Entrada : CE_entrada : CE_entrada_detalle : CE_medicamentos : CI_Mostrar Entradas deMedicamentos
Obtiene listado y datos de los medicamentos
Obtiene datos coincidentes
Selecciona medicamento a dar entrada
Crear entrada de med.
Guarda entrada de med.
Solicita medicamento a dar entrada
Guarda cantidad de entrada del med.
Muestra listado de entradas de medicamentos y la búsqueda
Introduce número y f echa de entrada
Selecciona del menú la opción "Mov imientos de Productos"
Introduce código o nombre del med. para su búsqueda
Presiona el botón "Adicionar"
Solicita listado y datos de los medicamentos
Solicita adicionar una nuev a entrada de med.
Muestra datos del med. seleccionado
Dev uelv eMed(codcup, producto, f orma_f armaceutica, precio)
Solicita datos del medicamento
Introduce datos (cantidad, lote y v encimiento) y selecciona aceptar
Comprueba campos
Muestra la entrada de medicamentos a adicionar
42
Modificar Entrada de Medicamentos
: Jefe de Farmacia : CI_Principal : CI_Mostrar Entradas deMedicamentos
: CI_Modificar Entrada deMedicamentos
: CC_Entrada : CE_entrada : CE_entrada_detalle : CE_medicamentos
Selecciona del menú la opción "Movimientos de Productos"
Sol ici ta listado de entradas de medicamentos
Obtiene l istado de entradas de medicamentos
Muestra listado de entradas de medicamentos y la búsqueda
Introduce nro. de entrada para su búsqueda
Buscar datos coincidentes
Obtiene datos de los medicamentos
Obtiene datos coincidentes
Muestra datos coincidentes
Selecciona la entrada y oprime el botón "Modificar"
Sol ici ta modificar entrada de medicamentos
Muestra la entrada de medicamentos a modifcar
Introduce nuevos datos y selecciona guardar
Modificar entrada de medicamentos
Comprueba campos
Guarda datos modificados
Guarda nueva cantidad
43
Eliminar Entrada de Medicamentos
: CI_Principal : CI_Mostrar Entradas deMedicamentos
: CI_Eliminar Entradade Medicamentos
: CC_Entrada : CE_entrada : CE_entrada_detalle : CE_medicamentos : Jefe de Farmacia
Solicita listado de entradas de medicamentos
Obtiene listado de entradas de medicamentos
Muestra listado de entradas de medicamentos y la búsqueda
Busca datos coincidentes
Obtiene datos coincidentes
Elimina entrada
Obtiene datos de los medicamentos
Solicita eliminar entrada de med.
Muestra datos coincidentes
Elimina cantidad
Selecciona del menú la opción "Movimientos de Productos"
Introduce nro. de entrada para su búsqueda
Selecciona entrada y selecciona eliminar
Presiona el botón "Si"
Solicita eliminar la entrada
Muestra mensaje de confirmación
Mostrar Listado de Entradas de Medicamentos
: CI_Principal : CI_Mostrar Entradasde Medicamentos
: CC_Entrada : CE_entrada : Gestor
Solicita listado de entradas de medicamentos
Obtiene listado de entradas de medicamentos
Muestra listado de entradas de medicamentos
Selecciona del menú la opción "Mov imientos de Productos"
44
Buscar Entrada de Medicamentos
: Gestor : CI_Mostrar Entradasde Medicamentos
: CC_Entrada : CE_entrada : CI_Principal
Muestra el listado de entradas de medicamentos y la búsqueda
Busca datos coincidentes
Muestra datos coincidentes
Introduce nro. de entrada para su búsqueda
Obtiene listado de entradas de medicamentos
Selecciona del menú la opción "Movimientos de Productos"
Solicita listado de entradas de medicamentos
Obtiene datos coincidentes
45
Figura 7 Diagramas de secuencias del CUS_Gestionar Pedidos
Crear Pedido
: Almacenero : CI_Principal : CI_NuevoPedido
: CC_Pedido : CE_ pedidos : CE_pedido_detalle : CE_medicamentos
Selecciona del menú la opción "Pedido de Medicamentos "
Solicita datos de los medicamentos
Obtiene datos de los medicamentos
Muestra interfaz
Presiona el botón "Proponer"
Solicita selección med. igual o por debajo del mínimo y cálculo a completar al máximo
Realiza cálculo a completar al máximo y crea Pedido
Guarda cantidad
Presiona el botón "Exportar"
Generar archivo de pedido
Introduce número y fecha del pedido
Introduce código o nombre del med. para su búsqueda
Obtiene datos coincidentes
Solicita datos del medicamento
Devuelve datos coincidentes
46
Visualizar Pedido
: Almacenero : CI_Principal : CI_MostrarPedidos
: CC_Pedido : CE_ pedidos : CE_pedido_detalle : CE_medicamentos : CI_ VisualizarPedido
Selecciona del menú la opción "Pedidos de Medicamentos"
Solicita l istado de pedidos
Obtiene listado de pedidos
Muestra listado de pedidos y la búsqueda por intervalo de fechas
Introduce la primera y segunada fecha
Solicita pedidos realizados en ese período
Obtiene pedidos realizados del período
Obtiene datos de los medicamentos
Muestra pedidos real izados del período
Selecciona el pedido a visualizar y presiona el botón "Ver"
Solicita vizualizar el pedido seleccionado
Visualiza el pedido seleccionado
Obtiene datos cantidades pedidas por med.
47
Mostrar Listado de Pedidos
: Almacenero : CI_Principal : CI_MostrarPedidos
: CC_Pedido : CE_ pedidos
Selecciona del menú la opción "Pedidos de Medicamentos"
Solicita listado de pedidos
Obtiene listado de pedidos
Muestra listado de pedidos
Buscar Pedido
: Almacenero : CI_MostrarPedidos
: CC_Pedido : CE_ pedidos : CI_Principal
Introduce primera y segunda fecha para buscar pedidos del período
Busca pedidos del período
Muestra pedidos del período buscado
Muestra el listado de pedidos y la búsqueda
Obtiene listado de pedidos de medicamentos
Obtiene pedidos del período
Selecciona del menú la opción "Pedidos de Medicamentos"
Solicita listado de pedidos de medicamentos
48
2.3.3 Diagrama de clases persistentes.Las clases persistentes son las clases que necesitan ser capaz de guardar su estado
en un medio permanente, la necesidad de guardar su estado está dada por el
almacenamiento físico permanente de la información de la clase, para el intercambio
de información, o para la copia de seguridad en caso del fracaso del sistema.
CE_ destinosiddestino : integerdestino : v archar
CE_pedidosnumped : integerf echa : dateidpedido : serial
Crear Pedido()Mostrar Pedidos()Visualizar Pedido()Buscar Pedido()
CE_salidaidsalida : serialnrodoc : v archarf echa : dateexistant : integerexistact : integeriddestino : integer
Crear Salida()Modif icar Salida()Eliminar Salida()Buscar Salida()Mostrar Salida()
n1 n1
CE_ ajusteidajuste : serialnrodoc : v archarf echa : dateexistant : integerexistact : integeriddestino : integer
n
1
n
1
CE_retenidosidretenido : integerf echa : datedetalle : v archarnroplanav iso : v archar
CE_ prov eedoresidprov ee : v archarprov eedor : v archar
CE_ entradaidentrada : v archarf echa : dateexistant : integerexistact : integeriddestino : integerid_ent : serial
Crear Entrada()Modif icar Entrada()Eliminar Entrada()Buscar Entrada()Mostrar Entrada()
n
1
n
1
CE_pedido_detalleidpedido : serialidmedicamentos : serialcantidad : integerid_pd : serial
n1 n1
CE_f ormas_f armaceuticasidf ormf arm : integerf orma_f armaceutica : v archar
CE_salida_detalleidmedicamentos. serialidsalida : serialcantidad : integerid_sd : serial
1n
1n
CE_ ajuste_detalleidmedicamentos : serialidajuste : serialcantidad : integerid_ad : serial
1n 1n
CE_ lotesnrolote : v archarf echav enc : datecantidad : integeridprov ee : v archaridretenido : integerid_lote : serial
1..n
1
1..n
1
1
n
1
n
CE_ entrada_detalleidmedicamentos : serialcantidad : integerid_ent : serialid_ed : serial 1n 1n
CE_ medicamentosidcodcup : integerproducto : v archarmaximo : integerminimo : integerexistencia : integeridf ormf arma : integernrolote : v archaridalm : v archarexistini : integerexistf inal : integerconsumo : integerdiasabast : integernormaabast : integerprecio : realidmedicamentos : serial
1
n
1
n
n1 n1
1
n
1
n
1
n
1
n
nn nn1
n1
n
CE_ prov inciaidprov incia : integerprov incia : v archar
CE_ almacenidalm : v archarnombre : v archaridmunicipio : integerdireccion : v archar
n
1
n
1
CE_rolesidrol : integernombre : v archar
CE_municipioidmunicipio : integermunicipio : v archaridprov incia : integeridusuario : integer
1n 1n
1
1..n
1
1..n
CE_ trazasid_traza : serialuser_name : charactercargo : characterf echa-hora : timestampacciones : charateruser_id : integer
CE_usuariosidusuario : integerusuario : v archarpass : v archarrol : integeridmunicipio : integer
1..n1 1..n1 1n 1n
n1
n1
Figura 8 Diagrama de clases persistentes.
49
2.3.4 Modelo de Datos.El modelo de los datos describe la representación física y lógica de datos
persistentes en el sistema. Ver Anexo #3.
2.3.5 Modelo de Despliegue.El diagrama de despliegue muestra la configuración de los nodos contribuyentes en
la ejecución de un sistema. Se modela la topología del hardware sobre la que se
ejecuta el sistema y la distribución física del mismo.
Figura 9 Modelo de Despliegue.
2.4 Flujo de Implementación.El flujo de implementación está compuesto por los modelos de componentes, general
y por cada caso de uso, que son los encargados de representar los componentes a
construir y su organización y dependencia entre nodos físicos en los que funcionará
la aplicación.
2.4.1 Modelo de Componentes.2.4.1.1 Diagrama de la arquitectura del sistema.Es la arquitectura con que está diseñado el sistema, en el cual se separan los datosde la aplicación, la interfaz de usuario y la lógica de negocio en tres componentesdistintos Modelo Vista Controlador (MVC).
Paquete Vis ual Paquete Contro l Paquete clas es Entidad
farm acia
Figura 10 Diagrama de componentes general
PC
Impresora
USB
50
Paquete Visual
Autenticarusuario.hError.h
Gestionarusuario.h
GestionarProv incia.h
GestionarMunicipio.h
GestionarEntidad.h
GestionarMedicamento.h
Gestionar Entrada deMedicamentos.h
Principal.h
Gestionar Salida deMedicamentos.h
Gestionar Ajuste deMedicamentos.h
Retener lote deMedicamento.h
GestionarPedido.h
Analizar Máximos yMínimos.h
VisualizarTrazas.h
Generarreportes.h
Figura 10.1 Diagrama de componentes Paquete Visual
Paquete Control
CAutenticar.h
CUsuario.h
CProvincia.h
CMunicipio.h
CEntidad.h
CMedicamento.hCEntrada.hCSalida.h
CAjuste.h
CRetener.h
CPedido.h
CMáximo.h
CTrazas.h
Figura 10.2 Diagrama de componentes Paquete Control
51
Paquete clases Entidad
usuario.h
Provincia.h
Municipio.h
Almacén.h
Proveedor.h
Lotes.h
Lotes_Medicamentos.h
Formas_Farmacéuticas.h
Medicamentos.h
Retenidos.hEntrada.h
Entrada_Detalle.h
Salida.h
Salida_Detalles.h
Ajuste.h
Ajuste_Detalle.h
Proveedores.h
Destinos.h
Pedido.h Pedido_Detalle.h
Trazas.h
Figura 10.3 Diagrama de componentes Paquete Modelo
2.4.1.2 Diagramas de componentes de los casos de usos más importantes.
Gestionar Entrada deMedicamentos.h
CEntrada.h
Entrada.h
Entrada_Detalle.h
Medicamentos.h
farmacia
Principal.h
Figura 13 Diagrama de componentes CUS_Entrada de Medicamentos
52
Gestionar Salida deMedicamentos.h
Principal.h
Salida.h
Salida_Detalles.h
Medicamentos.h
farmacia
Figura 14 Diagrama de componentes CUS_Salida de Medicamentos
Pedido.h
Principal.h GestionarPedido.h
CPedido.h Pedido_Detalle.h
Medicamentos.h
farmacia
Figura 15 Diagrama de componentes CUS_Pedido
Conclusiones parcialesEn este capítulo mediante el modelado del negocio se entendieron mejor los
métodos de trabajo, con el levantamiento de requerimientos funcionales se definieron
los casos de uso críticos a automatizar. Se muestran además, los requerimientos no
funcionales. Se describieron los actores que interactúan con el sistema, los casos de
uso a automatizar y se presenta el diagrama de casos de uso del sistema y el
diagrama de clases del diseño. También se realizaron los diagramas de secuencia
del diseño, las clases persistentes, el modelo de datos, el diagrama de la arquitectura
del sistema y el diagrama de componentes de los casos de uso más importantes.
53
CAPÍTULO 3. IMPLEMENTACIÓN DEL SISTEMA.IntroducciónEn el presentación capítulo se tratarán una serie de elementos que son necesarios
para dar una amplia perspectiva del objetivo que se persigue con la implementación
del sistema de la presente investigación, con el fin de organizar las ideas analizadas;
dando una amplia información del diseño de la interfaz del software; la forma general
y principios en que se basa el sistema de ayuda, y la forma general y principios de la
protección y seguridad; así como forma general del tratamiento de errores.
3.1 Aspectos relativos a la implementación del sistema.El sistema se desarrolló en el Embarcadero RAD Studio C++ Builder 2010, el cual es
un entorno de desarrollo rápido de aplicaciones, en lenguaje C++ para Windows.
Este tiende a englobar la usabilidad, utilidad y la rapidez de ejecución. Además se
utiliza para el desarrollo rápido de interfaces gráficas de usuario.
3.2 Diseño de la interfaz.El diseño de la interfaz de usuario es la categoría de diseño que establece un medio
de comunicación entre el usuario y la computadora. Tiene como objetivo definir las
acciones de interfaz (y sus representaciones en pantalla) que posibilitan al usuario
explotar las opciones que brinda el sistema. Una interfaz bien diseñada mejora la
percepción del contenido y de los servicios que proporciona el sistema de software
(Pressman 2005, p.259). Para el diseño de la interfaz del sistema se tuvo en cuenta
que toda aplicación en ambiente Escritorio, lleva necesariamente incluido en su
proceso, el cumplimiento de determinadas características como la claridad, la
sencillez y facilidad de manipulación, pues ello le posibilita al usuario la accesibilidad
efectiva a la información a través de una simple interacción con los elementos de la
pantalla; estando desarrollado dichos elementos en un entorno atrayente y
agradable, ya que uno de los objetivos principales de un sistema informático que
automatice un proceso dado es que sea aceptado sin problemas por el usuario, o
sea, que el cambio no involucre rechazo.
54
Figura 16 Interfaz principal
3.3 Forma general y principios en que se basa el sistema de ayuda.La ayuda de la aplicación es una opción que ofrece al usuario una herramienta de
consulta sobre los conocimientos necesarios para la explotación del mismo.
Contempla toda la información concerniente a la aplicación, manipulación y servicios
que brinda el sistema. El usuario puede acceder a la ayuda seleccionando en el
menú.
3.4 Forma general y principios de la protección y seguridad.Con el propósito de garantizar la seguridad de la información que se encuentra en la
base de datos del sistema se han definido varios usuarios con diferentes roles para
la manipulación de los recursos de la misma. Los niveles de acceso están
proporcionados por los tipos de usuarios definidos según las características de los
usuarios que interactúan con el sistema. Cada usuario tendrá acceso solo a las
opciones del sistema que le admite el rol especificado para él. Garantizando así la
confidencialidad de la información.
55
3.5 Forma general del tratamiento de errores.Una parte significativa en el desarrollo de un sistema lo constituye la validación de
los datos que interactúan con el usuario y el análisis de los errores que éstos puedan
generar. Tener ésto en cuenta y solucionarlo contribuye en gran medida a la calidad
del producto terminado.
Al realizarse un error la aplicación debe detectarlo y tratar de corregirlo. El mejor
remedio para evitar los errores es la prevención, pero evidentemente éstos ocurrirán
incluso con los usuarios de más avanzados, por lo que si no se pueden evitar los
errores al menos hay que tratar de minimizar sus consecuencias y ayudar a los
usuarios a recuperarse de éstos.
Las entradas de datos incorrectos causan, al menos, pérdida de tiempo a los
usuarios y pueden inclusive provocarle interrupciones a la aplicación. Para evitar
entradas incorrectas se usaron en la mayoría los casos controles de selección, de
forma que el usuario no tenga que teclear la información, sino que la escoja a partir
de valores ya existentes.
Se incluyen mensajes de errores comprensibles y útiles, para ayudar a los usuarios a
completar operaciones sobre los distintos objetos del sistema, logrando mejorar en
gran medida su interacción y garantizando la confianza y seguridad en la
manipulación del mismo.
Conclusiones parcialesEn este capítulo se abordaron una serie de elementos necesarios para la
implementación del sistema de la presente investigación, dando a conocer todo lo
necesario a la hora de confeccionar un buen diseño de la interfaz, así como dando
las formas generales y principios en que se basa el sistema de ayuda, el sistema de
protección y seguridad, y por último todo lo relacionado con el tratamiento de errores
en la aplicación.
56
CONCLUSIONESAl finalizar este trabajo se arribaron a las siguientes conclusiones:
Se alcanzó el objetivo mediante la implementación de un sistema para el
control de medicamentos hospitalarios y realización de pedidos de los
mismos, con una adecuada interfaz y facilidades para el usuario en el área
Farmacia Interna – Almacén de Medicamentos.
Las tecnologías utilizadas para el desarrollo de la aplicación permitieron
garantizar el cumplimiento de los requerimientos técnicos y de explotación de
la misma así como los requisitos solicitados por el usuario.
Se definieron los conceptos relacionados con el problema en cuestión, así
como las características que distinguen a los que manipulan toda la
información, lográndose así un diseño consistente y de fácil manipulación para
el usuario.
57
RECOMENDACIONES
Se recomienda:
Extender el sistema a otras entidades de salud.
Enriquecer el sistema aumentando las funcionalidades actuales, teniendo en
cuenta lo abarcador que puede ser el tema referente al control, recepción y
realización de pedidos de medicamentos hospitalarios.
58
BIBLIOGRAFÍA1. ÁLVAREZ, S. y HERNÁNDEZ, A. (2000). Metodología para el desarrollo de
aplicaciones con tecnologías orientadas a objetos utilizando notación UML. La
Habana: [s. n.].p. 48.
2. Control de materiales hospitalarios. [Disponible en:
http://www.infomed.sld.cu/instituciones/cedisap/Asimed3.html]. [Consultado: 4/ 2/
13]
3. CUBA. Ministerio de Salud Pública. (2006). Manual de normas y procedimientos
farmacia hospitalaria. [La Habana]. t.1. p. 27, 88, 89, 91.
4. DIETEL, H. M. y DIETEL, P. J. (2010). Cómo programar en C / C ++. La Habana:
Félix Varela. 3 t.
5. HERNÁNDEZ SAMPIER, R. (2003). Metodología de la investigación. La Habana:
Félix Varela. 2 t.
6. MAZ integra el control de medicamentos en su gestión hospitalaria con Microsoft
[Disponible en: http://www.computing.es/informatica-
profesional/noticias/1031525001701/maz-integra-control-medicamentos.1.html].
[Consultado: 4/ 2/ 13]
7. PÉREZ MARCHÁN, H. L. (2011). Sistema para la migración y diagnóstico de la
base de datos de intranet de ACINOX desde SQL Server hacia PostgreSQL.
Trabajo de Diploma para optar por el título de Ingeniero Informático. Universidad
de Las Tunas: Vladimir Ilich Lenin. p. 4, 5.
8. PRESSMAN, R. S. (2005). Ingeniería del Software. Un enfoque práctico. La
Habana: Félix Varela. p. 259.
59
9. QUATRANI, F. (1999). Visual modeling with Rational Rose 2000 and UML. USA:
Addison- Wesley. p. 23.
10.SÁNCHEZ ABÍN, A. (2009). Programa para el monitoreo y registro de variables
en fermentadores. Trabajo de Diploma para optar por el título de Ingeniero
Informático, Universidad de Camagüey.
11.xHosp - Sistema integral para la administración hospitalaria. [Disponible en:
http://www.virtus.com.mx/xhosp/index.html]. [Consultado: 4/ 2/ 13]
12.ZUKOWSKI, J. (2006). Programación Java 2 J2SE 1.4. La Habana: Félix Varela.
3 t. p. 51.
60
ANEXOSAnexo #1. Descripción textual del caso de uso del sistema Gestionar Salida deMedicamentos.
Nombre del Caso de Uso CUS_Gestionar Salida de Medicamentos
Actores Generalizado: Gestor, Especializados: Especialista, Jefe deFarmacia
Propósito Realizar salidas de medicamentos.Resumen El CUS se inicia cuando el Gestor desea dar una nueva salida
de medicamentos, mostrar listado de salidas, buscar salida demedicamentos, pero modificar o eliminar solo lo puede realizarel jefe de farmacia y termina luego que el sistema permiterealizar cualquiera de estas opciones.
Referencias RF 8.1, RF 8.2, RF 8.3, RF 8.4, RF 8.5, CUS_BuscarMedicamento (Incluido), CUS_Autenticar usuario (Incluido)
Pre-condiciones Que el usuario haya accedido al sistema.Pos-condiciones (-).
Curso Normal de los EventosAcciones del Actor Respuesta del Sistema1. El Gestor selecciona el menú“Gestión”.
2. El sistema le muestra la opción: Movimientos de Productos:
Nueva Salida de Medicamentos. Mostrar Listado de Salidas de
Medicamentos. Buscar Salida de Medicamentos. Modificar Salida de Medicamentos. Eliminar Salida de Medicamentos.1. Si el Gestor selecciona la opción:
Nueva Salida de Medicamentos, ira la sección “Nueva Salida deMedicamentos”.
2. Si el Gestor selecciona la opción:Mostrar Listado de Salidas deMedicamentos, ir a la sección“Mostrar Listado de Salidas deMedicamentos”.
61
3. Si el Gestor selecciona la opción:Buscar Salida de Medicamentos, ira la sección “Buscar Salida deMedicamentos”.
4. Si el Gestor selecciona la opción:Modificar Salida de Medicamentos,ir a la sección “Modificar Salida deMedicamentos”.
5. Si el Gestor selecciona la opción:Eliminar Salida de Medicamentos,ir a la sección “Eliminar Salida deMedicamentos”.
Sección “Nueva Salida de Medicamentos”1. El Gestor selecciona la opción“Movimientos de Productos”.
2. El sistema habilita el listado de losmedicamentos y los campos deldocumento salida, llamando alCUS_Buscar Medicamento.
3. El Gestor presiona el botón“Adicionar”.
4. El sistema habilita los campos de lainterfaz Adicionar.
5. El Gestor introduce el número yfecha de la salida.6. El Gestor introduce código onombre del medicamento para subúsqueda.
7. El sistema devuelve los registros quecoincidan con los datos introducidos.
8. El Gestor selecciona elmedicamento a dar salida.
9. El sistema muestra los datos delmedicamento seleccionado.
10. El Gestor introduce cantidad a darsalida y continúa realizando la mismaacción para cada uno de los mismos adar salida y presiona el botón“Aceptar”.
62
11. El sistema verifica validez de los datosintroducidos.12. El sistema verifica que no exista elnúmero de la salida de medicamentos enla Base de Datos.13. El sistema rebaja la cantidad de laexistencia en la Base de Datos, que estécon el lote más próximo a vencer.
Curso Alternativo de los Eventos11.1 Al existir campos vacíos, muestra unmensaje de error o al introducir unacantidad mayor que la existencia real yregresa a la acción # 9. ( Ver CursoNormal de Eventos)12.1 AL existir el número del documentoen la Base de Datos, muestra un mensajede error y regresa a la acción # 5. ( VerCurso Normal de Eventos)
Sección “Modificar Salida de Medicamentos”1. El Jefe de Farmacia selecciona laopción “Movimientos de Productos”.
2. El sistema muestra el listado y labúsqueda por número de salida demedicamentos.
3. El Jefe de Farmacia introduce elnúmero del documento para subúsqueda.
4. El sistema devuelve los registros quecoincidan con los datos introducidos.
5. El Jefe de Farmacia selecciona eldocumento de salida a modificar ypresiona el botón “Modificar”.
6. El sistema habilita los campos amodificar.
7. El Jefe de Farmacia modifica losdatos en los campos y presiona elbotón “Guardar”.
63
8. El sistema verifica validez los datosintroducidos en los distintos campos.9. El sistema guarda los datosmodificados en los campos y actualiza laBase de Datos.
Curso Alternativo de los Eventos8.1 Al existir campos vacíos, muestra unmensaje de error y regresa a la acción #7. ( Ver Curso Normal de Eventos)
Sección “Eliminar Salida de Medicamentos”1. El Jefe de Farmacia selecciona laopción “Movimientos de Productos”.
2. El sistema muestra el listado y labúsqueda por número de salida demedicamentos.
3. El Jefe de Farmacia introduce elnúmero de la salida a eliminar para subúsqueda.
4. El sistema devuelve los registros quecoincidan con los datos introducidos.
5. El Jefe de Farmacia selecciona lasalida de medicamentos a eliminar ypresiona el botón “Eliminar”.
6. El sistema muestra un mensaje paraconfirmar si desea realmente eliminarlo.
7. El Jefe de Farmacia aceptaeliminarlo.
8. El sistema elimina el registro de lasalida de medicamentos y actualiza laBase de Datos.
Curso Alternativo de los Eventos
7.1 El Jefe de Farmacia oprime elbotón “No”.
7.2 El sistema regresa a la acción # 2. (Ver Curso Normal de Eventos)
Sección “Mostrar Listado de Salida de Medicamentos”
64
1. El Gestor selecciona la opción“Movimientos de Productos”.
2. El sistema muestra el listado de salidasde medicamentos.
Curso Alternativo de los Eventos
Sección “Buscar Salida de Medicamentos”1. El Gestor selecciona la opción“Movimientos de Productos”.
2. El sistema muestra un edit para labúsqueda.
3. El Gestor introduce en el edit eldato que identifica la salida demedicamentos (número de la salida)para la búsqueda.
4. El sistema verifica que exista el númerode la salida de medicamentos en la Basede Datos.5. El sistema devuelve los registros quecoincidan con los datos introducidos.
Curso Alternativo de los Eventos4.1 Al no existir el registro de la salida enla Base de Datos, muestra un mensaje deerror. (Ver # 2 del Curso Normal deEventos)
65
Anexo #2. Diagramas de secuencias del CUS_Gestionar Salida deMedicamentosCrear Salida de Medicamentos
: Gestor : CI_Principal : CI_Nueva Salidade Medicamentos
: CC_Salida : CE_salida : CE_salida_detalle : CE_medicamentos : CI_Mostrar Salidade Medicamentos
Selecciona del menú la opción "Movimientos de Productos"
Solici ta listado y datos de los medicamentos
Obtiene l istado y datos de los medicamentos
Introduce número y fecha de sal ida
Introduce código o nombre del med. para su búsqueda
Solici ta datos del medicamento
Obtiene datos coincidentes
DevuelveMed(codcup, producto, forma_farmaceutica, precio)
Selecciona medicamento a dar salida
Solici ta medicamento a dar sal ida
Muestra datos del med. seleccionado
Introduce cantida a dar salida y selecciona aceptar
Comprueba campos
Guarda salida de med.
Guarda cantidad de salida del med.
Rebaja cantidad actual del med.
Muestra listado de salidas de medicamentos y la búsqueda
Presiona el botón "Adicionar"
Sol ici ta adicionar una nueva salida de med.
Muestra la sal ida de medicamentos a adicionar
Crear salida de med.
66
Modificar Salida de Medicamentos
: CI_Principal : CI_Mostrar Salidade Medicamentos
: CI_Modificar Salida deMedicamentos
: CE_salida : CC_Salida : CE_salida_detalle : CE_medicamentos : Jefe de Farmacia
Solicita listado de salidas de medicamentos
Obtiene listado de salidas de medicamentosMuestra listado de salidas de medicamentos y la búsqueda
Busca datos coincidentes
Obtiene datos coincidentes
Muestra datos coincidentes
Solicita modificar salida de med.
Muetra salida de med. a modificar
Modificar salida de med.
Comprueba campos
Guarda datos modificados
Guarda nueva cantidad
Rebaja nueva cantidad actual del med.
Selecciona del menú la opción "Movimientos de Productos"
Introduce nro. de salida para su búsqueda
Selecciona salida y selecciona modificar
Obtiene datos de los medicamentos
Introduce nuevos datos y selecciona guardar
67
Eliminar Salida de Medicamentos
: CI_Principal : CI_Mostrar Salidade Medicamentos
: CI_Eliminar Salidade Medicamentos
: CC_Salida : CE_salida : CE_salida_detalle : CE_medicamentos : Jefe de Farmacia
Solicita listado de salidas de medicamentos
Obtiene listado de salidas de medicamentos
Muestra listado de salidas de medicamentos y la búsqueda
Busca datos coincidentes
Obtiene datos de los medicamentos
Obtiene datos coincidentes
Muestra datos coincidentes
Solicita eliminar salida de med.
Elimina salida
Elimina cantidad
Selecciona del menú la opción "Movimientos de Productos"
Introduce nro. de salida para su búsqueda
Selecciona salida y selecciona eliminar
Muestra mensaje de confirmación
Presiona el botón "Si"
Solicita eliminar salida de med.
68
Mostrar Listado de Salidas de Medicamentos
: CI_Principal : CI_Mostrar Salidade Medicamentos
: CC_Salida : CE_salida : Gestor
Solicita listado de salidas de medicamentos
Obtiene listado de salidas de medicamentos
Muestra listado de salidas de medicamentos
Selecciona del menú la opción "Histórico"
Buscar Salida de Medicamentos
: Gestor : CI_Mostrar Salidade Medicamentos
: CC_Salida : CE_salida : CI_Principal
Obtiene datos coincidentes
Muestra datos coincidentes
Introduce nro. de salida para su búsqueda
Obtiene listado de salidas de medicamentos
Muestra el listado de salidas de medicamentos y la búsqueda
Selecciona del menú la opción "Histórico"
Solicita listado de salidas de medicamentos
Busca datos coincidentes
69
Anexo #3. Modelo de Datos.
T_f armaciaprov eedores
idprov ee : SMALLINTprov eedor : SMALLINT
<<PK>> PK_T_f armaciaprov eedores4()
T_f armaciaretenidos
idretenido : SMALLINTf echa : SMALLINTdetalle : SMALLINTnroplanav iso : SMALLINT
<<PK>> PK_T_f armaciaretenidos11()
T_f armaciapedidos
numped : SMALLINTf echa : SMALLINT
<<PK>> PK_T_f armaciapedidos12()
T_f armaciapedido_detalle
numped : SMALLINTcodcup : SMALLINTcantidad : SMALLINTT_f armaciapedidos_numped : SMALLINTidcodcup : SMALLINTidf ormf arm : SMALLINT
<<PK>> PK_T_f armaciapedido_detalle13()<<FK>> FK_T_f armaciapedido_detalle30()<<FK>> FK_T_f armaciapedido_detalle32()
1..*1
1..*1
<<Identif y ing>>
T_f armaciaroles
idrol : SMALLINTnombre : SMALLINT
<<PK>> PK_T_f armaciaroles17()
T_f armaciausuariosidusuario : SMALLINTusuario : SMALLINTpass : SMALLINTrol : SMALLINTidmunicipio : SMALLINTidrol : SMALLINTT_f armaciamunicipio_idmunicipio : SMALLINT...
<<PK>> PK_T_f armaciausuarios16()<<FK>> FK_T_f armaciausuarios33()<<FK>> FK_T_f armaciausuarios34()
1..*
1
1..*
1
<<Non-Identif y ing>>
T_f armaciaf ormas_f armaceuticas
idf ormf arm : SMALLINTf orma_f armaceutica : SMALLINT
<<PK>> PK_T_f armaciaf ormas_f armaceuticas1()
T_f armacialotes
nrolote : SMALLINTf echav enc : SMALLINTcantidad : SMALLINTidprov ee : SMALLINTidretenido : SMALLINTT_f armaciaprov eedores_idprov ee : SMALLINTT_f armaciaretenidos_idretenido : SMALLINT
<<PK>> PK_T_f armacialotes2()<<FK>> FK_T_f armacialotes26()<<FK>> FK_T_f armacialotes27()
1..*
1
1..*
1
<<Non-Identif y ing>>1..*
1
1..*
1
<<Non-Identif y ing>>
T_f armaciaalmacen
idalm : SMALLINTnombre : SMALLINTidmunicipio : SMALLINTdireccion : SMALLINTT_f armaciamunicipio_idmunicipio : SMALLINT...
<<PK>> PK_T_f armaciaalmacen3()<<FK>> FK_T_f armaciaalmacen41()
T_f armaciaprov inciaidprov incia : SMALLINTprov incia : SMALLINT
<<PK>> PK_T_f armaciaprov incia14()
T_f armaciamunicipio
idmunicipio : SMALLINTmunicipio : SMALLINTidprov incia : SMALLINTidusuario : SMALLINTT_f armaciaprov incia_idprov incia : SMALLINT
<<PK>> PK_T_f armaciamunicipio15()<<FK>> FK_T_f armaciamunicipio42()
1..* 11..* 1
<<Non-Identif y ing>>
1..*
1
1..*
1<<Non-Identif y ing>>
1..* 11..* 1
<<Non-Identif y ing>>
T_f armaciaentrada_detalle
codcup : SMALLINTidentrada : SMALLINTcantidad : SMALLINTT_f armaciaentrada_identrada : SMALLINTidf ormf arm : SMALLINTidcodcup : SMALLINT
<<PK>> PK_T_f armaciaentrada_detalle6()<<FK>> FK_T_f armaciaentrada_detalle43()<<FK>> FK_T_f armaciaentrada_detalle44()
T_f armaciasalida_detalle
codcup : SMALLINTidsalida : SMALLINTcantidad : SMALLINTT_f armaciasalida_idsalida : SMALLINTidf ormf arm : SMALLINTidcodcup : SMALLINT
<<PK>> PK_T_f armaciasalida_detalle8()<<FK>> FK_T_f armaciasalida_detalle49()<<FK>> FK_T_f armaciasalida_detalle50()
T_lotes_medicamentos
idf ormf arm : SMALLINTidcodcup : SMALLINTnrolote : SMALLINT
<<FK>> FK_T_lotes_medicamentos39()<<PK>> PK_T_lotes_medicamentos20()<<FK>> FK_T_lotes_medicamentos40()
1..*
1
1..*
1
<<Identif y ing>>
T_f armaciamedicamentosidcodcup : SMALLINTproducto : SMALLINTmaximo : SMALLINTminimo : SMALLINTexistencia : SMALLINTidf ormf arma : SMALLINTnrolote : SMALLINTidalm : SMALLINTexistini : SMALLINTexistf inal : SMALLINTconsumo : SMALLINTdiasabast : SMALLINTnormaabast : SMALLINTprecio : SMALLINTT_f armaciaalmacen_idalm : SMALLINTidf ormf arm : SMALLINT
<<PK>> PK_T_f armaciamedicamentos0()<<FK>> FK_T_f armaciamedicamentos29()<<FK>> FK_T_f armaciamedicamentos36()
1..*
1
1..*
1
<<Non-Identif y ing>>
1..*
1
1..*
1
<<Identif y ing>>
1..*1
1..*1
<<Identif y ing>>
1..*
1
1..*
1<<Identif y ing>>
1..*1
1..*1
<<Identif y ing>>
1..*
1
1..*
1
<<Identif y ing>>
T_f armaciaajuste_detalle
codcup : SMALLINTidajuste : SMALLINTcantidad : SMALLINTT_f armaciaajuste_idajuste : SMALLINTidf ormf arm : SMALLINTidcodcup : SMALLINT
<<PK>> PK_T_f armaciaajuste_detalle10()<<FK>> FK_T_f armaciaajuste_detalle51()<<FK>> FK_T_f armaciaajuste_detalle53()
1..*
1
1..*
1
<<Identif y ing>>
T_f armaciasalidaidsalida : SMALLINTnrodoc : SMALLINTf echa : SMALLINTexistant : SMALLINTexistact : SMALLINTiddestino : SMALLINTT_f armaciadestinos_iddestino : SMALLINT
<<PK>> PK_T_f armaciasalida7()<<FK>> FK_T_f armaciasalida54()
1..*
1
1..*
1
<<Identif y ing>>
T_f armaciaentradaidentrada : SMALLINTnrodoc : SMALLINTf echa : SMALLINTexistant : SMALLINTexistact : SMALLINTiddestino : SMALLINTT_f armaciadestinos_iddestino : SMALLINT
<<PK>> PK_T_f armaciaentrada5()<<FK>> FK_T_f armaciaentrada55()
1..* 11..* 1
<<Identif y ing>>
T_f armaciadestinos
iddestino : SMALLINTdestino : SMALLINT
<<PK>> PK_T_f armaciadestinos18()
1..*1 1..*1
<<Non-Identif y ing>>
1..*
1
1..*
1
<<Non-Identif y ing>>
T_f armaciaajusteidajuste : SMALLINTnrodoc : SMALLINTf echa : SMALLINTexistant : SMALLINTexistact : SMALLINTiddestino : SMALLINTT_f armaciadestinos_iddestino : SMALLINT
<<PK>> PK_T_f armaciaajuste9()<<FK>> FK_T_f armaciaajuste56()
1..*
1
1..*
1<<Identif y ing>>
1..*
1
1..*
1
<<Non-Identif y ing>>
