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. Estado del Arte.

17

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.

3. Obtención de Conocimiento.

Fabricación y comercialización.

19

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álsis.

4.2. Relación

Actividades / Actores.

27

Análisis.

4.4. Requerimientos no funcionales.

● Escalabilidad.

● Interoperabilidad.

● Seguridad.

● Enrutamiento.

● Monitoreo.

● Desempeño.

● Diseño.

Escenarios de verificación.

28

Análisis.

5. Especificación de Requerimientos.

29

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.

1. Proceso general.

DDA-Bass

31

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

General.

34

Diseño.

3. Vistas.

Pantallas

Lógica.

Datos.

35

Diseño.

3.1 Vistas - Capas.

CONSUMIDORES.

BPM.

SOA.

ESB.

SISTEMAS EXTERNOS.

36

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 - SOA.

38

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 - BPM.

40

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.

● ESB/SOA/BPM.

● Android.

● Java, Javascript,

Websockets.

47

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.

50

Construcción.

3. Procesos.

52

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.

CU013. Apartar medicamento.55

Construcción.

3. Procesos.

CU013. Cambiar estado apartado ASYNC.

Temporizador. 56

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


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.


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.


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

GRACIAS.

71

arquitectura para observatorio nacional de oferta y...

Documents