caso de estudio centro médico y laboratorio
TRANSCRIPT
SISTEMA ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP)
CASO DE ESTUDIO: CENTRO MÉDICO DE ESPECIALIDADES Y LABORATORIOS CLÍNICOS
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
2
TABLA DE CONTENIDO
Situación Actual ..................................................................................................................................... 3
Análisis del Sistema ............................................................................................................................... 4
Especificación de Requisitos ........................................................................................................................... 4
Identificación Del Sistema ......................................................................................................................... 4
Especificación De Funciones ...................................................................................................................... 4
Modelo de Casos de Uso ................................................................................................................................ 5
Especificación de Casos de Uso ................................................................................................................. 5
Diagrama de Casos de Uso ........................................................................................................................ 9
Glosario ........................................................................................................................................................ 10
Modelo de Dominio ...................................................................................................................................... 11
Diagrama de Actividades ......................................................................................................................... 11
Diagrama de Clases Conceptuales ........................................................................................................... 12
Modelo de Comportamiento ........................................................................................................................ 15
Diagramas de Secuencia .......................................................................................................................... 15
Contratos de las Operaciones .................................................................................................................. 18
Diagramas de Estado ............................................................................................................................... 20
Diseño del Sistema............................................................................................................................... 21
Modelo Arquitectónico ................................................................................................................................ 21
Diagrama de Componentes ..................................................................................................................... 21
Modelo de Diseño ........................................................................................................................................ 23
Diagramas de Colaboración ..................................................................................................................... 23
Diagrama de Clases de Diseño ................................................................................................................. 28
Preparando la Implementación............................................................................................................ 33
Modelo de Implementación ......................................................................................................................... 33
Diagrama de Clases de Implementación ................................................................................................. 33
Estructura de Clases................................................................................................................................. 34
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
3
SITUACIÓN ACTUAL
El Centro Médico de Especialidades y Laboratorios Clínicos, CEMELAB, es un servicio que de atención médica
(consultas) de diferentes especialidades y laboratorio para diferentes exámenes médicos a lo largo de todo
el país. CEMELAB posee convenio con casi todas las ISAPRES lo que la hace una excelente alternativa.
El gerente general ha decidido desarrollar un sistema electrónico de fichas médicas e historial de pacientes
(SEFP) para realizar todo el seguimiento de los pacientes independientemente de donde se atiendan o
realicen los procedimientos indicados por los especialistas. Este sistema de ficha electrónica está
reemplazando al sistema actual de fichas de atención que tiene cada centro.
Para el diseño del SEFP se ha contratado a su consultora, la cual ha realizado una primera entrevista
obteniendo una descripción aproximada del proceso y ciclo de vida de la ficha en cuestión. Esta información
incluye la siguiente:
1) Cuando un paciente nuevo llega a cualquier centro, se le crea una nueva ficha médica, la cual debe
ser completada con la información básica del individuo (nombre completo, rut, dirección, teléfono
de contacto y correo electrónico si tuviera). Estos datos deben ser ingresados en la recepción
correspondiente (ya sea en el laboratorio como en la recepción de atención médica).
2) Cuando un especialista atiende a un paciente, éste podrá ver la ficha completa del individuo para
poder realizar un seguimiento completo. Esto lo hace a través del terminal ubicado en cada box de
atención.
3) Una vez que ha terminado la atención del especialista, éste debe llenar con la anamnesis realizada
en la entrevista y posterior análisis realizado. Esta información debe incluir fecha de la atención,
datos de la inspección (peso, talla, IMC, temperatura y presión arterial), observaciones del examen
físico obtenido, diagnóstico e indicaciones (alimentaria y conductual, medicamentos y/o
procedimientos clínicos, derivaciones u hospitalización).
4) Además, en cada atención, el SEFP debe conectarse con un servicio web de la Agenda Médica para
informar cuando se realizan las atenciones de los especialistas, de manera de llevar el control y
poder cancelar los honorarios médicos respectivos.
5) Algo similar pasa cuando un paciente va a laboratorio por un procedimiento. En este caso el
tecnólogo médico o enfermera podrá ver la información referente a la última entrevista con
especialista o aquella que le derivó a dicho procedimiento. Así mismo, deberá ingresar cualquier
observación y los resultados obtenidos en el procedimiento (ya sea in situ o posterior análisis de los
resultados).
6) En caso de ser derivado a un centro asistencial para hospitalización, el especialista que lo deriva
podrá imprimir un informe médico que deberá presentar en el hospital o clínica que asista para que
lleve toda la información de manera más expedita.
7) El SEFP no debe realizar cobros por bonos o servicios prestados, ni tampoco el control de
remuneraciones y honorarios médicos del personal.
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
4
ANÁLISIS DEL SISTEMA
ESPECIFICACIÓN DE REQUISITOS
En esta sección se describe la visión funcional del sistema a la luz de los requerimientos expresados por el
cliente final.
Identificación Del Sistema
El sistema se describe de la siguiente forma:
Nombre del Sistema: Sistema Electrónico de Fichas de Paciente (SEFP)
Panorama: CEMELAB, a través de sus centros médicos y laboratorios a lo largo del país
Clientes: Recepcionistas, Médicos y Laboratoristas
Metas: Crear un sistema de registro electrónico de fichas únicas de pacientes del centro
para:
Centralizar la información médica de cada paciente registrado en el centro
Mantener la información en línea de manera de que cualquier especialista
pueda consultarla en forma oportuna
Entregar la información requerida al paciente en caso de hospitalización y/o
traslado a otro centro de atención.
Especificación De Funciones
En un análisis simple, podemos obtener que los requerimientos 1 al 6 son del tipo funcional y el número 7 es
una restricción del sistema. Por otro lado, el requerimientos 4 tiene una componente de interoperatividad
con el sistema de agendamiento médico.
La especificación funcional del sistema se detalla a través de las siguientes funciones:
# Ref: R1.1
Función: Registro de un Paciente
Descripción: El sistema debe permitir el registro de un paciente con los datos básicos de éste
(nombre completo, rut, dirección, teléfono de contacto y correo electrónico).
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# Ref: R1.2
Función: Registro de Anamnesis
Descripción: El sistema debe permitir que el médico tratante ingrese el detalle de la atención
en box incluyendo los procedimientos y medicamentos indicados.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# Ref: R1.3
Función: Registro de Observaciones en un Procedimiento
Descripción: El sistema debe permitir que la enfermera o médico a cargo ingrese las
observaciones durante el procedimiento médico de un paciente.
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
5
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# Ref: R1.4
Función: Registro de Resultados de un Procedimiento
Descripción: El sistema debe permitir que el tecnólogo médico ingrese los resultados y las
inferencias según sea el caso de los procedimientos realizados por el paciente.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# Ref: R2.1
Función: Consulta de Historial del Paciente
Descripción: El sistema debe permitir al profesional consultar sobre la historia reciente del
paciente registrada en su ficha.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
Información Segmentada La información debe ser segmentada según el nivel de
acceso del profesional consultante.
Política
# Ref: R2.2
Función: Actualización de Agenda Médica
Descripción: El sistema debe actualizar el sistema de agendamiento cuando el especialista
cierra la ficha luego de terminada la consulta de un paciente.
Categoría: Oculto
Atributo Detalles y Restricciones Categoría
Servicio Web La actualización debe realizarse a través de un servicio
web prestado por el sistema de agenda médica.
Interoperatividad
# Ref:
Función:
Descripción:
Categoría:
Atributo Detalles y Restricciones Categoría
MODELO DE CASOS DE USO
En esta sección se describen los casos de uso, su detalle y la relación que tienen con las funciones
determinadas en la sección anterior. Es importante incorporar el detalle de cada iteración priorizado de
manera de mantener coherencia con lo que se realize a través del proceso de desarrollo complete.
Especificación de Casos de Uso
Casos de Uso de Alto Nivel
A pesar de que no siempre es así, en este caso los casos de uso se parecerán mucho a lo que encontramos
como funciones. Veamos paso a paso la técnica de especificación.
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
6
Si observamos las metas de la especificación funcional, podemos decir que el límite del sistema está la
creación y registro del historial médico de un paciente que ingresa y se atiende en algún centro de
CEMELAB. Sin embargo, también podemos decir que excluye:
La administración de la agenda
La compra de bonos y el pago de los servicios prestados por el centro
El control de remuneraciones y honorarios de profesionales
A partir de los clientes y del texto entregado, podemos decir que los actores del sistema son:
Actor Objetivo
Recepcionista Registrar un paciente nuevo para atención Imprimir detalle de ficha médica en caso de derivación o traslado
Especialista Consultar ficha del paciente a ser atendido Ingresar a la ficha del paciente la anamnesis
Enfermera Consultar ficha del paciente a ser atendido Ingresar observaciones en procedimiento
Tecnólogo Ingresar resultados y diagnóstico de un procedimiento
Paciente Ser atendido
Agenda Médica Actualizar las horas médicas cuando se cierre una atención
Los casos de uso encontrados en esta iteración son los siguientes:
Caso de Uso: CU1: Registrar Paciente
Actores: Recepcionista (I), Paciente
Tipo: Primario
Descripción: Cuando llega un paciente nuevo, éste debe ser registrado en el sistema y su ficha
será creada. La información necesaria para este registro es nombre completo, rut,
dirección, teléfono y correo electrónico.
Caso de Uso: CU2: Consultar Historial
Actores: Especialista/ Enfermera (I)
Tipo: Primario
Descripción: Antes de la atención, el encargado deberá revisar la ficha del paciente.
Caso de Uso: CU3: Registrar Anamnesis
Actores: Especialista (I), Paciente
Tipo: Primario
Descripción: Al terminar la atención médica, el médico tratante ingrese el detalle de la atención
en box incluyendo los procedimientos y medicamentos indicados.
Caso de Uso: CU4: Registrar Observaciones por Procedimiento
Actores: Enfermera (I)
Tipo: Secundario
Descripción: Durante un procedimiento, la enfermera puede ingresar observaciones que le
parezcan relevantes para el análisis del mismo.
Caso de Uso: CU5: Registrar Resultado de Procedimiento
Actores: Tecnólogo (I)
Tipo: Primario
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
7
Descripción: Al analizar una muestra, el tecnólogo debe ingresar los resultados clínicos en la
ficha, así como también el diagnóstico preliminar si procede.
Caso de Uso: CU6: Generar Traslado
Actores: Recepcionista (I), Especialista, Paciente
Tipo: Opcional
Descripción: En caso de un traslado (derivación u hospitalización), se debe emitir un informe
indicando el último diagnóstico y procedimientos asociados a éste.
Caso de Uso: CU7: Actualizar Agenda Médica
Actores: Especialista (I)
Tipo: Primario
Descripción: Cada vez que el especialista cierra una atención médica, ésta debe ser actualizada en
la agenda médica.
Es importante destacar que solo los CU principales serán expandidos a continuación.
Casos de Uso Expandidos
El detalle de los casos de uso identificados es el siguiente:
Caso de Uso: CU1: Registrar Paciente
Actores: Recepcionista (I), Paciente
Propósito: Realizar el registro de un paciente nuevo en el SEFP.
Resumen: Cuando llega un paciente nuevo, éste debe ser registrado en el sistema y su ficha
será creada. La información necesaria para este registro es nombre completo, rut,
dirección, teléfono y correo electrónico.
Tipo: Primario y Esencial
Ref. Cruzadas: R1.1
Curso Normal
Acciones de los Actores Respuestas del Sistema
1. Paciente llega al mesón de atención y entrega
su RUT.
2. Recepcionista ingresa RUT en el sistema para
confirmar que es nuevo.
3. Sistema confirma que el paciente es nuevo y
solicita información básica.
4. Recepcionista solicita al paciente información.
5. Paciente entrega a Recepcionista información
solicitada.
6. Recepcionista ingresa la información en el
sistema.
7. Sistema registra la información y crea la ficha
electrónica informando acción.
8. Recepcionista entrega RUT al Paciente.
Cursos Alternos
(3a) Si el paciente ya existe, informa al Recepcionista y termina el CU.
(7a) Si el RUT ya está registrado con otra información, alerta al Recepcionista y solicita confirmación para
actualizar información.
Caso de Uso: CU2: Consultar Historial
Actores: Especialista/Enfermera (I)
Propósito: Consultar aspectos relevantes de la ficha previos a la atención.
Resumen: Antes de la atención, el encargado deberá revisar la ficha del paciente utilizando el
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
8
RUT de éste.
Tipo: Primario y Esencial
Ref. Cruzadas: R2.1
Curso Normal
Acciones de los Actores Respuestas del Sistema
1. Especialista/Enfermera ingresa el RUT del
paciente en el sistema.
2. Sistema obtiene ficha del paciente y muestra
información.
Cursos Alternos
(2a) Si el paciente no existe, lo informa y termina el CU.
Caso de Uso: CU3: Registrar Anamnesis
Actores: Especialista (I), Paciente
Propósito: Registrar la información resultante de la consulta médica.
Resumen: Al terminar la atención médica, el médico tratante ingrese el detalle de la atención
en box incluyendo los procedimientos y medicamentos indicados.
Tipo: Primario y Esencial
Ref. Cruzadas: R1.2, CU7
Curso Normal
Acciones de los Actores Respuestas del Sistema
1. Especialista ingresa el RUT del paciente. 2. Sistema encuentra la ficha médica, abre la
atención médica y solicita información sobre los
datos de la inspección y observaciones al
examen físico.
3. Especialista ingresa datos de peso, talla, presión
arterial, temperatura, etc. y las observaciones si
las hubiera.
4. Sistema registra información de la inspección y
solicita información sobre diagnóstico del
paciente.
5. Especialista ingresa el diagnóstico. 6. Sistema registra el diagnóstico y solicita
información sobre procedimientos,
medicamentos e indicaciones.
7. Especialista ingresa los procedimientos,
medicamentos e indicaciones entregadas al
paciente.
8. Sistema registra información y cierra la atención
médica (CU7).
Cursos Alternos
(2a) Si la ficha no existe, informa al Especialista y termina el CU.
Caso de Uso: CU5: Registrar Resultado de Procedimiento
Actores: Tecnólogo (I)
Propósito: Registrar la información de análisis y diagnóstico del procedimiento realizado.
Resumen: Al analizar una muestra, el tecnólogo debe ingresar los resultados clínicos en la ficha,
así como también el diagnóstico preliminar si procede.
Tipo: Primario y Esencial
Ref. Cruzadas: R1.4
Curso Normal
Acciones de los Actores Respuestas del Sistema
1. Tecnólogo ingresa el RUT del paciente. 2. Sistema encuentra la ficha médica, solicita
información sobre la fecha de la muestra, los
resultados del examen y diagnóstico en caso de
ser necesario.
3. Tecnólogo ingresa datos obtenidos de la
muestra y en caso de que aplique se ingresa el
4. Sistema registra información y cierra la ficha.
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
9
diagnóstico.
Cursos Alternos
(2a) Si la ficha no existe, informa al Tecnólogo y termina el CU.
Caso de Uso: CU7: Actualizar Agenda Médica
Actores: Especialista
Propósito: Enviar un mensaje al Sistema de Agenda Médica (SAM) de cierre de atención.
Resumen: Al cerrar una ficha por atención médica, el sistema debe generar un mensaje al SAM
para informar que el especialista ha dado término a la atención.
Tipo: Primario y Esencial
Ref. Cruzadas: R2.2, CU3
Curso Normal
Acciones de los Actores Respuestas del Sistema
1. Especialista cierra la atención médica (CU3). 2. Sistema registra el cierre de la ficha y envía un
mensaje al SAM indicando el cierre de la
atención.
3. Sistema recibe confirmación de parte del SAM
de que se ha realizado la transacción y termina
el CU.
Cursos Alternos
(3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una
alerta al administrador del sistema, quién debe cursar manualmente el proceso.
En este último CU, en el Curso Alterno (3a) se menciona que debe existir un administrador del sistema. Esto
es porque no se ha mencionado que pasa con la conectividad y comunicación entre ambos sistema (SAM y
SEFP), de modo que ha sido una sugerencia en los requerimientos. Es importante validarlo con el cliente
final antes de cerrar la iteración y utilizar dicha información para el análisis del sistema.
Diagrama de Casos de Uso
Para este caso, el Diagrama de Casos de Uso no es muy simple, ya que incorpora conexiones entre casos de
uso (CU3 y CU7, tal como aparece en su especificación expandida). A continuación se muestra gráficamente
la relación de los actores con los casos de uso especificados.
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
10
GLOSARIO
En esta sección se describen los conceptos más importantes del dominio y que impactan en su
entendimiento.
Término Definición
Ficha Médica Registro electrónico (en este caso) en donde queda almacenada toda la historia
médica de un paciente.
Registro Proceso a través del cual se guarda la información ingresada por un usuario.
Box Espacio físico donde se realiza la anamnesis.
Anamnesis Proceso de revisión que realiza un especialista en un box de atención a un
paciente.
Datos de la
Inspección
Información que resulta de un examen físico realizado por un especialista en un
box de atención (peso, talla, temperatura y presión arterial).
Diagnóstico Inferencia que realiza el especialista como resultado del examen físico.
Procedimiento Cualquier tipo de examen físico o psicológico que puede solicitar el especialista.
Agenda Médica
(SAM)
Sistema externo necesario para registrar cuando un especialista cierra una
atención médica.
Este glosario resumido (ya que podríamos encontrar muchos más términos para este problema) solo
muestra un ejemplo de cómo van describiéndose las diferentes definiciones de, en este caso, los conceptos
del dominio.
System
Recepcionista
Especialista
Tecnólogo
Enfermera
Agenda Médica
CU1: Registrar Paciente
CU3: Registrar Anamnesis
CU7: Actualizar SAM
CU6: Generar Traslado
CU5: Registrar Resultados
CU4: Registrar Observaciones
CU2: Consultar Ficha
<<include>>
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
11
MODELO DE DOMINIO
En esta sección se describen los artefactos que muestran la visión de negocio y el contexto en el cual se
desarrollará el sistema.
Diagrama de Actividades
El enfoque que utilizaremos será el ver el diagrama de actividades global a partir de las transiciones que
tiene la ficha de un paciente desde su generación y su uso posterior.
De esta manera, el diagrama nos muestra los diferentes “carriles-de-nado” para los actores y entidades que
utilizan la ficha o realizan actividades como resultado del uso de la ficha. Así, el diagrama comienza por el
recepcionista (ya sea en el laboratorio como en la consulta médica) el cual registra la información básica de
la ficha (crear).
A continuación hemos indicado un conector de decisión para diferenciar si el siguiente flujo (por consulta
médica o por procedimiento). De esta manera diferenciamos el paso dependiendo del actor principal. Cada
uno de esos flujos termina en un conector con una X de manera de que podamos volver al flujo principal en
la decisión para el siguiente flujo.
Finalmente, notaremos que no tiene una actividad de término, ya que la ficha no se destruye en el dominio,
sino que una vez que el paciente ingresa al esquema, se mantendrá desde ese momento en adelante.
Los procesos se describen de la siguiente forma:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
12
Diagrama de Clases Conceptuales
Lo que vamos a realizar es utilizar ambos métodos de identificación de clases conceptuales para luego ir
dibujando el diagrama general. Veamos primero entonces la lista de categorías:
Categoría de Clase Conceptual Ejemplos
Objetos tangibles o físicos InformeDeDerivacion
Especificaciones, diseños o descripciones de las cosas DetalleDeInforme ResultadoProcedimiento DetalleAnamnesis
Lugares CentroMedico Recepción ConsultaMedica BoxDeProcedimiento
Líneas de la transacción Anamnesis Procedimiento
Roles de la gente Recepcionista Especialista Laboratorista Paciente
Contenedores de otras cosas -
Cosas en un contenedor -
Otros sistemas externos AgendaMedica
Recepcionista Especialista LaboratoristaSistema de Agenda Médica
Crear Ficha de Paciente
[paciente ingresa al centro]
Ver Ficha de Paciente
[paciente entra a consulta]
Ver Ficha de Paciente
[paciente entra a toma de muestra]
Realizar la Consulta
Registrar la Anámnesis
Registrar Término de Atención
Imprimir Informe Médico
[derivación a centro asistencial]
[no hay derivación]
Realizar el Procedimiento
Registrar Observaciones
Realizar Análisis
Registrar Resultados
[hay observaciones]
[no hay observaciones]
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
13
Categoría de Clase Conceptual Ejemplos
Conceptos abstractos Anamnesis Procedimiento FichaDePaciente
Organizaciones -
Hechos -
Procesos Anamnesis Procedimiento
Reglas y políticas -
Catálogos RegistroDeFichas
Registro de finanzas, trabajo, contratos, asuntos legales -
Instrumentos y servicios financieros -
Manuales, documentos, artículos de referencia, libros InformeDeDerivacion
Note que aparecen las mismas clases en varias categorías. Veamos ahora las frases nominales de los
escenarios de casos de uso:
Caso de Uso: CU1: Registrar Paciente
Curso Normal
Acciones de los Actores Respuestas del Sistema
9. Paciente llega al mesón de atención y entrega
su RUT.
10. Recepcionista ingresa RUT en el sistema para
confirmar que es nuevo.
11. Sistema confirma que el paciente es nuevo y
solicita información básica.
12. Recepcionista solicita al paciente información.
13. Paciente entrega a Recepcionista información
solicitada.
14. Recepcionista ingresa la información en el
sistema.
15. Sistema registra la información y crea la ficha
electrónica informando acción.
16. Recepcionista entrega RUT al Paciente.
Cursos Alternos
(3a) Si el paciente ya existe, informa al Recepcionista y termina el CU.
(7a) Si el RUT ya está registrado con otra información, alerta al Recepcionista y solicita confirmación para
actualizar información.
Caso de Uso: CU2: Consultar Historial
Curso Normal
Acciones de los Actores Respuestas del Sistema
3. Especialista/Enfermera ingresa el RUT del
paciente en el sistema.
4. Sistema obtiene ficha del paciente y muestra
información.
Cursos Alternos
(2a) Si el paciente no existe, lo informa y termina el CU.
Caso de Uso: CU3: Registrar Anamnesis
Curso Normal
Acciones de los Actores Respuestas del Sistema
9. Especialista ingresa el RUT del paciente. 10. Sistema encuentra la ficha médica, abre la
atención médica y solicita información sobre los
datos de la inspección y observaciones al
examen físico.
11. Especialista ingresa datos de peso, talla, presión
arterial, temperatura, etc. y las observaciones si
12. Sistema registra información de la inspección y
solicita información sobre diagnóstico del
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
14
las hubiera. paciente.
13. Especialista ingresa el diagnóstico. 14. Sistema registra el diagnóstico y solicita
información sobre procedimientos,
medicamentos e indicaciones.
15. Especialista ingresa los procedimientos,
medicamentos e indicaciones entregadas al
paciente.
16. Sistema registra información y cierra la atención
médica (CU7).
Cursos Alternos
(2a) Si la ficha no existe, informa al Especialista y termina el CU.
Caso de Uso: CU5: Registrar Resultado de Procedimiento
Curso Normal
Acciones de los Actores Respuestas del Sistema
5. Tecnólogo ingresa el RUT del paciente. 6. Sistema encuentra la ficha médica, solicita
información sobre la fecha de la muestra, los
resultados del examen y diagnóstico en caso de
ser necesario.
7. Tecnólogo ingresa datos obtenidos de la
muestra y en caso de que aplique se ingresa el
diagnóstico.
8. Sistema registra información y cierra la ficha.
Cursos Alternos
(2a) Si la ficha no existe, informa al Tecnólogo y termina el CU.
Caso de Uso: CU7: Actualizar Agenda Médica
Curso Normal
Acciones de los Actores Respuestas del Sistema
4. Especialista cierra la atención médica (CU3). 5. Sistema registra el cierre de la ficha y envía un
mensaje al SAM indicando el cierre de la
atención.
6. Sistema recibe confirmación de parte del SAM
de que se ha realizado la transacción y termina
el CU.
Cursos Alternos
(3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una
alerta al administrador del sistema, quién debe cursar manualmente el proceso.
Como podemos ver, en los diferentes escenarios encontramos un lenguaje mixto, en donde nos podemos
referir de diferentes formas a los mismo conceptos, por lo que es importante no solo tomar lo que dice, sino
que formalizar también el concepto como tal, ya que en el diagrama de clases conceptuales es donde debe
quedar finalmente el concepto que será utilizado finalmente en el sistema.
El dominio se observa en el siguiente diagrama:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
15
Este diagrama puede ser la primera aproximación para el futuro diseño de clases y por supuesto un insumo
importante para los siguientes artefactos y modelos de análisis y diseño.
MODELO DE COMPORTAMIENTO
En esta sección se describen los artefactos que describen el comportamiento del sistema.
Diagramas de Secuencia
Para especificar los diagramas de secuencia es importante hacerlos a través de los escenarios encontrados
en los casos de uso. Según lo expuesto en este problema, los escenarios alternos son sencillos, así que,
donde corresponda, se utilizarán los cursos alternos como parte del mismo diagrama.
Veamos el escenario del primer caso de uso:
Paciente
EspecialistaLaboratorista
Recepcionista
FichaDePaciente
Procedimiento Anamnesis
DetalleProcedimiento
+observaciones+resultados+diagnostico
DetalleAnamnesis
+datos_inspeccion+observaciones+indicaciones+otros
posee1
1
contiene
0..*
1
+cotiene
0..*
1
es-descrita-por
1
1
es-descrita-por
1
1
crea
0..1
1
ingresa
0..1
1
ingresa
0..1
1
DetalleDeFicha
+rut+nombre+direccion+telefono+email
es-descrita-por
1 1
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
16
Es posible observar en este diagrama que gran parte de la carga se la estaría llevando el objeto
DetalleDeFicha (adelantándonos para cuando lleguemos a los diagramas de estado). Sigamos con los demás
CU y sus respectivos diagramas:
Al igual que en el caso anterior, este diagrama no es más que una traducción del escenario realizado para el
CU. Veamos el siguiente:
: Recepcionista Sistema CatalogoDePacientes
: DetalleDeFicha
1 : validarRut()2 : pacienteExiste()
3 : ack
4
5 : ingresarDetalle()6 : nuevo()
78 : asociarDetalle()
910
Funcionario Sistema CatalogoDePacientes
1 : consultar()2 : buscar()
3
4
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
17
En este caso podemos ver que se complejiza un poco la lógica, sin embargo debemos destacar un par de
puntos.
1. Resumimos los 3 ingresos que existen en el escenario en 1 sola operación (con la lógica de que la
filla se llena sin registrar la información hasta el final).
2. La creación del objeto DetalleAnamnesis es porque según el modelo de dominio, DetalleDeFicha
solo sabe registrar DetalleAnamnesis a través de una Anamnesis (la cual puede ser generad dentro
de DetalleFicha como una línea de transacción).
3. Las operaciónes de consultar, en realidad es la misma utilizada en el CU2.
Sigamos con el siguiente CU:
: Especialista Sistema CatalogoDePacientes d : DetalleDeFicha
: DetalleAnamnesis
1 : consultar()
2 : buscar()
3 : d4
5 : registrarInformación()6 : crear()
7 : det
8 : registrarAnamnesis()
910
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
18
En este caso vemos una similitud muy obvia con el CU3, tanto así que a estas alturas podríamos
“generalizarlo” de manera de que sea más reutilizable. Sin embargo, para efectos prácticos, sigamos con el
análisis tal cual.
En el último CU analizado solo tenemos el hecho del cierre de la atención médica y en este caso son
operaciones hacia fuera del sistema, así que es poca la interacción.
Con estos diagramas completamos el análisis del comportamiento a través de las secuencias, y pasaremos a
ver los contratos.
Contratos de las Operaciones
Una vez que ya se han realizado todos los diagramas de secuencia, se debe comenzar identificado cuáles son
las operaciones principales para luego ir describiéndolas a través de la estructura planteada para los
contratos. Veamos entonces los contratos del problema.
: Laboratorista Sistema CatalogoDePacientes d : DetalleDeFicha
: DetalleProcedimiento
1 : consultar()2 : buscar()
3 : d
4
5 : registrarInformacion()6 : crear()
7 : det
8 : registrarProcedimiento()
910
: Especialista Sistema AgendaMedica
1 : cerrarAtención()
2 : cierreFicha()
3 : ack4
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
19
Operación: CO1. validarRut(rut)
Responsabilidad: Validar que el RUT exista dentro del catalogo de pacientes
Tipo o Clase: Sistema
Ref. Cruzadas: CU1
Notas: -
Excepciones: Si el RUT existe, se aborta el resto del CU
Salidas: -
Precondiciones - Exista una instancia r de tipo CatalogoDePacientes
Postcondiciones: - No se haya encontrado una instancia f de FichaDePaciente
dentro de r que tenga asociada una instancia d de
DetalleDeFicha que tenga como atributo rut el valor del
parámetro rut.
Operación: CO2. ingresarDetalle(rut, nombre, direccion, fono, email)
Responsabilidad: Crear y agregar la información básica del paciente a la ficha
Tipo o Clase: Sistema
Ref. Cruzadas: CU1
Notas: -
Excepciones: -
Salidas: -
Precondiciones -
Postcondiciones: - Se haya creado una instancia d de tipo DetalleDeFicha
- Se hayan fijado los atributos rut, nombre, dirección,
teléfono e email con los valores entregados por parámetro.
- Se haya creado una instancia f de tipo FichaDePaciente
- Se haya asociado d a f
Operación: CO3. consultar(rut)
Responsabilidad: Obtiene la información de la ficha del paciente a partir del
rut ingresado.
Tipo o Clase: Sistema
Ref. Cruzadas: CU2, CU3, CU5
Notas: -
Excepciones: Si la ficha no existe, devuelve un valor nulo.
Salidas: -
Precondiciones - Exista una instancia r de CatalogoDePacientes
Postcondiciones: - Se haya encontrado una instancia p de DetalleDePaciente
cuyo atributo rut sea igual al valor del parámetros rut.
Operación: CO4. registrarInformacion(objeto)
Responsabilidad: Registra en la ficha del paciente la información entregada en
forma de objeto.
Tipo o Clase: Sistema
Ref. Cruzadas: CU3, CU5
Notas: Objeto puede tomar valores de DetalleAnamnesis y
DetalleProcedimiento
Excepciones: -
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
20
Salidas: -
Precondiciones - Exiasta una instancia d de DetalleDePaciente
Postcondiciones: - Se haya asociado objeto a d.
Operación: CO5. cerrarAtencion(especialista)
Responsabilidad: Envía una notificación al sistema de agenda médica
indicando el térmido de la atención del especialista.
Tipo o Clase: Sistema
Ref. Cruzadas: CU7
Notas: Utiliza XML para construir la llamada al SAM.
Excepciones: -
Salidas: Un mensaje intersistemas para el SAM
Precondiciones -
Postcondiciones: -
Como podemos ver en los contratos expuestos, se hicieron varias optimizaciones en las operaciones,
generalizando las que habíamos originalmente encontrado en los diagramas. Esto permitirá un menor riesgo
desde el punto de vista del diseño e implementación futura.
Diagramas de Estado
Como última parte del análisis vamos a realizar algunos diagramas de estados que nos permiten identificar
los cabios de estado de los objetos principales.
En particular, uno de los objetos que sufre cambios es la instancia de FichaDePaciente que representa a un
paciente particular. Veamos cómo queda el diagrama de estados en este caso (considerando todos los
contratos del modelo).
Como podemos ver en el diagrama, los estados en realidad son pocos, ya que no pasa por muchos cambios
(solo se ven las asociaciones dadas por los contratos).
Es importante hacer notar que, a pesar de que este sea una visión del análisis del comportamiento no
necesariamente es la única. Esto es muy importante desde el punto de vista del problema final, ya que si la
consistencia es buena, no requiere mayor perfeccionamiento.
Disponible
entry/fijarDetalleDePaciente
nuevo
En Llenado
do/asociarDetalle
[es atendido]
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
21
DISEÑO DEL SISTEMA
MODELO ARQUITECTÓNICO
En esta sección se describen las decisiones de la arquitectura que afectan a la organización de los programas
finales.
Diagrama de Componentes
La primera premisa para nuestro diagrama es que separaremos las capas de interfaz gráfica de las
funcionales (negocio) y operativa, es decir, utilizaremos un modelo de 3 capas de diseño arquitectónico.
La capa funcional estará compuesta de 3 componentes básicos y que son separados por su naturaleza:
Gestión de la Ficha (creación y consulta de la ficha de un paciente)
Gestión de la Consulta Médica (ingreso de anamnesis)
Gestión de los Procedimientos (ingreso de observaciones y resultados)
Ahora bien, tanto la capa Consulta Médica como la capa Procedimiento requieren trabajar con la ficha, por
lo que también existirán algunas dependencias entre ellas:
Como podemos ver, las interfaces que exponemos para la comunicación entre los paquetes nos definen
algunas operaciones que se realizarán en los diagramas de colaboración. De esta manera, estamos
obligando que las clases las debamos discriminar de acuerdo a la naturaleza del componente:
Ficha: Todas las clases que operen con la ficha.
Consulta Médica: Todas las clases que operen con la anamnesis.
Procedimiento: Todas las clases que operen con los procedimientos.
Es fácil ver que el centro del negocio está en las clases que controlan las fichas de los pacientes y que el
resto en realidad no es tan relevante como habíamos pensado, por lo que nos sugiere que en realidad no
necesitamos tantos componentes, sino que solo uno principal y que contenga todas las operaciones del
sistema con la ficha, sin embargo, para el ejemplo, mantendremos la consistencia con el diseño realizado y
seguiremos manteniéndolo por separado.
Lo que nos queda ahora es exponer los servicios que van hacia la interfaz gráfica y completar el diagrama
con la capa completa:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
22
Las operaciones expuestas en la capa funcional (que particularmente son solo las de sistema) no son para
que las use el usuario final directamente, sino que para que sean gatilladas a partir de la interfaz. De esta
manera, podríamos (y optimizando el diagrama anterior) organizar el sistema de la siguiente manera:
Lo que finalmente describimos es una componente gráfica por lugar donde funcionará el sistema y
relacionamos con qué servicio expuesto se comunican dichas componentes directamente. Así podemos
discriminar cómo organizar también los programas de la interfaz gráfica fácilmente.
Por último, debemos también comunicarnos con la capa de datos, la cual es la que gestiona las tablas de la
base de datos y muestra los servicios expuestos necesarios para trabajar con la capa funcional. Este sería
entonces el diagrama final de componentes del sistema:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
23
Como podemos notar, el Registro de Fichas es una componente que representa la interacción con la base de
datos directamente. De esta manera, cuando se desea, por ejemplo, realizar una búsqueda de una ficha por
el rut, es necesario que se obtenga la ficha desde la base (a través de un select de la tabla respectiva).
En particular, solo se exponen 2 servicios básicos que son “consultar” y “registrar” (similar a un select y un
update en SQL), los cuales son consumidos solo por la componente de Ficha.
MODELO DE DISEÑO
En esta sección se describe en detalle el diseño del sistema a partir de las operaciones de éste y
completando con una vision técnica de las clases de diseño.
Diagramas de Colaboración
Los diagramas de colaboración realizan las interacciones necesarias para que lo objetos colaboren bajo el
objetivo de cumplir las operaciones de cada caso de uso.
Operación: CO1. validarRut(rut)
Responsabilidad: Validar que el RUT exista dentro del catalogo de pacientes
Tipo o Clase: Sistema
Ref. Cruzadas: CU1
Notas: -
Excepciones: Si el RUT existe, se aborta el resto del CU
Salidas: -
Precondiciones - Exista una instancia r de tipo CatalogoDePacientes
Postcondiciones: - No se haya encontrado una instancia f de FichaDePaciente
dentro de r que tenga asociada una instancia d de
DetalleDeFicha que tenga como atributo rut el valor del
parámetro rut.
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
24
Lo primero que debemos buscar en este caso es qué objeto debe ser el controlador de la operación. Es fácil
ver que como no tuvimos nunca una clase que represente nada físico del sistema, siempre utilizamos
“Sistema” como tal. Así que, como estamos hablando de aplicar el patrón, deberemos decidir si:
Lo utilizamos como un controlador general del sistema (SistemaControlador, por ejemplo).
Lo utilizamos como un controlador modular (RegistroControlador, por ejemplo).
Para que podamos probar los controladores modulares, en este caso elegiremos la segunda opción. Además,
que el ejemplo es bastante “bueno” para que podamos separar las funciones en cada ámbito de la atención
médica.
Si seguimos aplicando otros patrones, por ejemplo, para validar el rut debemos identificar de quién es la
responsabilidad de conocer o mantener conocimiento de las fichas de los pacientes. Con el patrón de
experto podemos determinar que ese es el CatálogoDePacientes, que ya teníamos identificado
anteriormente. Por último, sabiendo que el experto de información de conocer el rut de un paciente es
DetalleDeFicha, y aplicando el patrón de cadena de responsabilidad (de GoF), podemos llevar la
responsabilidad desde el controlador hasta el mismo objeto para entregar el valor del rut pidiéndole a
CatalogoDePacientes, luego a FichaDePaciente y que realice la validación si existe una ficha (esperamos
respuesta negativa por supuesto).
De esta manera, el primer diagrama de colaboración quedaría como sigue:
De una forma análoga, podemos revisar el segundo contrato:
Operación: CO2. ingresarDetalle(rut, nombre, direccion, fono, email)
Responsabilidad: Crear y agregar la información básica del paciente a la ficha
Tipo o Clase: Sistema
Ref. Cruzadas: CU1
Notas: -
Excepciones: -
Salidas: -
Precondiciones -
Postcondiciones: - Se haya creado una instancia d de tipo DetalleDeFicha
- Se hayan fijado los atributos rut, nombre, dirección,
teléfono e email con los valores entregados por parámetro.
- Se haya creado una instancia f de tipo FichaDePaciente
- Se haya asociado d a f
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
25
Es fácil ver que debemos primero buscar si el anterior controlar de las operaciones aplica en ésta, y la
respuesta es sí, porque seguimos en el mismo módulo (CU) de registro de paciente.
Por otro lado, como debemos crear un DetalleDeFicha, debemos buscar el mejor creador ese tipo de
objetos. Como sabemos, la clase que usa más estrechamente estos objetos es FichaDePaciente, sin embargo
también es parte del contrato crear un objeto de ese tipo, así que podemos realizar esa creación en cadena,
delegando la responsabilidad al mejor creador de FichaDePaciente, y que se lo podemos entregar de
inmediato al CatalogoDePacientes (ya que él es quien necesitará utilizar esas instancias de aquí en
adelante).
Por último, finalmente necesitamos obtener el experto de la información del detalle del paciente y es
DetalleDeFicha, lo que nos permite mejorar la creación de ese tipo de objetos delegándole toda esa
información a su creador (FichaDePaciente) y permitiendo que la creación se lleve a cabo en una sola
responsabilidad encapsulada.
El diagrama de colaboración quedaría así:
Notemos que en este caso particular, la existencia de la relación con el catálogo no estaba definida en el
contrato, pero la aplicación de los patrones de diseño nos permitió descubrir esta relación. Por otro lado
tampoco aparece en forma explícita el cumplimiento de la postcondición de asociar d a f, pero por la
delegación de la creación quedan asociadas esas instancias.
El siguiente contrato es:
Operación: CO3. consultar(rut)
Responsabilidad: Obtiene la información de la ficha del paciente a partir del
rut ingresado.
Tipo o Clase: Sistema
Ref. Cruzadas: CU2, CU3, CU5
Notas: -
Excepciones: Si la ficha no existe, devuelve un valor nulo.
Salidas: -
Precondiciones - Exista una instancia r de CatalogoDePacientes
Postcondiciones: - Se haya encontrado una instancia p de DetalleDePaciente
cuyo atributo rut sea igual al valor del parámetros rut.
Para buscar el controlador, primero debemos consultarnos si se aplica el anterior. En este caso no lo es,
porque no estamos en el registro de un paciente, pero tampoco estamos en algún CU particular, ya que esta
operación es transversal a los CU2, CU3 y CU5.
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
26
A pesar de ello, como la naturaleza de la operación tiene que ver con obtener la información de la ficha del
paciente, podremos crear un nuevo controlador modular llamado FichaControlador, que permite realizar las
operaciones básicas de consulta o manipulación de la ficha1.
Por otro lado, como estamos buscando una ficha particular, debemos aplicar exactamente la misma idea de
lo aplicado en el CO1. De esta manera, podemos cambiar nuestra primera realización para mejorar y aplicar
este contrato en forma equivalente.
Así, las colaboraciones corregidas para aplicar esta operación también serían:
Por último, la colaboración del CO3 sería:
Como podemos ver, la naturaleza de la operación es la misma, pero la respuesta que se espera es diferente
del controlador. El siguiente contrato es:
Operación: CO4. registrarInformacion(objeto)
Responsabilidad: Registra en la ficha del paciente la información entregada en
forma de objeto.
Tipo o Clase: Sistema
Ref. Cruzadas: CU3, CU5
1 Note que las operaciones anteriormente analizadas también tienen que ver con la ficha, por lo que una
mejora sería juntarlas todas en este mismo controlador, quedando 3 operaciones (CO1, CO2 y CO3).
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
27
Notas: Objeto puede tomar valores de DetalleAnamnesis y
DetalleProcedimiento
Excepciones: -
Salidas: -
Precondiciones - Exiasta una instancia d de DetalleDePaciente
Postcondiciones: - Se haya asociado objeto a d.
Primero, esto tiene diferentes matices, ya que está siendo generalizada una operación que no tendrían el
mismo controlador, así que serían vistas en forma diferente (como 2 contratos aparte).
De esta forma, el primero será recibido por ConsultaControlador, el cual manejará las operaciones realizadas
por el especialista en la consulta médica. La otra será gestionada por ProcedimientoControlador, que tiene
que ver más con las operaciones realizadas durante un procedimiento médico.
Ahora si comenzamos a ver el primer caso como registrarAnamnesis(…) tendremos el detalle necesario para
aplicar los patrones de creador y experto que nos lleve al primer diagrama de colaboración:
De una manera análoga podemos realizar la operación respecto al registro del procedimiento quedando el
diagrama de la siguiente forma:
Lo relevante de este análisis, es que como el detalle necesario es por cada una de las clases, es necesario
que hayamos separados las operaciones para cada caso, ya que, tal como vimos en clase, se convertirán en
los métodos de cada una de las clases (y las clases destino son las mismas).
Por último, veamos el último contrato del dominio:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
28
Operación: CO5. cerrarAtencion(especialista)
Responsabilidad: Envía una notificación al sistema de agenda médica
indicando el término de la atención del especialista.
Tipo o Clase: Sistema
Ref. Cruzadas: CU7
Notas: Utiliza XML para construir la llamada al SAM.
Excepciones: -
Salidas: Un mensaje intersistemas para el SAM
Precondiciones -
Postcondiciones: -
Como podemos ver, esta operación tiene que ver con la consulta médica (y de hecho es una operación de
secundaria, ya que es una notificación). Sin embargo, este contrato no aporta información al sistema como
tal, porque solo elabora un mensaje a un sistema externo, lo que no se ve reflejado en las postcondiciones.
Diagrama de Clases de Diseño
Una vez analizado por completo las operaciones del sistema, podemos plantear paso a paso el diagrama de
clases de diseño. Veamos cómo va quedando:
Con un simple paso por los diagramas de colaboración, podemos identificar las siguientes clases:
En el diagrama, además pusimos desde ya los atributos que vienen desde el diagrama de clases
conceptuales, ya que a priori sabemos que esos valores se mantendrán para el diseño.
El siguiente paso es completar con la información de los tipos de datos de los atributos y sus visibilidades
correctas:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
29
Es fácil detectar que la información almacenada es mayormente de texto, ya que todos los datos generados
por los especialistas médicos son de ese tipo.
Siguiendo con las definiciones aprendidas en la técnica de creación del diagrama de clases de diseño,
podemos obtener ahora los métodos de cada una de las clases a partir de los diagramas de colaboración
dibujados en la sección anterior. Así, podemos asociar los siguientes métodos encontrados a las siguientes
clases:
FichaControlador: validarRut, ingresarDetalle, consultar.
ConsultaControlador: registrarAnamnesis.
ProcedimientoControlador: registrarProcedimiento.
CatalogoDePacientes: buscar, crearFichaDePaciente.
FichaDePaciente: consultarRut, crear, crearAnamnesis, crearProcedimiento.
DetalleDeFicha: getRut, crear.
Anamnesis: crear.
DetalleDeAnamnesis: crear
Procedimiento: crear
DetalleDeProcedimiento: crear
De esta manera, el diagrama quedaría de la siguiente forma detallado:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
30
El paso siguiente es incorporar las asociaciones de acuerdo a la cercanía de las clases del diagrama. Esto es
bastante rápido de identificar porque basta con responder cualquiera de las 3 situaciones indicadas
anteriormente:
A es un creador de objetos de tipo B
A agrega objetos de tipo B
A necesita mantener conocimiento de los objetos de tipo B
De esta manera, el diagrama que estamos completando pasaría a ser de la siguiente forma:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
31
Como podemos ver incorporamos también el concepto de composición en varias de esas asociaciones, por
el hecho de ser creadores de otros objetos.
Observemos por un momento la relación entre Procedimiento – DetalleDeProcedimiento y Anamnesis –
DetalleDeAnamnesis. Podemos notar una semejanza con la caja del supermercado, porque en este caso
Procedimiento y Anamnesis están jugando el papel de “línea de venta”, por lo que es posible resumir esa
sobrecarga de clases (ya que ambas hacen lo mismo) en una sola que permita almacenar ambos tipos de
registros.
Para hacer esto, y aprovechar de utilizar la generalización en el diagrama, incorporaremos la clase
RegistroDeFicha (que reemplazará Procedimiento y Anamnesis como “línea de venta”) y una clase
DetalleDeRegistro que será la superclase que incorporará ambos tipos de registros.
Además, si vemos la forma en que se comportan las operaciones de las clases, podemos notar que no
existen dependencias, por lo que no debemos incorporar más detalle y podemos mostrar finalmente el
siguiente diagrama de clases de diseño como una primera versión de nuestro SEFP:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
32
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
33
PREPARANDO LA IMPLEMENTACIÓN
MODELO DE IMPLEMENTACIÓN
En esta sección se describen las labores de preparación de la codificación.
Diagrama de Clases de Implementación
Describiremos el diagrama de clases de implementación, utilizando el DCD de la unidad anterior. Para ello
entonces pasaremos por los pasos básicos indicados en la técnica de desarrollo del modelo respectivo.
Primero, comencemos normalizando los tipos de datos al lenguaje elegido (Java). El diagrama de clases
quedaría algo parecido a lo siguiente:
Luego de realizado esto, se van describiendo las clases a través de anotaciones en el diagrama considerando
no solo los atributos explícitos, sino que también operaciones complejas y atributos de asociación.
Para el caso de las asociaciones múltiples que existen en este diagrama, vamos a utilizar una estructura
Vector de objetos para que vaya acumulando los objetos del tipo de destino sin necesidad de conocer el
número de elementos que finalmente vamos a registrar.
De esta manera, tendremos un diagram parecido a este:
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
34
El siguiente paso (que aparece en la técnica vista en este capítulo) indica incorporar lógica de programación
en el diagrama, sin embargo, dada la complejidad de éste, vamos a optar por escribir el código (estructura
de clases) a partir de lo ya obtenido, y luego incorporar lógica programática.
Estructura de Clases
La estructura obtenida corresponde a las clases, con sus atributos y las firmas de todos los métodos
identificados. Sin embargo, vamos a aprovechar de incorporar lógica en los métodos de las clases según
corresponda.
A continuación el listado de las clases desde la menos acoplada a las más acoplada:
public class DetalleDeAnamnesis {
private String datos_inspeccion;
private String observaciones;
private String indicaciones;
private String otros;
public DetalleDeAnamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
this.setDatos_Inspeccion(inspeccion);
this.setObservaciones(observaciones);
this.setIndicaciones(indicaciones);
this.setOtros(otros);
}
private void setDatos_Inspeccion(String inspeccion) {
this.datos_inspeccion = inspeccion;
}
private void setObservaciones(String observaciones) {
this.observaciones = observaciones;
}
private void setIndicaciones(String indicaciones) {
this.indicaciones = indicaciones;
}
private void setOtros(String otros) {
this.otros = otros;
}
}
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
35
public class DetalleDeProcedimiento {
private String observaciones;
private String resultados;
private String diagnostico;
public DetalleDeProcedimiento(String observaciones, String resultados,
String diagnostico) {
this.setObservaciones(observaciones);
this.setResultados(resultados);
this.setDiagnostico(diagnostico);
}
private void setObservaciones(String observaciones) {
this.observaciones = observaciones;
}
private void setResultados(String resultados) {
this.resultados = resultados;
}
private void setDiagnostico(String diagnostico) {
this.diagnostico = diagnostico;
}
}
public class DetalleDeFicha{
private int rut;
private String nombre;
private String direccion;
private String fono;
private String email;
public DetalleDeFicha (int rut, String nombre, String direccion,
String fono, String email) {
this.setRut(rut);
this.setNombre(nombre);
this.setDireccion(direccion);
this.setFono(fono);
this.setEmail(email);
}
public int getRut() {
return this.rut;
}
private void setRut(int rut) {
this.rut = rut;
}
private void setNombre(String nombre) {
this.nombre = nombre;
}
private void setDireccion(String direccion) {
this.direccion = direccion;
}
private void setFono(String fono) {
this.fono = fono;
}
private void setEmail(String email) {
this.email = email;
}
}
public class Procedimiento {
private DetalleDeProcedimiento detalle;
public Procedimiento(String observaciones, String resultados,
String diagnostico) {
this.detalle = new DetalleDeProcedimiento(observaciones,
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
36
resultados, diagnostico);
}
}
public class Anamnesis {
private DetalleDeAnamnesis detalle;
public Anamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
this.detalle = new DetalleDeAnamnesis(inspeccion, observaciones,
indicaciones, otros);
}
}
public class FichaDePaciente {
private DetalleDeFicha detalle;
private Vector procedimientos;
private Vector anamnesis;
public FichaDePaciente(int rut, String nombre, String direccion,
String fono, String email) {
this.detalle = new DetalleDePaciente(rut, nombre, direccion,
fono, email);
}
public DetalleDePaciente consultarRut(int rut) {
return this.detalle;
}
public void crearAnamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
Anamnesis anam = new Anamnesis(inspeccion, observaciones,
indicaciones, otros);
this.anamnesis.addElement(anam);
}
public void crearProcedimiento(String observaciones, String resultados,
String diagnostico) {
Procedimiento proc = new Procedimiento(observaciones,
resultados, diagnostico);
this.procedimientos.addElement(proc);
}
}
public class CatalogoDePacientes {
private Vector fichas;
public FichaDePaciente buscar(int rut) {
for(int i=0; i<this.fichas.size(); i++) {
if (this.fichas.elementAt(i).getRut() == rut)
return this.fichas.elementAt(i);
}
}
public void crearFichaDePaciente(int rut, String nombre,
String direccion, String fono, String email) {
FichaDePaciente ficha = new FichaDePaciente(rut, nombre,
direccion, fono, email);
this.fichas.addElement(ficha);
}
}
public class ConsultaControlador {
private FichaDePaciente paciente;
public void registrarAnamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
this.paciente.crearAnamnesis(inspeccion, observaciones,
indicaciones, otros);
ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB
37
}
}
public class ProcedimientoControlador {
private FichaDePaciente paciente;
public void registrarProcedimiento(String observaciones,
String restultados, String diagnostico) {
this.paciente.crearProcedimiento(observaciones, resultados,
diagnostico);
}
}
public class FichaControlador {
private CatalogoDePacientes fichas;
public void validarRut(int rut) {
FichaDePaciente f = this.fichas.buscar(rut);
}
public void ingresarDetalle(int rut, String nombre, String direccion,
String fono, String email) {
this.fichas.crearFichaDePaciente(rut, nombre, direccion,
fono, email);
}
public void consultar(int rut) {
FichaDePaciente f = this.fichas.buscar(rut);
}
}