Arquitectura de Software

    

Primera Entrega

Semana 7

Rubiano Ruiz Alver Martin Cod.: 1721025990

Andrés Felipe Arias Cod: 1711023779

Anyeli Vianed Ruiz Llano Cod: 1811981289

Carlos Andrés Navarrete Morales Cod: 1711024458

Institución Universitaria Politécnico Gran Colombiano

Facultad de Ingeniería y Ciencias Básicas

Módulo: Arquitectura Del Software

Bogotá, Colombia

2020
 Objetivos Generales

 Practicar y demostrar los conocimientos adquiridos en el módulo de Arquitectura de

Software.
 Diseñar, implementar y probar estilos de Arquitectura de Software.
 Diseñar e implementar un Sistema de Control de Medicamentos, basado en una
Arquitectura Orientada a Servicios (SOA), haciendo énfasis en el acceso, protección
y preservación de la i
 Información para facilitar la toma de decisiones clínicas.

Objetivos Específicos

 Identificar problemáticas relacionadas con la arquitectura orientada a servicios, en

el ámbito del: social media, móvil, Web Chat, Financiero, telecomunicaciones y
medios de pago.
 Definir el uso de los estilos de arquitectura orientados a servicios SOAP y REST.
 Definir el propósito del Sistema, mediante el análisis de la una situación problema,
con el fin de aplicar una Arquitecta Orientada a Servicios (SOA).
 Diseñar el sistema para el manejo de la información de medicamentos bajo criterios
de la Arquitectura Orientada a Servicios (SOA).
 Implementar el Servicio API Rest para gestionar el control de medicamentos.
 Definir el cronograma de artefactos requeridos para la implementación del sistema.
 Justificación
En los ultimos años el software ha venido evolucionando, asi mismo la forma como se
realiza la recolección de requerimientos, diseño, codificación, documentación, pruebas,
despliegue y mantenimiento, lo que en muchas ocasiones define el éxito o fracaso de
nuestros proyectos, la Arquitectura de Software es una guía en el camino, con lineamientos
que nos ayuden a la construcción de la solución o aplicación requerida.
Como estudiantes de Ingenieria de Software tomamos el reto de realizar este modulo con
el fin de diseñar e implementar los conocimientos en cuanto a la Arquitectura de Software,
por lo cual decidimos abordar la una solución a la problemática de la información
referente7 a medicamentos, donde no se tiene una información global de ellos y se tienen
diversas fuentes de información las cuales son diferentes o no contienen toda la
información necesaria para conocer todo lo que se rqeuiere de un medicamento antes de
adquirirlo o suministrarlo.
 MARCO TEÓRICO

En el presente proyecto, se propone un marco de software destinado a facilitar un apoyo de

decisión clínica generalizado y efectivo en cuanto al control y seguimiento de
medicamentos se refiere. El marco propuesto abarca un enfoque de arquitectura orientada a
servicios (SOA).

Arquitectura definida

La definición utilizada en este proyecto es la cual define que la arquitectura es la

organización fundamental de un sistema incorporado en sus componentes, sus relaciones
entre sí y con el medio ambiente, y los principios que guían su diseño y evolución. [IEEE
1471].

Arquitectura de software

La arquitectura de software es el proceso de convertir características de software como

flexibilidad, escalabilidad, factibilidad, reutilización y seguridad en una solución
estructurada que cumpla con las expectativas técnicas y comerciales.

Características de la arquitectura de software

Como se explicó, las características del software describen los requisitos y las expectativas
de un software en niveles operativos y técnicos. El software debe ser "ampliable, modular y
mantenible" si una empresa atiende solicitudes urgentes que deben completarse con éxito
en cuestión de tiempo. Como arquitecto de software, debe tener en cuenta que el
rendimiento y la baja tolerancia a fallas, escalabilidad y confiabilidad son sus
características clave. Ahora, después de definir las características anteriores, el propietario
de la empresa le dice que tienen un presupuesto limitado para ese proyecto, aquí surge otra
característica que es "La viabilidad. "
Arquitectura SOA.

La arquitectura orientada a servicios es una filosofía de diseño descrita como "el

equivalente de software de los ladrillos de Lego", donde un conjunto de herramientas de
unidades de combinación y servicios realizan una tarea bien definida.

Las implementaciones más extendidas de SOA implican el uso de servicios web, donde un
recurso/servicio computacional dado puede ser invocado por una máquina remota a través
de mensajes compuestos en XML y enviados a través de HTTP, para que puedan operar a
través de firewalls. Piense en un servicio web, en su forma más simple, como una subrutina
que se puede llamar a través de Internet.

El establecimiento de una arquitectura sólida orientada a servicios requiere que las

empresas tengan en cuenta una serie de elementos, incluidos el gobierno de SOA , la
seguridad, los patrones de diseño y la gestión de API.

Patrones de diseño SOA

Los patrones de diseño de SOA permiten a las organizaciones resolver problemas de diseño
de forma rápida y sencilla mediante el uso de soluciones comprobadas. Esencialmente,
estos patrones SOA son piezas valiosas de información que brindan a las empresas métodos
para enfrentar desafíos relacionados con problemas comunes dentro de la empresa, como la
conectividad API.

Los patrones de diseño ofrecen repetibilidad, consistencia y estructura de los ecosistemas

empresariales. Además, debido a que los patrones de diseño de SOA se prueban en batalla,
las empresas pueden aprovechar una mayor calidad de diseño en toda la infraestructura.
Siguiendo las mejores prácticas del patrón de diseño SOA, las organizaciones pueden
fortalecer su arquitectura SOA.

Beneficios de SOA analizados

En el diseño de software, la simplificación mediante la descomposición del problema en

unidades semi-independientes (subrutinas, clases) es un principio importante e
incontrovertible. En SOA, donde las unidades (servicios) llevan una existencia
relativamente autónoma (por ejemplo, las unidades son libres de residir en hardware
físicamente separado), la descomposición de una solución de software en servicios
individuales sólo tiene sentido en dos circunstancias:

 Cuando un servicio en particular puede proporcionar un valor independiente a la

persona que llama remotamente.
 Cuando la separación física de servicios en múltiples máquinas proporciona
escalabilidad cuantificable y beneficios de rendimiento a través del paralelismo de
hardware que más que compensa la sobrecarga adicional de la comunicación entre
máquinas.
SOA puede ayudar a garantizar que las aplicaciones se puedan escalar fácilmente, al tiempo
que disminuye los costos que a menudo se encuentran al desarrollar soluciones de servicios
empresariales.

SOA para el Control de Datos de medicamentos.

Aunque hay una tendencia creciente en la adopción de SOA en otros sectores de la

economía, su implementación en la atención médica ha sido relativamente lenta. Por lo
general, muchas de las economías se producen cuando los servicios se utilizan
principalmente al interior, e incluso entonces, lograr la escalabilidad puede requerir
actualizaciones de la infraestructura de la red interna para minimizar esta sobrecarga.
Por ejemplo, los médicos, las organizaciones de atención médica, los grupos de
consumidores y los desarrolladores de informática consideran que el apoyo a las decisiones
clínicas es un método clave para abordar las ineficiencias y los errores documentados que
ocurren en las prácticas clínicas ocupadas.

Sin embargo, muchas organizaciones de atención médica ahora ven el apoyo a las
decisiones como un medio selectivo para brindar una mejor atención a sus pacientes de una
manera que los distinga de sus competidores. Por las razones enumeradas anteriormente,
SOA dentro de un entorno local puede facilitar enormemente el apoyo a la toma de
decisiones clínicas.

La manera en que se implementa SOA, es como una serie de "cajas negras" que, dada una
entrada, producen una salida. En general, los servicios de SOA no son "profesionales con
licencia", por lo que legalmente, el proveedor de atención médica del paciente (médico o
institución) es responsable de anular cualquier consejo erróneo proporcionado por un
servicio de SOA.

¿Cuánta información requeriría un "servicio de control de medicamentos" como entrada

para dar un asesoramiento adecuado en todos los entornos, y cuán complejo debería ser el
resultado para cubrir una miríada de características potenciales del paciente? En las mejores
bases de datos comerciales de medicamentos en el mercado actual, la sofisticación
algorítmica y de estructura de datos para tal servicio de control aún no tienen aplicación en
masa; Lo mejor que hacen estos sistemas es reproducir el texto de inserción del paquete del
proveedor de medicamentos.
De esta forma, la logística de implementar de manera responsable los servicios clínicos de
SOA a larga distancia puede ser abrumadora. El modelo de "caja negra" para servicios
SOA supone una entrada y salida relativamente mínima.

Metodología

El uso de una arquitectura orientada a servicios (SOA) se ha identificado como un enfoque

prometedor para mejorar la atención de salud al facilitar un apoyo confiable para la toma de
decisiones clínicas. En este caso, se tiene en cuenta el control de medicamentos.

La arquitectura SOA consta de cinco componentes principales: un servicio web para el

transporte y la conversión de los datos, protocolos de comunicación, analizadores de datos
para preprocesar datos, un repositorio de dispositivos para guardar los datos e información
transmitida y manejo de errore de esta información. Además, se utilizaron tecnologías
como el lenguaje XML y un lenguaje de programación. Además, también se utilizaron
conceptos de ingeniería de software como patrones de diseño.
Caracteristicas de los patrones:

CARACTERÍSTICAS
DEL PATRÓN SOA
REQUERIMIENTO ¿Como puedo tener más informacion sobre los
medicamentos y especificaciones?
ÍCONO

RESUMEN PROBLEMA El desconocimiento de las

caracteristicas y las prescripciones de
 algunos medicamentos, asi como la
confusión por nombre debido a una
codificación deficiente, con respecto a
quien debe realizar su proceso de
dispensión , hace que se busque una
solución donde se presente una manera
sencilla de identificar un medicamente
previamente inscrito en una base de
datos.
SOLUCIÓN

APLICACIÓN Este servicio Api rest, esta enfocado en

arquitectura de tres capas cuales son las
de presentación, dominio y acceso a
datos
IMPACTO La app tendria la ventaja de ser una api
rest donde cualquier cliente la puede
usar ya que es solo información de texto
en formato Json y esta ligado a no usar
librerias solo la infomación que
requiera el cliente, la desventaja es que
obligaria a conocer mas de protocolos
de html aprender mas sobre el.

PRINCIPIOS
 ARQUITECTU
RA
RELACIONES Se relaciona con una Base de Datos
EJEMPLO DE CASO DE Ejemplo api rest https://swapi.co/ solo se traer la
ESTUDIO información que necesite.

Cronograma

Ver Excel Nombre: Cronograma1.xmls

Este cronograma detalla el tiempo de construcción del api rest junto con las entregas, puede variar
el tiempo de desarrollo.

Modelo de diagrama Api Rest(MockUp)

Diagrama de primera vizualización

Diagrama de interfaz de conexión de ApiRest con BD

Modelo de diagrama de Base de datos

Requerimientos no funcionales:

 Está pagina de consulta estará disponible 7*24.

 Toda la información se encuentra almacena en una base de datos.
 La información contenida se encuentra bajo la resolución 1019 de 2019 del ministerio de
salud.
 Por seguridad se contarán con credenciales para acceder a todo el contenido que se
encuentra en la página.
 Se realiza con lenguaje PHP, html, se realiza con este codigo para tener actualizaciones al
dia y solo hacer cambio pequeños.
 La base de datos esta en My SQL, se alimenta de un archivo .csv
 Mantenimiento y actualizaciones servidores, de este modo tambien es fácil el traslado de
la base de datos.

Requerimientos funcionales:

 Se tendrá la posibilidad de que el interesado acceda a toda la información de un

medicamento de forma confiable.
 El cliente o usuario puede tener acceso a travez de Json para incluirlo en su pagina o app
 Vizualización de medicamentos donde esta en constante actualización
 Cualquier empresa puede tener acceso a la información en modo de texto, no se maneja
imagen.
Implementacion API Rest

Se realiza api rest desde un servidor que se tiene provisional la URl donde se puede consultar es:

https://tiendabytetobyte.000webhostapp.com/api.php

Los archivos de desarrollo, estos archivos estan en el servidor provicional menos en index.php que
puede funcionar desde eun Xampp

 Consta de un api.php
 Config.php
 Utils.php
 Inventario.sql ( SQL para la creación de inventario)
 Index.php : este hace el llamdo al Api o landing de vizualizacón de medicamentos

Retroalimentación de cronograma

1. Se realiza cambios en el cronograma cronogramaV2.xmls más detalles en la

implementación

Realice evaluación de las distintas metodologías presentadas en la unidad 4. Contraste

los resultados con la metodología escogida.
Se realizo una evaluacion teniendo en cuenta:
Formato de mensaje de solicitud

Los mensajes SOAP presentan una estructura XML. Los servicios web SOAP analizan el código XML
para determinar la operación que debe realizar el servicio web. La solicitud REST consiste en una
cadena URI simple con una consulta.

Formato de mensaje de respuesta

El servicio web SOAP devuelve una respuesta en formato XML según los parámetros definidos por
el WSDL.

El servicio web REST de Informatica devuelve mensajes de respuesta Notación de objeto JavaScript
(JavaScript Object Notation, JSON) o XML. El formato de mensaje de respuesta no viene definido
por un WSDL ni por un esquema. El formato de salida se define al definir el servicio web REST de
Informatica.

Formato de asignación de servicio web

Los servicios web SOAP de Informatica contienen asignaciones de operaciones. Las asignaciones
de operaciones SOAP contienen una transformación de entrada que analiza el código XML
proveniente de un mensaje de solicitud. Añada transformaciones a la asignación de servicio web
para procesar los datos según la solicitud de cliente.

Los servicios web REST contienen asignaciones de recursos. La asignación de recursos no lee la
consulta de la solicitud. La asignación de recursos REST contiene una transformación de lectura en
lugar de una de entrada. La transformación de lectura lee un objeto de datos del repositorio de
modelos para recuperar los datos que se devolverán al cliente. De forma predeterminada, no es
necesario añadir una transformación de filtro ni de búsqueda para recuperar los datos a partir de
la consulta del cliente. El servicio web REST filtra los datos de salida una vez que la asignación
devuelve los datos.

REST utiliza HTTP, entonces es mucho más sencillo. Desarrollar APIs, crear clientes y la
documentación es más fácil de entender.

REST permite inúmeros formatos de datos, dando por ejemplo al desarrollador la posibilidad de
utilizar JSON que normalmente es más rápido y como permite la utilización de JSON, permite
también un mejor soporte a los clientes del explorador. SOAP solamente permite XML.

REST tiene mejor escalabilidad y rendimiento.

Las lecturas del REST se pueden cachear, las lecturas basadas en SOAP no se pueden.

Correciones de propuestas por el tutor.

 Diagrama UML
Enlace del vídeo video explicativo en postman
https://youtu.be/b87P1ePuR0s
Se realizaron las respectivas pruebas , de los metodo POST, GET, DELETE y PUT.

Documentación postmorten
Introducción
 Se plantea un desarrollo api rest donde muestre toda la información de los medicamentos
al que el cliente o el usuario requiera, se usa un desarrollo planteado en PHP, ya que se ve
de forma mas general y receptiva para sitios que quieran consumir estos datos.
 Introducción de errores
 Se ve un consumo optimo el Json o xml probado desde postman, pero se tiene dificulta el
ma multiplataformidad de código, no esta implementado para lenguajes como .NET Java
Script,
 Se obtuvieron errores en el desarrollo, se pude tener un modo post que no se hace
ingreso desde el php
  La causa del problema de uso de mas lenguajes de desarrollo se da desde cuando ya esta
planteado el desarrollo y esta en producción, esta hace que el desarrollador tendría que
gastar mas tiempo organizando y verificando como debe implementar los lenguajes
 Ya cuando se despliega el Api Rest desde php se ve la funcionalidad pero para cierto tipos
de tecnologías
 Se debe un análisis de la causa del problema donde se deja abierto a realizar un desarrollo
adicional sobre el Rest, no se tiene problema con la base de datos don de la información y
verificado en formato plano para ser cargado desde el SQL, se toma encuesta dentro del
diagrama de visualización, donde se puede hacer una integración a otros lenguajes, es
viable ya que con una implantación de esta se requiere de un servidor diferente a un costo
mas amplio.
 Se tiene impacto a corto plazo a los cliente que vayan usar el api con las diferentes
lenguajes, ya que es un desarrollo ágil y rápido de implementar desde el php y menos
costoso
 Se debe tener una acción al momento de preguntar al cliente lo que pasa si se realiza un
desarrollo a bajo costo y rápido, se hace una entrega que es funcional para lo que el se
necesita al momento, pero a largo plazo esto no va funcionar bien para lo que puede estar
enfocado a futuro o durabilidad

CARACTERÍSTICAS QUE SE TUVIERON ENCUENTA EN EL SIGUENTE CUADRO

Nos basamos en Características del ISO 9126 para definir metricas

Conclusiones

Se puede concluir que con los conocimientos adquiridos en el módulo nos es posible tener una
estructura clara y organizada, lo cual nos ayudará a tener una mayor eficiencia al momento de
tener que realizar el desarrollo de un proyecto a nivel global.

Con los estilos seleccionados se logró tener una mejor organización con el fin de realizar la
distribución de tareas y nos permitió definir nuestro proyecto analizando el problema e integrando
patrones SOA se generó la orientación del proyecto, el cual es orientado a servicios y nos permitió
generar el proyecto más completo siendo nuestro enfoque a

Se llega también a la conclusión de la gran necesidad de integrar servicios como social media,
móvil, Web Chat, Financiero, telecomunicaciones y medios de pago en nuestros desarrollos ya que
permiten tener mayor comunicación en todos los ámbitos y facilidades para los usuarios que usan
el servicio.

Con la ayuda de los estilos de arquitectura orientados a servicios SOAP y REST, se finalizó la
integración de nuestro proyecto dando un mayor alcance a nuestro servicio de medicamentos,
cumpliendo con el cronograma realizado inicialmente.

Recomiendaciones
Se puede realizar el desarrollo con el uso de más lenguajes con el fin de tener mas
alcanzabilidad y escalabilidad, teniendo una plataforma más robusta y completa.

Se puede hacer uso de herramientas de control de versiones tipo Git Hub para desarrollo del
proyecto, esto con el fin de llevar el control de los aportes de cada persona y tener acceso
en tiempo real de lo realizado por cada persona.

Referencias

Prakash M. Nadkarni, MD, Randolph A. Miller, MD, Arquitectura orientada a servicios en

software médico: promesas y peligros, Revista de la Asociación Americana de Informática
Médica , Volumen 14, Número 2, marzo de 2007, páginas 244–246, https:
//doi.org/10.1197/jamia.M2349

Kawamoto K, Lobach D. Propuesta para cumplir los objetivos estratégicos de la hoja de

ruta de los EE. UU. Para la acción nacional sobre el apoyo a la decisión a través de una
arquitectura orientada a servicios que aproveche los servicios HL7 J Am Med Inform Assoc
2007; 14 : 146-155.

Javier Vivanco junio del 2019 (Modelo C4 de documentación de arquitectura de software) de

https://medium.com/@javiervivanco/el-modelo-c4-de-documentaci%C3%B3n-para-la-
arquitectura-de-software-424704528390

Encarna Abella (metodología del Scrum) de

https://www.wearemarketing.com/es/blog/metodologia-scrum-que-es-y-como-funciona.html

Humberto Servantes (Arquitectura de Software) de https://sg.com.mx/revista/27/arquitectura-

software
 Glosarios de términos

 SOAP: de la sigla en inglés Simple Object Access Protocol , protocolo de acceso

simple a objetos.

 REST: de la sigla en inglés Representational State Transfer, trasferencia de
representación de estado.
 SOA: Arquitectura Orientada a Servicios
 XML: Standard Generalized Markup Language), un lenguaje que permite la
organización y el etiquetado de documentos.
 HTTP: protocolo de transferencia de hipertexto que se usa en la Web. HTTP es
una sigla que significa HyperText Transfer Protocol, o Protocolo de Transferencia
de Hipertexto
 REST: API REST la idea de “servicio” como tal desaparece. Lo que tenemos son
recursos, accesibles por identificadores (URIs).
 API: (siglas de 'Application Programming Interface') es un conjunto de reglas
(código) y especificaciones que las aplicaciones pueden seguir para comunicarse
entre ellas.
 IEEE: Insitute of Electrical and Electronics Engineers (Instituto de Ingenieros
Eléctricos y Electrónicos) asociación técnico-profesional mundial dedicada a la
estandarización, entre otras cosas.