Arquitectura para Observatorio Nacional de Oferta y...
-
Upload
nguyenmien -
Category
Documents
-
view
216 -
download
0
Transcript of Arquitectura para Observatorio Nacional de Oferta y...
Arquitectura para Observatorio Nacional de Oferta y Disponibilidad de productos Farmacéuticos.
Presentado por:Renzo David Rojas Silva.
Director:Ing. Julio Ernesto Carreño Vargas, MsC.
Aplicación Práctica.
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.2
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.3
Justificación.
1. Contexto.
● Gasto 6.8% PIB.
● Gasto per cápita 533 USD.
● Tercero en gasto dentro de la región.
○ Argentina.
○ Brasil.
● Distribución.
○ 76% Sector público.
○ 13,9% Gasto de bolsillo.
8%
4
Justificación.
1. Contexto.
Gasto de bolsillo.
Consultas médicas. Hospitalizaciones.Exámenes médicos. Medicamentos.5
Justificación.
1. Contexto.
Medicamentos.
● Precios de medicamentos.
○ Medicamento de MARCA alcanza 17,31 veces su precio en comparación
a otros países.
○ Medicamento GENÉRICO alcanza ⅙ del precio de un medicamento de
MARCA.
● Existe poca disponibilidad y acceso a la información técnica e independiente
sobre los medicamentos comercializados en el país.
○ No existe criterio para evaluar satisfacción.
○ Se encuentra en manos del prescriptor.
○ Se encuentra en manos de la publicidad.
6
Justificación.
2. Pregunta.
¿De qué manera se puede fortalecer el
conocimiento de las personas para ejercer
su derecho a la libre elección al momento
de la compra de productos farmacéuticos?
7
Propuesta.
Observatorio Nacional de Oferta y Disponibilidad
de productos farmacéuticos.
● ¿Observatorio?
○ Consultas.
○ Información.
○ Recomendaciones.
● ¿Nacional?
○ Sector Farmacéutico.
● ¿Productos farmacéuticos?.
○ Comercial.
○ Genérico.
● ¿Oferta y Disponibilidad?
○ Resultados basados
en lo que existe.
○ No basado en
información
desactualizada.
● ¿Por donde comenzar?
8
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.9
Objetivos.
1. Objetivo General.
Definir una arquitectura para el desarrollo de un
observatorio nacional de oferta y disponibilidad de
productos farmacéuticos.
10
Objetivos.
2. Objetivos Específicos.
● Realizar la caracterización de un observatorio nacional de oferta y disponibilidad
de productos farmacéuticos mediante un proceso de ingeniería de requerimientos.
● Diseñar una arquitectura orientada a BPM y ESB que permita el desarrollo de un
observatorio nacional de oferta y disponibilidad de productos farmacéuticos.
● Evaluar la arquitectura diseñada para el desarrollo del observatorio.
● Desarrollar un prototipo que permita probar la arquitectura diseñada en un
ambiente de pruebas dentro del dominio del problema.
11
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.12
Metodología.
1. AUP - Agile Unified Process.
Inicio Investigar. Documentar.
DiseñoEspecificación
de requerimientos.
Diseño de Arquitectura.
Evaluación Arq.
Implementación.Creación del
prototipo.
Verificación Componentes. Sistema. Escenarios.
13
Metodología.
2. Proceso.
Análisis.
Estado del arte.
Comparación. Oportunidad.
Problemas
del sector.
Consumidores. Droguistas.
Caracterización.
Indicaciones
Arquitectura.
Especificación Req.
Obj1
Arquitectura Obj2
Componentes Despliegue.
Genérica.
Evaluación Obj3
Probar Obj4
Construcción.
14
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.15
2. Proceso general.
Ingeniería de requerimientos - Loucopoulos.
Análisis.
1. Literatura sobre el dominio.
2. Análisis de texto. Lenguaje natural.
3. Documento “Especificación de Requerimientos”.
16
Análisis.
1. Resumen.
ASPECTOS
Especializado en sector farmacéutico. x x x x x
Capacidad de acceso desde diferentes plataformas. x x x x
Recomendaciones sobre las búsquedas. x
Resultados basados en localización. x x x x x
Resultados con información actualizada (tiempo real). ~ ~ x
Herramienta para consumidores. x x x x x x
Herramienta para vendedores. x x
Op
en
He
alth
for
To
urists
.
Ob
se
rva
torio
Peru
ano.
Me
dic
am
en
to
acce
sib
les p
lus
Akiz
tá
FD
A -
Dru
g
Sh
ort
ag
es
Ob
se
rva
torio
.
18
Análisis.
4. Consumidores.
• Uso inadecuado e irracional de los medicamentos.
• Inequidades en el acceso a medicamentos.
• Oferta, suministro y disponibilidad insuficiente de medicamentos esenciales.
• Baja calidad de la información del mercado farmacéutico.
• Debilidades en rectoría y vigilancia.
¿Qué se propone?
• Observatorio como herramienta para el consumidor.
20
Análisis.
4. Consumidores.
• ¿Fuentes de datos?
• ¿Cómo unir diferentes sistemas?
• ¿Cómo manejar 8000 sistemas externos conectados?
• ¿Cómo lograr escalabilidad en tiempo de ejecución?
• ¿Cómo enviar mensajes a los componentes adecuados?
¿Qué se propone?
• Arquitecturas SOA.
• Componentes ESB. ¿Cómo convencer al droguista de unirse?
21
Análisis.
5. Droguistas.
• Difícil absorción de nuevas tecnologías.
• Desconocimiento de verdadera situación dentro del mercado.
¿Qué se propone?
• Observatorio como herramienta para el droguista.
22
Análisis.
5. Droguistas.
• ¿Cómo brindar información de interés al droguista?
• ¿Cómo ofrecer una ventaja competitiva?
• ¿Cómo ayudar al efectivo y eficiente análisis de una droguería dentro del sector?
• ¿Cómo abrir nuevas puertas para la entrada de nuevos clientes?
¿Qué se propone?
• Arquitectura BPM.
• Orquestador y generador de información.
• ¿Cómo generar información?
23
Análisis.
5.1. Indicadores.
Básicos = #.
● # Dentro de radio de búsqueda.
● # Con medicamento solicitado.
● # Apartado de medicamento.
● # Se ha buscado un
medicamento.
● # Se ha apartado un
medicamento.
● Perfil de consumidores por zona.
Derivados = %.
● % Que no se tenía el
medicamento buscado.
● % De apartados de una droguería.
● Posición en cuanto a apartados
dentro de una zona.
● Posición en cuanto a precio de un
medicamento.
24
Análisis.
4. Obtención de Requerimientos.
Identificación
de actores.
Actividades.
Relación
Actividades/Actores
● Consumidor.
● Droguista.
● Droguería.
● Administrador.
● Actividades vinculadas a problemas anteriores.
● Diagrama de Casos de Uso.
25
Análisis.
6. Actividades.
● Buscar medicamento por nombre comercial.
● Generar recomendación por genérico.
● Buscar droguerías cercanas.
● Buscar medicamento en droguerías.
● Obtener descripción detallada de medicamento.
● Comparar producto comercial contra genérico.
● Apartar medicamento.
● Generar indicadores de negocio.
● Obtener información droguería.
● Conectar sistema.
Problemas del
Sector.
26
Análisis.
4.4. Requerimientos no funcionales.
● Escalabilidad.
● Interoperabilidad.
● Seguridad.
● Enrutamiento.
● Monitoreo.
● Desempeño.
● Diseño.
Escenarios de verificación.
28
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.30
Diseño.
2. Definir entradas.
● Casos de Uso.
● Requerimientos NF.
● Requerimientos Arquitecturalmente Significativos.
○ Complejidad de desarrollo.
○ Número de dependencias.
○ Componentes involucrados.
32
Diseño.
2.1. Requerimientos Arquitecturalmente Significativos.
CÓDIGO CU COMPLEJIDAD NÚMERO DE
DEPENDENCIAS
COMPONENTES
INVOLUCRADOS
CU001 ALTA ALTA ALTA
CU003 ALTA BAJA ALTA
CU011 MEDIA MEDIA MEDIA
CU002 MEDIA BAJA BAJA
CU004 MEDIA MEDIA BAJA
CU005 BAJA MEDIA MEDIA
CU008 ALTA ALTA BAJA33
Diseño.
3.1. Vistas - ESB.
● Datos Externos.
● Virtualización de servicios.
● Base de Datos
Observatorio.
● Estrategia de Inserción.
● Conexiones de las
droguerías al Observatorio.
37
Diseño.
3.1. Vistas - Capas.
● Tot Servicios Utilitarios: 16.
● Tot Servicios de Negocio: 8.
● Tot Servicios de Proceso: 6.
39
Diseño.
3.1. Vistas - Capas.
BPM Consumidor. BPM Proveedor.
BPM Proveedor Asíncrono.
41
Sync. Async.
Polling.
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.46
Construcción.
1. Herramientas - BackEnd.
ESB - MuleSoft.
BPM - Bonitasoft.
Oracle SOA Suite 11g.
BPM Suite.
JDeveloper.
Weblogic.
Oracle Service Bus.
Business Activity Monitoring.
Oracle Database Express Edition 11g.
Oracle Linux 6 Update 4.48
Construcción.
2. Casos de Uso.
CÓDIGO
CU
NOMBRE
CU001 Buscar medicamento por nombre comercial.
CU003 Buscar medicamento en droguerías.
CU011 Apartar medicamento.
CU002 Buscar droguerías cercanas.
CU004 Generar recomendación por genérico.
CU008 Generar indicadores de negocio.
CÓDIGO
CU
NOMBRE
CU012 Iniciar sesión (Droguista).
CU013 Cerrar sesión (Droguista).
CU015 Cambiar estado apartado medicamento.
CU016 Consultar estado apartado medicamento.
● # Dentro de radio de búsqueda.
● # Con medicamento solicitado. 49
Construcción.
3. Procesos.
CU002. Buscar droguerías cercanas.
Procesamiento secuencial.
Medición indicador. 53
Construcción.
3. Procesos.
CU003 Buscar medicamento en droguería.
Procesamiento paralelo dinámico - Llamado a OSB - Excepción de negocio - Medición indicador -
Estrategia de inserción.54
Construcción.
3. Procesos.
CU004 Generar
recomendación
por genérico.
Procesamiento
paralelo estático.
INVIMA.
OBSERVAMED.
57
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.58
Pruebas.
1. Verificación arquitectura.
● Atributos de calidad de Análisis,
● Escenarios específicos
medibles.
● Herramientas Oracle
59
Pruebas.
1. Atributos de calidad - Escalabilidad.
● Balanceador de cargas.
● Oracle Service Bus.
● Algoritmos de balanceo.
60
Pruebas.
2. Escenarios - ES001.
Identificador escenario: ES001.
Nombre: El sistema debe permitir conectar una nueva droguería en
menos de 24 horas.
Atributo de Calidad: Escalabilidad.
Verificación: Con el observatorio desplegado, con dos droguerías
conectadas se procedió a la conexión de una nueva mediante
Web Service en MySQL y otra mediante conector JCA en
MSSQL.
Resultados: Para lograr cada conexión se tomó un tiempo promedio de
52,5 minutos:
-MySQL: 60 minutos.
-MSSQL: 45 minutos.
Estado: CUMPLIDO.
61
Pruebas.
2. Escenarios - ES002
Identificador escenario: ES007.
Nombre El sistema debe responder a una solicitud con una
latencia promedio de 30 segundos con todos los
servicios arriba y disponibles.
Atributo de Calidad: Desempeño.
Verificación: Con el uso de WebLogic se probaron cada uno de
los procesos desarrollados con ayuda de la utilidad
de pruebas de estrés.
Resultados: Los resultados de esta prueba se encuentran en la
tabla "Pruebas de estrés ES008", con cada uno de
los resultados obtenidos por proceso.
Estado: CUMPLIDO.
CONFIGURACIÓN PRUEBA RESULTADOS DE LA PRUEBA
Proceso Hilos Ciclos por
cada hilo
Tiempo
Min(ms)
Promedio(ms) Tiempo May(ms)
FindMedicine 30 1 25246 30733 35676
SeparateMedicineSyn 30 1 568 1900 2434
GetSeparateStatus 30 1 621 1553 2690
RecommendGeneric 30 1 1245 3005 4104
DrugstoreLogin 30 1 556 2334 3663
DrugstoreLogOut 30 1 618 1565 2455
62
Pruebas.2. Escenarios - ES009.
Identificador escenario: ES009.
Nombre: El sistema debe soportar la caída de una Droguería si esta no
se encuentra disponible para realizar consultas, descartándola
de la lista de resultados, y devolviendo la respuesta en un
tiempo promedio de 120 segundos.
Atributo de Calidad: Tolerancia a fallos.
Verificación: Con el observatorio desplegado, se procedió a realizar la
desconexión de la droguería conectada con Servicio Web y
creada en MySQL. Posteriormente se realizó una prueba de
estrés sobre el Proceso FindMedicine y verificar que la
droguería no se encontrara en la lista dentro de la respuesta
Resultados:
La droguería no apareció en la lista de resultados cuando se
encontraba desconectada. Para el resultado de la prueba de
estrés referirse a la tabla “Prueba de estrés ES009”.
Estado: CUMPLIDO.
CONFIGURACIÓN PRUEBA RESULTADOS DE LA PRUEBA
Proceso Hilos Ciclos por
cada hilo
Tiempo
Min(ms)
Promedio(ms) Tiempo May(ms)
FindMedicine 30 1 111691 138116 145293 63
Pruebas.
2. Escenarios - ES003.
Identificador escenario: ES003.
Nombre: El sistema debe enrutar mensajes correspondientes a sistemas externos
(droguerías) de forma dinámica.
Atributo de Calidad: Enrutamiento.
Verificación: Con el observatorio desplegado y todas las droguerías conectadas se
realizaron consultas donde aparecieran diferentes droguerías según los
parámetros de entrada.
Resultados: Dependiendo de la consulta ingresada, se enrutaron los mensajes a
droguerías distintas según los parámetros de entrada mediante el Proxy
dentro del OSB encargado de esta tarea.
Estado: CUMPLIDO.
64
Análisis pruebas.
• Limitaciones de hardware.
• Recursos no adecuados para ejecutar una aplicación del lado servidor.
• La activación de todos los componentes afecta el desempeño.
• Escenarios probados dieron respuestas positivas.
• La flexibilidad del sistema permite la incorporación de componentes que permiten mejorar las respuestas de los escenarios.
• Arquitectura probada y que permite el desarrollo del Observatorio.
65
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.66
Conclusiones.
• Arquitectura genérica libre de tecnología.
• Herramienta que ataca la problemática.
• Marcos de referencia para SOA/BPM/ESB.
• Eficiencia en BPM.
• Capacidades ESB.
• BPM Mobile: desacople con pantallas integradas con motor BPM.
• Escenarios de utilización de la arquitectura.
67
Trabajo futuro.
• Oportunidad de negocio.
• Componentes que permitan mayor desacople.
Registry.
• Procesos BPM.
Task.
Rules.
• Implementación con herramientas libres.
• Implementación más indicadores de negocio.
• Incorporación sistemas externos.
Proveedores.68
Agenda.
1. Justificación.
2. Objetivos.
3. Metodología.
4. Análisis.
5. Diseño.
6. Construcción.
7. Pruebas.
8. Conclusiones.
9. Prototipo.69
Prototipo.
1. Video.
• https://youtu.be/OKQJQbihTBE -> Consultar medicamento.
• https://youtu.be/5R2Wr9Nhnxg -> Indicadores.
• https://youtu.be/fsr97wBXUSg -> Apartar medicamento.
• https://youtu.be/rvzmZBjO5xQ -> Recomendación.
70