Vista de análisis

La realización del análisis da como resultado un modelo del sistema que pretende ser correcto, completo, consistente y verificable. El objetivo del mismo

es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que ayude a estructurar el sistema entero, incluyendo su arquitectura, (Lorenzo, 2017).

Para el análisis es necesario la confección de las clases del análisis. Esta representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. Se centra en el tratamiento de los requisitos funcionales y pospone los no funcionales, denominándolos requisitos especiales, hasta llegar a las actividades de diseño e implementación siguientes. Contiene y define atributos reconocidos por el dominio del sistema. Siempre encajan en uno de los tres estereotipos básicos: de interfaz o frontera, de control y de entidad, (Lorenzo, 2017).

Las clases de interfaz son los puntos por los cuales algún actor externo puede interactuar con el sistema. Representan abstracciones de ventanas, formularios, paneles, distintos tipos de interfaces, sensores, API, etc. No es necesario que estas clases describan cómo se ejecuta físicamente la interacción, (Lorenzo, 2017).

La clase entidad se emplean para modelar los conceptos, cuyo estado debe ser conservado más allá de la ejecución del sistema. Los objetos que son instancias de esta clase se pueden almacenar y recuperar con posterioridad. Tienen como principal característica ser contenedoras de datos, (Lorenzo, 2017).

Las clases de control se crean con el objetivo de coordinar y llevar el control de la secuencia de eventos necesarios para completar cada interacción de un actor con el sistema. Se estila emplear una clase controladora para cada caso de uso. Estas determinan y garantizan el cumplimiento de las reglas del negocio

Teniendo en cuenta lo anterior se puede conformar el diagrama de clases del

análisis que aparece en la figura 3 para los casos de uso relacionados con la

Fig. 3. Diagrama de clases del análisis obtenido para casos de uso del sistema

asociados a la gestión de pacientes.

En el mismo se observa una clase de tipo interfaz Inicio, la cual interactúa en un primer momento con el personal médico, desde donde se puede acceder a la clase de interfaz GestionPaciente. Desde este lugar el personal médico tiene la posibilidad de realizar acciones como agregar los datos clínicos de un paciente, modificarlos, eliminarlos y/o desactivar un paciente. En caso de que la opción elegida sea agregar o modificar un paciente, el usuario interactúa con las interfaces de Agregar paciente o Modificar paciente correspondiente. Toda la actividad es manejada por la clase controladora ControladorPaciente, la cual interactúa con la clase de tipo entidad Paciente, encargada del manejo de datos. De manera similar sucede con la gestión de los usuarios, la gestión de los antecedentes patológicos personales y la gestión de los tratamientos.

También es preciso obtener en el análisis el diagrama de colaboración o comunicación. Estos contienen instancias de objetos y actores, junto con los enlaces y mensajes que describen cómo ellos se relacionan e interactúan. Describe qué es lo que tiene lugar en los objetos participantes en términos de cómo los objetos se comunican enviándose mensajes unos a otros. Para cada variante de flujo de eventos de caso de uso se puede obtener un diagrama de comunicación, (Lorenzo, 2017).

Se obtienen los diagramas de colaboración para los casos de uso del sistema más significativos: Añadir información de paciente en la figura 4, Modificar información de paciente en la figura 5, y Desactivar paciente en la figura 6.

Fig. 4 Diagrama de colaboración para el caso de uso del sistema Añadir

información de paciente obtenido.

El Personal Médico interactúa con la clase de tipo frontera Inicio, la cual activa la interfaz de usuario GestionPaciente. El Personal Médico selecciona la opción Agregar. La Interfaz de usuario GestionPaciente activa la interfaz de usuario AgregarPaciente, donde el usuario llena la información del nuevo paciente. Hecho esto y seleccionada la opción Agregar, el sistema realiza un llamado al método agregarPaciente en la clase controladora ControladoraPaciente, la cual, a su vez, guarda la información en la base de datos.

Fig. 5 Diagrama de colaboración obtenido para el caso de uso del sistema

Modificar información de paciente.

Para este caso de uso del sistema, el personal médico, desde la clase de tipo frontera Inicio selecciona la opción Gestión de paciente, la cual activa la interfaz GestionPaciente, una vez aquí el usuario selecciona la opción Modificar. Esto activa los métodos correspondientes para buscar al paciente seleccionado en la base de datos, activando la interfaz de usuario Modificar paciente, donde se completa cada campo de datos con la información relacionada con el paciente. El usuario modifica los datos deseados y selecciona la opción Confirmar. Esta acción activa el método actualizarPaciente, el cual, modifica la información existente relacionada con el paciente.

Fig. 6 Diagrama de colaboración obtenido para el caso de uso del sistema

Desactivar paciente.

El personal médico interactúa con la clase de tipo frontera Inicio, desde donde selecciona la opción Gestionar paciente, se activa la interfaz GestionPaciente. Desde aquí selecciona el paciente a desactivar, realizando un llamado al método desactivarPaciente en la clase controladora ControladorPaciente, guardando los cambios en la base de datos.

Es necesario señalar que los diagramas obtenidos que se presentan responden al flujo principal de la realización de los casos de uso más significativos.

Otros elementos a obtener son los diagramas de secuencia. Estos son necesarios para obtener una ilustración de las realizaciones de los casos de uso. Ellos aclaran los roles de los objetos en el flujo, y, por consiguiente, brindan la entrada básica para la determinación de las responsabilidades y las interfaces de las clases. Incluye las secuencias cronológicas, pero no prioriza gráficamente las relaciones entre los objetos. Muestran la secuencia explícita de los mensajes, y resultan de gran utilidad cuando es preciso visualizar el orden de los mensajes en el tiempo, (Lorenzo, 2017).

Se obtienen los diagramas de secuencia para los casos de uso del sistema más significativos: Añadir información de paciente en la figura 7, Modificar información de paciente en la figura 8, y Desactivar paciente en la figura 9.

Fig. 7 Diagrama de secuencia obtenido para el caso de uso del sistema Añadir

información de paciente.

Modificar información de paciente.

Fig. 9 Diagrama de secuencia obtenido para el caso de uso del sistema

Desactivar paciente.

En todos los diagramas expuestos se puede apreciar la interacción del personal médico, actor principal de los casos de uso del sistema más significativos, con las clases de tipo interfaz Inicio y GestionPaciente. De igual manera de estas con la clase de tipo controladora ControladorPaciente y manejar el flujo de actividades hacia los datos de la clase entidad Paciente. En ello se puede destacar el orden secuencial que presentan las actividades en la realización de los casos de uso del sistema.

Con el objetivo de gestionar los datos de los pacientes que ingresan a la sala de Cardiología, se diseña una base de datos relacional, a partir del diagrama entidad – relación.