Propuesta para Trabajo de Grado -...

CIS1530AP04 Arquitectura para Observatorio Nacional de Oferta y disponibilidad de productos farma-

céuticos.

Renzo David Rojas Silva

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

BOGOTÁ, D.C.

2015

Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

Página i

Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008

CIS1530AP04

Arquitectura para Observatorio Nacional de Oferta y disponibilidad de productos far-

macéuticos.

Autor(es):

Renzo David Rojas Silva

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO

DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE

SISTEMAS

Director

Julio Ernesto Carreño Vargas.

Jurados del Trabajo de Grado

<Nombres y Apellidos Completos del Jurado >

<Nombres y Apellidos Completos del Jurado >

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~CIS1530AP04/

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA


BOGOTÁ, D.C.

Ingeniería de Sistemas CIS1530AP04

Página ii

11,2015

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA


Rector Magnífico

Jorge Humberto Peláez Piedrahita, S.J.

Decano Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Ingeniero Rafael Andrés González Rivera


Página iii


Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus

proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral

católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que

se vean en ellos el anhelo de buscar la verdad y la Justicia”


Página iv

AGRADECIMIENTOS

En primer lugar quisiera agradecer a mi familia que siempre ha estado allí como apoyo, alen-

tándome a seguir adelante y a cumplir todas las metas que me proponga.

En segundo lugar quisiera agradecer al Ingeniero Julio Ernesto Carreño, quien me dirigió en la

elaboración de este trabajo de grado; gracias por su paciencia y dedicación.


Página v


CONTENIDO

CONTENIDO .............................................................................................................. V

INTRODUCCIÓN .......................................................................................................8

I - DESCRIPCIÓN GENERAL ..................................................................................9

1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES. ............................................9 1.1. Formulación del problema que se resolvió. ........................................................... 10 1.2. Justificación del problema. .................................................................................... 10 1.3. Impacto Esperado. .................................................................................................. 12

2. DESCRIPCIÓN DEL PROYECTO. ..........................................................................13 2.1. Objetivo general. .................................................................................................... 13 2.2. Objetivos específicos. ............................................................................................. 13

3. METODOLOGÍA. ................................................................................................13

II – MARCO TEÓRICO ............................................................................................18

1. MARCO CONTEXTUAL.......................................................................................18 1.1. Perú. ....................................................................................................................... 18 1.2. Italia. ...................................................................................................................... 19 1.3. Estados Unidos. ...................................................................................................... 20 1.4. Venezuela: .............................................................................................................. 21 1.5. España: ................................................................................................................... 22 1.6. Resumen comparativo. ........................................................................................... 23

2. MARCO CONCEPTUAL. ......................................................................................25 2.1. Arquitectura de software. ....................................................................................... 25 2.2. Problemas dentro de la Arquitectura de software. ................................................. 26 2.3. Bus de Servicios Empresarial. ................................................................................ 26 2.4. Business Process Management. .............................................................................. 27 2.5. Business Activity Monitoring. ................................................................................. 28 2.6. BPM junto a ESB. ................................................................................................... 28

III – ANÁLISIS ..........................................................................................................29

1. OBTENCIÓN DE CONOCIMIENTO: .......................................................................29 1.1. Análisis. .................................................................................................................. 30

2. OBTENCIÓN DE REQUERIMIENTOS. ....................................................................32 2.1. Identificación de actores: ....................................................................................... 33 2.2. Identificación de actividades macro de valor: ....................................................... 34 2.3. Atributos de Calidad. .............................................................................................. 38

3. ESPECIFICACIÓN DE REQUERIMIENTOS. .....................................................................40


Página vi

IV – DISEÑO ..............................................................................................................41

1. REQUERIMIENTOS ARQUITECTURALMENTE SIGNIFICATIVOS: ...........................42

2. VISTA LÓGICA. .................................................................................................43

3. VISTA DE COMPONENTES. .................................................................................46 3.1. Componentes específicos para el Observatorio. .................................................... 53

4. VISTA DE DESPLIEGUE. .....................................................................................61

5. EVALUACIÓN ARQUITECTURA. .........................................................................64

V – DESARROLLO DE LA SOLUCIÓN ................................................................69

VI – RESULTADOS ..................................................................................................79

VI – CONCLUSIONES .............................................................................................83

1. ANÁLISIS DE IMPACTO DEL DESARROLLO .........................................................83

2. CONCLUSIONES Y TRABAJO FUTURO ................................................................84

IV- REFERENCIAS Y BIBLIOGRAFÍA ................................................................87

IV - ANEXOS .............................................................................................................92


Página vii


ABSTRACT

The main objective of the following work was the analysis, design and construction of an ar-

chitecture that enables the development of a Supply and availability observatory of pharma-

ceutical products inside the Colombian context, searching to leave a tool of interest to the con-

sumers and the owners of drugstores. In that way we started with the analysis of the Health and

Pharmaceutical sector from different points of view, doing emphasis on the problems. Next,

we proceeded with the description of the main functionalities and last the construction of the

architecture and evaluation through the prototype developed.

RESUMEN

El objetivo del presente trabajo de grado fue analizar, diseñar y construir una arquitectura que

soportara el desarrollo de un Observatorio de oferta y disponibilidad de productos farmacéuti-

cos dentro del contexto colombiano, buscando dejar una herramienta de interés para los consu-

midores y para las droguerías. Así se comenzó con el análisis del sector Salud y Farmacéutico

desde los diferentes puntos de vista detectando los problemas. Seguido se procedió con la ela-

boración de las funcionalidades principales que ofrece el observatorio, para luego construir la

arquitectura y evaluarla mediante el prototipo desarrollado.


Página 8

INTRODUCCIÓN

El sector salud se presenta como uno de los más grandes a nivel mundial y Colombia no es la

excepción [42].

Dentro de este sector surgen varios problemas y necesidades que están presentes en el día a día

de muchos ciudadanos, como lo es la obtención de medicamentos.

Este problema es de particular interés en Colombia donde un medicamento de marca puede

llegar a costar hasta 6 veces más que el mismo medicamento en su presentación genérica [48].

Igualmente no existe información al alcance de los consumidores que permita una comparación

entre productos genéricos y comerciales, lo que ocasiona que los consumidores no cuenten con

los recursos necesarios para tomar decisiones que se ajusten más a sus situaciones actuales,

teniendo en cuenta el presupuesto disponible para la obtención de productos farmacéuticos.

Igualmente y desde otro punto de vista, el sector Micro PyMe farmacéutico colombiano, con-

formado por las droguerías que venden al consumidor final, se encuentran pasando por amargos

momentos, debido a la llegada de nuevas empresas de grandes envergaduras, que hacen com-

petencia directa, y que al contar con más recursos económicos, ocasionan la desaparición de

los droguistas independientes dentro de la industria.

Por lo anterior, el siguiente trabajo de grado se centró en la creación de una arquitectura que

permita dar respuesta a los problemas del sector, tanto para consumidores como para droguis-

tas, mediante la construcción de un Observatorio Nacional de oferta y disponibilidad de pro-

ductos farmacéuticos.

Para el desarrollo de la propuesta se desarrolló una arquitectura BPM/SOA apoyada sobre un

ESB. Lo anterior debido a las características que ofrecen estos tres estilos al combinarse, adap-

tándose a las necesidades detectadas para la elaboración del Observatorio. Con el sistema cons-

truido sobre la base expuesta se logró una arquitectura escalable, abierta, de fácil monitoreo y

que permite la generación de información de interés sobre los procesos que se creen.

Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación práctica.

Página 9


I - DESCRIPCIÓN GENERAL

1. Oportunidad, Problemática, Antecedentes.

Dentro de la economía mundial, el sector de la salud es uno de los más grandes, aportando

aproximadamente un total del 8% del PIB mundial [42].

En Colombia vemos que la suma del gasto en salud ( sector público mas sector privado ) al-

canza un total del 6.8% del PIB nacional, acumulando un total de USD 533 en gasto per cápita

dentro del país; es el tercero en gasto de salud dentro de la región, después de Argentina y

Brasil [43].

Del gasto ya presentado, un 76% viene del sector público, es decir, el gobierno y otras entidades

del estado, mientras el 13.9% proviene del bolsillo [43], lo que en ingles se conoce como Out

of pocket y que hace referencia al gasto realizado con recursos propios de los hogares colom-

bianos cuando se quiere acceder a servicios de salud.

Con base en lo anterior, el gasto de bolsillo en la salud incluye, entre otras cosas, las consultas

médicas generales o especializadas, exámenes médicos, hospitalizaciones y medicamentos.

Haciendo referencia al último punto, vemos que Colombia es uno de los países con los precios

más altos en medicamentos [44], donde un producto farmacéutico de marca puede alcanzar

hasta 17,31 veces su precio en comparación del mismo en otros países [44].

Esta realidad es la que ha llevado a que aproximadamente el 51.1% de la población colombiana

(estratos 1, 2 y 3) tenga que hacer uso de un régimen subsidiado para poder tener acceso a la

salud [46].

El resumen de resultados de la defensoría del pueblo que expone cifras y resultados en cuanto

a la aplicación de la acción de tutela [47], nos muestra que más de una ter-cera parte de estas

para el año 2012 fueron por reclamos en derechos de salud.

Del mismo informe se evidencia que el 37% de tutelas fueron impuestas por la negación de

tratamientos, 19% negación de citas especializadas, 13% negación de cirugías, 10% negación

de imágenes diagnósticas y un 9% por negación de medicamentos.


Página 10

Que los pacientes no tengan acceso a los debidos medicamentos es una situación compleja, ya

que al ser estos un producto de primera necesidad, es necesaria la obtención por otros medios

y como se ha expuesto anteriormente, los medicamentos de marca dentro del país son muy

costosos para gran parte de la población.

Por otra parte, en Colombia existe poca disponibilidad y acceso a la información técnica e

independiente sobre los medicamentos comercializados en el país [48]. Por lo tanto cuando un

ciudadano sufre de un problema de salud, no tiene criterio para evaluar su satisfacción frente a

un producto, se encuentra a manos del prescriptor (cuando acude a uno) o se encuentra a merced

de la publicidad y el mercadeo [49].

Esto ocasiona que se tenga un desconocimiento de la gama existente de marcas genéricas, que

pueden llegar a tener un valor de hasta 6 veces menos que el mismo producto de una marca

reconocida [48].

1.1. Formulación del problema que se resolvió.

A partir de lo dicho anteriormente se formuló la siguiente pregunta a resolver con el desarrollo

de la propuesta:

¿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?

1.2. Justificación del problema.

Al proponer el diseño de una arquitectura para el desarrollo de un observatorio nacional de

oferta y disponibilidad de productos farmacéuticos, se está dejando la base para el desarrollo

de una nueva herramienta, dispuesta al alcance de los colombianos para poder acceder a la

información existente en el mercado de medicamentos de forma rápida, actualizada y entregada

al usuario según las necesidades de la consulta que se quiera realizar.

Al hablar de un alcance nacional, estamos haciendo referencia a la vinculación de diferentes

sistemas con fuentes de datos heterogéneas, en formatos distintos, provenientes del sector pyme

farmacéutico (droguerías, farmacias).


Página 11


Por lo tanto, y para lograr la escalabilidad y funcionalidad deseada es necesaria la planeación

adecuada de la arquitectura que soporte la heterogeneidad mencionada anteriormente; es acá

donde cobra valor el diseño de una arquitectura ESB (Bus de Servicio Empresarial).

Un sistema construido sobre una arquitectura ESB posee características que lo hacen apto para

manejar un alto volumen de transacciones y una comunicación de tiempo real entre sistemas

[50]. De igual forma posee la capacidad de interoperabilidad con distintos sistemas, escritos en

distintos lenguajes, basándose en conectores que se desarrollan para cada componente nuevo

distinto que se quiera incorporar [50].

Esta última característica es la que permite que los sistemas desplegados bajo una arquitectura

ESB sean flexibles y de fácil escalabilidad a medida que estos crecen y se tornan más complejos

[50] [45].

Una vez que se logra solucionar el problema de la heterogeneidad de sistemas, conectándolos

por medio de una arquitectura ESB, es necesario realizar una orquestación de éstos para lograr

crear un proceso nuevo para dar valor a los servicios y los datos que unifica el bus; acá cobra

importancia BPM como orquestador y como elemento que logra transformar los datos en in-

formación.

Al unir las características de una arquitectura ESB con las ventajas de BPM logramos crear

sistemas capaces de manejar procesos de negocio, donde se definen actividades de alta inter-

vención de usuarios, sobre una base de alta flexibilidad, escalabilidad y de alto rendimiento

otorgada por ESB [50] [45].

Así el observatorio pretende ser una herramienta que ayude a las personas en su búsqueda de

medicamentos, brindándoles las diferentes opciones de precios disponibles en el mercado, así

como las diferentes alternativas existentes para cubrir la necesidad que están presentando.

Desde otro punto, el sistema resultaría de interés para el propietario de Micro PyME farmacéu-

tica (puntos de venta de medicamentos a usuario final) al ser una herramienta, que al ser ofre-


Página 12

cida como servicio, estaría dentro del alcance de adquisición y que brindaría recursos al em-

presario para hacer frente a los nuevos competidores internacionales que han ingresado al mer-

cado colombiano a causa del proceso de globalización que viene sucediendo a nivel mundial.

1.3. Impacto Esperado.

A corto plazo, la realización del proyecto busca dejar una base arquitectónica valida, probada

y evaluada para el desarrollo del observatorio. Lo anterior es de gran importancia debido a la

gran heterogeneidad de componentes que harían parte del sistema, donde es importante manejar

desde el diseño de la arquitectura el control de éstos, para poder ofrecer los diferentes servicios

con la ayuda de BPM, sin afectar atributos de calidad, que al no ser tenidos en cuenta desde

esta primera fase del diseño, re-percutirían en un sistema insostenible e imposible de desarro-

llar.

Al tomar como base una arquitectura BPM/ESB, el sistema, a mediano plazo y al ser llevado a

un ambiente comercial, tiene la intención de ser abierto y de fácil extensión para la incorpora-

ción de nuevos componentes y de nuevos servicios de forma eficiente, que cubran las necesi-

dades tanto del usuario final, como las del pequeño empresario; es una de las finalidades del

trabajo a desarrollar dejar el diseño arquitectónico planteado para que lo anterior pueda ser

realizable.

A largo plazo, el observatorio pretende ser una herramienta de utilidad tanto para la persona

que se encuentra en la búsqueda de un medicamento, como para los empresarios dueños de

pequeños y medianos puntos de venta de medicamentos (droguerías), que al unirse bajo un

mismo sistema, pueden generar datos e información del entorno donde se encuentran inmersos

para ayudar al mayor conocimiento de su mercado efectivo, generar interés en un nuevos nichos

de mercado con estrategias de penetración personalizadas para poder hacer frente y sobrevivir

dentro del sector junto con las grandes superficies, equilibrando la competencia y ofreciendo

mejor calidad de vida al usuario final, basada en una mejor prestación de servicios y fortaleci-

miento a sus derechos fundamentales como colombiano.


Página 13


2. Descripción del Proyecto.

2.1. Objetivo general.

Definir una arquitectura para el desarrollo de un observatorio nacional de oferta y disponibili-

dad de productos farmacéuticos.

2.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 ob-

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

3. Metodología.

La metodología que se utilizó durante el desarrollo del proyecto estuvo basada en fases progre-

sivas e iterativas según la metodología ágil AUP (Agile Unified Process) [32]. El final de cada

fase dio como resultados diferentes entregables, necesarios para comenzar la fase siguiente.

Con esta dinámica se buscó que cada fase se retroalimentara con las anteriores. Así, el proyecto

se dividió en cuatro fases fraccionadas en secciones de investigación, análisis, desarrollo y

pruebas.

3.1. Fase de Inicio.

En la primera fase del proyecto, se realizó un proceso de investigación y de análisis en el cual

se procedió a una recolección de datos con respecto al estado actual de la problemática; de

igual forma se investigó sobre proyectos similares que sirvieron como referencia para el desa-

rrollo de la arquitectura.

3.1.1. Método.


Página 14

Se realizó por medio de investigación especulativa, donde se buscó información acerca de la

problemática planteada en la sección I-1(Oportunidad, problemática, oportunidad).

3.1.2. Actividades.

3.1.2.1. Investigar.

En esta actividad se realizó un trabajo de investigación, analizando el estado actual de la pro-

blemática planteada, características de arquitecturas ESB junto con BPM y proyectos ya desa-

rrollados en el área.

3.1.2.2. Documentar.

En esta actividad se realizó la documentación de la información relevante a la problemática y

de la arquitectura propuesta.

3.1.3 Resultados Obtenidos.

A partir de la actividad anterior se obtuvo un estado del arte sobre la problemática investigada,

características relevantes de ésta y al mismo tiempo sobre la arquitectura ESB junto con BPM.

3.2. Fase de Diseño.

En la segunda fase se desarrolló un diseño basado en la recolección de datos de la fase anterior

y se realizará un proceso de ingeniería de requerimientos en los cuales se plantearon las nece-

sidades básicas a cubrir con la arquitectura a desarrollar.

3.2.1. Método.

Se realizaron un conjunto de actividades principales para la ingeniería de requerimientos como

lo propone Loucopoulos [25], adecuado a las necesidades del proyecto. Luego de ello se reali-

zará la arquitectura acorde a los requerimientos y se evaluó para asegurar que cumplía con lo

especificado.

3.2.2. Actividades.


Página 15


3.2.2.1. Diseño de casos de uso.

El objetivo de esta actividad fue analizar y sintetizar la información obtenida en la fase anterior

para poder realizar un primer levantamiento de los casos de uso que llevaron a la solución de

la problemática planteada.

3.2.2.2. Especificación de requerimientos.

El propósito de esta actividad es pautar las especificaciones de los requerimientos funcionales

y no funcionales detectados junto con los atributos de calidad.

3.2.2.3. Diseño arquitectura del sistema.

En esta actividad se realizó la caracterización arquitectónica del sistema de una manera más

específica basándonos en el proceso de requerimientos para que cumpliera con lo especificado

anteriormente.

3.2.2.5. Evaluación de arquitectura.

Para asegurar una arquitectura que cumpliera con los requisitos planteados, se procedió a rea-

lizar la evaluación de la arquitectura para verificar que cumpliera con los requerimientos espe-

cificados.


Se obtuvo al final de esta fase un documento de requerimientos con:

Modelo inicial de casos de uso.

Requerimientos funcionales y no funcionales del sistema.

Luego de esto se realizó Un SAD (Software Architecture Document) con:

Modelo de casos de uso ajustado.

Arquitectura lógica.

Arquitectura física.


Página 16

3.3. Fase de Implementación.

En la tercera fase se empezó la construcción del prototipo a partir de la información obtenida

en la segunda fase.

3.3.1. Método.

Se usaron los productos obtenidos en etapas anteriores para comenzar la construcción del pro-

totipo. Se dividió en pequeñas iteraciones para validar el trabajo realizado en cada periodo de

tiempo y adecuar el prototipo por si surgían cambios en los requerimientos o la arquitectura

diseñada.

3.3.2. Actividades

3.3.2.1. Desarrollo del prototipo

En esta actividad se realizó la codificación del prototipo.

3.3.2.2. Documentación de prototipo

De manera paralela al desarrollo del prototipo se realizó la documentación del código, sus fun-

cionalidades y manual de usuario.

3.3.2. Resultados Obtenidos.

Al final de la etapa de construcción se obtuvo un prototipo funcional con:

Manual de usuario con descripción de las funcionalidades del prototipo.

Prototipo funcional del sistema.

3.4. Fase de Verificación


Página 17


En esta fase se evaluó que el prototipo cumpliera con los requerimientos especificados que se

implementaron (funcionales y no funcionales) dentro de un ambiente de pruebas controlado

dentro del dominio de la problemática planteada.

3.4.1. Método

Debido a la naturaleza del sistema, donde existe la comunicación de diferentes componentes

que “hablan” diferentes idiomas fue necesario hacer una verificación de software por medio de

pruebas de componentes y pruebas del sistema, como propone Sommerville [31].

3.4.2. Actividades

3.4.2.1. Probar componentes.

Se realizan pruebas sobre los componentes individuales del sistema para verificar que estos

respondían de manera correcta, antes de estar inmersos dentro de una gran arquitectura.

3.4.2.2. Probar sistema.

Acá se integraron todos los componentes una vez ya probados por separado, para ver el fun-

cionamiento del sistema como un todo.

3.4.2.3. Documentar resultados.

Una vez finalizadas las pruebas, se realizó un documente de pruebas con respecto a lo obtenido

en las dos actividades anteriores.


Finalmente se obtuvo un documento o reporte de pruebas sobre el prototipo desarrollado.


Página 18

II – MARCO TEÓRICO

1. Marco Contextual

El problema expuesto en la primera sección de este documento no ha sido únicamente de interés

en Colombia, por lo que ya se ha analizado desde diferentes perspectivas y en diferentes con-

textos nacionales.

1.1. Perú.

En Perú se ve un proyecto de iniciativa gubernamental enfocado a la creación de una herra-

mienta para apoyo de la comunidad. La principal intención es dar un recurso a las personas

para que puedan ejercer su libre derecho en la elección sobre compra de medicamentos [16].

Así se pretende dar información de toda la gama de medicinas, tanto genéricas como de marca

junto a su precio de venta en diferentes establecimientos comerciales a nivel nacional.

El sistema peruano permite el envío de información mediante tres formas [17]:

Envío de información mensual mediante llenado de un formulario.

Envío de información mensual mediante archivo Excel.

Envío de información mediante el servicio en línea – Web Service.

1.1.1. Aspectos positivos.

Para lograr el éxito del proyecto, vemos que el apoyo por parte del estado mediante la genera-

ción de leyes fue vital. Como resultado del proyecto, se ha logrado la construcción de un repo-

sitorio amplio de datos para que los usuarios puedan contar con la información suficiente cada

vez que deseen acceder a precios y descripción de medicamentos.

1.1.2. Aspectos negativos.

Hablando de los diferentes medios que ofrece el sistema para acceder a la información, encon-

tramos que solo cuenta con una aplicación cliente web disponible para el público, por la cual

se accede para realizar consultas. Lo anterior llega a ser una desventaja ya que no se cuentan

con otros clientes que permitan el ingreso desde otros dispositivos.


Página 19


1.1.3. Oportunidades.

Con la arquitectura planteada en este trabajo de grado, es posible la fácil y rápida adición o

eliminación de clientes que consuman las funciones ofrecidas por el Observatorio mediante el

Bus Empresarial, diseñando el flujo del proceso con BPM. Esto quiere decir que el sistema

puede llegar a tener una mayor penetración en la población, ya que se podrían realizar clientes

que respondan a diferentes características o limitaciones de los usuarios para facilitar el acceso

a la información.

1.2. Italia.

En Italia, encontramos otra iniciativa de gobierno donde se quiere crear una base de datos de

libre acceso para la consulta de información de cualquier tipo relacionada al sector salud [18].

Más precisamente, el proyecto gira en torno al cumplimiento de cuatro objetivos:

Promover el libre y continuo acceso a datos e información.

Disminuir costos del mantenimiento de los datos, tanto para el gobierno, como para los

interesados en estos.

Disminuir tiempos de diseño y desarrollo para aquellos interesados en acceder a los

datos.

Evitar el uso de protocolos propietarios de acceso a datos.

Así, CloudApp, llega a ser una colección de varias bases de datos relacionadas a temas de salud

a nivel nacional: hospitales, droguerías, entre otros.

Haciendo uso de la información expuesta mediante CloudApp, el mismo gobierno italiano co-

menzó el desarrollo de una aplicación para el apoyo a los turistas en el país. Así nace Open

Health for Tourist (OHT) [18].



Página 20

Para lograr el libre acceso a los datos, el proyecto hace uso de los lineamientos dictados por

The Open Data Protocol, donde se encuentran herramientas para el buen desarrollo de interfa-

ces REST. De igual forma los resultados de las consultas sobre el sistema pueden ser devueltos

en tres formatos: JSON, RDF y KML. La arquitectura descrita anteriormente junto con la filo-

sofía de los estándares abiertos, evidencia el deseo de unir una gran cantidad de sistemas hete-

rogéneos bajo una misma fachada.


El sistema, sin embargo, solo muestra información aplicando ciertos filtros (ej. geo localiza-

ción), sin brindar un servicio más allá al usuario final. De igual forma, para el sector salud no

se ve mayor aplicación del sistema, ya que este solo participa aportando los datos para que

otros accedan a ellos y no reciben ninguna clase de beneficio a cambio.


Bajo la base de la arquitectura propuesta en este trabajo de grado, se logra la integración de un

sector de forma organizada de tal manera que la escalabilidad del sistema se lleva a cabo sin

mayores problemas. La incorporación de BPM ayuda a crear nuevos servicios tanto para los

usuarios finales como para los profesionales involucrados en el sector, sin quedarse solamente

en un sistema para mostrar datos.

1.3. Estados Unidos.

En Estados Unidos encontramos el FDA como programa del departamento de salud y servicios

humanos [19]. Food Drug Administration es una entidad gubernamental encargada de velar por

la protección de la salud pública mediante el control de drogas tanto veterinarias como para

humanos. Entre sus tareas se encuentra la de hacer avanzar el sector de la salud ayudando en

la innovación de nuevas tecnologías para lograr medicamentos más seguros, eficaces y asequi-

bles para la población.

Para lograr cumplir con el último punto, FDA ha desarrollado el sistema Drug Shortages. Este

llega al público por medio de una aplicación android y iOS en la cual el usuario puede estar al


Página 21


tanto de los medicamentos que están sufriendo de escases y medicamentos descontinuados

[19].


Vemos que la aplicación no solo está enfocada a suplir las necesidades de los pacientes, sino

también pretende ser una herramienta para otros actores dentro del sector como los son los

médicos, ayudando a los prescriptores a tomar mejores decisiones sobre los tratamientos de los

pacientes. Adicionalmente permite la búsqueda de medicamentos por sus componentes activos.


La aplicación nos da información completa y detallada de los medicamentos, pero en ningún

momento la relaciona con su disponibilidad en droguerías. Acá vemos una ventaja con el sis-

tema que se desarrolla bajo la arquitectura planteada en este trabajo. De igual forma en ningún

punto se brinda información más allá de la disponible sobre medicamentos.

1.4. Venezuela:

En Venezuela encontramos un sistema desarrollado por AMS (Applied Mobility Systems),

creado con el propósito de ayudar a lidiar con la situación de desabastecimiento existente a

nivel nacional que ha afectado todos los sectores de la industria, incluido el de los medicamen-

tos [20].

Así surge Akiztá, aplicación android y iOS que busca conectar los diferentes inventarios de la

industria farmacéutica a nivel nacional para lograr una búsqueda de productos de forma más

eficiente [21].


La información ofrecida por la aplicación es actualizada al inicio de cada día, lo que ocasiona

la aparición de inconsistencias con lo existente en el inventario de la farmacia y con lo repor-

tado en la aplicación.



Página 22

El Observatorio propuesto es una herramienta más especializada en el sector salud nacional

colombiano, lo cual permite que la información que allí se encuentra pueda ser más detallada

y comparable una con otra para brindar a los consumidores mayores puntos de vistas sobre sus

búsquedas.

1.5. España:

Otro sistema lo encontramos en España. “Medicamento Accesible Plus”, es una aplicación

desarrollada para Android y iOS que permite la búsqueda de información sobre un medica-

mento, ya sea escaneando el código de barras del empaque o ingresando el nombre del producto

[22] [23].

La aplicación ofrece los servicios de búsqueda de medicamento, búsqueda de farmacias y una

función para guardar una lista de medicamentos preferidos.


La aplicación cliente está creada pensando en las necesidades de los usuarios de tercera edad.

Lo anterior implica que la interfaz cuenta con parámetros ajustables para permitir el uso de

sistema con mayor facilidad a los adultos mayores.


Como aspecto negativo vemos que la función de búsqueda de medicamento no está relacionada

con la función de búsqueda de farmacia; lo anterior quiere decir que no podemos buscar un

medicamento en las farmacias que tenga la aplicación.


El sistema propuesto en este trabajo de grado está en la capacidad de integrar fuentes hetero-

géneas, provenientes en distintos formatos, todo con la finalidad de poder unir datos de dife-

rentes actores para brindar consultas más completas y basadas en lo disponible al momento de

realizarlas.


Página 23


1.6. Resumen comparativo.

Viendo cada uno de los sistemas expuestos anteriormente, encontramos que todos buscan de

forma general ofrecer a los usuarios una mejor base de información para que estos puedan

tomar mejores decisiones frente a la búsqueda y selección de medicamentos.

De igual forma, vemos que en cada uno la información es un componente estático. Lo anterior

quiere decir que no existe una comunicación directa entre los sistemas que alimentan la infor-

mación y el sistema por el cual los usuarios acceden para realizar búsquedas, ocasionando que

los resultados obtenidos puedan no ser del todo acordes con la realidad de los sistemas de las

droguerías.

Con la arquitectura propuesta en este trabajo, se logra una integración eficiente y eficaz, donde

la información expuesta a los usuarios finales siempre debe concordar con lo que manejan los

diferentes componentes integrados al sistema en tiempo real. De igual forma, usando BPM, el

modelado de nuevos servicios tanto para los usuarios finales como para los droguistas y terce-

ros involucrados se transforma en una tarea más sencilla donde el profesional no experto en TI

puede intervenir, lo que ocasiona creación de procesos de mayor valor para todas las partes. De

igual forma, y con base en BPM, el Observatorio es capaz de generar datos de interés para las

droguerías conectados a este, cada vez que se desarrolla un nuevo proceso de negocio. Lo an-

terior permite dar una herramienta de análisis de mercado, con variables de interés que den

una perspectiva de la situación actual a cada droguista dentro del sector nacional en compara-

ción con su competencia.

Para una mejor exposición de las características funcionales de las aplicaciones detectadas den-

tro del marco contextual junto con el Observatorio planteado en el presente trabajo, se realizó

la siguiente tabla donde se marcan las características existentes dentro de cada sistema. La

comparación se realizó alrededor de siete funcionalidades importantes detectadas en todos los

productos.


Página 24

En la tabla anterior se observa cada uno de los sistemas expuestos en el marco contextual donde

se marcan las características que cada uno posee con el sigo “x”; en caso de una casilla vacía o

en blanco, la tabla indica que el sistema carece de esa funcionalidad; en caso de encontrar el

signo “~”, la tabla indica que la funcionalidad existe, pero no se cubre de la forma esperada, a

comparación del Observatorio propuesto.

1.7. Resumen Arquitectónico comparativo.

Una vez realizada la comparación funcional del Observatorio, se procedió a entrar en más de-

talle en cuanto a la arquitectura ofrecida por cada uno de los sistemas del marco contextual para

igualmente obtener los aspectos positivos y negativos de cada uno con el fin de detectar la

oportunidad que existe para el Observatorio. Para lograr lo anterior se procedió a la elaboración

de una tabla comparativa para cruzar lo existente en cada sistema.

ASPECTOS

Especializado en sector farmacéu-

tico.

x x x x x

Capacidad de acceso desde diferen-

tes plataformas.

x x x x

Recomendaciones sobre las búsque-

das.

x

Resultados basados en localización. x x x x x

Resultados con información actua-

lizada (tiempo real).

~ ~ x

Herramienta para consumidores. x x x x x x

Herramienta para vendedores. x x

Tabla 1Comparación sistemas.


Página 25


En la tabla anterior se observan diferentes

aspectos arquitectónicos detectados en las aplicaciones analizadas, su comparación en-

tre todas y con el Observatorio. Una casilla con el signo “x” indica que el aspecto es

cubierto por el sistema; Una casilla con el signo “~” indica que el aspecto existe pero

no se encuentra totalmente cubierto, o no se ofrece mayor información de este. Una

casilla vacía indica que el sistema no cumple el aspecto.

Para un análisis más profundo del marco contextual por favor referirse al anexo “Estado Del

Arte”.

2. Marco Conceptual.

Dentro del marco del trabajo desarrollado, es importante abarcar conceptos claves que ayuden

al entendimiento de la problemática, así como a la contextualización de la solución presentada.

2.1. Arquitectura de software.

Una arquitectura de software es lo que se conoce como los planos de un sistema; se realiza en

una etapa de diseño (es el nivel de abstracción más alto), antes de entrar a construcción y per-

mite la descripción de los componentes (estructura), así como la interacción que existirá entre

ASPECTOS

ARQUITECTÓNICOS.

Comunicación con estándares

abiertos.

x x

Soporte de SOAP y REST. x ~ ~ ~ x

Análisis de lógica de negocio a par-

tir de indicadores.

x

Soporte universal a repositorios con

estándar JDBC.

~ x

Capacidad de extensión a otras apli-

caciones clientes.

x ~ ~ x

Incorporación en tiempo de desplie-

gue de sistemas terceros.

x x x

Tabla 2 Aspectos arquitectónicos.


Página 26

ellos (comportamiento) para lograr los objetivos definidos para el sistema, teniendo en cuenta

el ambiente donde este funcionará [1].

Dentro de los años que tiene la disciplina de la arquitectura de software, los profesionales in-

volucrados ha encontrado problemas que comparten los mismos atributos, es decir, comparten

las mismas características de otros ya resueltos. Lo anterior es lo que ocasiona la aparición de

patrones y estilos arquitectónicos.

Un patrón, dentro del contexto de la arquitectura de software, se conoce como una guía para

atacar cierto problema que ha surgido en otras ocasiones, llegando a una solución que ya ha

sido validada previamente con otros casos de éxito [4].

2.2. Problemas dentro de la Arquitectura de software.

La comunicación entre sistemas heterogéneos surge como uno de los problemas históricos den-

tro de la disciplina [5].

Entre las soluciones dadas para el problema anterior, encontramos la integración de tecnologías

a través de interfaces, lo cual en sistemas que se encuentran en continuo cambio y crecimiento

resulta en un acoplamiento no deseado de los componentes [7].

Posteriormente surge la comunicación basada en mensajes, donde ahora la interacción queda

en manos de agentes que se comunican entre ellos; cualquier cambio que sea introducido, se

ve reflejado en los agentes de comunicación, donde no es necesario re escribir los componentes.

Sin embargo, se siguen observando problemas en la escalabilidad del sistema, donde persiste

una comunicación punto a punto, realizada por intermediarios [5]. Es acá donde vemos el na-

cimiento de los buses de servicios empresariales (Enterprise Service Bus – ESB).

2.3. Bus de Servicios Empresarial.

Las arquitecturas de Bus Empresarial son aquellas que se encuentran optimizadas para el ma-

nejo de altos volúmenes de mensajes, en tiempo real, entre sistemas heterogéneos y con baja

latencia [6]. Por lo tanto son arquitecturas pensadas para ser usadas en situaciones donde el

desempeño no se vea afectado frente a un gran número de transacciones y sistemas externos

conectados. Lo anterior permite la distribución de la lógica de negocio en pequeños sistemas


Página 27


livianos [5], donde el bus es el encargado de asegurar la confiabilidad y seguridad en la entrega

de los mensajes entre los diferentes componentes.

Esta arquitectura, se centra en el uso de un bus que simplifica la topología de comunicación

entre sistemas, que es capaz de manejar estándares abiertos de comunicación [5].

De igual forma, una arquitectura ESB tiene que ofrecer un conjunto de funciones básicas por

medio del bus [8]: Transparencia de localización, Transformación, Conversión de proto-

colo, Monitoreo/Administración, Seguridad.

A pesar de que esta arquitectura debe ofrecer el conjunto mínimo de características ya mencio-

nadas, los buses empresariales son ofrecidos por diferentes vendedores que los desarrollan ha-

ciendo uso de ciertas herramientas tecnológicas, orientados a resolver una necesidad muy es-

pecífica del mercado, donde es necesario hacer énfasis en una de las funcionalidades que

ofrece. Según el artículo “Towards Reusing ESB Services in Different ESB Architectures” [8],

estos productos se pueden dividir en 3 categorías según sus variaciones arquitectónicas:

Buses JBI (Java Business Integration): se centran principalmente en lograr el total

desacople entre los diferentes sistemas integrados al bus.

Buses SCA (Service Component Architecture): su objetivo es el desacople entre la

lógica de negocio (procesos de alto nivel) y el acceso a los diferentes componentes que

ofrecen servicios dentro del bus.

Buses MQM (Message Queuing Middleware): su funcionalidad se basa en el envío

de mensajes por medio de una cola.

2.4. Business Process Management.

BPM (Business Process Management), se encarga principalmente del diseño y análisis de pro-

cesos de negocio [6]; debido a lo anterior es usado para lograr la optimización de procesos

mediante re ingeniería [9].

Desde otro punto, puede ser visto como una cadena coordinada y orquestada de actividades,

diseñada para cumplir con objetivos de negocio [9]. Los procesos diseñados mediante BPM


Página 28

son capaces de ver reflejados componentes tales como personas, actividades, flujos, datos y

sistemas externos [9].

Los procesos modelados con BPM, poseen las características de ser de larga duración y cen-

trados en usuarios, donde la intervención de éstos es alta, por lo general para la aprobación de

actividades intermedias [6].

2.5. Business Activity Monitoring.

Por otro lado, y en una etapa posterior al modelado de los procesos de negocio que cumple con

los objetivos planteados, aparece una rama que nos permite el análisis de estos en tiempo real

mediante indicadores también definidos por los dueños del proceso; Business Activity Moni-

toring (BAM).

Mediante BAM, se puede lograr el monitoreo de los procesos en tiempo real (tableros de esta-

dos) y de forma estática mediante reportes. Ofrece a los usuarios interesados crear nuevas vistas

a partir de los datos guardados sin necesidad de crear sentencias SQL que hagan la tarea, com-

binando datos históricos y entrantes. [10].

2.6. BPM junto a ESB.

BPM y ESB son conceptos que combinados, pueden complementarse para lograr arquitecturas

con las ventajas y características que cada uno presenta por separado [6].

Sin embargo, la combinación de estos para resolver un problema no siempre es necesaria y

puede resultar en arquitecturas complejas, innecesarias y difíciles de mantener.

La combinación de BPM con ESB nos da como resultado la delegación de responsabilidades

dentro de cada tecnología. La arquitectura ESB toma el papel de base para garantizar una in-

terconectividad entre sistemas heterogéneos, manteniendo todas las ventajas ya mencionadas,

mientras BPM se encarga de la orquestación de éstos para crear servicios de valor, sin preocu-

parse de cómo realizar la comunicación y centrándose en el análisis y buen diseño del proceso

a alto nivel [6] [11].


Página 29


Para un análisis más profundo del marco conceptual por favor referirse al anexo “Estado Del

Arte”.

III – ANÁLISIS

Para lograr el levantamiento de requerimientos para la construcción de la arquitectura y sistema

propuesto en este documento, se procedió a tomar como base la metodología propuesta por

Loucopoulos [25], quien plantea un proceso expuesto en la siguiente figura:

Ilustración 1Metodología para levantamiento de requerimientos, Loucopoulos [25]

Como se ve en la imagen anterior, cada etapa mostrada depende de la anterior. El fin del pro-

ceso es contar con una especificación formal de los requerimientos funcionales y no funciona-

les del sistema. La especificación final obtenida se puede ver con mayor detalle en el docu-

mento “Especificación de Requerimientos”. A continuación se expone como se desarrolló y el

rol de cada etapa dentro de la obtención de la especificación final.

1. Obtención de conocimiento:

En esta primera etapa se pretende lograr una comprensión a fondo del dominio del problema,

con el fin de tener mayor claridad del contexto donde se proyecta desplegar el sistema, identi-

ficar variables importantes, entender el lenguaje técnico del área y generar una base sólida de

conocimiento para poder comenzar la obtención de requerimientos.

Como entradas para el proceso de obtención de conocimiento, es importante contar con fuentes

de información que permitan adquirir una apropiación del conocimiento.

Loucopoulos propone como válidas diferentes fuentes de información para realizar el análisis.

Para el caso práctico del trabajo de grado presentado, se recurrió a la recolección de la literatura

sobre el dominio [25] que permitió la estructuración del problema.

Obtención de conocimiento

Obtención de requerimientos

Especificación de

requerimientos


Página 30

Así, el análisis realizado, abarcó desde el área más general del sector farmacéutico en Colom-

bia, la identificación de las partes que participan dentro de este, hasta la perspectiva de los

problemas detectados desde el punto de vista de los actores involucrados. A continuación se

presenta el análisis a gran escala; para una profundización del análisis realizado para la obten-

ción de conocimiento por favor referirse al anexo “Análisis problemática”.

1.1. Análisis.

1.1.1. Sector farmacéutico en Colombia.

El sector farmacéutico es aquel que se encarga del desarrollo de las actividades de fabricación,

elaboración y comercialización de productos medicinales, que tienen como fin ayudar a mini-

mizar los riesgos de enfermedades en las personas [26].

En Colombia, este es un sector que hace parte de la Manufactura Industrial, participando con

las actividades de elaboración y exportación de medicamentos; aporta aproximadamente el 3%

de participación a este sector, que a su vez aporta con el 16% del PIB nacional [27].

1.1.2. Actores dentro del sector.

Los droguistas independientes, pertenecientes al sector de la Micro PyMe, se encuentran dentro

de la industria farmacéutica. De igual forma esta industria se encuentra inmersa dentro de un

sistema de salud. A continuación se expone un diagrama que identifica los actores que partici-

pan en el sector, visto desde el proceso de distribución primaria de medicamentos y con base

en lo presentado en [29].

Ilustración 2 Cadena de distribución primaria [29].


Página 31


Visto desde el proceso de la cadena de distribución comercial, podemos notar como sólo los

actores de la rama de distribuidores entran como competidores en la venta de medicamentos al

cliente final. A continuación se muestra un diagrama exponiendo a los actores participantes de

la distribución comercial.

Ilustración 3 Cadena de distribución comercial [30].

Como se ha venido introduciendo desde la presentación de la problemática en la primera sec-

ción de este documento (I-1, Oportunidad, Problemática, Antecedentes), la temática principal

a atacar aborda la cadena de distribución comercial y más precisamente está relacionada con

las droguerías independientes y el consumidor.

1.1.3. Problemática según los actores.

1.1.3.1. Consumidor:

Dentro del contexto del sector farmacéutico, el consumidor es aquella persona que hace uso de

los servicios de una droguería en la búsqueda de un medicamento. Es decir, es aquella persona

que, con o sin una prescripción médica, acude a una droguería en búsqueda de un medicamento.

El documento Conpes Social 155 [12] habla de la política farmacéutica colombiana y da una

explicación de la situación y problemas actuales del sector que afectan directamente al consu-

midor como actor dentro del sistema de salud.

Dentro del documento, se observa un gran problema general que luego es dividido y analizado

en sub componentes. Así, se habla del Acceso inequitativo a los medicamentos y deficiencia

en la calidad de atención como problema macro, que es analizado y dividido en 5 partes [12]:

Uso inadecuado e irracional de los medicamentos.


Página 32

Uso ineficiente de los recursos financieros de la salud e inequidades en el acceso a

medicamentos.

Oferta, suministro y disponibilidad insuficiente de medicamentos esenciales.

Ausencia de transparencia, baja calidad de la información y escaso monitoreo del

mercado farmacéutico.

Debilidades en la rectoría y en la vigilancia.

1.1.3.2. Droguista:

Para el marco del desarrollo del proyecto, se define al droguista como aquel perteneciente al

sector de la industria Micro PyMe colombiana dedicada a la comercialización de productos

farmacéuticos al consumidor final.

Como se ha venido evidenciando, el sector de la Micro PyMe farmacéutica cuenta con una gran

cantidad de participantes, que debido a su naturaleza se enfrentan con problemas crecientes día

a día, principalmente por la entrada de competidores internacionales de grandes superficies. Un

estudio realizado en [15], expone tres problemáticas que ha venido presentando el droguista

debido a lo anterior explicado:

Problema en poder de negociación frente a los laboratorios farmacéuticos [15].

Difícil absorción de nuevas tecnologías dentro de sus negocios que ayuden a la

administración de procesos internos.

Desconocimiento de su verdadera situación dentro del mercado.

Para obtener una descripción más detallada del análisis, por favor consultar el anexo

“Análisis problemática”.

2. Obtención de requerimientos.

Luego de lograr una obtención del conocimiento sobre el dominio del problema en el paso

anterior, Loucopoulos propone la utilización del análisis realizado sobre las fuentes usadas para

obtener una indicación de los requerimientos funcionales y no funcionales del sistema.

Para ello propone varias técnicas. Entre ellas está la obtención de requerimientos por medio de

análisis de lenguaje natural, específicamente por medio de textos [25].


Página 33


De igual forma, y como expone Brugge en [28], la obtención de requerimientos será plasmada

en un diagrama de cosos de uso que representará los requerimientos del sistema, que en la fase

de especificación serán descritos con mayor detalle.

Para crear el diagrama de casos de uso, y adaptando la metodología expuesta, primero se pro-

cedió con la identificación de los actores dentro del sistema para luego analizar las actividades

necesarias para atacar la problemática expuesta, crear la relación con los actores y finalmente

realizar una especificación detallada.

2.1. Identificación de actores:

Para identificar que actores hacen parte del sistema fue necesario tomar como base lo expuesto

en la sección 1.2.2 del presente capítulo (Actores dentro del sector) y lo profundizado en el

anexo “Análisis problemática”.

El problema principal a atacar, se encuentra en la cadena de distribución comercial, donde los

actores directamente relacionados son las droguerías independientes y los consumidores:

Consumidor: es quien hace uso del sistema para satisfacer su necesidad de búsqueda

de medicamentos. Igualmente es a quien se le brindará información y recomendaciones

sobre sus búsquedas para que pueda tomar mejores decisiones.

Droguista: es quien hace uso del observatorio proporcionando sus datos al conectar

su sistema. De igual forma tiene acceso a indicadores que le ayudan a tener un mejor

entendimiento del mercado donde se encuentra y de las necesidades de los consumi-

dores. Son droguistas pertenecientes al sector Micro PyMe farmacéutico.

Droguería: hace referencia al sistema de cada droguista que es conectado al observa-

torio, exponiendo los datos de los medicamentos para que sean usados en las consultas

de los consumidores. Estos sistemas deberán tener los datos del inventario en digital,

dentro de una base de datos para poder realizar la conexión.

Los actores ya mencionados fueron extraídos de los actores que pertenecen al sector farmacéu-

tico nacional. De igual manera, y como todo sistema, este necesita de actores que lo mantengan

y lo controlen, por lo cual fue necesaria la definición de un nuevo rol.


Página 34

Administrador: es quien tiene acceso al sistema con el fin de gestionarlo. Tendrá ac-

ceso a los datos dentro del Observatorio: droguerías, medicamentos, indicadores.

2.2. Identificación de actividades macro de valor:

Ya con unos actores base principales detectados, pertenecientes al sector y quienes harán uso

del sistema, se identificaron actividades macro que atacaran de forma directa algunos de los

problemas expuestos en la sección 1.2.3 (Problemática según los actores). De igual forma se

usó lo detectado en el marco contextual para cubrir falencias de productos anteriores y tomar

los aspectos positivos para integrarlos.

De los problemas expuestos desde el punto de vista del consumidor se decidió trabajar con el

punto 2 y 4 de la problemática: lo anterior permitió definir un alcance para el prototipo.

Uso ineficiente de los recursos financieros de la salud e inequidades en el acceso a

medicamentos: principalmente se abordó la inequidad en el acceso a medicamentos.

En [13], se expone que una de las causas principales de la inequidad son las campañas

realizadas por las grandes compañías pertenecientes al sector buscando desprestigiar

el nombre de los genéricos, y de igual forma ocultando cualquier información que

pueda ser accesible de estos, todo debido a la gran diferencia de precios existentes entre

medicamentos genéricos y de marca, generando desinformación en el consumidor.

Para atacar esto, el Observatorio planteado en este trabajo de grado pretende brindar

mayor información a los consumidores para que tengan conocimiento de toda la oferta

que existe en cuanto a variación entre marcas, forma genérica y precios, para que, sin

inducir a una decisión u otra, se tengan mejores herramientas para la toma de decisio-

nes. Con base en lo anterior, a continuación se enumeran un conjunto de actividades

necesarias para atacar el problema expuesto:

o Buscar medicamento por nombre comercial: el observatorio permite reali-

zar la búsqueda de un medicamento por nombre comercial, que según se ha

expuesto, es uno de los pocos datos con los que cuenta un consumidor a la hora

de comprar o cuando ha sido recetado por un tercero.

o Generar recomendación por genérico: para lograr la recomendación, se

parte de la búsqueda de medicamento por nombre comercial, donde se obtiene


Página 35


una descripción comparable con su forma genérica que es presentada al con-

sumidor que realiza la búsqueda.

o Buscar droguerías cercanas: el observatorio permite cruzar la información

existente y detallada de medicamentos con las droguerías que están en la ca-

pacidad de suplir la necesidad del consumidor; es por ello que al realizar una

búsqueda, la información recuperada y mostrada es de las droguerías cercanas

al punto donde el consumidor solicitó la búsqueda. De igual forma es una ac-

tividad incluida debido a la falencia que se vio en los sistemas del marco con-

textual, donde ninguno cruzaba los datos de los medicamentos con los de las

droguerías.

o Buscar medicamento en droguerías: dada la información de un medica-

mento que un consumidor desea buscar, el observatorio busca entre las dro-

guerías inscritas, cercanas a él, dónde se encuentra el producto.

Ausencia de transparencia, baja calidad de la información y escaso monitoreo del

mercado farmacéutico: la forma en que se ataca este problema es mediante la expo-

sición de información de una forma sencilla y entendible para el consumidor, para que

este pueda, de forma rápida comparar la información con la que cuenta para tomar la

mejor decisión. Las actividades con las que se ataca este problema son las siguientes:

o Obtener descripción detallada de medicamento: con esto se busca educar

al consumidor para que esté consciente de las características del producto que

está buscando. Esto se incluyó debido a que es un factor común detectado en

las aplicaciones descritas en el marco contextual.

o Comparar producto comercial contra genérico: esto pretende que el con-

sumidor tenga una forma de comparar la información principal de forma sen-

cilla para ayudarlo en la toma de decisiones.

o Apartar medicamento: luego de una búsqueda de medicamento, esta opción

permite al consumidor enviar una solicitud de apartado al droguista quien


Página 36

puede aceptarla o rechazarla. Lo anterior apoya a los consumidores en su bús-

queda y obtención de medicamentos al igual que al droguista, quien cuenta con

una nueva herramienta que apoye y estimule sus procesos de ventas.

Por otro lado, el observatorio también es una herramienta para la droguería, por lo que también

cuenta con unas actividades macro que ayudan a atacar los siguientes problemas detectados en

la sección anterior:

Difícil absorción de nuevas tecnologías dentro de los negocios Y Desconocimiento

de su verdadera situación dentro del mercado: el Observatorio es una herramienta

que pretende servir de apoyo a las droguerías, logrando negocios más competitivos que

respondan a un entorno dinámico de mercado donde la información en tiempo real

sobre el estado del negocio es vital para lograr perdurar. Por lo anterior se han definido

los siguientes procesos:

o Generar indicadores de negocio: Para dar una ventaja competitiva a este sec-

tor de la industria y de igual manera generar interés por parte de los droguistas

al uso del observatorio, se aprovecharán los datos generados por las búsquedas

de los consumidores para generar información de valor para el empresario.

Para lograrlo, se definieron indicadores de desempeño cuyo objetivo es gene-

rar información que ayude a dar un diagnóstico del droguista en el mercado

[33]. Cada indicador se clasificó como básico o derivado [33]. Un indicador

básico se obtiene de los datos generados por el proceso. Un indicador derivado

se obtiene con la unión de dos o varios indicadores básicos.

Con lo anterior se definieron los siguientes indicadores de interés:

Indicadores Básico:

Número de veces que una droguería estuvo dentro de un radio

de búsqueda. Por periodos de tiempo.

Número de veces que una droguería tuvo el medicamento que

se solicitó. Por periodos de tiempo.

Número de veces que se apartó un medicamento en la drogue-

ría. Por periodos de tiempo.


Página 37


Número de veces que se buscó un producto. Por periodo de

tiempo y por zonas.

Número de veces que se apartó un producto. Por periodo de

tiempo y por zonas.

Indicadores Derivados:

Porcentaje de veces que una droguería no tuvo el medica-

mento que se solicitó.

Porcentaje de apartados dentro de una droguería por periodo

de tiempo y zona.

Posición en cuanto a apartados realizados en una zona por pe-

riodo de tiempo para una droguería.

Posición en cuanto a precio de medicamento en una zona por

periodo de tiempo para una droguería.

Perfil de consumidores por zonas.

Con estos indicadores definidos, el observatorio permite la creación de infor-

mación en tiempo real debido a que los datos son obtenidos directamente de

los procesos realizados por los consumidores.

o Obtener información de droguería: permite la obtención de los datos de una

droguería específica dada por el consumidor. Esto ayuda a hacer más visibles

al micro empresario dentro del mercado y entre los consumidores.

Con respecto al administrador del sistema, este desempeña una función de controlador y veedor

donde se definieron las siguientes responsabilidades generales:

Gestionar sistema: es la manera en que se audita el observatorio. Se tiene información

de los procesos corriendo dentro del sistema, descripción visual de cada uno, estado,

instancias creadas en un momento determinado, estado de los servicios externos y da-

tos generales de droguerías inscritas, consumidores inscritos, servicios terceros conec-

tados, entre otros datos de interés configurables.


Página 38

Conectar sistema: es como se conecta una droguería al Observatorio. Cuando se rea-

liza esta actividad, se están exponiendo los datos básicos de medicamentos dentro del

observatorio para permitir las búsquedas descritas anteriormente por el consumidor.

Con el conjunto de actividades definidas se ha creado el siguiente diagrama de casos de uso

que ilustra los principales procesos que se deben llevar a cabo dentro del Observatorio.

Ilustración 4 Diagrama de casos de uso general.

2.3. Atributos de Calidad.

Para identificar los requerimientos no funcionales que soportan la solución del problema con

el desarrollo del Observatorio, se usó una categorización por atributos de calidad para dividir

y analizar las características del sistema en diseño y ya desplegado.

A continuación se van abarcando los atributos de calidad y como deben presentarse en el ob-

servatorio:


Página 39


Escalabilidad: Relacionando el sistema en un contexto nacional expuesto en la sec-

ción Sector farmacéutico en Colombia, vemos que la industria Micro PyMe tiene la

característica de contar con un enorme número de participantes droguistas, quienes

son la fuente de datos principal del observatorio. Esto ocasiona que el observatorio

tenga que ser fácilmente escalable (scale up y scale out) para la incorporación de nue-

vos droguistas (junto con sus respectivos repositorios de datos) y clientes con el sis-

tema desplegado.

Interoperabilidad: De igual forma y relacionado con el punto anterior, el observatorio

se encuentra conectado a diferentes sistemas que se comunican en diferentes idiomas

por lo cual se debe soportar una abstracción para la lógica de negocio en la forma como

se conectan los componentes para lograr la interoperabilidad deseada. Para ello el ob-

servatorio debe soportar:

o Mediación de protocolos y Transformación de mensajes.

Enrutamiento: El observatorio ofrece diferentes servicios que a su vez hacen uso de

diferentes componentes conectados a la arquitectura que se comunican mediante el

envío de mensajes. Esto ocasiona que la arquitectura y el sistema en si necesiten habi-

lidades de enrutamiento para permitir la entrega de mensajes a los componentes, abs-

trayendo esta habilidad de la lógica de negocio. Con lo anterior la arquitectura también

debe soportar:

o Confiabilidad de entrega y Manejo de errores.

Seguridad: Configurar la seguridad en cada uno de los puntos finales conectados al

observatorio es una tarea ardua y que de ser llevada a cabo así necesitaría una gran

cantidad de tiempo para ser finalizada. Lo anterior es lo que resalta la necesidad de

manejo y configuración de la seguridad de una manera centralizada.

Monitoreo: El observatorio debe brindad facilidades de monitoreo de una forma cen-

tralizada para permitir controlar el estado actual de los procesos desplegados y ayudar

a la detección de posibles sobrecargas sobre el sistema.


Página 40

Desempeño: Además de contar con un manejo robusto de transacciones, el sistema

debe ser capaz de llevarlas a cabo de forma rápida para no generar problemas en los

consumidores.

Diseño visual de la lógica de negocio: La lentitud en un proceso puede ser causa de

un mal diseño de proceso, por lo cual es necesario que se cuente con herramientas que

permitan la fácil detección de malos diseños dentro de la lógica de negocio.

Servicios de larga y corta duración: En las transacciones que debe soportar el sistema

encontramos unas que comienzan y son ejecutadas en su totalidad en un corto periodo

de tiempo, como los son las consultas sobre los datos ya existentes. Otras transacciones

requieren de una intervención humana alta, caracterizadas por ser asíncronas y de larga

duración; El sistema debe ser capaz de soportar estos dos tipos de transacciones.

Soporte de estándares abiertos: Para lograr cumplir con una abierta interconexión

entre sistemas heterogéneos, la arquitectura debe ser capaz de soportar la integración

de protocolos populares y abiertos de comunicación.

3. Especificación de requerimientos.

Ya detectadas las necesidades y funcionalidades principales del sistema y basado en un dia-

grama de casos de uso general, se realizó una especificación con más detalle que se podrá

encontrar en el anexo “Especificación de Requerimientos” donde también se encuentran otros

casos de uso auxiliares, mas técnicos que soportan la construcción del Observatorio. De igual

forma, y para lograr un mejor entendimiento de los casos de uso generales más importantes, se

realizó un modelado de procesos que ilustrara los pasos dentro de cada funcionalidad. Se usó

una aproximación planteada en [14], donde se explica cómo mapear entre casos de uso y dia-

gramas de procesos. A continuación se presenta el caso de uso CU001_Buscar medicamento

por nombre comercial como ejemplo de la especificación realizada.


Página 41


Ilustración 5 CU001_Buscar medicamento por nombre comercial, especificación en pro-

ceso.

Lo realizado anteriormente, junto con la especificación de los casos de uso encontrado en el

anexo “Especificación de Requerimientos”, permitió un mayor entendimiento de las funciona-

lidades del observatorio, así como una descripción formal para poder comenzar la construcción.

Para los requerimientos no funcionales, se usó una descripción y especificación basada en es-

cenarios como propone Bass en [33]. El detalle de los escenarios de los requerimientos no

funcionales se puede encontrar en el documento anexo “Especificación de Requerimientos”.

IV – DISEÑO

Para el diseño de la arquitectura y procesos que soportan los requerimientos funcionales y no

funcionales detectados en la etapa de análisis, se procedió con lo planteado por Bass [33],

usando una metodología de Diseño Dirigido por Atributos (Attribute-Driven Design):


Página 42

Ilustración 6 Proceso diseño de arquitectura, Bass [33].

El anterior diagrama muestra el conjunto de actividades planteada por Bass [33] realizadas para

el diseño de la arquitectura del Observatorio. El proceso es iterativo y se repitió siempre que

se detectó un sub componente del sistema general.

A continuación se exponen los resultados de cada actividad.

1. Requerimientos Arquitecturalmente Significativos:

Como entradas para el levantamiento de la arquitectura se hizo uso de los casos de uso detec-

tados en la etapa de análisis. Adicionalmente y mediante la especificación de estos, se tomó un

grupo de Requerimientos Arquitecturalmente Significativos teniendo en cuenta la complejidad

de desarrollo, el número de dependencias con otros casos de uso y el número de llamados a

sistemas externos.

Complejidad de desarrollo: se calculó teniendo en cuenta el número de pasos nece-

sarios para ejecutar el caso de uso que se encuentra descrito en el flujo dentro de la

especificación del documento Especificación de Requerimientos.

o COMPLEJIDAD ALTA: [9-13] pasos dentro del flujo.

o COMPLEJIDAD MEDIA: [5-8] pasos dentro del flujo.

Definir entradas

•Especificación casos de uso

•Escenarios Requerimientos no funcionales.

•Requerimientos Arquitecturalmente Significantes.

Descomponer

•Del sistema general descomponer en sub sistemas.

Refinar

•Asociar sub sistemas con funcionalidades y escenarios.

•Refinar funcionalidades y escenarios si es necesario.

Creación de vistas.

•Lógica.

•De componentes.

•De despliegue.

Verificación

•Evaluación de la arquitectura propuesta.


Página 43


o COMPLEJIDAD BAJA: [0-4] pasos dentro del flujo.

Numero de dependencias: se calculó teniendo en cuenta el número de dependencias

que tiene un caso de uso con otros. Se hizo en base a la descripción de casos de uso,

que permitió obtener el caso de uso con mayor número de dependencias ( 5 dependen-

cias ) y a partir de este se definió la siguiente clasificación:

o COMPLEJIDAD ALTA: [4-5] dependencias.

o COMPLEJIDAD MEDIA: [1-3] dependencias.

o COMPLEJIDAD BAJA: 0 dependencias.

Componentes involucrados: se calculó teniendo en cuenta cuantos componentes dis-

tintos están involucrados en el flujo dentro de la especificación del caso de uso. Se

tomó como base el caso de uso que más componentes tenía involucrados (5 llamados)

y a partir de este se definió la siguiente clasificación:

o COMPLEJIDAD ALTA: [4-5] pasos dentro del flujo.

o COMPLEJIDAD MEDIA: [2-3] pasos dentro del flujo.

o COMPLEJIDAD BAJA: 1 paso dentro del flujo.

A continuación se exponen los CU seleccionados como 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 BAJA

Tabla 3Casos de uso arquitecturalmente significativos.

2. Vista Lógica.

Para lograr una profundización y entender el impacto de los casos de uso Arquitecturalmente

Significativos dentro de la arquitectura, se procedió a la elaboración de un diagrama Entity

Boundary Controller (EBC). El diagrama resultante se puede ver en la Ilustración 7.


Página 44

El diagrama permitió identificar varios componentes lógicos del observatorio importantes para

el desarrollo de la arquitectura. Posteriormente cada uno de estos elementos lógicos fue rela-

cionado con un componente físico.

Las necesidades de interconexión entre distintos sistemas heterogéneos, la necesaria orquesta-

ción de estos para brindar servicios de valor a los consumidores finales junto con los compo-

nentes detectados en el diagrama EBC dan a resaltar la necesidad de implementar una arqui-

tectura BPM/SOA apoyada en un ESB.

2.1. Decisión de SOA/ESB.

De acuerdo al contexto explicado anteriormente, donde se desplegará el Observatorio, se evi-

dencia la necesidad de contar con una arquitectura que soporte atributos de calidad para permi-

tir la unificación de los diferentes sistemas de las droguerías, manejando los siguientes reque-

rimientos:

Transformación: como se explicaba en el capítulo de análisis, es esencial contar con

una herramienta que permita la transformación y mediación de protocolos y formatos

de mensajes provenientes de los diferentes sistemas de las droguerías; en Colombia

existen aproximadamente 8000 micro pymes farmacéuticas. Un ESB permite la trans-

formación transparente para la capa de negocio, donde se permite el cambio de for-

matos y protocolos sin necesidad de afectar cómo se desarrolla las funcionalidades

del Observatorio.

Enrutamiento: las invocaciones de los procesos a las droguerías no siempre involu-

cran al total de estas que se encuentran inscritas al Observatorio. Por lo anterior es

necesario enrutar mensajes basados en el contenido de este a los diferentes sistemas

externos. Esta capacidad la otorga el ESB que basado en proxys y componentes in-

ternos, se puede dirigir un mensaje de acuerdo a las especificaciones del mensaje.

Virtualización: todos los servicios que se invoquen en la lógica de negocio deben

poder ser accedidos independientemente de su localización para permitir la incorpo-

ración de nuevas droguerías con el observatorio ya desplegado y sin realizar cambios

en los procesos.


Página 45


Confiabilidad: la entrega de mensajes a los componentes deseados, debe ser un pro-

ceso que cuente con una eficacia en su realización. Para ello el ESB permite una con-

figuración de reintentos de envíos de mensajes si estos no pudieron ser entregados

debido a problemas de red, por ejemplo. De igual forma al no poder ser entregado el

mensaje al componente, que se encuentra caído, el ESB permite el manejo de errores,

permitiendo así que el sistema continúe y reporte el evento sucedido.

Escalabilidad: para permitir un scale out del sistema es necesaria la distribución de

la lógica del negocio en diferentes componentes de hardware. El ESB nos permite

una invocación de la lógica basado en algoritmos de balanceo que permiten lograr el

atributo mencionado. Igualmente el ESB permite un alto y robusto manejo de mensa-

jes y transacciones.

2.2. Decisión de BPM.

Debido a la necesidad de entregar información al droguista, de forma eficiente, eficaz y en

tiempo real la implementación de una lógica de negocio por medio de BPM es clave. Acá se

aprovechan las ventajas de BPM desde su parte analítica de procesos, donde se pueden generar

indicadores de valor en base a las acciones y procesos que los consumidores disparan desde

sus dispositivos. Adicionalmente, BPM es un orquestador de SOA, lo que permite organizar

los diferentes servicios ofrecidos por ESB para crear nuevos servicios de valor para el usuario.

Análisis de procesos: Mediante la incorporación de indicadores, que pueden ser defi-

nidos por los interesados, BPM permite la creación de tableros de mando y reportes

dinámicos que dan información de interés al droguista.

Orquestador de servicios: BPM permite la organización y orquestación de los servi-

cios expuestos por la capa inferior. De igual forma permite encapsular y exponer los

procesos creados como nuevos servicios para ser expuestos al usuario final por medio

del ESB o que sean consumidos por otros procesos para crear otros nuevos de alto

nivel.


Página 46

3. Vista de componentes.

Para lograr una descomposición del sistema que ayudara a satisfacer los requerimientos detec-

tados anteriormente y que permitiera la organización de los componentes lógicos detectados en

el diagrama EBC, se tomaron como base lineamientos para la creación de arquitecturas

BPM/SOA de referencias como IBM [34], Oracle [35], MuleSoft [36] y The OpenGroup [37].

Como primer paso fue necesaria la identificación y selección de las capas necesarias para la

construcción y organización de la arquitectura del Observatorio. Tomando como referencia los

modelos ya mencionados y adaptándolos según el contexto en el cual se desplegará el Obser-

vatorio, se obtuvieron las capas expuestas en la ilustración 8 Capas Lógicas Observatorio. A

continuación se explica la función de cada una:

Capa Sistemas Externos: hace referencia a aquellos servicios y sistemas que se en-

cuentran fuera de los límites del Observatorio. Esta capa representa principalmente los

sistemas de las droguerías (repositorios de datos) y otros sistemas externos de terceros

que ofrezcan servicios utilitarios. De igual forma acá también es incorporada la base

de datos propia del Observatorio para permitir un desacople.

Capa SOA: acá se encuentra toda la estructuración de los servicios ofrecidos y consu-

midos por el Observatorio. Cada uno de los servicios expuestos o consumidos por esta

capa se encuentran clasificados de la siguiente manera [39]:


Página 47


Ilustración 7 Diagrama EBC-CU Arquitecturalmente significativos.


Página 48

Ilustración 8 Capas lógicas Observatorio


Página 49


o Servicios utilitarios: son expuestos por la Capa ESB mediante proxys y son

consumidos por la capa SOA para ser usados por otros servicios. Hacen refe-

rencia a los servicios más pequeños y ofrecen operaciones específicas y que

carecen de valor para los consumidores.

o Servicios de Negocio: son servicios de nivel medio. Hacen uso de los servicios

utilitarios combinando varios de estos para crear nuevos servicios de valor.

Son estrictamente de corta duración. Son creados mediante BPM consumiendo

los servicios utilitarios y son expuestos nuevamente en la capa SOA como

nuevos servicios.

o Servicios de Proceso: son los servicios de más alto nivel que representan un

valor para los consumidores de la capa superior. Hacen uso de los servicios de

Negocio. Son creados mediante BPM y son expuestos nuevamente en la capa

SOA para ser usados por la capa de consumidores. Pueden ser de corta o larga

duración.

Ilustración 9 Tipos de servicios

Capa BPM: como se mencionaba anteriormente, esta se encarga de la orquestación de

servicios utilitarios y servicios de negocio para crear servicios de proceso. Se encarga

de la creación, modelado y coordinación de los servicios; igualmente acá se produce

la generación de indicadores sobre los procesos mediante BAM. De acuerdo a los pro-

cesos expuestos en la etapa de análisis, se detectaron tres escenarios importantes donde

participa la capa BPM:

o BPM como consumidor: mediante el modelado de procesos, BPM puede con-

sumir servicios expuestos por las capas SOA, ESB y orquestarlos.


Página 50

Ilustración 10 BPM como consumidor

El siguiente diagrama de secuencia expone, mediante el Caso de Uso

CU002_Buscar droguerías cercanas, el escenario descrito al realizar el llamado

al servicio Utilitario getAllDrugstores expuesto por el ESB.

Ilustración 11 BPM como consumidor, secuencia.

El diagrama anterior muestra una parte del proceso Buscar droguerías cercanas

donde se expone el escenario de BPM como consumidor. Acá el proceso hace

un llamado a la actividad getAllDrugstores que está implementada como un

servicio. La actividad busca en el catálogo de servicios SOA el servicio que la

implementa y llama al servicio en la capa ESB. Este a su vez llama al Servicio

de Negocio relacionado que realiza la consulta SQL sobre la base de datos del


Página 51


observatorio. Cuando la respuesta vuelve hasta el proxy, este la transforma al

formato solicitado y la retorna a la actividad que lo llamó.

o BPM como proveedor síncrono: los procesos creados con la capa BPM pue-

den ser encapsulados y expuestos como servicios en la capa SOA para ser con-

sumidos por otros procesos o consumidores finales. Así, los servicios de Ne-

gocio y de Proceso son procesos BPM expuestos como servicios en SOA.

Ilustración 12 BPM como Proveedor.

El siguiente diagrama de flujo expone mediante el Caso de Uso

CU001_Buscar medicamento por nombre comercial, el escenario descrito an-

teriormente.

Ilustración 13 BPM como proveedor, secuencia.


Página 52

Este escenario comienza con interacción del usuario quien solicita el método

findMedicine dentro del consumidor móvil. Este método en el cliente llama un

servicio expuesto a los consumidores mediante el ESB quien llama a un servi-

cio de la capa SOA que se encuentra implementado mediante un proceso BPM

que es invocado. De igual forma este proceso BPM llama a otras actividades

que llaman a otros servicios para realizar el proceso. Cuando el mensaje llega

al componente SOA FindNearestDrugstores se inicia el escenario descrito en

BPM como consumidor de la ilustración 11.

o BPM como proveedor asíncrono: algunos procesos de negocio, por su natu-

raleza pueden ser de larga duración debido a la intervención de otros usuarios

para completarlos. Lo anterior ocasiona que los procesos BPM de larga dura-

ción tengan que ser expuestos como servicios asíncronos para no dejar a los

consumidores finales que los invocan en espera sin poder realizar nada más.

El Caso de Uso CU011_Apartar medicamento presenta estas condiciones en

el siguiente diagrama de secuencia:

Ilustración 14 BPM como proveedor asíncrono.


Página 53


En el diagrama anterior se muestra la petición de apartado de un medicamento

desde la aplicación móvil consumidor. Debido a que este servicio necesita de

la aprobación de la droguería, cuando el consumidor invoca al servicio, este

responde automáticamente con un código único del apartado solicitado para

no dejar a la aplicación cliente esperando por respuesta. Cuando se realiza la

solicitud, el proceso del CU011 crea un proceso asíncrono encargado de poner

la solicitud en la consola web del droguista y que queda esperando a que este

conteste. Para consultar el estado de la solicitud, es necesario otro proceso que

dado el código del apartado retorne el estado de este, realizando una forma de

polling. Para ver el proceso complementario a este escenario ver anexo “SAD”

Capa de Consumidores: son consumidores finales que hacen uso de una interfaz de

usuario. Es la última capa de la arquitectura y consume los servicios de Proceso ex-

puestos en la capa de SOA haciendo uso del ESB como intermediario.

Las capas anteriores necesarias para la construcción de la arquitectura se relacionaron a nivel

lógico con el diagrama EBC creado. La Ilustración 15 de la siguiente página ilustra la relación

creada.

Una vez hecha la relación lógica entre capas y EBC para la realización de la arquitectura

BPM/SOA/ESB del Observatorio, se llevó a cabo la incorporación de componentes específicos

dentro de cada una que permitieron el desarrollo del sistema.

3.1. Componentes específicos para el Observatorio.

Bus de Servicios Empresarial – ESB: componente principal de la Capa ESB. Este es

el componente que se encarga de la abstracción de la homogeneidad existente entre

los diferentes esquemas de datos de las diferentes droguerías y exponer las interfaces

de acceso a estas de manera uniforme. Por otro lado se encarga de exponer los servicios

que los consumidores externos usan, es decir, es el punto de entrada a la lógica desa-

rrollada. De igual forma se conecta con servicios de terceros utilitarios para exponerlos

a la capa SOA. Para lograrlo se vale de componentes Proxy y Servicios de Negocio:


Página 54

o Servicios de Negocio: componente interno del ESB que se encarga de consu-

mir directamente las bases de datos externas mediante un conector específico

o mediante un servicio web expuesto externamente sobre estas:

Consumidor mediante conector: En este caso es necesario que la

base de datos de la droguería soporte el estándar JDBC. Será otorgado

un usuario para conectarse directamente desde el Observatorio a la BD

creando el conector dentro del Bus de Servicio Empresarial.

Consumidor mediante servicio web externo: La droguería tendrá

que ofrecer la dirección de un servicio web mediante el cual se puedan

llevar a cabo las consultas necesarias dentro del Observatorio. No

existirá adaptador interno y el Servicio de Negocio se comunicará con

el Servicio Web dado.

De igual forma, el Servicio de Negocio se puede comunicar con servicios ex-

ternos, distintos a los droguistas, que son expuestos como servicios utilitarios.

o Proxy: componente interno del ESB que se encarga de consumir los Servicios

de Negocio. Dentro de este componente se realiza la lógica de enrutamiento,

cambio de protocolos, cambio de esquemas de distintos mensajes y se ofrecen

bajo una sola interfaz uniforme como servicios utilitarios.

Dentro del observatorio se encuentran los siguientes servicios utilitarios:


Página 55


Ilustración 15 Diagrama EBC con capas lógicas-CU Arquitecturalmente significativos.


Página 56

Nombre Descripción

getAllDrugstores Obtiene la información de todas las droguerías del observatorio.

distanceCalculator Obtiene la distancia entre dos puntos (latitud, longitud) en kilómetros.

medicinesSearch Obtiene la información de un medicamento basado en su nombre desde las droguerías.

getGenerics Obtiene una lista de medicamentos genéricos desde la base de datos del observatorio basado

en un componente activo.

getGenericId Obtiene el Id del componente activo de un medicamento desde la bd del observatorio.

getOwnerSession Retorna el estado de la sesión actual del droguista dentro de la aplicación web.

ReserveMedicine Envía a la aplicación cliente web del droguista la solicitud de apartado de un medicamento.

getManufacturers Retorna los laboratorios Genéricos que producen el componente activo.

insertMedicine Inserta un nuevo medicamento dentro del registro histórico de búsquedas del observatorio.

insertSeparateRegistry Inserta una nueva solicitud de apartado con su estado dentro del Observatorio.

selectDrugstoreOwner Retorna la información de la persona asociada como dueña de una droguería.

selectSeparateRegistry Retorna una solicitud de apartado existente dentro del observatorio.

updateOwnerSession Actualiza la sesión actual de un droguista dentro de la aplicación web.

updateSeparateRegistry Actualiza un registro de apartado dentro del Observatorio.

getConsumerSession Obtiene la sesión actual del consumidor.

updateConsumerSession Actualiza la sesión actual del consumidor.

Tabla 4 Servicios utilitarios.

A continuación se muestra el resumen del componente ESB con sus partes relacio-

nadas:


Página 57


Ilustración 16 Componente ESB

En la parte más baja del diagrama vemos dos componentes de bases de datos que re-

presentan las dos formas de conectar un sistema al Observatorio. La base de datos X

se incorpora mediante un conector que la expone como servicio. La base de datos N se

conecta mediante web service expuesto de forma externa, por lo cual el conector no es

necesario pero si la incorporación de un wsdl que describa el servicio. La base de datos

al extremo derecho del diagrama es la propia del Observatorio, la cual es incorporada

con conector. De igual forma el servicio externo más a la izquierda necesita de su wsdl

para ser consumido por el Servicio de Negocio. Arriba de los servicios de negocio se

encuentran los Proxy que se encargan de las tareas necesarias de transformación, en-

rutamiento y enriquecimiento de mensajes. Cada proxy expone una interfaz uniforme

independiente de los Servicios de negocios con los que se comunica como Servicio

Utilitario a la capa SOA. Por cada servicio utilitario del Observatorio es necesaria la

creación de un Proxy.


Página 58

Servidor SOA: encargado de la Capa SOA, consume administra y expone servicios

de los tres tipos ya mencionados: Utilitarios, de Negocio y de Proceso. Cuenta con un

Catálogo de Servicios interno donde se registran servicios externos (utilitarios, proxys

del ESB) e internos (creados con BPM) para ser re utilizados o expuestos a los consu-

midores. Cuenta con un motor de procesos para el despliegue de servicios. De igual

forma cuenta con un servidor de presentación que se conecta al Motor de servicios para

poder llevar una administración en tiempo real de los servicios desplegados por medio

de un navegador de internet. A continuación se muestra el componentes:

Ilustración 17 Servidor SOA

Dentro de la capa SOA, en sí, sólo se encuentran desplegados servicios de proceso y

servicios de negocio. Para el caso del Observatorio se cuentan con los siguientes ser-

vicios de Proceso y de Negocio:

SERVICIOS DE NEGOCIO SERVICIOS DE PROCESO

FindNearestDrugsto-

res

Dados una latitud, longitud y radio, retorna

las droguerías que se encuentran dentro del

perímetro.

FindMedicine Proceso para encontrar un medicamento co-

mercial en las droguerías cercanas al usuario.


Página 59


FindMedicineIn-

Drugstores

Dado un nombre comercial de medicamento

y una lista de droguerías, retorna todos los

medicamentos dentro de las droguerías que

tenga el nombre dado.

SeparateMedici-

neSyn

Proceso para apartar un medicamento dentro

de una droguería. Devuelve el codigo único

asociado a la solicitud.

GetSeparateStatus Dado el código único de una solicitud de

apartado de medicamento retorna el estado

actual de esta.

RecomendGeneric Proceso para pedir al Observatorio la reco-

mendación de un medicamento genérico ba-

sado en uno comercial.

DrugstoreLogin Permite al droguista autenticarse dentro del

sistema Web.

ObtainMedicineInfo Proceso para obtener toda la información dis-

ponible de un medicamento.

DrugstoreLogOut Permite al droguista cerrar sesión dentro del

sistema Web.

ObtainDrugstoreInfo Proceso para obtener toda la información dis-

ponible de una droguería.

ConsumerLogin Permite al consumidor autenticarse dentro del

sistema móvil.

CompareCommer-

cialGeneric

Proceso para pedir al Observatorio la realiza-

ción de una comparación entre medicamento

comercial y sus genéricos.

ConsumerLogOut Permite al consumidor cerrar sesión dentro

del sistema móvil.

SeparateMedicineAsy Proceso de larga duración, asíncrono que en-

vía la petición de apartado a una droguería y

espera a que esta conteste.

Tabla 5 Servicios de negocio y de proceso.

Componentes BPM: En primer lugar se encuentra un Motor BPM encargado de des-

plegar y poner en funcionamiento un proceso BPM. Está compuesto de los siguientes

componentes:

o Modelador de Procesos: mediante herramientas visuales permite el modelado

de procesos nuevos. Por otro lado el modelador se conecta con el Catálogo de

Servicios del servidor SOA para permitir el consumo de servicios ya existentes

dentro del proceso que se está creando.

o Motor BPM: componente donde se ejecuta el proceso de negocio una vez

desplegado. Cuando el proceso es expuesto como servicio en el motor SOA,

este último hace referencia a la instancia del proceso que se está ejecutando

dentro del motor BPM cuando es llamado.

o Servidor de Administración (BAM): permite ver el rendimiento en tiempo

real de los procesos que se encuentran desplegados así como todo su análisis

y creación de informes de análisis a partir de indicadores de negocio.

A continuación se muestra el componente.


Página 60

Ilustración 18 Componente BPM.

Componentes Consumidores: El Observatorio cuenta con un cliente Web para los

droguistas y un cliente Móvil para los consumidores. Para el cliente Web se cuenta con

un servidor de presentación que ofrece las pantallas para que los droguistas puedan

conectarse al sistema y recibir notificaciones de apartados. A continuación se exponen

los componentes consumidores:

Ilustración 19 Consumidores.

En la Ilustración 20, Componentes Observatorio se presentan todos los componentes y su co-

municación dentro de un solo diagrama.

Ya con los componentes detectados se procedió a relacionar estos con el diagrama EBC reali-

zado anteriormente. La relación detectada se expone en la Ilustración 21.


Página 61


El proceso realizado anteriormente permitió la identificación de componentes necesarios den-

tro del Observatorio y la relación de estos con las funcionalidades lógicas del sistema. Poste-

riormente se realizó el diagrama de despliegue que expone como se ubicaron los componentes.

4. Vista de Despliegue.

Para realizar el despliegue de todos los componentes del Observatorio, se procedió a investigar

las diferentes formas topológicas en que se pude configurar un Bus de servicios empresarial.

Así se escogió una topología Hub and Spoke [38]que permite una instalación sencilla del bus,

donde existe un gran solo componente que se comunica de forma central con todos los servicios

que se exponen en este para lograr el enrutamiento de mensajes. De igual forma permite dis-

ponibilidad al distribuir la instalación del mismo ESB en dos o más servidores. Permite una

administración sencilla y fácil depuración.

Con base en lo anterior, los componentes del observatorio se desplegaron como se muestra en

la Ilustración 22 Diagrama de Despliegue.

A continuación se describen los nodos detectados dentro del diagrama de despliegue expuesto

en la Ilustración 22 Diagrama de Despliegue:

Nodo Servidor ESB: Donde es desplegado el ESB junto con los proxy y servicios de

negocio definidos dentro de él. Posee lógica para enrutar, transformar, y validar los

mensajes entrantes y salientes.

Nodo Servidor SOA: Acá son desplegados los servicios de esta capa (servicios de

proceso y de negocio). Adicionalmente contiene todos los componentes que permiten

el manejo, control y monitoreo de los servicios desplegados dentro del motor de pro-

cesos.

Nodo Servidor BPM: Acá son desplegados los procesos pertenecientes a esta capa.

Se encuentra el motor de proceso, el modelador de procesos, el servidor de adminis-

tración y la base de datos del servidor de administración donde se guarda la definición

de los KPI junto con las medidas tomadas de estos en los procesos ejecutados.


Página 62

Ilustración 20 Componentes Observatorio.


Página 63


Ilustración 21 EBC Componentes-CU Arquitecturalmente significativos.


Página 64

Nodos Droguerías: Es el componente externo, el cual es conectado al Observatorio

por solicitud de un droguista. Representa la conexión entre la base de datos de la dro-

guería con el Observatorio. Sobre este componente se realizan consultas, de forma or-

questada para dar respuesta a las solicitudes de los consumidores.

Nodo Base de datos Observatorio: Componente del Observatorio donde este va guar-

dando los datos correspondientes a los droguistas inscritos junto con los medicamentos

que se han buscado. De igual forma acá se van almacenando los datos correspondientes

a los indicadores de negocio.

o Estrategia de inserción de datos:

Debido a que la principal fuente de datos son las droguerías, la base de datos

del Observatorio se encuentra vacía al principio. Para solucionar esto, la base

de datos será cargada con dos reportes de precios, descripción de medicamen-

tos y laboratorios obtenidos del INVIMA y del OBSERVAMED, ambas insti-

tuciones públicas en Colombia. De igual forma, la base de datos se ira llenando

a medida que se realizan consultas desde el cliente móvil.

Nodos Cliente Web: Es el cliente por el cuál accede el droguista para consultar indi-

cadores de interés y de igual forma para pedir en primer lugar la inscripción al obser-

vatorio de una droguería.

Nodos Cliente Móvil: Es el cliente por el cual accede el consumidor al Observatorio.

Acá se exponen los servicios que están disponibles para él.

Nodo Servicio Externo: Representa la forma de conexión de los servicios externos de

terceros que consuma el observatorio y que no se encuentran dentro de su dominio. Un

ejemplo de este servicio es aquel que calcula la distancia entre dos puntos en un mapa.

5. Evaluación Arquitectura.

Para verifica que la arquitectura cumple con los atributo de calidad señalados en la etapa de

análisis, se realizó una evaluación con base en la metodología SBAR [40] [41] comparando la

arquitectura propuesta contra los atributos de calidad definidos en el capítulo de análisis (Ca-

pitulo III-2.4). Así se procedió a abordar cada atributo de calidad describiendo como uno o

varios componentes de la arquitectura tienen la capacidad para suplir el requerimiento, y seña-

lando posibles tácticas arquitecturales de ser necesario.


Página 65


Ilustración 22 Diagrama de Despliegue.


Página 66

Escalabilidad y Desempeño: se aborda logrando una fácil escalabilidad horizontal del

sistema en sus diferentes capas de ESB, SOA o BPM. Para lograr escalabilidad que

soporte el número de transacciones recibidas por los consumidores finales para lograr

un mejor desempeño, es necesaria una escalabilidad en los componentes de servidor

SOA y BPM. El siguiente diagrama muestra cómo se puede implementar una escala-

bilidad horizontal al distribuir la instalación del servidor SOA en dos nodos físicos.

Para seguir manejándolos como uno solo, y que los consumidores puedan seguir acce-

diendo a los servicios de forma transparente, es necesario un componente Balanceador

de cargas (componente a la izquierda) que distribuya las peticiones a los diferentes

servidores. En el nuevo servidor se pueden realizar copias de los servicios o desplegar

nuevos. El catálogo de servicios sigue siendo el mismo para que todos los servicios se

registren en un único punto. El servidor de presentación (donde también se administran

los procesos) es único y conoce los dos motores de procesos para llevar una sola vista

lógica de la capa.

Ilustración 23 Escalabilidad y Desempeño.

Para lograr escalabilidad dentro de los sistemas externos conectados al observatorio,

de igual forma se puede distribuir la instalación del bus en diferentes nodos. Esto per-

mite un mejor manejo de los mensajes desde el observatorio hacia las droguerías.


Página 67


Interoperabilidad y Soporte de estándares abiertos: para lograr la interoperabilidad

deseada, para la comunicación del Observatorio con las droguerías, el Bus Empresarial

es el componente clave.

o Mediación de protocolos: la disponibilidad de diferentes conectores dentro

del Bus permiten el paso de un mensaje proveniente en un protocolo a otro.

o Transformación de mensajes: mediante características de transformación

por XSLT y lenguajes de consultas sobre documentos XML como XQuery, el

Bus Empresarial permite realizar la transformación de esquemas para brindar

homogeneidad en los servicios que ofrece.

Ilustración 24 Interoperabilidad.

El diagrama anterior muestra un servidor ESB junto con el componente Bus Empresa-

rial donde los componentes verdes exponen los conectores capaces de entender dife-

rentes protocolos. Todos los conectores son expuestos como Servicios de Negocio que

son consumidos por los proxy (componentes morados) donde se realiza la transforma-

ción de esquemas para unificar los datos y exponer servicios a la capa SOA. De igual

forma los conectores están basados en estándares abiertos de comunicación lo que hace

posible la conexión con una gran variedad de sistemas externos.


Página 68

Seguridad: La seguridad en la comunicación se configura tanto en los proxy que ofre-

cen servicios a la capa SOA y en los Servicios de Proceso que son aquellos que se

exponen a los consumidores. Gracias a la centralización de los puntos de comunicación

entre diferentes capas técnicas de encriptación pueden ser usadas implementando el

protocolo de comunicación HTTPS, debido a que todo está basado en SOAP dentro

del Observatorio.

Ilustración 25 Seguridad HTTPS.

Monitoreo: El monitoreo es logrado gracias a los servidores existentes en la capa SOA

y la capa BPM. Ambos se encuentran conectados a los motores respectivos como se

explicaba anteriormente y permiten a los administradores del Observatorio ver el es-

tado actual de los servicios y los procesos.


Página 69


Diseño visual de la lógica de negocio: El componente modelador de procesos BPM

permite la creación de lógica de negocio de forma visual.

Servicios de larga y corta duración: Nuevamente, con la ayuda del motor de procesos

BPM se logra esta característica, donde la invocación de servicios síncronos y asíncro-

nos que soportan este requerimiento es posible.

Finalmente la arquitectura fue probada con el prototipo desarrollado y haciendo uso de los

escenarios planteados. Para mayor detalle de la arquitectura y de la evaluación de esta referirse

al anexo “SAD” y “Evaluación de la Arquitectura”. Para una mejor vista de los diagramas

presentados puede referirse al anexo “Imágenes Diagramas”.

V – DESARROLLO DE LA SOLUCIÓN

Para el desarrollo del prototipo se procedió con fases pequeñas iterativas sobre cada compo-

nente, probando de forma paralela cada nueva característica que se fue desarrollando para fi-

nalmente, y luego de desarrollados todos los componentes, unirlos y realizar pruebas del sis-

tema.

Para el prototipo se escogieron los siguientes casos de uso, pertenecientes al set de casos de

uso significativos, que permitieron destacar las características de la arquitectura escogida, así

como realizar la validación de está mediante los escenarios de los atributos de calidad.

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.

Tabla 6 CU Desarrollados.

Para el desarrollo de la lógica de negocio se procedió a la comparación de diferentes herra-

mientas líderes en el mercado, tanto del ámbito del software libre como del ámbito comercial

para elegir la que mejor se ajustaba a las necesidades de desarrollo del prototipo, teniendo muy

presente la curva de aprendizaje, facilidad de integración de BPM con SOA y ESB y facilidad


Página 70

de desarrollo. Así se realizó la siguiente tabla que expone las características principales de cada

producto escogido para el análisis.

Jboss MuleSoft +

Bonita

Oracle IBM

SOA/ESB

Facilidad de instalación. 10 10 10 5

Facilidad de integración

con BPM.

10 5 10 10

Documentación para aprendizaje.

10 6 10 6

Documentación para

desarrollo.

10 6 10 6

Facilidad creación de ser-vicios web SOAP y

REST.

8 10 7 10

Facilidad invocación de servicios web SOAP y

REST.

8 10 10 10

Facilidad de transforma-

ción de mensajes.

5 5 8 8

Facilidad de enrutamiento

de mensajes.

10 9 5 8

Sub total 71 61 70 63

BPM

Facilidad de instalación. 10 10 10 5

Facilidad de integración con SOA/BPM.

10 5 10 10

Facilidad creación de ser-

vicios web SOAP y REST.

8 5 10 10

Facilidad invocación de

servicios web SOAP y

REST.

8 5 10 10

Capacidades de análisis

de procesos (KPI).

8 5 10 8

Facilidad para el desarro-

llo de pruebas unitarias.

10 5 10 5

Sub total 54 35 60 48

Total 125 96 130 111

Tabla 7 Comparación stacks de desarrollo.

En la tabla anterior se expone una comparación entre los stacks de desarrollo para

SOA/ESB/BPM ofrecidos por JBoss, MuleSoft (ESB) con BonitaSoft (BPM), Oracle e IBM.

Para la comparación se buscó información referente a cada una de las herramientas e informa-

ción de procesos de implementación y guías de desarrollo ([51], [52], [53], [54], [55]). Cada

aspecto comparado recibió una puntuación de 0 a 10, primero realizando un subtotal por

SOA/ESB y luego por BPM; la herramienta con mayor puntaje fue la elegida.


Página 71


Así para el desarrollo de la lógica de negocio se escogió el stack de herramientas SOA de

ORACLE debido, entre otros aspectos, a que este provee todos los componentes necesarios

para la construcción del prototipo con la arquitectura propuesta, bajo un solo proveedor [3]:

BPM: Oracle Linux 6 Update 4 (64-bit), Oracle Database Express Edition 11g Release

2, Oracle BPM Suite 11.1.1.7.1, Oracle JDeveloper 11.1.1.7.0, Oracle Weblogic

10.3.6.

SOA y ESB: Oracle Linux 6 Update 4 (64-bit), Oracle Database Express Edition 11g

Release 2, Oracle JDeveloper 11.1.1.7.0, Oracle Weblogic 10.3.6., Oracle SOA Suite

11.1.1.7.1 (con Business Activity Monitoring).

Componente Móvil: se procedió con el desarrollo bajo plataforma android con la he-

rramienta Android Studio, debido a su licenciamiento y acceso gratuito [2].

Componente Web: IDE Netbeans 8.0.2, con lenguaje Java para el back end y ja-

vascript para el lado cliente, que permitió el uso de la tecnología Websockets para

comunicación en tiempo real [24].

Así, la arquitectura del prototipo se expone en la Ilustración 26 con el uso de tecnologías es-

pecíficas en cada componente.

CU001_Buscar medicamento por nombre comercial.

Para este caso de uso se accede desde la aplicación cliente móvil, donde está configurado un

solo usuario autenticado por defecto para efectos del prototipo. A continuación la aplicación

solicita el nombre del medicamento y un radio de búsqueda. El siguiente ejemplo se realizó

buscando el medicamento Advil.


Página 72

Ilustración 26 Diagrama Tecnologías


Página 73


Ilustración 27 Pantalla búsqueda.

Cuando el consumidor solicita la búsqueda, la aplicación se conecta con el sistema BackEnd

disparando el proceso FindMedicine. La solicitud del ejemplo realiza el camino mostrado en

la Ilustración 28, dentro del proceso disparado según se observa en la consola de administra-

ción SOA. De igual manera este proceso dispara dos más relacionados a los casos de uso

CU002 y CU003 mostrados en las Ilustraciones 29 y 30.

Ilustración 28 Flujo CU001.


Página 74

Ilustración 29 Flujo CU002.

Ilustración 30 Flujo CU003

Dentro de los casos de uso CU003 y CU002, los procesos anteriormente mostrados se conectan

al Bus de Servicios de Oracle, tal como se planteó en la arquitectura con el fin de comunicarse

y enrutar los mensajes necesarios a los sistemas externos. En la ilustración 29 las actividades

getAllDrugstores_Activity y distanceUserDrugstore_Activity son las que se conectan con el

OSB. En la ilustración 30 las actividades findMedicine_Activity y insertMedicineObs_Activity

son las que se conectan con el OSB. En la ilustración 30, el subproceso creado para buscar los

medicamentos en las droguerías se ejecuta de forma paralela por cada droguería, lo que permite

una ejecución del proceso eficiente, y donde el número de droguerías conectadas no influye

significativamente sobre el desempeño del proceso.

Una vez terminados los procesos, el cliente móvil recibe la respuesta por parte del Observato-

rio.


Página 75


Ilustración 31 Pantallas resultado búsqueda.

CU011_Apartar medicamento.

Luego de realizada una búsqueda, el consumidor puede entrar en cada una de las farmacias

listadas para ver los medicamentos que se obtuvieron por cada droguería cercana a él. La ilus-

tración 31, muestrea la pantalla del extremo derecho con los medicamentos para la droguería

1.

Una vez mostrado parte del detalle del medicamento, se puede realizar un apartado de este en

la droguería mediante el botón “Apartar medicamento”. Se pide confirmación al presionar esta

opción.

Ilustración 32 Pantallas apartando medicamento.

Una vez enviado el mensaje de apartado al observatorio, se retorna un mensaje de éxito al

usuario y este es redirigido a la pantalla de apartados para que pueda ver el estado de la solitud.


Página 76

En la pantalla anterior se observa el estado de cada solicitud que puede ser: PENDIENTE POR

APROBACIÒN, APROBADO POR DROGUERÌA, RECHAZADO POR DROGUERÌA o

SIN RESPUESTA DE DROGUERÌA.

De igual forma, desde el cliente web creado para el droguista, este ve en tiempo real la nueva

solicitud que ha sido pedida por el consumidor. Para hacerlo primero tiene que autenticarse en

el cliente web para luego cargar las solicitudes relacionadas con su droguería. Para la autenti-

cación se crearon dos procesos más: DrugstoreLogIn y DrugstoreLogOut.

Ilustración 33 Ingreso consola web droguista.

Ilustración 34 Consola droguista.

Desde la pantalla anterior el droguista puede ver todos los pedidos que se le han realizado (tabla

izquierda), que al hacer click sobre cada uno, en la pantalla derecha se muestra el detalle y las

opciones de confirmar o rechazar la solicitud.

Para lograr la realización del caso de uso CU011 fue necesario el desarrollo de tres nuevos

procesos dentro del observatorio que permitieran una comunicación asíncrona debido a que es

una tarea de larga duración donde el cliente móvil no podía quedarse esperando por la respuesta

de la droguería. Para ello se desarrollaron los siguientes procesos:


Página 77


Ilustración 35 Reservar síncrono

Ilustración 36 Reservar asíncrono.

Para verificar la respuesta por parte de la droguería de igual forma también se creó un proceso

síncrono para el consumidor, que obtuviera el estado dado un código único de apartado.

CU008_Generar indicadores de negocio.

Para el caso de uso se pusieron dos puntos de medición dentro de los procesos referentes a los

casos de uso CU002 y CU003 para poder obtener dos indicadores referentes a: “Número de

veces que una droguería estuvo en un radio de búsqueda” y “Número de veces que una drogue-

ría tuvo el medicamento que se solicitó”. Para lograr el registro de los Indicadores de Negocio

se definieron los siguientes atributos dentro del proceso:

Dimensiones: tipo de indicador de negocio que permite la agrupación de valores. Se

definieron las siguientes dimensiones:

o Drugstore_name: Para permitir la agrupación de datos por el nombre de cada

droguería.


Página 78

o dateSearch: Fecha de la captura del indicador de negocio. Se utiliza para poder

mostrar información por periodos de tiempo (mes, año).

Los puntos de medición son representados por las cámaras dentro del proceso. Posteriormente

se definió una vista dentro del BAM para poder consultar la información. A continuación se

muestra el reporte.

Ilustración 37 Reporte indicadores de negocio.

El reporte nos muestra 4 droguerías inscritas en el Observatorio donde la columna izquierda

indica la cantidad de veces que esa droguería estuvo en un radio de búsqueda y la columna

derecha la cantidad de veces que tuvo el medicamento solicitado. Así, según el ejemplo, la

Droguería 1 estuvo en 6 búsquedas de las cuales 6 tuvo lo que se buscaba, a diferencia de la

Droguería Hospital San Ignacio que solo apareció en 4 búsquedas y no tuvo el medicamento

necesitado nunca.

CU004_Generar recomendación por genérico.

Para lograrlo, el Observatorio hace uso de la información disponible del INVIMA, SISMED

y OBSERVAMED. Se procedió con la identificación del componente activo más general del

producto que seleccionó el consumidor. Con base a este componente (discriminando concen-

tración), el observatorio busca los laboratorios conocidos de productos genéricos que fabrican

medicamentos con esta sustancia, los agrupa y response la solicitud. El consumidor una lista

de laboratorios farmacéuticos con su respectivo conjunto de medicamentos genéricos.


Página 79


Ilustración 38 Proceso generar recomendación genérico.

Primero, la aplicación muestra un listado con los laboratorios genéricos encontrados que pro-

ducen medicamentos con el componente activo dado.

Ilustración 39 Listado laboratorios genéricos y medicamentos.

Sobre cada laboratorio se tiene el nombre y la cantidad de medicamentos genéricos encontra-

dos. Cuando se presiona un laboratorio y se presiona “Mostrar medicamentos” la aplicación

muestra en pantalla la lista de medicamentos encontrados.

Para más detalle sobre las funcionalidades del prototipo implementado por favor referirse al

anexo Descripción funcionalidad prototipo.

VI – RESULTADOS

Como se muestra en la ilustración 27 del diagrama anterior, para probar la arquitectura se

conectaron 4 bases de datos representando a las droguerías más la base de datos del observa-

torio. Para las droguerías se usaron 2 bases de datos conectadas por medio de conector JCA


Página 80

Oracle XE, 1 base de datos MSSQL conectada por medio de conector JCA y 1 base de datos

MySQL conectada por medio de un servicio web externo.

Como se planteó en la metodología, se realizaron pruebas funcionales por componentes para

luego realizar pruebas de sistema progresivas, hasta contar con todos los componentes conec-

tados al sistema.

Para estas pruebas el Observatorio se dividió en los siguientes componentes:

Componente OSB: Se conectaron primero dos bases de datos más la base de datos

del Observatorio. Luego desplegado el sistema se conectaron las otras dos restantes

para validar uno de los escenarios de los requerimientos no funcionales. De igual

forma se probaron las funcionalidades de ruteo y transformación para validar escena-

rios.

Componente BPM/SOA: Es la capa intermedia del observatorio. Con la creación de

cada nuevo proceso se hicieron pruebas de estrés teniendo en cuenta la comunicación

con el OSB. Para las pruebas de estrés se usó el Weblogic Server que permite la con-

figuración de las pruebas, creación de hilos concurrentes y da como resultado el

tiempo promedio de cada respuesta para poder compararlo con los escenarios de los

requerimientos no funcionales.

Componente Móvil: Es la interfaz con el consumidor. Antes de conectarlo con el

sistema BackEnd, se quemaron datos dentro del dispositivo móvil para simular las

interacciones y probar las pantallas. Luego de desarrollada toda la aplicación móvil se

conectó por medio de la invocación de servicios web al sistema BackEnd para probar

la interacción.

Componente Web: Es la interfaz con los droguistas. Primero se probó con datos que-

mados para probar la interacción y flujos de pantallas. Luego se conectó con el obser-

vatorio para probar la interacción con el sistema BackEnd.

Componente BAM: Es el servidor necesario para la implementación de los Indica-

dores de Negocio y su representación gráfica. Primero se probó la creación de reportes


Página 81


con datos quemados en la base de datos del BAM, luego se conectó con el BackEnd

para probar que los indicadores se guardaran y se generaran los reportes en tiempo

real.

Cada componente se fue conectando progresivamente con el BackEnd (OSB y BPM/SOA), y

se fue probando como un todo, hasta tener todo conectado.

Con cada componente se probaron los escenarios relacionados para verificar que se cumpliera

con lo especificado y terminar de evaluar la arquitectura. A continuación se presentan los re-

sultados para tres escenarios mostrando la evaluación realizada:

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 minu-

tos:

-MySQL: 60 minutos.

-MSSQL: 45 minutos.

Estado: CUMPLIDO.

Tabla 8 Evaluación ES001.

Como se describe en el campo “Verificación”, se incorporaron dos nuevas bases de datos luego

de contar con el observatorio funcionando desplegado. El campo “Resultados” muestra lo que

se obtuvo de la prueba del escenario. El campo “Estado” indica si el escenario fue CUMPLIDO

o NO CUMPLIDO, para verificar que la arquitectura cumple con lo propuesto.

ES007.

Para las pruebas relacionadas con este escenario es importante describir las características de

hardware donde se está ejecutando el servidor con la lógica del BackEnd, siendo este un

computador portátil, no configurado para su uso como servidor dedicado, el cual si se tendría

en un ambiente de producción.


Página 82

o Portátil Lenovo G40. Procesador i5-4200U, 1.60GHz. Memoria RAM: 8GB.

Para las droguerías usadas, se tiene un inventario entre 1500 y 2000 (extraídos del reporte ge-

nerado por el INVIMA) medicamentos a excepción de la base de datos MySQL debido a limi-

taciones de almacenamiento impuestas por el proveedor del servidor en la nube. Igualmente,

se inscribieron 20 droguerías (unas copias de las otras) para forzar un escenario donde en una

búsqueda a 5 km el Observatorio encontrara 20 droguerías cercanas y llamara a cada uno de

los sistemas.


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 desa-

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

Tabla 9 Evaluación ES007.

CONFIGURACIÓN PRUEBA RESULTADOS DE LA PRUEBA

Proceso Hilos

Ciclos por

cada hilo

Tiempo

Min(ms) Promedio(ms) Tiempo May(ms)

FindMedicine 50 10 29246 45652 40584

SeparateMedicineSyn 50 10 502 1579 2256

GetSeparateStatus 50 10 1114 2798 3908

RecommendGeneric 50 10 1015 2854 3995

DrugstoreLogin 50 10 556 2334 3663

DrugstoreLogOut 50 10 618 1565 2455

Tabla 10 Pruebas de estrés ES007.

Con las dos tablas anteriores se exponen los resultados obtenidos para el ES008, donde por

cada proceso consumido por los clientes móviles y web, se realizaron pruebas de estrés ha-

ciendo uso del WebLogic, con las configuraciones mostradas. Los resultados obtenidos, en su

mayoría se adaptan a las restricciones del escenario, sin embargo es preciso aclarar que las

características de hardware donde corre el BackEnd no son las adecuadas para un servidor, por

lo que se da como CUMPLIDO el escenario con la certeza que en un hardware adecuado cum-

plirá lo estipulado. Igualmente, el llamado a cada droguería se realiza de forma paralela lo que

permite que la complejidad en tiempo se mantenga a medida que se incorporan más. Por otro


Página 83


lado la respuesta de este escenario se encuentra sujeta a la respuesta del sistema más lenta al

cual se conecte el Observatorio.

ES009


Nombre:

El sistema debe soportar la caída de una Droguería si esta no se en-

cuentra 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 encon-traba desconectada. Para el resultado de la prueba de estrés referirse a

la tabla “Prueba de estrés ES009”.

Estado: CUMPLIDO.

Tabla 11 Evaluación ES009

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

Tabla 12 Prueba de estrés ES009.

Los anteriores tres escenarios son unos de los más cruciales dentro del observatorio, debido a

que en estos es necesaria la conexión y comunicación con las droguerías como sistemas exter-

nos y con otros servicios utilitarios.

Con el resultado de todos los escenarios evaluados, encontrado en el documento anexo Evalua-

ción de la Arquitectura, junto con la especificación de cómo cada componente aborda cada

atributo de calidad, se concluye que la arquitectura planteada y desarrollada por medio del

prototipo es válida y permite el desarrollo del Observatorio bajo las condiciones dadas.

VI – CONCLUSIONES

1. Análisis de Impacto del Desarrollo

Con lo obtenido durante la elaboración del trabajo de grado se puede concluir lo siguiente:


Página 84

Desde el punto de vista disciplinar se ha dejado una arquitectura genérica (libre de tecnología)

que permite la unificación de diferentes fuentes de datos heterogéneas, que se pueden exponer

bajo una misma interfaz para abstraer la complejidad en la transformación de los mensajes

usados en la comunicación entre los sistemas externos, de la lógica de negocio realizada me-

diante procesos visuales que permiten la generación de información de interés mediante la me-

dición de estos. Con lo anterior, se han dejado unos planos para la construcción de sistemas

que requieran el cumplimiento de las características ya mencionadas, extrapolando el contexto

de la problemática del Sector Salud/Farmacéutico a otros sectores donde soluciones de este

estilo sean necesarias.

Desde el punto de vista social, la elaboración del Observatorio es un proyecto, que totalmente

finalizado, deja una herramienta para la población colombiana en su búsqueda de medicamen-

tos bajo un precio justo y accesible al igual que una fuente para la consulta de datos específicos

sobre productos de este sector. De igual forma, es un sistema para generar una ventaja compe-

titiva a aquellos participantes del sector Micro PyMe farmacéutico nacional, para apoyar en su

capacidad de competencia y dar frente a las grandes cadenas que hoy día están abarcando el

mercado.

Desde el punto de vista económico, el Observatorio permite una mejora en la calidad de vida

de las personas que no posees ni información ni recursos para la obtención de cierto medica-

mento comercial, brindando una fuente de información para conocer nuevas alternativas gené-

ricas que desconocía y que muy seguramente si van a estar al alcance económico del consumi-

dor.

2. Conclusiones y Trabajo Futuro

Con lo obtenido durante la elaboración del trabajo de grado se puede concluir lo siguiente:

El objetivo específico 1 “Realizar la caracterización de un observatorio nacional de

oferta y disponibilidad de productos farmacéuticos mediante un proceso de ingeniería

de requerimientos” se puede dar por cumplido con la elaboración del documento “Es-

pecificación de Requerimientos”.


Página 85


El objetivo específico 2 “Diseñar una arquitectura orientada a BPM y ESB que permita

el desarrollo de un observatorio nacional de oferta y disponibilidad de productos far-

macéuticos” se puede dar por cumplido con la elaboración del documento SAD.

El objetivo específico 3 “Evaluar la arquitectura diseñada para el desarrollo del obser-

vatorio” se puede dar por cumplido con la elaboración del documento Evaluación de

la Arquitectura.

El objetivo específico “Desarrollar un prototipo que permita probar la arquitectura di-

señada en un ambiente de pruebas dentro del dominio del problema” se puede dar por

cumplido con la elaboración del prototipo funcional, del cual se entrega el código y el

documento “Descripción funcionalidad prototipo”.

Entre otras conclusiones obtenidas mediante la elaboración del trabajo de grado tenemos:

Entre el diseño y construcción de procesos de negocio siempre es necesaria la re ela-

boración o re estructuración de ciertos componentes dentro de estos. Lo anterior debido

a falta de experiencia con las herramientas utilizadas que exigían la construcción de

los procesos de ciertas formas específicas restringidas.

La incorporación de otros componentes que ayudaran a obtener una arquitectura más

escalable no fueron posibles de implementar debido a la restricción de tiempo existente

para el proyecto. Tal es el caso del Registry, componente que permite desacoplar los

consumidores de servicios con los proveedores al brindar un repositorio central donde

se registran todos los servicios disponibles dentro del sistema.

La utilización de componentes BPM, teniendo en cuenta la eficiencia en los procesos

no es muy común, por lo que la documentación encontrada no ayudó a obtener la ar-

quitectura deseada; por lo anterior, y luego de obtener experiencia con las herramientas

escogidas para el desarrollo del proyecto, se escogió hacer especial énfasis en la opti-

mización al hacer uso de procesamiento paralelo de actividades, compuertas paralelas,

manejo de errores, temporizadores que finalizaran con tareas luego de un tiempo de-

terminado y procesos asíncronos, igualmente para dejar una base para aquellos que

quieran implementar soluciones BPM basadas en eficiencia.

Con la exposición de los procesos BPM como servicios, se logra obtener un término

acuñado desde la aparición de los dispositivos móviles conocido como BPM Mobile.


Página 86

Esto permite exponer los procesos al exterior y que sean consumidos por cualquier

dispositivo que sea capaz de realizar invocaciones por llamadas HTTP, transformando

los procesos en algo que era meramente interno de las organizaciones a algo externo.

Con relación al punto anterior, la exposición por servicios permite el desarrollo de

nuevas interfaces que permitan logra un sistema que penetre en diferente tipos de usua-

rios teniendo en cuenta incapacidades especiales que requieran un diseño de interfaz

muy específico, sin necesidad de preocuparse por la implementación de la lógica ya

existente, funcional y verificada.

Los ESB son componentes de software que usados de la manera adecuada y bajo las

condiciones de problemas adecuados, brindan una serie de atributos de calidad que

permiten, en general, sistemas más sostenibles cuando la cantidad de usuarios conec-

tados a este crece a gran escala.

Como trabajo futuro sobre el trabajo de grado realizado se propone:

Una validación con usuarios finales no fue posible para el desarrollo del proyecto de-

bido a restricciones de tiempo y a que su principal objetivo no era este. Por lo anterior

se propone realizar este proceso.

Incorporación de un componente Registry dentro de la arquitectura que permita un

mayor desacople entre los consumidores dentro de la capa SOA y lo proveedores en la

capa ESB, para lograr una arquitectura más escalable.

La elaboración de la arquitectura propuesta con herramientas completamente libres que

se puedan usar en ambientes comerciales sin necesidad de pago, realizando la respec-

tiva arquitectura aterrizada a tecnología que refleje los cambios necesarios para poder

realizarla.

Incorporación de más procesos de negocio según necesidades del sector. Lo anterior

puede ser atacar otro de los problemas expuestos como lo es “poder de negociación

frente a los laboratorios farmacéuticos” incorporando sistemas externos de los labora-

torios al observatorio para colocar órdenes más grandes, conformadas por grupos de

droguerías, logrando un mejor precio en el abastecimiento de estos gracias al volumen

de compra.


Página 87


IV- REFERENCIAS Y BIBLIOGRAFÍA

[1] “What is software architecture” (2006) [en línea], disponible en: http://www.ibm.com/de-

veloperworks/rational/library/feb06/eeles/, recuperado: agosto 2015.

[2] “Android Studio” [en línea], disponible en: http://developer.android.com/intl/es/sdk/in-

dex.html, recuperado: Octubre de 2015.

[3] “Oracle Fusion Middleware SOA Suite” [en línea], disponible en: http://www.ora-

cle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html, recuperado: Octu-

bre de 2015.

[4] Tešanovic, A. “What is a pattern?” [en línea], disponible en: http://st.inf.tu-dres-

den.de/Lehre/dpf/IntroductoryPapers/tesanovic-WhatIsAPattern.pdf, recuperado: agosto 2015.

[5] Gang, L. “A comparative study between soft system bus and Enterprise Service bus” (2012)

[en línea], disponible en: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&ar-

number=6394383&url=http%3A%2F%2Fieeex-

plore.ieee.org%2Fiel5%2F6392590%2F6394246%2F06394383.pdf%3Far-

number%3D6394383, recuperado: Agosto 2015.

[6] “Using ESB technology as a foundation for BPM” (2012) [en línea], disponible en:

https://www.mulesoft.com/lp/whitepaper/soa/business-processes-management, recuperado:

11 de abril de 2015.

[7] “Understanding Enterprise Application Integration - The Benefits of ESB for EAI”[en

linea], disponible en: https://www.mulesoft.com/resources/esb/enterprise-application-integra-

tion-eai-and-esb, recuperado: Agosto 2015.

[8] Kumara, I. “Towards Reusing ESB Services in Different ESB Architectures” (2010) [en

línea], disponible en: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5615740, re-

cuperado: Agosto 2015.

[9] Fuhua, G. “Architecture Comibining SOA and BPM “(2011) [en linea], disponible en:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnum-

ber=5974589&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnum-

ber%3D5974589, recuperado: Agostos 2015.

[10] “Oracle Business Activity Monitoring” [en linea], disponible en: http://www.ora-

cle.com/technetwork/es/middleware/bam/overview/index.html, recuperado: Noviembre de

2015.

[11] “Mule ESB Enterprise Performance” (2014) [en línea], disponible en: https://www.mule-

soft.com/lp/whitepaper/soa/esb-enterprise-performance, recupera-do: 11 de abril de 2015.

http://www.ibm.com/developerworks/rational/library/feb06/eeles/

http://www.ibm.com/developerworks/rational/library/feb06/eeles/

http://developer.android.com/intl/es/sdk/index.html

http://developer.android.com/intl/es/sdk/index.html

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

http://st.inf.tu-dresden.de/Lehre/dpf/IntroductoryPapers/tesanovic-WhatIsAPattern.pdf

http://st.inf.tu-dresden.de/Lehre/dpf/IntroductoryPapers/tesanovic-WhatIsAPattern.pdf

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6394383&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F6392590%2F6394246%2F06394383.pdf%3Farnumber%3D6394383




https://www.mulesoft.com/resources/esb/enterprise-application-integration-eai-and-esb

https://www.mulesoft.com/resources/esb/enterprise-application-integration-eai-and-esb

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5615740

http://www.oracle.com/technetwork/es/middleware/bam/overview/index.html

http://www.oracle.com/technetwork/es/middleware/bam/overview/index.html


Página 88

[12] Consejo Nacional de Política Económica y Social, Colombia, “Documento Conpes Social

155, Política farmacéutica nacional” (2012, 30 de agosto) [en línea], disponible en: https://co-

laboracion.dnp.gov.co/CDT/Conpes/Social/155.pdf, recuperado: 4 de abril de 2015.

[13] Colombia, Congreso Nacional de la República (2000), “Ley 500 de 2000 por la cual se

dictan disposiciones para promover el desarrollo de las micro, pequeñas y media-nas empresas”

[en línea], disponible en: www.mincit.gov.co/descargar.php?idFile=2309, recuperado: 4 de

mayo de 2015.

[14] “An algorithm to derive use cases from business processes” (2002) [en línea], disponible

en: http://www.researchgate.net/publication/228889707_An_algorithm_to_derive_use_ca-

ses_from_business_processes, recuperado: Agosto de 2015.

[15]Morales,B. ”DISEÑO DE INSTRUMENTO DE INVESTIGACIÓN PARA LA

IDENTIFICACIÓN DE LAS VARIABLES EN EL SECTOR FORMAL E INFORMAL DE

LA ECONOMIA” (2009) [en línea], disponible en: http://repository.unimi-

nuto.edu:8080/jspui/bitstream/10656/2050/1/TA_MoralesGalvanBlancaAlejandra_2009.pdf,

recuperado: Noviembre 2015.

[16] Perú, Observatorio de Productos Farmacéuticos [en línea], disponible en: http://observa-

torio.digemid.minsa.gob.pe/, recuperado: 15 de mayo de 2015.

[17] Perú, “Directiva Administrativa Nº176 MINSA/DIGEMID V.01.” [en línea], disponible

en: http://observatorio.digemid.minsa.gob.pe/OPMSCMS/Archivos/RM341-

2011MINSA.pdf, recuperado: 15 de mayo de 2015.

[18] Cannataro, M. (2013), “Using Open Data in Health Care and Tourism” [en línea], dispo-

nible en: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnum-


ber%3D6732750, recuperado: agosto de 2015.

[19] “U.S Food and Drug Administration” (2014) [en línea], disponible en:

http://www.fda.gov/AboutFDA/WhatWeDo/default.htm, recuperado: agosto 2015.

[20] Applied Mobility Systems (AMS) [en línea], disponible en: http://appliedmobility.com/,

recuperado: 16 de mayo de 2015.

[21] Akiztá [en línea], disponible en: http://akizta.com/#/home, recuperado: 16 de mayo de

2015.

[22] “Medicamentos Accesibles Plus” [en línea], disponible en: http://www.portal-

farma.com/Profesionales/Buenas-practicas-profesionales/rscinfo/medicamento-accesible-

plus/Paginas/introduccion-general.aspx, recuperado: 21 de mayo de 2015.

[23] “Medicamentos Accesibles Plus – App” [en línea], disponible en: https://play.goo-

gle.com/store/apps/details?id=com.technosite.medicamentoaccesible, recuperado: 21 de mayo

de 2015.1

http://www.researchgate.net/publication/228889707_An_algorithm_to_derive_use_cases_from_business_processes

http://www.researchgate.net/publication/228889707_An_algorithm_to_derive_use_cases_from_business_processes

http://repository.uniminuto.edu:8080/jspui/bitstream/10656/2050/1/TA_MoralesGalvanBlancaAlejandra_2009.pdf

http://repository.uniminuto.edu:8080/jspui/bitstream/10656/2050/1/TA_MoralesGalvanBlancaAlejandra_2009.pdf

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6732750&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6732750



http://www.fda.gov/AboutFDA/WhatWeDo/default.htm

http://appliedmobility.com/


Página 89


[24] “Websocket” [en línea], disponible en: https://www.websocket.org/, recuperado: Octubre

de 2015.

[25] Pericles Loucopoulos and Vassilios Karakostas. 1995. System Requirements Engi-neer-

ing. McGraw-Hill, Inc., New York, NY, USA.

[26] “Sector farmacia” (2009) [en línea], disponible en: http://ubikate.gov.co/sites/default/fi-

les/farmacia.pdf, recuperado: Septiembre de 2015.

[27] “El sector de productos farmacéuticos para uso humano en Colombia” (2005) [en línea]

disponible en: https://bitacorafarmaceutica.files.wordpress.com/2008/08/la-industria-farma-

ceutica-en-colombia.pdf, recuperado: Septiembre d 2015.

[28] Brugge, B. (2010) Object-Oriented Software Engineering, Prentice Hall.

[29] “ESTUDIO DEL SECTOR FARMACEUTICO COLOMBIANO CORRESPONDIENTE

AL PROCESO DE ADQUISICIÓN, DISTRIBUCION, SUMINISTRO Y CONTROL DE

MEDICAMENTOS A TRAVES DE UN OPERADOR LOGISTICO PARA LOS USUARIOS

DEL SUBSISTEMA DE SALUD DE LAS FUERZAS MILITARES DE LAS VIGENCIAS

2014 A 2018” (2014) [en línea], disponible en: http://www.sanidadfuerzasmilitares.mil.co/?id-

categoria=71264&download=Y, recuperado: Septiembre de 2015.

[30] Bustamante, A. “Sector farmacéutico Colombiano” (2007) [en línea], disponible en:

http://www.corficolombiana.com.co/WebCorficolombiana/Repositorio/informes/ar-

chivo2262.pdf, recuperado: Septiembre de 2015.

[31] Sommerville, Ian. (2005), Ingeniería de Software, Pearson Education

[32] “The Agile Unified Process (AUP)” [en línea], disponible en: http://www.amby-

soft.com/unifiedprocess/agileUP.html, recuperado: 15 de abril de 2015.

[33] Bass, L. Clements, P. Kazman, R. (2003) Software Architecture in Practice (2nd Edition)

Addison-Wesley Professional.

[34] “Design an SOA solution using a reference architecture” (2014) [en línea], disponible en:

http://www.ibm.com/developerworks/library/ar-archtemp/, recuperado: Octubre de 2015.

[35] “Oracle Reference Architecture” (2010) [en línea], disponible en: http://www.ora-

cle.com/technetwork/topics/entarch/oracle-ra-soa-foundation-r3-1-176715.pdf, recuperado:

Octubre de 2015.

[36] “Services in SOA” [en línea], disponible en: https://www.mulesoft.com/resources/esb/ser-

vices-in-soa recuperado: Octubre de 2015.

[37] “SOA Reference Architecture Technical Standard” (2013) [en línea], disponible en:

https://www.opengroup.org/soa/source-book/soa_refarch/layers.htm#figure4, recuperado: Oc-

tubre de 2015.

https://www.websocket.org/

http://ubikate.gov.co/sites/default/files/farmacia.pdf

http://ubikate.gov.co/sites/default/files/farmacia.pdf

https://bitacorafarmaceutica.files.wordpress.com/2008/08/la-industria-farmaceutica-en-colombia.pdf

https://bitacorafarmaceutica.files.wordpress.com/2008/08/la-industria-farmaceutica-en-colombia.pdf

http://www.sanidadfuerzasmilitares.mil.co/?idcategoria=71264&download=Y

http://www.sanidadfuerzasmilitares.mil.co/?idcategoria=71264&download=Y

http://www.corficolombiana.com.co/WebCorficolombiana/Repositorio/informes/archivo2262.pdf

http://www.corficolombiana.com.co/WebCorficolombiana/Repositorio/informes/archivo2262.pdf

http://www.ibm.com/developerworks/library/ar-archtemp/

http://www.oracle.com/technetwork/topics/entarch/oracle-ra-soa-foundation-r3-1-176715.pdf

http://www.oracle.com/technetwork/topics/entarch/oracle-ra-soa-foundation-r3-1-176715.pdf

https://www.mulesoft.com/resources/esb/services-in-soa

https://www.mulesoft.com/resources/esb/services-in-soa

https://www.opengroup.org/soa/source-book/soa_refarch/layers.htm#figure4


Página 90

[38] Rotem, A. SOA Patterns (2012), Manning.

[39] Dikmans, L. “SOA made simple” (2011) [en línea], disponible en: http://www.ora-

cle.com/technetwork/articles/soa/soa-made-simple-chap-4-1918442.pdf, recuperado: Octubre

de 2015.

[40] Bengtsson, P. “Scenario-based Software Architecture Reengineering” (1998) [en línea],

disponible en: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnum-


ber%3D685756, recuperado: Octubre de 2015.

[41] Babar, M. “A framework for Classifying and Comparing Software Architecture Evalua-

tion Methods” (2004) [en linea], disponible en: http://ieeex-

plore.ieee.org/xpl/login.jsp?tp=&arnumber=1290484&url=http%3A%2F%2Fieeex-

plore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1290484, recuperado: Octubre de

2015.

[42] “Información sobre el sector salud” (2010) [en línea], disponible en: http://www.camara-

baq.org.co/index.php?option=com_content&view=article&catid=156:salud-competi-

tiva&id=419:informacion-del-cluster&Itemid=268, recuperado: 1 de abril de 2010.

[43] “World Development Indicators: Heath systems” (2014) [en línea], disponible en:

http://wdi.worldbank.org/table/2.15, recuperado: 1 de abril de 2010.

[44] Silva, M y Tirado, A. (2013), Oportunidades y amenazas para el sector farmacéutico con

la firma del TLC con los estados unidos, Bogotá, Universidad EAN, [en línea], disponible en:

http://repository.ean.edu.co/bitstream/handle/10882/4703/StepanianMichael2013.pdf?se-

quence=1, recuperado: 1 de abril de 2015.

[45] “Mule ESB Enterprise Performance” (2014) [en línea], disponible en: https://www.mule-

soft.com/lp/whitepaper/soa/esb-enterprise-performance, recupera-do: 11 de abril de 2015.

[46] “¿Qué es el Régimen Subsidiado?” [en línea], disponible en: http://www.astrea-ce-

sar.gov.co/apc-aa-fi-

les/39366334626636306461313563366464/INFORME_REGIMEN_SUBSIDIADO_PARA_

XX.doc, recuperado: 4 de abril de 2015

[47] Defensoría del Pueblo, Colombia, “La tutela y el derecho a la salud 2012” (2013) [en

línea], disponible en: http://www.asivamosensalud.org/media/santafe/lecturas_sugeri-

das/6265849126fdb7c8e5f828f2c4edc7e7.pdf, recuperado: 4 de abril de 2015.

[48] Consejo Nacional de Política Económica y Social, Colombia, “Documento Conpes Social

155, Política farmacéutica nacional” (2012, 30 de agosto) [en línea], disponible en: https://co-

laboracion.dnp.gov.co/CDT/Conpes/Social/155.pdf, recuperado: 4 de abril de 2015.

[49] Ministerio de la Protección Social, Colombia, “Programa de reorganización, rediseño y

modernización de las redes de prestación de servicios de salud” (2011, 12 de septiembre) [en

http://www.oracle.com/technetwork/articles/soa/soa-made-simple-chap-4-1918442.pdf

http://www.oracle.com/technetwork/articles/soa/soa-made-simple-chap-4-1918442.pdf

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=685756&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D685756






http://www.astrea-cesar.gov.co/apc-aa-files/39366334626636306461313563366464/INFORME_REGIMEN_SUBSIDIADO_PARA_XX.doc




http://www.asivamosensalud.org/media/santafe/lecturas_sugeridas/6265849126fdb7c8e5f828f2c4edc7e7.pdf

http://www.asivamosensalud.org/media/santafe/lecturas_sugeridas/6265849126fdb7c8e5f828f2c4edc7e7.pdf

https://colaboracion.dnp.gov.co/CDT/Conpes/Social/155.pdf

https://colaboracion.dnp.gov.co/CDT/Conpes/Social/155.pdf


Página 91


línea], disponible en : http://www.minsalud.gov.co/Politicas%20Farmaceuti-

cas/Pol%C3%ADtica%20farmac%C3%A9utica/Documentos%20soporte/Diagnostico%20Si-

tuaci%C3%B3n%20Farmac%C3%A9utica%20Nacional%202011.pdf, recuperado: 4 de abril

de 2015.

[50] “Using ESB technology as a foundation for BPM” (2012) [en línea], disponible en:

https://www.mulesoft.com/lp/whitepaper/soa/business-processes-management, re-cuperado:

11 de abril de 2015.

[51] “JBoss Enterprise BRMS Compared to Oracle SOA Suite and Oracle BPM Suite

(11.1.1.6)” (2013) [en línea], disponible en: https://www.redhat.com/es/files/resources/en-

rhjb-brms-compared-oracle-soa-oracle-business-process-management-competitive-brief-

10185747.pdf.

[52] “ESB Support” [en línea], disponible en:

http://docs.jboss.org/tools/OLD/3.0.1.GA/en/esb_ref_guide/html/esb_support.html.

[53] “Understanding Integration From A "Needs-Based" Perspective - Mule vs. Open ESB /

Glassfish ESB” [en línea], disponible en: https://www.mulesoft.com/resources/esb/under-

standing-integration-needs-based-perspective-mule-vs-open-esb-glassfish-esb

[54] “Our response to MuleSoft blog “10 reasons to walk from BizTalk”” (2014) [en línea],

disponible en: http://blogs.biztalk360.com/response-mulesoft-blog-10-reasons-walk-biztalk/

[55] “JBoss ESB 4.3 GA” [en línea], disponible en: http://docs.jboss.org/jbos-

sesb/docs/4.3.GA/manuals/pdf/services/ContentBasedRouting.pdf.

http://www.minsalud.gov.co/Politicas%20Farmaceuticas/Pol%C3%ADtica%20farmac%C3%A9utica/Documentos%20soporte/Diagnostico%20Situaci%C3%B3n%20Farmac%C3%A9utica%20Nacional%202011.pdf



https://www.redhat.com/es/files/resources/en-rhjb-brms-compared-oracle-soa-oracle-business-process-management-competitive-brief-10185747.pdf



http://docs.jboss.org/jbossesb/docs/4.3.GA/manuals/pdf/services/ContentBasedRouting.pdf

http://docs.jboss.org/jbossesb/docs/4.3.GA/manuals/pdf/services/ContentBasedRouting.pdf


Página 92

IV - ANEXOS

Estado del Arte: profundización del marco contextual y conceptual. Disponible en:

http://pegasus.javeriana.edu.co/~CIS1530AP04/anexos.html.

Análisis problemática: profundización del análisis realizado para la obtención de re-

querimientos. Disponible en: http://pegasus.jave-

riana.edu.co/~CIS1530AP04/anexos.html.

Especificación de Requerimientos: especificación de casos de uso y requerimientos no

funcionales. Disponible en: http://pegasus.jave-


SAD: arquitectura planteada. Disponible en: http://pegasus.jave-


Evaluación de la Arquitectura: evaluación de la arquitectura planteada. Disponible en:

http://pegasus.javeriana.edu.co/~CIS1530AP04/anexos.html.

Descripción funcionalidad de Prototipo: descripción del alcance que se logró con el

prototipo y manual de usuario. Disponible en: http://pegasus.jave-


Imágenes Diagramas: imágenes de los diagramas de mayor importancia dentro del tra-

bajo. Disponible en: http://pegasus.javeriana.edu.co/~CIS1530AP04/anexos.html.

http://pegasus.javeriana.edu.co/~CIS1530AP04/anexos.html











Propuesta para Trabajo de Grado -...

Documents

Transcript of Propuesta para Trabajo de Grado -...