Gestion de Citas

UNIVERSIDAD NACIONAL HERMILIO VALDIZÁNEAP. INGENIERÍA DE SISTEMASANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN

UNIVERSIDAD NACIONAL HERMILIO VALDIZÁNFACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMASE.A.P. Ingeniería de Sistemas

ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN

TRABAJO DE APLICACIÓN

TEMA

Gestión de citas en el Hospital Regional Hermilio Valdizán

Profesora: Ing. Jorge Culantres Santos

Alumnos: EUGENIO FALERA, Dalwin Abel.GAVIDIA CASTILLO, Kelwin.VALER BEJARANO, Jhersy.

HUÁNUCO-PERÚ2009

Pág. 1


INTRODUCCIÓN

El presente trabajo de aplicación de teorías de sistemas de

información que comprende la etapa de análisis y diseño del

sistema, busca estudiar (entender) la gestión de citas en el

Hospital Regional Hermilio Valdizán como un sistema; comprendido

esto, necesitamos aplicar un adecuado estudio.

Para este desarrollo necesitamos evaluar nuestro sistema desde

diferentes perspectivas (diagrama de objetos, diagrama de casos

de uso, diagramas de actividades, diagrama de secuencias,

diagrama de colaboraciones, diagrama de clases, etc.)

Este modo de hacer las cosas tiene que ver con el ciclo de vida

de un proyecto o software. Lo primero que se trata de hacer es

el análisis, luego se vuelcan el diseño, la implementación y la

puesta en marcha.

Pág. 2


DEFINICIÓN DE OBJETIVOS

OBJETIVO GENERAL

“Analizar y diseñar el sistema de gestión de citas del

Hospital Regional Hermilio Valdizán para proponer

finalmente un sistema de información.”

OBJETIVOS ESPECÍFICOS

“Estudiar el caso de gestión de citas actual.”

“Obtener las necesidades del caso.”

“Diseñar un nuevo sistema de gestión de citas con los

requerimientos del usuario.”

“Proponer el nuevo sistema del caso.”

Pág. 3


Especificaciones

PRESENTACIÓN DE LA ORGANIZACIÓN

HOSPITAL REGIONAL HERMILIO VALDIZÁN MEDRANO DE HUÁNUCO

1. GENERALIDADES

El Hospital Regional hermilio Valdizán Medrano es un Órgano

desconcentrado de la Dirección de Red de Salud Huánuco que

tiene la misión de proteger la dignidad personal, promoviendo

la salud, previniendo las enfermedades y garantizando la

atención integral de salud de todos los habitantes de la

Región de Huánuco; proponiendo y conduciendo la políticas

sanitarias en concertación con todos los sectores y donde se

realice investigación y docencia.

2. DOMICILIO LEGAL

El Hospital Regional “Hermilio Valdizán Medrano” de Huánuco

tiene su domicilio legal en el Jr. Hermilio Valdizán N° 950,

Distrito de Huánuco; Provincia de Huánuco y Departamento de

Huánuco.

3. VISIÓN

Ser un Hospital acreditado, lider en la Región Centro

Oriental, con infraestructura, equipos modernos y recursos

humanos suficientes, que brinden atención especializada con

calidad, equidad, integridad e interculturalidad y donde se

realice investigación y docencia.

4. MISIÓN

Brindar servicios de salud especializadas a la Región Huánuco

con equidad, integridad, interculturalidad y calidad basado

Pág. 4

PARTE UNO


en principios morales, éticos y humanos, que busquen la

recuperación y rehabilitación física y mental de nuestros

usuarios.

5. OBJETIVOS ESTRATÉGICOS

Los Objetivos Estratégicos del Hospital son los siguientes:

a. Garantizar el acceso y la atención integral con servicios

de salud de calidad adecuados a las necesidades de la

población y bajo criterios de equidad.

b. Proteger la vida y salud de todas las personas desde su

concepción y durante sus ciclos de vida hasta su muerte.

c. Lograr que todos los niños reciban lactancia materna

exclusiva, ablactancia nutritiva y adecuada nutrición

infantil.

d. Impulsar una adecuada política de gestión de los recursos

humanos a través de capacitación permanente.

e. Disminuir la morbi-mortalidad de la población de Huánuco,

mediante actividades integrales de salud y mejorar la

calidad de salud al usuario en el año 2006.

6. DIAGNÓSTICO SITUACIONAL

La planificación estratégica por resultados para el 2009,

exige una drástica implementación de actividades en el

Hospital Hermilio Valdizán. En el área de informática se

viene desarrollando la migración del antiguo sistema de datos

(en DOS) a un mejor gestos de datos y aplicaciones (Base de

datos MySQL e Interfaz de usuario en Java).

Pág. 5


Análisis

1. NOMBRE DEL SISTEMA: Gestión de citas

2. DESCRIPCIÓN DEL NEGOCIO ACTUAL

El paciente -que de aquí en adelante se denominará «cliente»-

que llega al Hospital Hermilio Valdizán Medrano de Huánuco por

consultorio externo (Ej. paciente ambulatorio1) se puede acercar

donde la entrada principal del Hospital para informarse del

cronograma de atenciones (Días en que los médicos por

especialidad no estarán disponibles) del presente mes. El

encargado de hacer los cronogramas mensuales es la Unidad de

Personal «1».

Existen tres tipos de cliente: paciente estándar, paciente

asegurado al Seguro Integral de Salud, y pacientes del Seguro de

Policías. Al mismo tiempo un paciente puede ser representado por

otra persona (Ej. Un menor de edad no puede solicitar una cita,

necesita de un apoderado). No hay preferencia en ninguno de los

casos.

El cliente lo primero que debe hacer para solicitar una cita es

obtener una «ficha de atención»2 en el área de Triaje. En un

flujo normal del proceso un cliente obtiene una ficha siempre y

cuando haya atención de la especialidad requerida y cupos3

disponibles. Si los últimos dos casos mencionados no están

disponibles, un empleado de esta área registra en un libro

nuestros datos personales y reserva automáticamente una cita

para la próxima fecha disponible.

Si se trata de un cliente estándar lo siguiente que debe hacer

es pagar un determinado monto por la consulta.

1 Paciente que necesita tratamiento médico por períodos de tiempo.2 Ficha que lleva impreso el nombre de una especialidad y un número de orden.3 Cita no ocupada.

Pág. 6

PARTE DOS


Más tarde el cliente debe acercarse al área de Admisión4

(posicionado en la entrada principal del Hospital) para

solicitar nuestro historial; para ello ofrecemos al personal en

la ventanilla nuestros datos personales. Nuestra solicitud será

validada por el trabajador de Admisión cuando presentemos la

documentación requerida (El cliente estándar presentará su

recibo de monto pagado por su derecho de consulta; el cliente

SIS presentará sus papeles del SIS; y el Policía asegurado

presentará su carné de seguro) y documento de identidad. Una vez

que el empleado de Admisión valida la solicitud procede a la

búsqueda del código de historial del cliente; ingresa los datos

personales del paciente requeridos por el sistema de búsqueda en

base de datos (programa en DOS) disponible en ese área, y si el

cliente está registrado en la base de datos del Hospital

entonces se obtiene como respuesta el código del historial

médico. Un proceso alternativo es cuando se trata de un cliente

nuevo, entonces se registran datos detallados de la persona en

la base de datos y se genera un código del nuevo historial.

Luego, otro de los empleados del área de Admisión es el

encargado de la búsqueda física del historial en los paquetes

documentados por fecha. La búsqueda es sistemática y no tan

rígida. Un proceso alternativo es el siguiente: si algún

historial no es encontrado se le notifica al empleado de la

ventanilla para que genere un nuevo código de historial (no

olvidar que el cliente a quién pertenecía el historial médico ya

está registrado en la base de datos del Hospital). Una vez

encontrados una cierta cantidad de historiales, estos están a

disposición del área de Triaje en otra ventanilla.

El área de Triaje recoge los historiales y hace llamadas

sistemáticamente a los pacientes (se sirve de las fichas de

atención) para la medición de sus signos vitales según sea la

especialidad designada. De ahí el paciente es derivado a la

especialidad (departamento) que solicitó, donde tiene que

esperar el turno que le asignaron.

4 Área donde se encuentran almacenados los historiales.

Pág. 7


3. DIAGRAMA DE CASOS DE USO DEL NEGOCIO

3.1. IDENTIFICANDO LOS LÍMITES DEL SISTEMA

¿Cuál es el límite de este sistema?

El sistema trata sobre la Gestión de Citas por Consulta Externa.

3.2. IDENTIFICANDO ACTORES

Comenzamos identificando los actores de este sistema, los

actores son cualquier cosa que interactue con el sistema. Nos

hacemos las siguientes preguntas:

¿Quién usa el sistema?

El cliente

¿Qué sistemas usan este sistema?

Triaje

Unidad de Personal

Área de Admisión

¿Quién provee información al sistema?

Unidad de personal

Cliente Unidad de Personal Triaje Admision

Pág. 8


IDENTIFICANDO CASOS DE USO

Created/modified by: <name>Date: <2009-01>

Approved by: <name>Date: <approval date>

Generar cronogramaUnidad de Personal

Obtener lista de citas

Consultar cronograma

<<include>>

Triaje

Consultar la atencion del servicio

<<extend>>

Pedir una cita

Cliente

Buscar Historial

Ceder Historial

Admision

Pedir Historial

Pág. 9


Diseño propuesto

1. REQUERIMIENTOS DEL SISTEMA5

El sistema debe permitir elaborar un cronograma de fechas

disponibles de atenciones.

Registrar clientes en todos los casos que se trate por

consultoría externa.

Reservar citas para una fecha determinada.

Manejo de cancelación de citas por parte de los clientes.

Debe ser coherente con las políticas y metas del

Hospital.

Elaboración de listas de citas.

2. REQUERIMIENTOS NO FUNCIONALES

Usabilidad: Se necesitará una capacitación a los usuarios

(trabajadores del Hospital y clientes).

Sistema: Se ejecutará en cualquier sistema operativo.

Seguridad: Conceptos de seguridad de base de datos y

generación de backups diarios. Consistencia de datos6.

Integración con otros sistemas: Puede interactuar con

Sistema de Caja, Sistemas de Atención por Especialidad, y

Unidad de Seguros.

Detección, Manejo y Reporte de errores: El sistema estará

desarrollada con lenguaje de programación que soporte

errores (Java o PHP).

Redundancia: El sistema deberá manejar duplicidad de

datos.

Rendimiento: La velocidad del sistema dependerá del

hardware. El sistema usará la tecnología de hilos.

5 Se trata de la Gestión de Citas.6 Los datos que se ingresan deben ser coherentes.

Pág. 10

PARTE TRES


3. Analisis de riesgo:

Gente

¿La inexperiencia de los diseñadores del software

crearán problemas?

¿Cómo podemos asegurarnos que el sistema sea fácil para

personas no técnicas?

Sistema

¿Podemos tener éxito si no tenemos una interfaz web?

¿Cómo podemos prevenir la perdida de datos y cita del

cliente en una falla del sistema?

¿Qué pasa si el sistema se llena inmediatamente con

citas?

¿Cómo manejamos el colapso de la base de datos?

Tecnología

¿El negocio posee los equipos necesarios de soporte del

sistema?

4. Factores de mercado: Un porcentaje de los clientes que se

atienden en el hospital “Hermilio Valdizán”, no manejan el

tipo de tecnología Internet, para ese caso existe un

representante del cliente, el cual se encargaría de

establecer una cita para el cliente.

5. SISTEMA PROPUESTO: Gestión de Citas por medios: Desktop y

Página Web.

6. DIAGRAMA DE CASOS DE USO DE NIVEL DEL SISTEMA

1. IDENTIFICANDO LOS LÍMITES DEL SISTEMA

¿Cuál es el límite de este sistema?

El sistema trata sobre la Gestión de Citas por Consulta Externa.

2. IDENTIFICANDO ACTORES

Comenzamos identificando los actores de este sistema, los

actores son cualquier cosa que interactue con el sistema. Nos

hacemos las siguientes preguntas:

Pág. 11


¿Quién usa el sistema?

El cliente

Representante del Cliente

¿Quién provee información al sistema?

Unidad de Personal

Triaje

Gestor de citas

¿Sucede algo automáticamente al momento de usar este

sistema?

Gestor de citas

Admision

(f rom Actors)


(f rom Actors)

Cliente

(f rom Actors)

Unidad de Personal

(f rom Actors)

Descripcion de los actores:

Cliente: Una persona natural o juridica que desea ser

atendida en el hospital.

Estados del Cliente

Estado Descripción

Pendiente El cliente ha

solicitado/reservado una

cita.

Confirmado El cliente ha confirmado la

atención de su cita a una

fecha dada.

Anulado El cliente ha cancelado su

cita.

Representate del cliente: Cualquier persona pertenezca

al Hospital o no (Ej. Pariente del paciente «cliente»)

que solicite una cita a nombre del cliente. El Personal

del Área de Triaje y/o Admisión podrían hacer el papel

de Representante del Cliente dada las siguientes

condiciones:

Pág. 12


El cliente no conoce el sistema y va donde Triaje

y/o Admisión para solicitar una cita.

El cliente es un menor de edad y necesita de un

tutor o apoderado para solicitar una cita.

El cliente se encuentra indispuesto para solicitar

una cita, por lo cual otorga poder a un

representante.

Unidad de Personal: Es el responsable de procesar un

cronograma por mes.

Gestor de citas: Es el software que se encarga de

reportar, actualizar y borrar citas no pendientes.

Triaje: Se encarga de confirmar las citas.

Pág. 13


DIAGRAMA DE CASOS DE USO DEL NIVEL DE SISTEMA PROPUESTO


(f rom Actors)

Generar Cronograma

(from <Use Case Name>)

Unidad de Personal

(f rom Actors)

Establecer Cita Web


Imprimir Ficha de Atencion


Confirmar Cita


Establecer Cita


<<include>>

Consultar Cronograma


<<include>>

<<include>>

Cambiar Estado de la Cita


Cliente

(f rom Actors)

Solicitar Historial


<<include>>

Buscar Historial


<<include>>

Admision

(f rom Actors)

Pág. 14

Aceptar Cancelar

Ayuda Registrarse

HOSPITAL REGIONAL HERMILIO VALDIZÁN DE HUÁNUCO

Usuario:

Contraseña:


7. DISEÑO DE INTERFACES (PROTOTIPO)

Vista 1.

Pág. 15

El usuario ingresa sus nombres y apellidos.

El usuario ingresa un código según tipo de usuario: Cliente: Número de

historial Personal de Admisión:

Código de personal Trabajadores de

Unidad de Personal: Código de Personal

HOSPITAL REGIONAL HERMILIO VALDIZÁN MEDRANO DE HUÁNUCOGESTIÓN DE CITAS

D L M M J V S

1 2 3 4

5 6 7 8 9 10 11

12 13 14 15 16 17 18

19 20 21 22 23 24 25

26 27 28 29 30 31

Sábado, 18 de julio del 2009

Calendario de AtenciónBienvenido Señor(a):Nombre de Usuario

Cerrar sesión

Ítem Especialidad Médico Cantidad cupos Seleccionar

1 Medicina General Dr.Chanamé 20

2 Traumatología Dr. Vitor Sierra 5

NOTA: Para confirmar la cita tiene que presentar la documentación necesaria. Ej.: Recibo si es un cliente normal.Una vez reservado la cita tiene un plazo de 7-8am de la fecha de la cita para confirmarla, en Admisión.

Establecer cita

Ayuda

Cita Pendiente

1. Nombre de la Especialidad. Ej.: Traumatología.2. Nombre del Médico con el que se va a tratarse. Ej.: Dr. Vitor Sierra3. Fecha

Cancelar CitaSi desea cancelar su cita pendiente haga click en el siguiente botón.


Vista 2.

PRECONDICIÓN: Datos validados del cliente:

De (1) y (5)

Pág. 16

Aceptar


_____________________________________FICHA DE ATENCIÓN

_____________________________________

1. Nombre y Apellidos del Cliente2. Código de Historial3. Nombre de la Especialidad. Ej.: Traumatología.4. Nombre del Médico con el que se va a tratarse. Ej.: Dr. Vitor Sierra5. Fecha

CONSERVAR Y PORTAR ESTA FICHA ES NECESARIO PARA ATENDERSE EN TU ESPECIALIDAD

Salir Imprimir

Escribir correctamente donde dice usuario y contraseña.Ingrese su contraseña según tipo de usuario:Si es cliente ingresar su código de historial.Si es trabajador de Admisión ingresar su código de personal.Si es personal de Unidad de Personal ingresar su código de personal.Si usted es cliente nuevo haga clic en registrarse.

Salir


Vista 3.

PRECONDICIÓN: Datos validados de (2):

De (2)

Vista 4.

PRECONDICIÓN: de (1)

Pág. 17

Reservar cita

Ayuda


NUEVO USUARIO

Apellidos: Nombres:

Sexo: Masculino Femenino

DNI:

Domicilio Actual:

Fecha de Nacimiento: 14

Teléfono/ Celular:

Grado de Instrucción:

Ocupación:

Mayo 1990

Religión:

Estado Civil:

Padre:

Apellidos Nombres

Madre:

Apellidos Nombres

Nombre de la persona responsable:Apellidos Nombres

Edad:

Domicilio:

DNI:

Teléfono:

Aceptar Cancelar


Vista 5.

PRECONDICIÓN: n de (1)

Pág. 18

Registrarse

Su código de historial es:

NOTA: Este número será necesario para ingresar a su cuenta la próxima vez

Salir

Hey!

Número de Historial generado


Vista 6.


Pág. 19

Aceptar

HOSPITAL REGIONAL HERMILIO VALDIZÁN MEDRANO DE HUÁNUCOGESTIÓN DE CITAS

D L M M J V S

1 2 3 4

5 6 7 8 9 10 11

12 13 14 15 16 17 18

19 20 21 22 23 24 25

26 27 28 29 30 31

Sábado, 18 de julio del 2009

Calendario de AtenciónBienvenido Señor(a):Nombre de Usuario

Cerrar sesión

LISTA DE CITAS

Ítem Nombre y Apellidos Historial Especialidad Médico

1 Jhersy Valer Bejarano HC001 Traumatología Médico3

2 Kelwin Gavidia castillo HC003 Medicina Médico2

3 Darwin Eugenio Falera HC002 Oftalmología Médico2

… … … … …

Estado Apellidos:

Nombres:

Código:

Buscar

Imprimir ficha

ConfirmarCancelar


Vista 7.

PRECONDICIÓN: Datos validados del Personal de Admisión.

De (1)

Pág. 20

Aceptar


_____________________________________NOMBRE DE ESPECIALIDAD

Nº DE ORDEN_____________________________________

1. Nombre y Apellidos del Cliente2. Código de Historial3. Nombre del Médico con el que se va a tratarse. Ej.: Dr. Vitor Sierra4. Fecha

CONSERVAR Y PORTAR ESTA FICHA ES NECESARIO PARA ATENDERSE EN TU ESPECIALIDAD

Aceptar


Vista 8.


Pág. 21

Imprimir ficha

HOSPITAL REGIONAL HERMILIO VALDIZÁN MEDRANO DE HUÁNUCOUNIDAD DE PERSONAL

Nuevo Médico

Ver Lista por especialidad:Ver

Buscar

Generar Cronograma

Ítem Medico Especialidad Días no Disponibles

CRONOGRAMA DE ATENCIONES

Apellidos:

Nombres:

BUSCAR MÉDICO


Vista 9.

PRECONDICIÓN: Datos validados de trabajador de Unidad de

Personal.

De (1)

Pág. 22

Aceptar


Arquitectura1. PRIMER INTENTO DE UNA ARQUITECTURA PARA EL SOFTWARE7

¿Trabajar con Paquetes, Subsistemas o Dominios?

Se dio por conveniente utilizar una arquitectura de paquetes,

pues creemos no tener dominios que crear, y no podemos detectar

subsistemas en el negocio debido a que nuestro sistema ya está

delimitado.

Acceso a Sistema

Administrar Cronograma

Adminstrar Cita Manejamiento de Historial

IAdministrarCita

establecerCita()ingresarDatos()

ingresarDetallesCita()aceptar()

mostrarFichaAtencion()mostrarDetalleCita()

IAdministrarCronograma

cargarDatos()mostrarCronograma()

IManejamientoHistorial

mostrarListaDeCitasActual()cambioDeEstadoCita()buscarCitaHistorial()

<<realizes>>

<<realizes>>

<<realizes>> <<realizes>>

7 Basado en el Apéndice 2.

Pág. 23

PARTE CUATRO


Pág. 24


Diseño de Base de Datos1. DISEÑO LÓGICO

DESCRIPCIÓN DE TABLAS:

Paciente: Estarán registrados todos los pacientes, las

personas que fueron atendidas o que necesitan de atención

medica.

Representante Paciente: registra a las personas que hacen

representación de un paciente que es menor de edad o no

está en condiciones de hacerlo por sí mismo.

Pág. 25

PARTE CINCO


Historial: registra los diagnósticos realizados a los

pacientes, para el sistema solo será de utilidad el código

de historial que este asignado un paciente para efectuar

una reservación de cita, de no contar con este deberá

dirigirse a admisión para que se asigne un historial.

Medico: Estarán registrados todos médicos, los

especialistas de la medicina que laboran en H.R. HERMILIO

VALDIZAN.

Especialidad Médica: Registra las especialidades que

ofrece el H.R. HERMILIO VALDIZAN.

Cronograma de Atención: registra los días no disponibles

de los médicos de una determinada especialidad durante el

mes en curso.

Cita: registra todas las solicitudes de cita que realizan

los pacientes, las cuales deberán ser confirmadas para que

pasen en espera de atención médica.

Pág. 26


Glosario«1» UNIDAD DE PERSONAL

Es la unidad orgánica encargada de lograr los recursos humanos

necesarios y adecuados para el cumplimiento de los objetivos

estratégicos y funcionales del Hospital; depende de la Oficina

de Administración y tiene asignados los siguientes objetivos

funcionales

a) Lograr la aplicación de las políticas y normas de carácter

interno y específico de administración y desarrollo de

personal; así como proponer su implementación, actualización

e innovación.

b) Gestionar, programar y registrar el pago de las

remuneraciones, pensiones, beneficios y bonificaciones.

c) Proponer la actualización e innovación de normas de

administración y desarrollo de personal.

d) Proponer al órgano de Dirección Ejecutiva los desplazamientos

del personal entre unidades orgánicas y/o puestos de trabajo,

en el marco de la normatividad vigente.

e) Implementar oportunamente el Cuadro para Asignación de

Personal del Hospital para dotarlo de los recursos humanos

necesarios.

f) Formular el Presupuesto Analítico de Personal.

g) Identificar y satisfacer las necesidades de recursos humanos,

que deben asignarse a los cargos o puestos de trabajo,

establecidos en el Cuadro para Asignación de Personal, para

desarrollar los procesos y sistemas organizacionales del

Hospital.

h) Establecer y ejecutar el planeamiento, programación,

reclutamiento, selección, contratación, registro, asignación

e inducción del personal para cubrir los puestos de trabajo o

cargos con financiamiento presupuestal.

Pág. 27

APÉNDICE 1


i) Programar y ejecutar el control, desarrollo y capacitación

del personal, para que desempeñen las capacidades y

habilidades requeridas para el logro de los objetivos

funcionales asignados.

j) Sistematizar y mantener actualizado el registro de

información de los recursos humanos del Hospital para la toma

de decisiones y la planificación del desarrollo de los

recursos humanos.

k) Desarrollar la cultura organizacional y asistir técnicamente

a la Dirección Ejecutiva para lograr el compromiso del

personal con la visión y misión institucional.

l) Mantener un clima laboral adecuado para el cumplimiento de

los fines del Hospital.

m) Lograr que se establezca en la unidad orgánica y en el ámbito

de su competencia y objetivos funcionales el control interno

previo, simultáneo y posterior.

Pág. 28


ArquitecturaSTEREOTYPE PACKAGES

Package: Un contenedor, representado como un folder, que puede

contener artefactos de diferentes tipos. Los paquetes en

Rational RequisitePro pueden contener requerimientos,

documentos, vistas y otros paquetes. Los paquetes en

RationalRose pueden contener elementos de un modelo y otros

paquetes.

Un paquete es un elemento general de un modelo propuesto que

organiza elementos del modelo dentro de grupos.

Subsystem Package: Aunque esté muy relacionado a un sistema, es

un grupo de elementos del modelo que tienen comportamiento y

objetivos específicos. Un subsistema es un paquete estereotipado

y es representado por el icono de un paquete con el estereotipo

«subsystem».

Human Resource Subsystem

<<subsystem>>

Domain Package: Contiene dominios. Los dominios son únicamente

modelados en un modelo de datos. Sin embargo, podemos usar el

nombre de un dominio como un tipo de dato común/habitual en uno

u otro modelo de objetos o modelo de datos.

User Interface<<domain>>

Pág. 29

APÉNDICE 2


2. PATRÓN DE ARQUITECTURA DE TRES NIVELES

Diseñar en 3 capas...trata sobre no poner todo tu código en las

interfaces de usuario de tu sistema (IU). Para subsanar esto, la

idea es tener 3 niveles de funcionalidad bien definidos:

Capa de presentación, con nuestras IU (formularios

windows, páginas HTML,..) y sus controles visuales

(textBox, comboBox, dataGrids) junto con sus eventos (los

click y etc.)

Capa de negocio (lógica del dominio), aquí ira todo el

código que define las reglas de negocio (cálculos,

validaciones). Surge de los procesos que hemos encontrado

en el análisis.

Capa de acceso a datos, el código que permite acceder a

las fuentes de datos. Esencialmente trata sobre 4

operaciones básicas, llamadas CRUD (por Create-Retrieve-

Update y Delete), que se realizan sobre cualquier fuente

de datos (normalmente alguna base de datos relacional).

Interfaz de usuario

Reglas del Negocio

Base de datos

Ejemplo de Arquitectura de Tres Niveles

En 3 tiers la ejecución está distribuida:

Front-End, donde se ejecutan las IU del cliente. Los Browsers.

MiddleWare, recibe solicitudes de las IU a través de la red.

Estos son mensajes (XML, SOAP,...) que se envían mediante

protocolos de transporte (HTTP,TCP,UDP,..). El Servidor Web.

BackEnd, nuestra base de datos ó algún proceso externo a nuestro

software.

Por último "Modelo-Vista-Controlador" es un patrón de diseño de

arquitectura que está asociado a la idea de 3 capas (3 layers),

aunque su objetivo es aún más fino. El mismo se centra en la

Pág. 30


secuencia de ejecución, desde que se produce un evento en la

capa de presentación hasta que el mismo es atendido en forma

completa.

Las partes que lo componen son:

Vista: componente que recibe el estímulo y genera un evento, que

puede involucrar a otros objetos de la IU. Corresponde a la capa

de presentación, y al Front-End(en Web:Html, JavaScript,...),

aunque suele haber parte en el MiddleWare (controles

ASP,PHP,...)

Modelo: componente asociado a las entidades de negocio (cliente,

factura, pago,...). En 3 capas incluye parte de la capa de

negocio (entidades, pero no lógica de procesos) y toda la capa

de acceso a datos. En 3 tiers se instala en el BackEnd (la BD) y

parte en el MiddleWare (entidades de negocio y acceso a datos).

Controlador: componente asociado a la lógica de procesos del

negocio. En 3 capas la parte que faltaba y en 3 tiers en el

MiddleWare.

3. Pipe and Filter

Usar la arquitectura de Pipes and Filters divide una tarea de

procesos más grande en una secuencia de pasos más pequeña, pasos

de procesamientos más pequeños (filters) que sean conectados por

los canales (pipes).

Pág. 31


Cada filtro expone una interfaz muy simple: Recibe el mensaje

en el pipe de entrada, procesa el mensaje y publica los

resultados en el pipe de salida. El pipe conecta un filter con

el siguiente, enviando mensajes desde un filter al siguiente.

Porque los componentes utilizan la misma interfaz, estos pueden

ser compuestos en diversas soluciones conectando a los

componentes con diferentes pipes. Podemos agregar nuevos filter,

omitir alguno existente, o cambiarlos en una nueva secuencia

todo sin tener que cambiar los filter. La conexión entre filter

y pipe a veces es llamada puerto. En la forma básica, cada

componente tiene un puerto de entrada y otro de salida.

Pipes and Filter describen un estilo de arquitectura fundamental

para los sistemas de mensajería: Los pasos de proceso

individuales (filter) son encadenados juntos a través de los

canales de la mensajería (pipes). Muchos patrones en esta y las

secciones siguientes, tales como patrones routing y

transformation se basan en el estilo de arquitectura Pipes and

Filter. Esta les permite fácilmente combinar patrones

individuales en soluciones más grandes.

Pipeline Processing (Proceso de tubería)

Conectando componentes con asincrónico Message Channels permite

que cada unidad en la cadena funcione en su propio hilo o su

propio proceso. Cuando una unidad ha terminado el proceso de un

mensaje, puede enviar el mensaje al canal de la salida y

comenzar inmediatamente a procesar otro mensaje. No tiene que

esperar los componentes subsecuentes para leer y para procesar

el mensaje. Esto permite que los mensajes múltiples sean

procesados concurrentemente mientras que pasan a través de las

etapas individuales. Por ejemplo, después de que se haya

desincriptado el primer mensaje, puede ser pasado al

componente de autentificación. Al mismo tiempo, el mensaje

siguiente esta listo para ser desincriptado (véase la figura).

Llamamos tal configuración un Pipeline Processing (Proceso de

tubería) porque los mensajes atraviesan los filtros como el

Pág. 32


líquido atraviesa un pipe. Cuando un procesamiento secuencial es

comparado estrictamente, un procesamiento Pipeline puede

significativamente aumentar el rendimiento del sistema.

Pipeline Processing with Pipes and Filters

Parallel Processing

Incrementando el Rendimiento con procesamiento Paralelo

4. SOA Arquitectura Orientada a Objetos

Los componentes del sistema encapsulan datos y operaciones que

deben utilizarse para manipular dichos datos. La comunicación y

coordinación entre componentes se realiza mediante envío de

mensajes.

En esencia es un sistema donde se enfatiza el empaquetamiento de

datos y operaciones que permiten manipular y acceder a dichos

datos.

Aquí los subsistemas están definidos alrededor de los datos y

sus funciones asociadas. Una vez identificado los subsistemas

pueden interrelacionarse de cualquier manera que necesiten para

cumplir el trabajo del sistema.

Pág. 33


Tomar Pedido Enviar Pedido

Procesar Pago

Ejemplo de Arquitectura Orientada a Objetos

Este enfoque enfatiza las dependencias entre las piezas del

sistema mientras muestra cada función como una pieza separada

autocontenida. En contraste, en la arquitectura de tres niveles

cada función existe en tres lugares, la interfaz de usuario, las

reglas de negocio y la base de datos. En la arquitectura Pipe

and Filter, las funciones pueden relacionarse sólo a través de

los datos.

Pág. 34

Documents

Gestion de Citas