SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP)

CASO DE ESTUDIO: CENTRO MDICO DE ESPECIALIDADES Y LABORATORIOS CLNICOS

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

TABLA DE CONTENIDO
Situacin Actual ..................................................................................................................................... 3 Anlisis del Sistema ............................................................................................................................... 4 Especificacin de Requisitos ........................................................................................................................... 4 Identificacin Del Sistema ......................................................................................................................... 4 Especificacin De Funciones ...................................................................................................................... 4 Modelo de Casos de Uso ................................................................................................................................ 5 Especificacin 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 Diseo del Sistema............................................................................................................................... 21 Modelo Arquitectnico ................................................................................................................................ 21 Diagrama de Componentes ..................................................................................................................... 21 Modelo de Diseo ........................................................................................................................................ 23 Diagramas de Colaboracin ..................................................................................................................... 23 Diagrama de Clases de Diseo ................................................................................................................. 28 Preparando la Implementacin............................................................................................................ 33 Modelo de Implementacin ......................................................................................................................... 33 Diagrama de Clases de Implementacin ................................................................................................. 33 Estructura de Clases................................................................................................................................. 34

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

SITUACIN ACTUAL
El Centro Mdico de Especialidades y Laboratorios Clnicos, CEMELAB, es un servicio que de atencin mdica (consultas) de diferentes especialidades y laboratorio para diferentes exmenes mdicos a lo largo de todo el pas. CEMELAB posee convenio con casi todas las ISAPRES lo que la hace una excelente alternativa. El gerente general ha decidido desarrollar un sistema electrnico de fichas mdicas 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 electrnica est reemplazando al sistema actual de fichas de atencin que tiene cada centro. Para el diseo del SEFP se ha contratado a su consultora, la cual ha realizado una primera entrevista obteniendo una descripcin aproximada del proceso y ciclo de vida de la ficha en cuestin. Esta informacin incluye la siguiente: 1) Cuando un paciente nuevo llega a cualquier centro, se le crea una nueva ficha mdica, la cual debe ser completada con la informacin bsica del individuo (nombre completo, rut, direccin, telfono de contacto y correo electrnico si tuviera). Estos datos deben ser ingresados en la recepcin correspondiente (ya sea en el laboratorio como en la recepcin de atencin mdica). 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 travs del terminal ubicado en cada box de atencin. 3) Una vez que ha terminado la atencin del especialista, ste debe llenar con la anamnesis realizada en la entrevista y posterior anlisis realizado. Esta informacin debe incluir fecha de la atencin, datos de la inspeccin (peso, talla, IMC, temperatura y presin arterial), observaciones del examen fsico obtenido, diagnstico e indicaciones (alimentaria y conductual, medicamentos y/o procedimientos clnicos, derivaciones u hospitalizacin). 4) Adems, en cada atencin, el SEFP debe conectarse con un servicio web de la Agenda Mdica para informar cuando se realizan las atenciones de los especialistas, de manera de llevar el control y poder cancelar los honorarios mdicos respectivos. 5) Algo similar pasa cuando un paciente va a laboratorio por un procedimiento. En este caso el tecnlogo mdico o enfermera podr ver la informacin referente a la ltima entrevista con especialista o aquella que le deriv a dicho procedimiento. As mismo, deber ingresar cualquier observacin y los resultados obtenidos en el procedimiento (ya sea in situ o posterior anlisis de los resultados). 6) En caso de ser derivado a un centro asistencial para hospitalizacin, el especialista que lo deriva podr imprimir un informe mdico que deber presentar en el hospital o clnica que asista para que lleve toda la informacin de manera ms expedita. 7) El SEFP no debe realizar cobros por bonos o servicios prestados, ni tampoco el control de remuneraciones y honorarios mdicos del personal.

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

ANLISIS DEL SISTEMA ESPECIFICACIN DE REQUISITOS

En esta seccin se describe la visin funcional del sistema a la luz de los requerimientos expresados por el cliente final.

Identificacin Del Sistema

El sistema se describe de la siguiente forma:
Nombre del Sistema: Panorama: Clientes: Metas: Sistema Electrnico de Fichas de Paciente (SEFP) CEMELAB, a travs de sus centros mdicos y laboratorios a lo largo del pas Recepcionistas, Mdicos y Laboratoristas Crear un sistema de registro electrnico de fichas nicas de pacientes del centro para: Centralizar la informacin mdica de cada paciente registrado en el centro Mantener la informacin en lnea de manera de que cualquier especialista pueda consultarla en forma oportuna Entregar la informacin requerida al paciente en caso de hospitalizacin y/o traslado a otro centro de atencin.

Especificacin De Funciones
En un anlisis simple, podemos obtener que los requerimientos 1 al 6 son del tipo funcional y el nmero 7 es una restriccin del sistema. Por otro lado, el requerimientos 4 tiene una componente de interoperatividad con el sistema de agendamiento mdico. La especificacin funcional del sistema se detalla a travs de las siguientes funciones:
# Ref: Funcin: Descripcin: Categora: Atributo R1.1 Registro de un Paciente El sistema debe permitir el registro de un paciente con los datos bsicos de ste (nombre completo, rut, direccin, telfono de contacto y correo electrnico). Evidente Detalles y Restricciones Categora

# Ref: Funcin: Descripcin: Categora: Atributo

R1.2 Registro de Anamnesis El sistema debe permitir que el mdico tratante ingrese el detalle de la atencin en box incluyendo los procedimientos y medicamentos indicados. Evidente Detalles y Restricciones Categora

# Ref: Funcin: Descripcin:

R1.3 Registro de Observaciones en un Procedimiento El sistema debe permitir que la enfermera o mdico a cargo ingrese las observaciones durante el procedimiento mdico de un paciente.

ANLISIS Y DISEO
Categora: Atributo

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Evidente Detalles y Restricciones Categora

# Ref: Funcin: Descripcin: Categora: Atributo

R1.4 Registro de Resultados de un Procedimiento El sistema debe permitir que el tecnlogo mdico ingrese los resultados y las inferencias segn sea el caso de los procedimientos realizados por el paciente. Evidente Detalles y Restricciones Categora

# Ref: Funcin: Descripcin: Categora: Atributo Informacin Segmentada

R2.1 Consulta de Historial del Paciente El sistema debe permitir al profesional consultar sobre la historia reciente del paciente registrada en su ficha. Evidente Detalles y Restricciones La informacin debe ser segmentada segn el nivel de acceso del profesional consultante. R2.2 Actualizacin de Agenda Mdica El sistema debe actualizar el sistema de agendamiento cuando el especialista cierra la ficha luego de terminada la consulta de un paciente. Oculto Detalles y Restricciones La actualizacin debe realizarse a travs de un servicio web prestado por el sistema de agenda mdica. Categora Interoperatividad Categora Poltica

# Ref: Funcin: Descripcin: Categora: Atributo Servicio Web # Ref: Funcin: Descripcin: Categora: Atributo

Detalles y Restricciones

Categora

MODELO DE CASOS DE USO

En esta seccin se describen los casos de uso, su detalle y la relacin que tienen con las funciones determinadas en la seccin anterior. Es importante incorporar el detalle de cada iteracin priorizado de manera de mantener coherencia con lo que se realize a travs del proceso de desarrollo complete.

Especificacin 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 parecern mucho a lo que encontramos como funciones. Veamos paso a paso la tcnica de especificacin.

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Si observamos las metas de la especificacin funcional, podemos decir que el lmite del sistema est la creacin y registro del historial mdico de un paciente que ingresa y se atiende en algn centro de CEMELAB. Sin embargo, tambin podemos decir que excluye: La administracin 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 Recepcionista Especialista Enfermera Tecnlogo Paciente Agenda Mdica Objetivo Registrar un paciente nuevo para atencin Imprimir detalle de ficha mdica en caso de derivacin o traslado Consultar ficha del paciente a ser atendido Ingresar a la ficha del paciente la anamnesis Consultar ficha del paciente a ser atendido Ingresar observaciones en procedimiento Ingresar resultados y diagnstico de un procedimiento Ser atendido Actualizar las horas mdicas cuando se cierre una atencin

Los casos de uso encontrados en esta iteracin son los siguientes:

Caso de Uso: Actores: Tipo: Descripcin: CU1: Registrar Paciente Recepcionista (I), Paciente Primario Cuando llega un paciente nuevo, ste debe ser registrado en el sistema y su ficha ser creada. La informacin necesaria para este registro es nombre completo, rut, direccin, telfono y correo electrnico. CU2: Consultar Historial Especialista/ Enfermera (I) Primario Antes de la atencin, el encargado deber revisar la ficha del paciente. CU3: Registrar Anamnesis Especialista (I), Paciente Primario Al terminar la atencin mdica, el mdico tratante ingrese el detalle de la atencin en box incluyendo los procedimientos y medicamentos indicados. CU4: Registrar Observaciones por Procedimiento Enfermera (I) Secundario Durante un procedimiento, la enfermera puede ingresar observaciones que le parezcan relevantes para el anlisis del mismo. CU5: Registrar Resultado de Procedimiento Tecnlogo (I) Primario

Caso de Uso: Actores: Tipo: Descripcin: Caso de Uso: Actores: Tipo: Descripcin:

Caso de Uso: Actores: Tipo: Descripcin:

Caso de Uso: Actores: Tipo:

ANLISIS Y DISEO
Descripcin:

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Al analizar una muestra, el tecnlogo debe ingresar los resultados clnicos en la ficha, as como tambin el diagnstico preliminar si procede. CU6: Generar Traslado Recepcionista (I), Especialista, Paciente Opcional En caso de un traslado (derivacin u hospitalizacin), se debe emitir un informe indicando el ltimo diagnstico y procedimientos asociados a ste. CU7: Actualizar Agenda Mdica Especialista (I) Primario Cada vez que el especialista cierra una atencin mdica, sta debe ser actualizada en la agenda mdica.

Caso de Uso: Actores: Tipo: Descripcin:

Caso de Uso: Actores: Tipo: Descripcin:

Es importante destacar que solo los CU principales sern expandidos a continuacin.

Casos de Uso Expandidos

El detalle de los casos de uso identificados es el siguiente:
Caso de Uso: Actores: Propsito: Resumen: CU1: Registrar Paciente Recepcionista (I), Paciente Realizar el registro de un paciente nuevo en el SEFP. Cuando llega un paciente nuevo, ste debe ser registrado en el sistema y su ficha ser creada. La informacin necesaria para este registro es nombre completo, rut, direccin, telfono y correo electrnico. Primario y Esencial R1.1 Curso Normal Acciones de los Actores 1. 2. 4. 5. 6. 8. Paciente llega al mesn de atencin y entrega su RUT. Recepcionista ingresa RUT en el sistema para confirmar que es nuevo. Recepcionista solicita al paciente informacin. Paciente entrega a Recepcionista informacin solicitada. Recepcionista ingresa la informacin en el sistema. Recepcionista entrega RUT al Paciente. Respuestas del Sistema

Tipo: Ref. Cruzadas:

3.

Sistema confirma que el paciente es nuevo y solicita informacin bsica.

7.

Sistema registra la informacin y crea la ficha electrnica informando accin.

Cursos Alternos (3a) Si el paciente ya existe, informa al Recepcionista y termina el CU. (7a) Si el RUT ya est registrado con otra informacin, alerta al Recepcionista y solicita confirmacin para actualizar informacin. Caso de Uso: Actores: Propsito: Resumen: CU2: Consultar Historial Especialista/Enfermera (I) Consultar aspectos relevantes de la ficha previos a la atencin. Antes de la atencin, el encargado deber revisar la ficha del paciente utilizando el

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

RUT de ste. Tipo: Ref. Cruzadas: Primario y Esencial R2.1 Curso Normal Acciones de los Actores 1. Especialista/Enfermera ingresa el RUT del paciente en el sistema. 2. Respuestas del Sistema Sistema obtiene ficha del paciente y muestra informacin. Cursos Alternos

(2a) Si el paciente no existe, lo informa y termina el CU. Caso de Uso: Actores: Propsito: Resumen: Tipo: Ref. Cruzadas: CU3: Registrar Anamnesis Especialista (I), Paciente Registrar la informacin resultante de la consulta mdica. Al terminar la atencin mdica, el mdico tratante ingrese el detalle de la atencin en box incluyendo los procedimientos y medicamentos indicados. Primario y Esencial R1.2, CU7 Curso Normal Acciones de los Actores 1. Especialista ingresa el RUT del paciente. 2. Respuestas del Sistema Sistema encuentra la ficha mdica, abre la atencin mdica y solicita informacin sobre los datos de la inspeccin y observaciones al examen fsico. Sistema registra informacin de la inspeccin y solicita informacin sobre diagnstico del paciente. Sistema registra el diagnstico y solicita informacin sobre procedimientos, medicamentos e indicaciones. Sistema registra informacin y cierra la atencin mdica (CU7).

3.

5.

Especialista ingresa datos de peso, talla, presin arterial, temperatura, etc. y las observaciones si las hubiera. Especialista ingresa el diagnstico.

4.

6.

7.

Especialista ingresa los procedimientos, 8. medicamentos e indicaciones entregadas al paciente. Cursos Alternos

(2a) Si la ficha no existe, informa al Especialista y termina el CU. Caso de Uso: Actores: Propsito: Resumen: Tipo: Ref. Cruzadas: CU5: Registrar Resultado de Procedimiento Tecnlogo (I) Registrar la informacin de anlisis y diagnstico del procedimiento realizado. Al analizar una muestra, el tecnlogo debe ingresar los resultados clnicos en la ficha, as como tambin el diagnstico preliminar si procede. Primario y Esencial R1.4 Curso Normal Acciones de los Actores 1. Tecnlogo ingresa el RUT del paciente. 2. Respuestas del Sistema Sistema encuentra la ficha mdica, solicita informacin sobre la fecha de la muestra, los resultados del examen y diagnstico en caso de ser necesario. Sistema registra informacin y cierra la ficha.

3.

Tecnlogo ingresa datos obtenidos de la muestra y en caso de que aplique se ingresa el

4.

ANLISIS Y DISEO
diagnstico.

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Cursos Alternos (2a) Si la ficha no existe, informa al Tecnlogo y termina el CU. Caso de Uso: Actores: Propsito: Resumen: Tipo: Ref. Cruzadas: CU7: Actualizar Agenda Mdica Especialista Enviar un mensaje al Sistema de Agenda Mdica (SAM) de cierre de atencin. Al cerrar una ficha por atencin mdica, el sistema debe generar un mensaje al SAM para informar que el especialista ha dado trmino a la atencin. Primario y Esencial R2.2, CU3 Curso Normal Acciones de los Actores 1. Especialista cierra la atencin mdica (CU3). 2. Respuestas del Sistema Sistema registra el cierre de la ficha y enva un mensaje al SAM indicando el cierre de la atencin. 3. Sistema recibe confirmacin de parte del SAM de que se ha realizado la transaccin 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, quin 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 comunicacin 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 iteracin y utilizar dicha informacin para el anlisis 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 especificacin expandida). A continuacin se muestra grficamente la relacin de los actores con los casos de uso especificados.

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

System CU1: Registrar Paciente

CU6: Generar Traslado Recepcionista

CU3: Registrar Anamnesis

Especialista <<include>> CU7: Actualizar SAM CU2: Consultar Ficha

Agenda Mdica

Enfermera CU4: Registrar Observaciones

CU5: Registrar Resultados Tecnlogo

GLOSARIO
En esta seccin se describen los conceptos ms importantes del dominio y que impactan en su entendimiento.
Trmino Ficha Mdica Registro Box Anamnesis Datos de Inspeccin Diagnstico Procedimiento Agenda (SAM) Mdica la Definicin Registro electrnico (en este caso) en donde queda almacenada toda la historia mdica de un paciente. Proceso a travs del cual se guarda la informacin ingresada por un usuario. Espacio fsico donde se realiza la anamnesis. Proceso de revisin que realiza un especialista en un box de atencin a un paciente. Informacin que resulta de un examen fsico realizado por un especialista en un box de atencin (peso, talla, temperatura y presin arterial). Inferencia que realiza el especialista como resultado del examen fsico. Cualquier tipo de examen fsico o psicolgico que puede solicitar el especialista. Sistema externo necesario para registrar cuando un especialista cierra una atencin mdica.

Este glosario resumido (ya que podramos encontrar muchos ms trminos para este problema) solo muestra un ejemplo de cmo van describindose las diferentes definiciones de, en este caso, los conceptos del dominio.

10

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

MODELO DE DOMINIO
En esta seccin se describen los artefactos que muestran la visin 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 generacin 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 mdica) el cual registra la informacin bsica de la ficha (crear). A continuacin hemos indicado un conector de decisin para diferenciar si el siguiente flujo (por consulta mdica 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 decisin para el siguiente flujo. Finalmente, notaremos que no tiene una actividad de trmino, 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:

11

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Especialista Sistema de Agenda Mdica Laboratorista

Recepcionista

[paciente ingresa al centro] Crear Ficha de Paciente

[paciente entra a toma de muestra] [paciente entra a consulta] Ver Ficha de Paciente Ver Ficha de Paciente

Realizar el Procedimiento Realizar la Consulta

[no hay observaciones] Registrar la Anmnesis [hay observaciones] Registrar Observaciones Registrar Trmino de Atencin

[derivacin a centro asistencial] Realizar Anlisis

[no hay derivacin] Imprimir Informe Mdico Registrar Resultados

Diagrama de Clases Conceptuales

Lo que vamos a realizar es utilizar ambos mtodos de identificacin de clases conceptuales para luego ir dibujando el diagrama general. Veamos primero entonces la lista de categoras:
Categora de Clase Conceptual Objetos tangibles o fsicos Especificaciones, diseos o descripciones de las cosas Ejemplos InformeDeDerivacion DetalleDeInforme ResultadoProcedimiento DetalleAnamnesis CentroMedico Recepcin ConsultaMedica BoxDeProcedimiento Anamnesis Procedimiento Recepcionista Especialista Laboratorista Paciente AgendaMedica

Lugares

Lneas de la transaccin Roles de la gente

Contenedores de otras cosas Cosas en un contenedor Otros sistemas externos

12

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Ejemplos Anamnesis Procedimiento FichaDePaciente Anamnesis Procedimiento RegistroDeFichas InformeDeDerivacion

Categora de Clase Conceptual Conceptos abstractos

Organizaciones Hechos Procesos Reglas y polticas Catlogos Registro de finanzas, trabajo, contratos, asuntos legales Instrumentos y servicios financieros Manuales, documentos, artculos de referencia, libros

Note que aparecen las mismas clases en varias categoras. Veamos ahora las frases nominales de los escenarios de casos de uso:
Caso de Uso: CU1: Registrar Paciente Curso Normal Acciones de los Actores 9. Paciente llega al mesn de atencin y entrega su RUT. 10. Recepcionista ingresa RUT en el sistema para confirmar que es nuevo. 12. Recepcionista solicita al paciente informacin. 13. Paciente entrega a Recepcionista informacin solicitada. 14. Recepcionista ingresa la informacin en el sistema. 16. Recepcionista entrega RUT al Paciente. Respuestas del Sistema

11. Sistema confirma que el paciente es nuevo y solicita informacin bsica.

15. Sistema registra la informacin y crea la ficha electrnica informando accin.

Cursos Alternos (3a) Si el paciente ya existe, informa al Recepcionista y termina el CU. (7a) Si el RUT ya est registrado con otra informacin, alerta al Recepcionista y solicita confirmacin para actualizar informacin. Caso de Uso: CU2: Consultar Historial Curso Normal Acciones de los Actores 3. Especialista/Enfermera ingresa el RUT del paciente en el sistema. 4. Respuestas del Sistema Sistema obtiene ficha del paciente y muestra informacin. 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 9. Especialista ingresa el RUT del paciente. Respuestas del Sistema 10. Sistema encuentra la ficha mdica, abre la atencin mdica y solicita informacin sobre los datos de la inspeccin y observaciones al examen fsico. 12. Sistema registra informacin de la inspeccin y solicita informacin sobre diagnstico del

11. Especialista ingresa datos de peso, talla, presin arterial, temperatura, etc. y las observaciones si

13

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

paciente. 14. Sistema registra el diagnstico y solicita informacin sobre procedimientos, medicamentos e indicaciones. 16. Sistema registra informacin y cierra la atencin mdica (CU7).

las hubiera. 13. Especialista ingresa el diagnstico.

15. Especialista ingresa los procedimientos, medicamentos e indicaciones entregadas al paciente. 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 5. Tecnlogo ingresa el RUT del paciente. 6. Respuestas del Sistema Sistema encuentra la ficha mdica, solicita informacin sobre la fecha de la muestra, los resultados del examen y diagnstico en caso de ser necesario. Sistema registra informacin y cierra la ficha.

7.

Tecnlogo ingresa datos obtenidos de la 8. muestra y en caso de que aplique se ingresa el diagnstico. Cursos Alternos

(2a) Si la ficha no existe, informa al Tecnlogo y termina el CU. Caso de Uso: CU7: Actualizar Agenda Mdica Curso Normal Acciones de los Actores 4. Especialista cierra la atencin mdica (CU3). 5. Respuestas del Sistema Sistema registra el cierre de la ficha y enva un mensaje al SAM indicando el cierre de la atencin. 6. Sistema recibe confirmacin de parte del SAM de que se ha realizado la transaccin 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, quin 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 tambin 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:

14

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

DetalleDeFicha +rut +nombre +direccion +telefono +email 1 1 es-descrita-por FichaDePaciente 1 1 1 0..1

1 posee

Paciente

crea 1

Recepcionista

contiene 0..* Laboratorista Procedimiento 1 ingresa es-descrita-por 1 DetalleProcedimiento +observaciones 0..1 +resultados +diagnostico

+cotiene 0..* Anamnesis Especialista

1 1

1 es-descrita-por 0..1 ingresa

DetalleAnamnesis +datos_inspeccion +observaciones +indicaciones +otros

Este diagrama puede ser la primera aproximacin para el futuro diseo de clases y por supuesto un insumo importante para los siguientes artefactos y modelos de anlisis y diseo.

MODELO DE COMPORTAMIENTO
En esta seccin se describen los artefactos que describen el comportamiento del sistema.

Diagramas de Secuencia
Para especificar los diagramas de secuencia es importante hacerlos a travs de los escenarios encontrados en los casos de uso. Segn lo expuesto en este problema, los escenarios alternos son sencillos, as que, donde corresponda, se utilizarn los cursos alternos como parte del mismo diagrama. Veamos el escenario del primer caso de uso:

15

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

: Recepcionista

Sistema

CatalogoDePacientes

1 : validarRut()

2 : pacienteExiste()

3 : ack 4 5 : ingresarDetalle() : DetalleDeFicha 6 : nuevo()

7 8 : asociarDetalle()

10

Es posible observar en este diagrama que gran parte de la carga se la estara llevando el objeto DetalleDeFicha (adelantndonos para cuando lleguemos a los diagramas de estado). Sigamos con los dems CU y sus respectivos diagramas:

Funcionario

Sistema

CatalogoDePacientes

1 : consultar()

2 : buscar()

3 4

Al igual que en el caso anterior, este diagrama no es ms que una traduccin del escenario realizado para el CU. Veamos el siguiente:

16

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

: Especialista

Sistema

CatalogoDePacientes

d : DetalleDeFicha

1 : consultar() 2 : buscar()

4 5 : registrarInformacin()

3:d : DetalleAnamnesis 6 : crear() 7 : det 8 : registrarAnamnesis()

10

En este caso podemos ver que se complejiza un poco la lgica, sin embargo debemos destacar un par de puntos. 1. Resumimos los 3 ingresos que existen en el escenario en 1 sola operacin (con la lgica de que la filla se llena sin registrar la informacin hasta el final). La creacin del objeto DetalleAnamnesis es porque segn el modelo de dominio, DetalleDeFicha solo sabe registrar DetalleAnamnesis a travs de una Anamnesis (la cual puede ser generad dentro de DetalleFicha como una lnea de transaccin). Las operacines de consultar, en realidad es la misma utilizada en el CU2.

2.

3.

Sigamos con el siguiente CU:

17

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

: Laboratorista

Sistema

CatalogoDePacientes

d : DetalleDeFicha

1 : consultar()

2 : buscar()

3:d 4 5 : registrarInformacion() 6 : crear() : DetalleProcedimiento

7 : det 8 : registrarProcedimiento()

10

En este caso vemos una similitud muy obvia con el CU3, tanto as que a estas alturas podramos generalizarlo de manera de que sea ms reutilizable. Sin embargo, para efectos pr cticos, sigamos con el anlisis tal cual.

: Especialista

Sistema

AgendaMedica

1 : cerrarAtencin() 2 : cierreFicha()

3 : ack

En el ltimo CU analizado solo tenemos el hecho del cierre de la atencin mdica y en este caso son operaciones hacia fuera del sistema, as que es poca la interaccin. Con estos diagramas completamos el anlisis del comportamiento a travs 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 cules son las operaciones principales para luego ir describindolas a travs de la estructura planteada para los contratos. Veamos entonces los contratos del problema.

18

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

CO1. validarRut(rut) Validar que el RUT exista dentro del catalogo de pacientes Sistema CU1 Si el RUT existe, se aborta el resto del CU - Exista una instancia r de tipo CatalogoDePacientes - 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 parmetro rut. CO2. ingresarDetalle(rut, nombre, direccion, fono, email) Crear y agregar la informacin bsica del paciente a la ficha Sistema CU1 - Se haya creado una instancia d de tipo DetalleDeFicha - Se hayan fijado los atributos rut, nombre, direccin, telfono e email con los valores entregados por parmetro. - Se haya creado una instancia f de tipo FichaDePaciente - Se haya asociado d a f CO3. consultar(rut) Obtiene la informacin de la ficha del paciente a partir del rut ingresado. Sistema CU2, CU3, CU5 Si la ficha no existe, devuelve un valor nulo. - Exista una instancia r de CatalogoDePacientes - Se haya encontrado una instancia p de DetalleDePaciente cuyo atributo rut sea igual al valor del parmetros rut. CO4. registrarInformacion(objeto) Registra en la ficha del paciente la informacin entregada en forma de objeto. Sistema CU3, CU5 Objeto puede tomar valores de DetalleAnamnesis y DetalleProcedimiento -

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones:

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones:

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones:

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones:

19

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

- Exiasta una instancia d de DetalleDePaciente - Se haya asociado objeto a d. CO5. cerrarAtencion(especialista) Enva una notificacin al sistema de agenda mdica indicando el trmido de la atencin del especialista. Sistema CU7 Utiliza XML para construir la llamada al SAM. Un mensaje intersistemas para el SAM -

Salidas: Precondiciones Postcondiciones: Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones:

Como podemos ver en los contratos expuestos, se hicieron varias optimizaciones en las operaciones, generalizando las que habamos originalmente encontrado en los diagramas. Esto permitir un menor riesgo desde el punto de vista del diseo e implementacin futura.

Diagramas de Estado
Como ltima parte del anlisis 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 cmo queda el diagrama de estados en este caso (considerando todos los contratos del modelo).
nuevo

Disponible entry/fijarDetalleDePaciente

[es atendido]

En Llenado do/asociarDetalle

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 visin del anlisis 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.

20

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

DISEO DEL SISTEMA MODELO ARQUITECTNICO

En esta seccin se describen las decisiones de la arquitectura que afectan a la organizacin de los programas finales.

Diagrama de Componentes
La primera premisa para nuestro diagrama es que separaremos las capas de interfaz grfica de las funcionales (negocio) y operativa, es decir, utilizaremos un modelo de 3 capas de diseo arquitectnico. La capa funcional estar compuesta de 3 componentes bsicos y que son separados por su naturaleza: Gestin de la Ficha (creacin y consulta de la ficha de un paciente) Gestin de la Consulta Mdica (ingreso de anamnesis) Gestin de los Procedimientos (ingreso de observaciones y resultados)

Ahora bien, tanto la capa Consulta Mdica como la capa Procedimiento requieren trabajar con la ficha, por lo que tambin existirn algunas dependencias entre ellas:

Como podemos ver, las interfaces que exponemos para la comunicacin entre los paquetes nos definen algunas operaciones que se realizarn en los diagramas de colaboracin. 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 Mdica: Todas las clases que operen con la anamnesis. Procedimiento: Todas las clases que operen con los procedimientos.

Es fcil 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 habamos 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 diseo realizado y seguiremos mantenindolo por separado. Lo que nos queda ahora es exponer los servicios que van hacia la interfaz grfica y completar el diagrama con la capa completa:

21

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

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, podramos (y optimizando el diagrama anterior) organizar el sistema de la siguiente manera:

Lo que finalmente describimos es una componente grfica por lugar donde funcionar el sistema y relacionamos con qu servicio expuesto se comunican dichas componentes directamente. As podemos discriminar cmo organizar tambin los programas de la interfaz grfica fcilmente. Por ltimo, debemos tambin 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 sera entonces el diagrama final de componentes del sistema:

22

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Como podemos notar, el Registro de Fichas es una componente que representa la interaccin con la base de datos directamente. De esta manera, cuando se desea, por ejemplo, realizar una bsqueda de una ficha por el rut, es necesario que se obtenga la ficha desde la base (a travs de un select de la tabla respectiva). En particular, solo se exponen 2 servicios bsicos 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 DISEO
En esta seccin se describe en detalle el diseo del sistema a partir de las operaciones de ste y completando con una vision tcnica de las clases de diseo.

Diagramas de Colaboracin
Los diagramas de colaboracin realizan las interacciones necesarias para que lo objetos colaboren bajo el objetivo de cumplir las operaciones de cada caso de uso.
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: CO1. validarRut(rut) Validar que el RUT exista dentro del catalogo de pacientes Sistema CU1 Si el RUT existe, se aborta el resto del CU - Exista una instancia r de tipo CatalogoDePacientes - 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 parmetro rut.

23

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Lo primero que debemos buscar en este caso es qu objeto debe ser el controlador de la operacin. Es fcil ver que como no tuvimos nunca una clase que represente nada fsico del sistema, siempre utilizamos Sistema como tal. As que, como estamos hablando de aplicar el patrn, 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 opcin. Adems, que el ejemplo es bastante bueno para que podamos separar las funciones en cada mbito de la atencin mdica. Si seguimos aplicando otros patrones, por ejemplo, para validar el rut debemos identificar de quin es la responsabilidad de conocer o mantener conocimiento de las fichas de los pacientes. Con el patrn de experto podemos determinar que ese es el CatlogoDePacientes, que ya tenamos identificado anteriormente. Por ltimo, sabiendo que el experto de informacin de conocer el rut de un paciente es DetalleDeFicha, y aplicando el patrn de cadena de responsabilidad (de GoF), podemos llevar la responsabilidad desde el controlador hasta el mismo objeto para entregar el valor del rut pidindole a CatalogoDePacientes, luego a FichaDePaciente y que realice la validacin si existe una ficha (esperamos respuesta negativa por supuesto). De esta manera, el primer diagrama de colaboracin quedara como sigue:

De una forma anloga, podemos revisar el segundo contrato:

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: CO2. ingresarDetalle(rut, nombre, direccion, fono, email) Crear y agregar la informacin bsica del paciente a la ficha Sistema CU1 - Se haya creado una instancia d de tipo DetalleDeFicha - Se hayan fijado los atributos rut, nombre, direccin, telfono e email con los valores entregados por parmetro. - Se haya creado una instancia f de tipo FichaDePaciente - Se haya asociado d a f

24

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Es fcil 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 mdulo (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 ms estrechamente estos objetos es FichaDePaciente, sin embargo tambin es parte del contrato crear un objeto de ese tipo, as que podemos realizar esa creacin 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 informacin del detalle del paciente y es DetalleDeFicha, lo que nos permite mejorar la creacin de ese tipo de objetos delegndole toda esa informacin a su creador (FichaDePaciente) y permitiendo que la creacin se lleve a cabo en una sola responsabilidad encapsulada. El diagrama de colaboracin quedara as:

Notemos que en este caso particular, la existencia de la relacin con el catlogo no estaba definida en el contrato, pero la aplicacin de los patrones de diseo nos permiti descubrir esta relacin. Por otro lado tampoco aparece en forma explcita el cumplimiento de la postcondicin de asociar d a f, pero por la delegacin de la creacin quedan asociadas esas instancias. El siguiente contrato es:
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: CO3. consultar(rut) Obtiene la informacin de la ficha del paciente a partir del rut ingresado. Sistema CU2, CU3, CU5 Si la ficha no existe, devuelve un valor nulo. - Exista una instancia r de CatalogoDePacientes - Se haya encontrado una instancia p de DetalleDePaciente cuyo atributo rut sea igual al valor del parmetros 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 algn CU particular, ya que esta operacin es transversal a los CU2, CU3 y CU5.

25

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

A pesar de ello, como la naturaleza de la operacin tiene que ver con obtener la informacin de la ficha del paciente, podremos crear un nuevo controlador modular llamado FichaControlador, que permite realizar las 1 operaciones bsicas de consulta o manipulacin de la ficha . 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 realizacin para mejorar y aplicar este contrato en forma equivalente. As, las colaboraciones corregidas para aplicar esta operacin tambin seran:

Por ltimo, la colaboracin del CO3 sera:

Como podemos ver, la naturaleza de la operacin es la misma, pero la respuesta que se espera es diferente del controlador. El siguiente contrato es:
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: CO4. registrarInformacion(objeto) Registra en la ficha del paciente la informacin entregada en forma de objeto. Sistema CU3, CU5

Note que las operaciones anteriormente analizadas tambin tienen que ver con la ficha, por lo que una mejora sera juntarlas todas en este mismo controlador, quedando 3 operaciones (CO1, CO2 y CO3).

26

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Objeto puede tomar valores de DetalleAnamnesis y DetalleProcedimiento - Exiasta una instancia d de DetalleDePaciente - Se haya asociado objeto a d.

Notas: Excepciones: Salidas: Precondiciones Postcondiciones:

Primero, esto tiene diferentes matices, ya que est siendo generalizada una operacin que no tendran el mismo controlador, as que seran 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 mdica. La otra ser gestionada por ProcedimientoControlador, que tiene que ver ms con las operaciones realizadas durante un procedimiento mdico. 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 colaboracin:

De una manera anloga podemos realizar la operacin respecto al registro del procedimiento quedando el diagrama de la siguiente forma:

Lo relevante de este anlisis, 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 convertirn en los mtodos de cada una de las clases (y las clases destino son las mismas). Por ltimo, veamos el ltimo contrato del dominio:

27

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

CO5. cerrarAtencion(especialista) Enva una notificacin al sistema de agenda mdica indicando el trmino de la atencin del especialista. Sistema CU7 Utiliza XML para construir la llamada al SAM. Un mensaje intersistemas para el SAM -

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones:

Como podemos ver, esta operacin tiene que ver con la consulta mdica (y de hecho es una operacin de secundaria, ya que es una notificacin). Sin embargo, este contrato no aporta informacin 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 Diseo

Una vez analizado por completo las operaciones del sistema, podemos plantear paso a paso el diagrama de clases de diseo. Veamos cmo va quedando: Con un simple paso por los diagramas de colaboracin, podemos identificar las siguientes clases:

En el diagrama, adems pusimos desde ya los atributos que vienen desde el diagrama de clases conceptuales, ya que a priori sabemos que esos valores se mantendrn para el diseo. El siguiente paso es completar con la informacin de los tipos de datos de los atributos y sus visibilidades correctas:

28

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Es fcil detectar que la informacin almacenada es mayormente de texto, ya que todos los datos generados por los especialistas mdicos son de ese tipo. Siguiendo con las definiciones aprendidas en la tcnica de creacin del diagrama de clases de diseo, podemos obtener ahora los mtodos de cada una de las clases a partir de los diagramas de colaboracin dibujados en la seccin anterior. As, podemos asociar los siguientes mtodos 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 quedara de la siguiente forma detallado:

29

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

El paso siguiente es incorporar las asociaciones de acuerdo a la cercana de las clases del diagrama. Esto es bastante rpido 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 pasara a ser de la siguiente forma:

30

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

Como podemos ver incorporamos tambin el concepto de composicin en varias de esas asociaciones, por el hecho de ser creadores de otros objetos. Observemos por un momento la relacin entre Procedimiento DetalleDeProcedimiento y Anamnesis DetalleDeAnamnesis. Podemos notar una semejanza con la caja del supermercado, porque en este caso Procedimiento y Anamnesis estn jugando el papel de lnea 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 generalizacin en el diagrama, incorporaremos la clase RegistroDeFicha (que reemplazar Procedimiento y Anamnesis como lnea de venta) y una clase DetalleDeRegistro que ser la superclase que incorporar ambos tipos de registros. Adems, 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 ms detalle y podemos mostrar finalmente el siguiente diagrama de clases de diseo como una primera versin de nuestro SEFP:

31

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

32

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

PREPARANDO LA IMPLEMENTACIN MODELO DE IMPLEMENTACIN

En esta seccin se describen las labores de preparacin de la codificacin.

Diagrama de Clases de Implementacin

Describiremos el diagrama de clases de implementacin, utilizando el DCD de la unidad anterior. Para ello entonces pasaremos por los pasos bsicos indicados en la tcnica de desarrollo del modelo respectivo. Primero, comencemos normalizando los tipos de datos al lenguaje elegido (Java). El diagrama de clases quedara algo parecido a lo siguiente:

Luego de realizado esto, se van describiendo las clases a travs de anotaciones en el diagrama considerando no solo los atributos explcitos, sino que tambin operaciones complejas y atributos de asociacin. Para el caso de las asociaciones mltiples 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 nmero de elementos que finalmente vamos a registrar. De esta manera, tendremos un diagram parecido a este:

33

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

El siguiente paso (que aparece en la tcnica vista en este captulo) indica incorporar lgica de programacin en el diagrama, sin embargo, dada la complejidad de ste, vamos a optar por escribir el cdigo (estructura de clases) a partir de lo ya obtenido, y luego incorporar lgica programtica.

Estructura de Clases
La estructura obtenida corresponde a las clases, con sus atributos y las firmas de todos los mtodos identificados. Sin embargo, vamos a aprovechar de incorporar lgica en los mtodos de las clases segn corresponda. A continuacin el listado de las clases desde la menos acoplada a las ms 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; } }

34

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

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,

35

ANLISIS Y DISEO

Sistema Electrnico de Fichas de Pacientes - CEMELAB

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);

36

ANLISIS Y DISEO
} }

Sistema Electrnico de Fichas de Pacientes - CEMELAB

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); } }

37