Sei sulla pagina 1di 10
Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

Sistema de Gestión de Pacientes

Grupo03 KK-

Grupo03

Grupo03

Grupo03

KK--4071

4071

-4071

4071

Año 2008

Año 2008

Año 2008

Año

2008

D.E.R. yyyy UML

D.E.R.

UML

D.E.R. D.E.R.

UML UML

Integrantes del equipo:

Nombre y Apellido

Legajo

e-mail

Teléfono

Federico José Botti

119046-5

federicojbotti@yahoo.com.ar

1555980033

María Gimena Conde

120810-0

gime_conde@yahoo.com.ar

1558920753

Docentes:

Solanas, Alberto Puyol, María Elisa González, Gerardo

VERSION

1.0

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

Historial de Revisiones

Fecha

Versión

Descripción

Autor

20/10/2008

1.0

DER y UML

Grupo03

03/11/2008

2.0

Se agregan diagramas de actividades y se completa introducción.

Grupo03

10/11/2008

2.2

Se agrega descripción de diagramas

Grupo03

       
Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

Tabla de Contenidos

  • 1. INTRODUCCIÓN

................................................................................................................................................

4

  • 2. ....................................................................................................................................................................

D.E.R

5

  • 3. ......................................................................................................................................................

U.M.L

……….6

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

1. Introducción

Continuando con la etapa de diseño del sistema g-pac08 nos encontramos en la necesidad de modelar la estructura de Base de Datos que utilizará. Para esto nos basamos en modelos llamados “Diagramas de Entidad Relación”. Éstos nos muestran rápidamente cuales son las entidades del sistema y las relaciones que existen entre ellas. A su vez nos apoyaremos en más diagramas UML para describir un poco mejor cuál es el diseño del sistema. Para esto utilizaremos diagramas de clases y diagramas de actividad. El primero nos sirve para entender como actúa la compleja estructura de objetos que intervienen en cada pedido al servidor Web (pedido que utiliza el protocolo de comunicaciones HTTPS – HyperText Transfer Protocol Secure); la segunda nos ayuda a clarificar y dar más detalle a uno o varios casos de uso relacionados. Es decir que se apoya en los casos de uso y los extiende especificando detalladamente como suceden las actividades dentro del sistema cuando se ejecuta el o los casos de usos intervinientes.

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

2. D.E.R.

Curso/ Grupo Proyecto K-4071 Sistema de gestión de pacientes Grupo 03 Versión Fecha HABILITACION PROFESIONAL 1.0

Figura 1 – D.E.R. de g-pac08

El diagrama de entidad relación nos ayuda a ver rápidamente y de forma clara cuáles son las entidades de datos que intervienen en el sistema y cuáles son las relaciones entre cada entidad. A partir de este modelo se procede a crear la estructura física de la base de datos que utilizaremos en la etapa de implementación.

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

3. U.M.L.

Curso/ Grupo Proyecto K-4071 Sistema de gestión de pacientes Grupo 03 Versión Fecha HABILITACION PROFESIONAL 1.0

Figura 2 – Pedido Típico al Servidor Web – Fuente: http://book.cakephp.org/view/21/A-Typical-CakePHP-Request

El cliente direcciona su navegador ingresando la dirección de su aplicación, por ejemplo, https://www.midominio.com.ar/users/add . El servidor Web toma el pedido y se lo pasa al objeto CakePHP “Dispatcher”. Este objeto pasa el pedido hacia el objeto Routes, que es el encargado de desglosar la url en sus partes componentes y pasarle los datos de la acción al controlador, encargado de la lógica de negocio. El controlador es el encargado de por un lado, tomar los datos del modelo o los modelos que tiene asociados, procesarlos y luego pasarle la información a la vista correspondiente. En este ejemplo el objeto Routes llama al controlador Users y en particular llama al método add(). Este método es el encargado de ejectuar la lógica de negocio, tomar los datos del modelo asociado y pasarle la información procesada a la vista con el mismo nombre (add.ctp).

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

Esta estructuración de la aplicación nos permite mucha flexibilidad y por sobre todas las cosas escalabilidad. En la figura 2 mostrada con anterioridad vemos una serie de elementos que no hemos explicado: components, helpers y behaviours. Los componentes fueron creados para asociar una serie de comportamientos polimórficos a distintos controladores en un solo archivo php. De esta forma agrupo comportamientos iguales en un solo lugar y los uso en tantos como sea requerido. Los Helpers y los Behaviours también son una extensión a nuestro modelo mvc y también sirven para agrupar en un solo lugar tanto vistas comunes de datos como comportamientos, respectivamente. Es decir que el Framework que hemos elegido utiliza muchas por no decir todas las ventajas de la programación orientada a objetos. Esto nos permite realizar aplicaciones flexibles, escalables y seguras.

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

Curso/ Grupo Proyecto K-4071 Sistema de gestión de pacientes Grupo 03 Versión Fecha HABILITACION PROFESIONAL 1.0

Figura 3 – Diagrama de actividades: “Login

El fundamento de la utilización de los diagramas de actividades se basa en la falta de profundización a la que nos dejan librados los casos de uso. Es decir que si bien estos se centran en describir qué sucedería si se ejecutara su curso normal o su curso alternativo no se explica de manera gráfica cuáles son las actividades que tengo que cumplimentar para concretar un determinado objetivo. El diagrama de actividades me permite por un lado mostrar los roles dentro de la plataforma que realizan las actividades y por otro como es el flujo de estas actividades para que el objetivo se lleve a cabo con éxito. Un mismo diagrama puede describir uno o varios casos de uso con lo cual es una herramienta de complemento a los casos de uso fundamental.

Página 8 de 10

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

El diagrama de actividad de “Login” describe el proceso de inicio de sesión en el sistema g-pac08. Se muestran las distintas actividades y sus flujos para llevar a cabo el objetivo final: “Usuario logueado con privilegios según su rol”.

Curso/ Grupo Proyecto K-4071 Sistema de gestión de pacientes Grupo 03 Versión Fecha HABILITACION PROFESIONAL 1.0

Figura 4 – Diagrama de actividades: “Turnos

El diagrama que se muestra en la figura 4 describe el proceso de solicitud de turnos. Vemos claramente que este proceso puede ser disparado por dos roles distintos de la plataforma: “Secretariay “Paciente”. Es decir que sin haber leído ni la especificación del caso de uso ni cualquier otra documentación del sistema, notamos rápidamente que los turnos pueden ser realizados tanto por parte del Paciente con su usuario logueado al sistema, como también por parte de la secretaria en nombre del usuario existente en el sistema.

Curso/ Grupo Proyecto

Curso/ Grupo

 

Proyecto

K-4071

Sistema de gestión de pacientes

Grupo 03

Versión

Fecha

HABILITACION PROFESIONAL

1.0

20/10/2009

Curso/ Grupo Proyecto K-4071 Sistema de gestión de pacientes Grupo 03 Versión Fecha HABILITACION PROFESIONAL 1.0

Figura 5 – Diagrama de actividades: “Historias Clínicas

El último diagrama descripto en la figura 5 nos muestra cuáles son las actividades que deben realizar o el médico, o el paciente para acceder a los datos de una historia clínica. En el primer caso puede darse la situación en un médico quiera anticiparse al turno siguiente entonces puede acceder a la ficha o historia clínica del paciente que se va a atender. De esta forma el médico no sólo gana tiempo sino se que se le hace mucho más claro el proceso de diagnóstico del paciente, sin tener que volver a rearmar la historia clínica del paciente. En el caso del paciente es claro que el centro médico para el que desarrollamos la aplicación quiere cierta restricción con respecto al permiso de visualización de historias clínicas. Es por este motivo que para que el paciente pueda visualizar su historia clínica, la Secretaria debe previamente autorizarlo.