Entrega Semana 7 Arquitectura de Software

ENTREGA FINAL.
ARQUITECTURA DE SOFTWARE
PROFESOR:
Martínez Natalia.
INTEGRANTES DEL GRUPO:
García López Andrés - Código: 100237928
Quiroga Ortiz Cristian Camilo – 2021981156
Rozo Castañeda Lina Estefanía - Código: 1721022861
Sosa Pinzon Cristian Camilo – 1821020779
Trujillo Gutiérrez Iván Andrés – Código 1921982787
INSTITUCIÓN UNIVERSITARIA POLITÉCNICO GRANCOLOMBIANO
FACULTAD DE INGENIERÍA, DISEÑO E INNOVACIÓN
Bogotá, Marzo del 2021

I. INTRODUCCIÓN
La arquitectura orientada a servicios nace de la necesidad, de construir servicios compuestos que
otorguen la oportunidad de generar integración de bases de datos diversas en un sistema orientado a
la mejora continua y la optimización de comunicación integral de un negocio, lo cual forma y
proporciona información eficiente capaz de ser consultada en diferentes fuentes de datos a una
organización.
En un mundo globalizado como en el que estamos la tecnología de la información y específicamente
las tecnologías orientadas a servicios deben lograr integrar de forma ágil y segura las herramientas y
procedimientos, planeación y ejecución y demás aspectos a tener en cuenta en la elaboración de
proyectos que aseguren los principios básicos de disponibilidad, concurrencia, y seguridad de la
información
Para el caso de nuestro tema de investigación es necesario entender el flujo de las operaciones y
transacciones que se realizan en controles y gestión de inventarios y como se entregan a un usuario
final como actualizaciones de stock en entradas y salidas de productos y servicios que pueden ser
verificables, controlables y seguras.
1
TABLA DE CONTENIDO.

2
II. OBJETIVOS
OBJETIVO GENERAL
Contribuir y aportar al sector empresarial de herramientas que le permitan dar continuidad de negocio
y productividad a partir del entendimiento y ejecución de modelos de negocio basados en el software
como servicio y como desde el diseño se puede establecer un correcto plan de ejecución.
OBJETIVOS ESPECÍFICOS
• Entender y aplicar mecanismos de seguridad utilizadas en herramientas SOA en la
implementación de alerta y notificación de transacciones de control de inventarios
• Analizar los mecanismos de actualización de control de inventarios con el fin de tener
información de procesos y procedimientos.
• Comprender las diferencias entre aplicaciones abiertas y cerradas en el intercambio de
información en control y gestión de inventarios y activos.
• Plantear alternativas de modelación de arquitecturas orientadas a servicios como standard de
aplicación de SOA en el ámbito empresarial.
3
III. PLANTEAMIENTO DEL PROBLEMA
Problema:
Se requiere saber la ubicación y la cantidad disponible de un producto para una empresa que cuenta
con un inventario de productos que se encuentran distribuidos en diversos locales a nivel nacional.
Actualmente poseen una aplicación monolítica para saber la cantidad de productos que tienen en cada
uno de sus locales.
El principal problema que ellos presentan es la actualización en tiempo real del inventario. Debido a
la lentitud de la red y el bajo rendimiento de los servidores tienen permitido solo actualizar el
inventario al terminar el día. Eso significa que todos los días al iniciar el día deben hacer una copia
del inventario general y exportarlo a un Excel para allí realizar los respectivos movimientos del
producto. Una vez la jornada haya terminado deben actualizar de manera manual los registros uno
por uno entre la hoja de cálculo y el aplicativo y guardar cambios para que el inventario general quede
en teoría actualizado en el servidor.
Solución:
Figura 1
Modelo SOA a implementar dada la propuesta:
4
Aplicación:
Se propone realizar un modelo SOA para manejar los estados y las cantidades actuales de los
productos para mantener actualizado el inventario.
El servicio 1: se encargará de listar los productos del inventario.
El servicio 2: se encargará de cambiar el estado a un producto cuando esté activo o agotado y actualiza
la cantidad de productos.
El servicio 3: se encargará de realizar la búsqueda del inventario por su Id.
Impacto:
Esta arquitectura se implementará en un modelo de capas por lo que va a permitir desacoplar la
aplicación en submódulos, esto es una gran ventaja para el mantenimiento.
Al utilizar el modelo orientado a servicios se tiene la ventaja de poder implementar cada uno de ellos
con versiones distintas de algún framework o incluso en lenguajes de programación distintos sin haya
algún tipo de incompatibilidad y tener desarrolladores más versátiles.
5
La desventaja es que al ser originalmente una aplicación monolítica se debe realizar ingeniería inversa
para entender y copiar el modelo de negocio lo que conllevaría a tiempos de desarrollo bastante altos.
6
IV. JUSTIFICACION
La información se constituye como uno de los activos más valiosos para toda empresa puesto que de
ella depende la misma toma de decisiones que puede afectarla o lograr un papel fundamental en su
crecimiento económico.
Es por esto que el análisis de los patrones de diseño SOA cobra mayor relevancia en los contextos de
creación y modificación de software dado sus características, es por esto que se debe tener en cuenta
que Los patrones de diseño más utilizados se clasifican en tres categorías principales, cada patrón de
diseño individual conforma un total de 23 patrones de diseño, cada uno de ellos define la solución
para resolver un determinado problema, facilitando además la reutilización del código fuente
. Las tres categorías principales son:
• Patrones creacionales
• Patrones estructurales
• Patrones de comportamiento
Figura 2
7
Mapa conceptual de los tipos de patrones de diseño
Las prácticas de desarrollo de software han tenido un gran desarrollo en los últimos tiempos.
Antes se requería completar todo el software antes de realizar pruebas, lo que suponía
encontrarse con dificultades. Para ahorrar tiempo y evitar volver a la etapa de desarrollo una
vez que este ha finalizado, se introdujo una práctica de prueba durante la fase de desarrollo.
Estas acciones se usan para identificar condiciones de error y problemas en el código que
pueden no ser evidentes en ese momento. En definitiva, los patrones de diseño aportan a estar
seguro de la validez del código, teniendo en cuenta que son metodologías validadas por
muchos profesionales del ramo y ayudan a una construcción de código y aplicaciones cada
vez más agiles y seguras.
Para el caso particular de nuestra observación en sistemas de control y actualización de
inventarios se tienen las siguientes características:
8
1. La necesidad en este proyecto. ¿Por qué se va a hacer?
2. Finalidad del proyecto ¿Para qué se va a hacer?
3. ¿Qué problemáticas resuelve?
4. Las exigencias que tiene. ¿Cómo se va a hacer?
• ¿Por qué se va a hacer?
Las principales características del SOA es determinar características de disponibilidad,
replicación, seguridad, es por esto que por medio del análisis de las aplicaciones por medio de
patrones de diseño se preverá fallos e inconvenientes a la hora de evaluar la creación y/o
modificación de estas.
• ¿Para qué se va a hacer?
El análisis de aplicaciones y software de control de inventarios cumple una vital importancia en
la operatividad de una compañía y las Pymes, por esto es necesario realizar ajustes cada vez más
certeros en la creación y análisis de software esto a la luz de patrones de diseño que permitan
optimizar tiempos de diseño y ejecución y a su vez brinden de seguridad al manejo de activos de
las compañías.
• ¿Qué problemáticas resuelve?
Para el caso particular se resolverían las siguientes características: Enrutamiento, Asincronía,
Interoperabilidad, Concurrencia, Centralización de datos, Clasificación de servicios,
Redundancia, Rollback, Abstracción de servicios, Consumo de memoria en la operación,
Autenticación
Es claro así, como la integración del SOA como práctica empresarial y de desarrollo de arquitecturas
cada vez más prácticas y escalables, según la necesidad del cliente, son de gran ayuda en la creación
9
de sistemas de información es por esto que múltiples compañías multinacionales tales como
Microsoft, RedHat, entre otras han iniciado hace mucho en ofrecer servicios diseñadores de
arquitectura de software dado aspectos tales como la eficiencia, la escalabilidad y la optimización de
tiempo, “Debido a los avances en la tecnología de los contenedores, los microservicios ahora son
la base para las aplicaciones nativas de la nube, es decir, los microservicios sin conexión directa
que se implementan en los contenedores de Linux y se conectan a través de las API o de una red
de servicios para el enrutamiento de los mensajes.”(REDHAT - ¿Qué es la arquitectura orientada a
los servicios (SOA)).
10
V. GLOSARIO
Análisis: Es la fase del desarrollo de software donde se realiza un enfoque hacía ela solución del
problema para dar paso al diseño.
Arquitectura: Arte que se basa en proyectar y diseñar espacios para finalmente construirlos, esto se
aplica a la arquitectura de software de manera abstracta.
Arquitectura de software: Es un conjunto de patrones y elementos que se relacionan entre sí para
formar la base de un sistema cuyo diseño se basa fundamentalmente en su arquitectura.
Cronograma: herramienta que presenta un detalle de las actividades que se deben desarrollar en los
tiempos establecidos.
Diseño: Fase de desarrollo de software donde se enfoca como se ejecuta la solución del problema
planteada durante el análisis.
Framework: Es un marco de desarrollo o trabajo que se compone de distintas clases, librerías,
tecnologías e incluso aplicaciones, que se programan con el fin de ayudar a desarrollar software que
ayuda y facilita el desarrollo de Backend y/o Fron end se diseñan a partir de patrones de
comportamiento, estructurales y de diseño.
Patrones de comportamiento: Se pueden comparar con un manual o modelo a seguir frente a
situación en concreto también tienen como finalidad facilitar el desarrollo y llevar un enfoque más
preciso.
Patrones de diseño: Métodos para resolver inconvenientes recurrentes en el desarrollo de software
y otras situaciones, estos nos permiten tener soluciones predefinidas para los inconvenientes
mencionados y así poder centrarse en el problema real del proyecto.
Patrones estructurales: Son patrones que definen la forma de las clases y objetos para que estos
conformen una estructura compuesta de la cual se puedan diseñar más funcionalidades.
11
SOA: Servicio orientada arquitectura
Update: El término update hace referencia a pequeños cambios, como pequeñas actualizaciones o
correcciones, de sistemas operativos e instalación de parches.
URL: Es el mecanismo usado por los navegadores para obtener cualquier recurso publicado en la
web.
Web: Conjunto de información que se encuentra en una dirección determinada de internet
12
VI. CRONOGRAMA
• Semana 3 semana 5 semana 7
Duración: (1 semana cada una)
Responsable: 5 integrantes
• Desarrollar objetivos generales, específicos.
Componentes: general 1, específicos 4
Duración. 2 a 3 horas)
Responsable: Trujillo Gutiérrez Iván Andrés – Código 1921982787
• Desarrollar justificación.
Duración (1 día)
• Glosario con términos y definiciones en palabras propias del dominio de la arquitectura de
software.
Duración (de 5 a 10 palabras)
Responsable: Quiroga Ortiz Cristian Camilo – 2021981156
• Identifique una situación problemática recurrente donde la arquitectura orientada a servicios
sea una solución adecuada
Duración: (4 a 5 horas)
Responsable: Sosa Pinzón Cristian Camilo – 1821020779
• Realizar un cronograma repartiendo las actividades y la duración
13
Responsable: García López Andrés - Código: 100237928
• Presentar las conclusiones y recomendaciones como resultado del trabajo de esta fase.
Duración: (1 - 3 horas)
Responsable: Rozo Castañeda Lina Estefanía - Código: 1721022861
• Diseñar, implementar y probar un servicio SOAP con la problemática planteada
Duración: (1dia)
• Desarrollar conclusiones de esta fase
• Realizar recomendaciones de esta fase
García López Andrés - Código: 100237928
• Crear un espacio para incluir correcciones planteadas por el tutor de la entrega pasada
Duración: (1 - 2 horas)
• Realizar evaluaciones de distintas metodologías presentadas en unidad 4

14
• Realizar contraste de resultados de la metodología escogida
Responsable: Quiroga Ortiz Cristian Camilo – 2021981156
• Realizar video del software y estructura
• Conclusiones y recomendaciones finales
Responsable: García López Andrés - Código: 100237928
• Plantear resultados obtenidos acordes a objetivos
• Fue presentado por 5 estudiantes que son:
duración 5 días máx. cada semana)
Responsables: García López Andrés - Código: 100237928
Rozo Castañeda Lina Estefanía - Código: 1721022861
15
Sosa Pinzón Cristian Camilo – 1821020779
16
VII. DISEÑO SERVICIO REST
DESARROLLO DE API CON NET CORE (.NET)
Teniendo en cuenta el ambiente de desarrollo con Net Core (.NET), es de resaltar que el producto
pertenece a la casa Microsoft y esta licenciada bajo licencia MIT (Licencia original del MIT,
Massachusetts Institute of Technology), la cual impone pocas restricciones en su reutilización, lo cual
también es uno de los aspectos principales de la arquitectura de software SOA.
El producto en cuestión brinda múltiples formas de cómo realizar un correcto modelamiento de la
estructura del software, en este caso la actualización de productos de un inventario, como ya lo
conocemos el modelo CRUD desde la perspectiva de .NET se podría analizar bajo el siguiente
diagrama suministrado en la figura por Microsoft, en su plataforma de documentación
(https://docs.microsoft.com)
Figura 3
Representación Modelo vista controlador interactuando con el cliente usando protocolos HTTP
17
El diseño propuesto se realizó bajo una arquitectura de capas que permite, por medio de las interfaces,
desacoplar la capa de dominio de la persistencia de los datos.
Figura 4
Modelo de diseño del servicio REST:
18
Capa Presentación: Expone los controladores que poseen las acciones con los verbos http para el api
REST.
Acciones HTTP del Controlador:
El método Get recibe como parámetro el id del inventario para realizar la búsqueda.
El método GetAll no recibe parámetros porque su función es listar la data que esté dentro de la base
de datos, en este caso la del inventario.
El método Update recibe un objeto tipo DTO (Data Transfer Object) que posee el id del inventario y
la cantidad que se desea extraer:
Figura 5
Código implementado de métodos Get, GetAll y update:
19
Capa de Dominio: Expone la lógica de negocio de los métodos Get, GetAll y Update.
El método Get recibe como parámetro el id del inventario para realizar la búsqueda. Una vez le
responda la capa de infraestructura, construye un objeto de tipo DTO para ser enviado dentro de un
response a la capa de presentación:
Figura 6
Código invocación método Get usando el dato id como parámetro:
20
El método GetAll no recibe parámetros porque su función es listar la data que esté dentro de la base
de datos, en este caso la del inventario. Una vez le responda la capa de infraestructura, construye una
lista de objetos de tipo DTO para ser enviado dentro de un objeto response a la capa de presentación.
Figura 7
Código invocación método GetAll:
21
El método Update recibe un objeto tipo DTO (Data Transfer Object) que posee el id del inventario y
la cantidad que se desea extraer. Una vez le responda la capa de infraestructura, construye una lista
de objetos de tipo DTO para ser enviado dentro de un objeto response a la capa de presentación. Es
decir, cuando actualice un elemento el API no va a responder con el elemento recién modificado, sino
que listará todos los elementos del inventario.
Figura 8
Código nvocación método update usando como parámetro objeto tipo DTO:
La Capa de Infraestructura o Repository: Contiene la lógica para la lectura y modificación de la
información que esta persistida en una base de datos relacional y motor de búsqueda postgressql.
22
El método Get de la capa de infraestructura posee la relación de las tablas que se encuentran en la
base de datos gracias al ORM entity framework core. En este caso son tres tablas la de inventario, la
de producto y la del estado.
Cuando se solicita que busque ese inventario él va a incluir la información de esas tablas y la va a
insertar en la consulta:
Figura 9
Código de consulta a base de datos relacional:
El objeto context posee la información del ORM y la cadena de conexión a la base de datos.
Las consultas se realizan utilizando LINQ que es un lenguaje integrado para consultas de tipo sql y
que es propio del lenguaje de programación C#:
Figura 10
Consulta ulizando el lenguaje integra LINQ:
23
En la actualización el método Update recibe el objeto completo que fue modificado. Al utilizar el
EntityState.Modified garantizamos que solo modifique los valores de las propiedades que cambiaron
y no todo el objeto:
Figura 11
Demostración de uso del método EntityState.Modified para optimizar las actualizaciones:
Explicación del código:
24
El proceso inicia cuando el controlador recibe la petición del cliente, y dependiendo del verbo HTTP
irá por una de las acciones que este posea.
Cuando entra en alguna de esas acciones, existe una referencia de la capa de dominio que se inyecta
en el constructor del controlador para que la capa de presentación pueda acceder a los métodos
expuestos en la capa de dominio.
En la capa de dominio se encuentran los métodos con la lógica de negocio para el tratamiento de la
información que llega del cliente, la filtre y la valide para que sea entregada al repositorio. Una vez
el repositorio tenga la data validada realizará la petición directamente al servidor en este caso a
PostgreSQL y responderá a la capa de dominio si fue exitosa o no la petición. Una vez que llegue la
respuesta a la capa de dominio, se valida, se filtra, según las reglas del negocio, y se construye una
respuesta que es enviada a la capa de presentación para exponerla al cliente.
Funcionamiento de la API:
Dentro de la clase principal startup, net core posee una manera fácil y rápida de catalogar un API
utilizando el paquete Swagger.
Figura 12
Código usando paquere Swagger:
Una vez se depura el API o publica se puede acceder a esta vista con su catálogo creado de manera
automática:
25
Figura 13
Vista del catálogo de la API:
Al hacer click en el primer método que corresponde al GetAll para traer toda la data del inventario y
posteriormente dar en ejecutar se desplegará lo siguiente:
Figura 14
Parte superior de vista de consulta usando GetAll :
26
Figura 15
Parte Inferior ista de consulta usando GetAll:
En el response body se puede apreciar la data extraída de la base de datos en formato json.
Cuando se requiere ingresar la cantidad para que esta se descontada del inventario utilizamos el verbo
PUT que corresponde al método Update en la lógica para actualizar esa información de la base de
datos:
Figura 16
27
Vista de botón PUT para llamar método update:
Figura 17
Vista despliege del boton de verbo PUT:
Vamos a editar el inventario con id = 2 para descontarle 5 productos que se vendieron:
28
Figura 18
Datos relacionados con el id 2 de los datos
Figura 19
Vista actualización datos relacionados al id 2:
Al ejecutar observamos la actualización de ese inventario:
Figura 20
29
datos relacionados al id 2 después de ejecutar la actualización:
Como se puede observar en la imagen de arriba el inventario de id=2 ahora queda con una cantidad
de 5 productos.
Si queremos consultar la información de un inventario en particular utilizamos su id para realizar
dicha búsqueda lo que corresponde al método Get dentro de la lógica de negocio:
Figura 21
Vista botón para llamar método GET:
30
Figura 22
Despliegue al llamar método GET:
El último verbo http del API permite protegerla para que solo los clientes autorizados puedan acceder
a este servicio y lo hace por medio de un token:
31
Figura 23
Vista Botón API:
Figura 24
Uso del botón del verbo API
32
VIII. CORRECIONES
Es importante tener en cuenta las correcciones y recomendaciones realizadas para la elaboración de
este trabajo en su primera fase, es por esto que nos permitimos listar así los ajustes realizados a esta
segunda entrega.
1. Justificación: Aunque bien, en el texto se hace énfasis en la importancia del uso de SOA
como alternativa de construcción de arquitecturas cada vez más confiables, robustas,
escalables y que brinden cada vez más agilidad en la implementación, es así mismo necesario
citar artículos donde se observe la necesidad y que alternativas se tienen para lograr una
implementación exitosa, es el caso que citamos de la empresa REDHAT, quienes en sus
productos ya ofrecen alternativas para el desarrollo de Api´s en entornos de desarrollo
basados en software Libre Linux, articulo expuesto en su página web principal para LATAM
(https://www.redhat.com/es/topics/cloud-native-apps/what-is-service-oriented-architecture),
De este modo y tomando como referencia el articulo (Reporte Técnico RT 06-16) llamado
“Desarrollo de aplicaciones con enfoque SOA(Service Oriented Architecture) de Andrea
Delgado, Laura González, Federico Piedrabuena de la universidad de la Republica de
Montevideo Uruguay del año 2006, es importante observar cómo estas metodologías son
adaptables a marcos de construcción y prueba de software tal como se realizó en su proyecto
“Link-All”
RECOMENDACIONES:
33
• De acuerdo a las correcciones realizadas al proyecto, se continúan haciendo ajustes al
cronograma planteado inicialmente.
• Se evidencia la necesidad de continuar fortaleciendo en la implementación la eficiencia,
capacidad de respuesta y adaptabilidad del proyecto, de acuerdo a los objetivos planteado.
• Es importante continuar a lo largo del desarrollo de la implementación, estar como equipo
bien documentados, de manera que sea posible no perder la conexión entre lo propuesto y
autores que soporten los hallazgos realizados.
• Continuar reforzando nuestros conocimientos sobre SOA para poder aplicar las nociones del
servicio, su construcción y resultados como elementos fundamentales para desarrollar
satisfactoriamente todas las fases de este proyecto.
34
TERCERA ENTREGA
1. COMPARACIÓN DE METODOLOGIAS UNIDAD 4
Tabla 1
Comparativa y evaluación de tecnologías presentadas en la unidad 4
METODOLOGÍA OBSERVACIÓN
PATRÓN DE Es una forma o herramienta reutilizable para resolver un
DISEÑO. problema.
SOA. Es un concepto de arquitectura de software que define la utilización
de servicios para dar soporte a los
requisitos del negocio. Esta arquitectura facilita el testeo, así como
también facilita el mantenimiento permitiendo una fácil
escalabilidad.
También se caracteriza por tener claridad en su seguridad y
definición de roles
REST. Es una tecnología mucho más flexible que transporta datos por
medio del protocolo HTTP, pero este
permite utilizar los diversos métodos que proporciona HTTP para
comunicarse, como lo son GET, POST,
PUT, DELETE, PATCH y a la vez, utiliza los códigos de respuesta
nativos de HTTP (404,200,204,409).
Es de fácil implementación a diversos sistemas dada su flexibilidad
y escalabilidad ya que es independiente de otras tecnologías y(o
lenguajes de programación y también consume menos recursos en el
servidor que otras tecnologías
35
SOAP. Conocidos como Web Services, son servicios que basan su
comunicación bajo el protocolo SOAP (Simple
Object Access Protocol) el cual este definido por Wikipedia como
“protocolo estándar que define cómo dos
objetos en diferentes procesos pueden comunicarse por medio de
intercambio de datos XML”.
A diferencia de la tecnología REST, SOAP no cuenta con una gran
flexibilidad y escalabilidad ya que solo permite el análisis de XML,
sin embargo, en casos específicos es más recomendable dada que es
mejor en análisis.
API. Es una manera de describir la forma en que los programas o los
sitios webs intercambian datos. El formato de
intercambio de datos normalmente es JSON o XML.
2. CONTRASTE DE LA METODOLOGÍA ESCOGIDA
El enfoque establecido para ofrecer la mejor y óptima solución al problema planteado exige
que se definan principios y rutas plenamente definidas y enmarcadas, que brinden lineamientos
concisos y claros, idealmente de una manera estandarizada, con el fin de evitar confusiones y
ambigüedades en todos los recursos interventores en el proyecto.
Por este motivo, a continuación, se definirán los distintos patrones que compondrán la
arquitectura a cumplir para construir a satisfacción el producto deseado.
36
Para empezar, es necesario reconocer la necesidad de establecer al máximo estándares con el fin de
que, por un lado, los artefactos e insumos producidos no se alejen de las mejores prácticas presentes
en la industria; y, por otro lado, minimizar las ambigüedades y confusiones que puedan darse dentro
de los integrantes del proyecto y así evitar errores por falta de claridad. Es así, que lo primero que se
requiere es definir, por medio del protocolo canonizado, un solo protocolo de interoperabilidad y
comunicación entre los diferentes componentes del sistema.
Tabla 2
Definición detallada del Concepto “Canonical Protocol”
Protocolo Canonizado
(Canonical Protocol) HTTP
Requerimiento Es necesario definir la menor cantidad de formas de
intercomunicación e interoperabilidad entre los componentes de
la solución
Problema Cuando los componentes soportan diferentes tecnologías de
comunicación entre sí, comprometen la interoperabilidad y se
anulan las comunicaciones entre sí.
Solución Esta arquitectura establece un único protocolo de
comunicaciones entre las diferentes capas del sistema: http
Aplicación El protocolo mediante el cual las capas del sistema se
intercomunicarán será únicamente http.
Impacto Susceptibilidad a las limitaciones propias del protocolo
establecido.
37
También es necesario determinar, dentro de esa estandarización, una forma de centralizar las
definiciones lógicas de los componentes, con el fin de evitar el desuso de componentes o la
redundancia de funcionalidad desplegada y distribuida en el sistema.
Tabla 3
Definición detallada del concepto “Logic centralization”
Centralización de la lógica (Logic
Centralization)
Requerimiento Es necesario implementar la menor cantidad de
funcionalidad requerida para el correcto
funcionamiento del sistema.
Problema Si no se definen elementos lógicos
centralizados, se incurrirá en el uso incorrecto
de los componentes existentes o se crearán
funcionalidades duplicadas, llevando a
procesos de mantenimiento más costosos.
Solución Esta arquitectura determina que el diseño de
los componentes se orientará a las entidades
lógicas de información requerida para el
correcto funcionamiento del sistema. De esta
manera, la funcionalidad implementada se
enfocará en las entidades y así se evitará la
redundancia y el retrabajo.
Aplicación Mediante esta definición, se definirán
componentes lógicos enfocados única y
38
exclusivamente enfocados en una única
entidad. Dicho de otro modo, cada unidad
contenedora de información relevante, llamada
entidad, tendrá asociados un conjunto de
elementos lógicos que administrarán su
información contenida, de tal modo que una
unidad lógica no afectará a dos entidades.
Impacto Las unidades lógicas dependen completamente
de las entidades.
3. POST MORTEM OBJETIVOS ESPECIFICOS
• Nos quedan claros los mecanicismos de seguridad en la herramienta SOA y además
aplicamos estos mecanismos y herramientas de la manera más adecuada para la
implementación de las alertas y notificaciones de control de los inventarios que se realizan
en la aplicación diseñada, se puede evidenciar que a lo largo de estas tres entregas se pudo
encontrar la manera más optima de utilizar y construir el mejor diseño a aplicar la aplicación.
• Se logran obtener los resultados de información de los procesos y procedimientos por medio
de las diferentes actualizaciones que se realizan en el control de inventarios para dar un mejor
uso a esta información, logrando recibir la información de manera oportuna y eficaz para
poder brindar mayor seguridad a la información brindada.
• Se logra comprender de manera adecuada las diferencias entre las aplicaciones abiertas y
cerradas para el intercambio de la información en control y gestión de inventarios.
• Se plantean diferentes alternativas de modelación de arquitecturas orientadas al servicio
tomando como principal la arquitectura de aplicación de SOA en el ámbito empresarial.
39
4. SUSTENTACION REST API:
El siguiente video se encuentra la explicación resumida de la aplicación desarrollada:
Entrega3 Arquitectura Politécnico Gran Colombiano
40
RECOMENDACIONES FINALES
• Teniendo en cuenta el cronograma planteado para el presente proyecto, se espera poder
cumplir con los tiempos proyectados, en miras a que se culmine satisfactoriamente el mismo
como parte fundamental de proceso de aprendizaje en el que nos encontramos los integrantes
del grupo de trabajo.
• Es importante que, como equipo, se tengan claras las fortalezas de cada uno de los integrantes,
para de esta manera poder unificar esfuerzos sacando lo mejor de cada uno.
• Continuar reforzando nuestros conocimientos sobre SOA para poder aplicar las nociones del
servicio, su construcción y resultados como elementos fundamentales para desarrollar
satisfactoriamente todas las fases de este proyecto.
41
CONCLUSIONES FINALES
• Se logro definir un proyecto de trabajo de acuerdo con los requerimientos del módulo y, a
partir de las habilidades identificadas entre los integrantes del grupo de trabajo.
• Mediante el proceso de levantamiento de información, y luego de varias rigurosas revisiones
a los requisitos y necesidades identificadas en el proyecto seleccionado, fue posible definir
el conjunto de requerimientos expuestos en este documento, que serán la base de muchos
otros insumos para el desarrollo de la solución.
• Gracias a la información obtenida, así como a los temas tratados durante el proceso de
aprendizaje y de realización de este documento, es posible identificar y definir el modelo de
desarrollo idóneo para la fabricación de la solución requerida para el proyecto.
• Conforme a los Estilos y Patrones descritos y delimitados en este documento, es posible
alcanzar el planteamiento, diseño y definición del producto a entregar a futuro, con altos
estándares de calidad. Asimismo, se espera definir los pasos a seguir para mantener la calidad
esperada mediante los procesos que los consultores de calidad requieran a lo largo del
desarrollo del proyecto.
• De acuerdo con el proyecto seleccionado por el equipo como primera fase, se concluye que
la SOA es un elemento fundamental que permite facilitar y estandarizar la integración de los
sistemas, las aplicaciones y los requerimientos de los procesos de negocio, en el caso
específico del negocio de inventarios.
• Nos parece importante resaltar de la estrategia que, antes de que existiera SOA, no se contaba
con buenas interfaces para acceder a las funcionalidades de otros ordenadores en red.
• El modelo SOA de arquitectura puede significar una forma de ordenar los sistemas de
información que posibilita la relación entre los diferentes servicios ofrecidos en la empresa.
42
• Gracias al diseño SOA se implementan mejoras en el desafío con pocos recursos, pero sin
dejar de lado la calidad y lo que se espera del producto ofrecido.
• La implementación de la arquitectura SOA en el proyecto, nos permite combinar las
interfaces de manera que se responda a las necesidades de la empresa.
• Los beneficios de la estrategia para la empresa son la generación de eficiencia, capacidad de
respuesta y adaptabilidad que permiten a la corporación interactuar como realmente lo
necesitan, aumentando a su vez la flexibilidad.
43
BIBLIOGRÁFIA
Algoritmo en Informática, María Estella Raffino de Concepto de, (2019). URL
https://concepto.de/algoritmo-en-informatica/#ixzz60wK0Fp9y Buenos Aires, Argentina.
Lenguaje de Programación, María Estella Raffino de Concepto de, (2018). URL
https://concepto.de/lenguaje-de-programacion/ Buenos Aires, Argentina.
Color Palette 1649, Gal Shir, (2015). URL https://colorhunt.co/palette/1649 Color Hunt, E-mail:
team@colorhunt.co.
Ingeniería Web y Web semántica. Modelo avanzado. Arquitectura Orientada a Servicios. (2015) URL
https://repositorio.grial.eu/bitstream/grial/381/3/Sistemas%20Inteligentes%20-%20SOA.pdf
Cómo construir un cronograma de entrega para tu proyecto https://www.wrike.com/es/blog/como-
construir-cronograma-de-entrega-proyecto/
Ingeniería y arquitectura del software, Angel Arias, Alicia Durango (2016), IT campus academy
¿Qué es la arquitectura orientada a los servicios (SOA)?
(2021) URL https://www.redhat.com/es/topics/cloud-native-apps/what-is-service-oriented-
architecture
44
Delgado, A, González, L y Piedrabuena, F. (2006.). Desarrollo de aplicaciones con enfoque SOA
(Service Oriented Architecture). .Reportes Técnicos 06-16.
Microsoft (02-04-2021) por Rick Anderson, Kirk Larkin, y Mike Wasson, Tutorial: Create a web API
with ASP.NET Core https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-
api?view=aspnetcore-5.0&tabs=visual-studio
APLICA. De sistema monolíticos a microservicios. URL
https://www.aplyca.com/es/blog/aplicaciones-monoliticas-o-
microservicios#:~:text=Actualizar%20una%20aplicaci%C3%B3n%20monol%C3%ADtica%20tien
e,identificar%20y%20solucionar%20problemas%20concretos.
Almeia, E. Aplicación monolítica o distribuida. URL
https://ealmeida.blogspot.com/2019/10/aplicacion-monolitica-o-
distribuida.html#:~:text=Desventajas%20de%20la%20aplicaci%C3%B3n%20monol%C3%ADtica.
&text=enlenteciendo%20el%20desarrollo%20y%20dificultando,la%20aplicaci%C3%B3n%20fuera
%20de%20servicio.
EKON (2019). La importancia de los inventarios en una empresa. URL
https://www.ekon.es/importancia-inventarios-
empresa/#:~:text=El%20control%20de%20inventario%20es,los%20clientes%20a%20otros%20pro
veedores.
45
BIND. ERP. ¿Qué son los inventarios de materias primas y productos terminados? URL
https://blog.bind.com.mx/que-son-los-inventarios-de-materias-primas-y-productos-terminados
REDHAT. ¿Qué es una API de REST? URL https://www.redhat.com/es/topics/api/what-is-a-rest-api
Fernández, A. (2018). 8 pasos para crear una Web Api con .Net Core. URL
https://azaharafernandezguizan.medium.com/8-pasos-para-crear-una-web-api-con-net-core-
25323708cac0#:~:text=Net%20Core%20es%20una%20versi%C3%B3n,en%20el%20propio%20fra
mework%20.
Deloitte. ¿Qué es un ORM? URL
https://www2.deloitte.com/es/es/pages/technology/articles/que-es-orm.html
46

Entrega Semana 7 Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

Entrega Semana 7 Arquitectura de Software

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Entrega Semana 7 Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

ENTREGA FINAL.

INTEGRANTES DEL GRUPO:

García López Andrés - Código: 100237928

Quiroga Ortiz Cristian Camilo – 2021981156

Rozo Castañeda Lina Estefanía - Código: 1721022861

Sosa Pinzon Cristian Camilo – 1821020779

Trujillo Gutiérrez Iván Andrés – Código 1921982787

INSTITUCIÓN UNIVERSITARIA POLITÉCNICO GRANCOLOMBIANO

FACULTAD DE INGENIERÍA, DISEÑO E INNOVACIÓN

Bogotá, Marzo del 2021

La arquitectura orientada a servicios nace de la necesidad, de construir servicios compuestos que

otorguen la oportunidad de generar integración de bases de datos diversas en un sistema orientado a

la mejora continua y la optimización de comunicación integral de un negocio, lo cual forma y

En un mundo globalizado como en el que estamos la tecnología de la información y específicamente

procedimientos, planeación y ejecución y demás aspectos a tener en cuenta en la elaboración de

proyectos que aseguren los principios básicos de disponibilidad, concurrencia, y seguridad de la

transacciones que se realizan en controles y gestión de inventarios y como se entregan a un usuario

verificables, controlables y seguras.

y productividad a partir del entendimiento y ejecución de modelos de negocio basados en el software

• Entender y aplicar mecanismos de seguridad utilizadas en herramientas SOA en la

implementación de alerta y notificación de transacciones de control de inventarios

• Analizar los mecanismos de actualización de control de inventarios con el fin de tener

información de procesos y procedimientos.

• Comprender las diferencias entre aplicaciones abiertas y cerradas en el intercambio de

información en control y gestión de inventarios y activos.

• Plantear alternativas de modelación de arquitecturas orientadas a servicios como standard de

aplicación de SOA en el ámbito empresarial.

uno de sus locales.

en teoría actualizado en el servidor.

Modelo SOA a implementar dada la propuesta:

productos para mantener actualizado el inventario.

El servicio 1: se encargará de listar los productos del inventario.

El servicio 3: se encargará de realizar la búsqueda del inventario por su Id.

Esta arquitectura se implementará en un modelo de capas por lo que va a permitir desacoplar la

aplicación en submódulos, esto es una gran ventaja para el mantenimiento.

algún tipo de incompatibilidad y tener desarrolladores más versátiles.

. Las tres categorías principales son:

vez más agiles y seguras.

Para el caso particular de nuestra observación en sistemas de control y actualización de

inventarios se tienen las siguientes características:

2. Finalidad del proyecto ¿Para qué se va a hacer?

3. ¿Qué problemáticas resuelve?

4. Las exigencias que tiene. ¿Cómo se va a hacer?

• ¿Por qué se va a hacer?

Las principales características del SOA es determinar características de disponibilidad,

patrones de diseño se preverá fallos e inconvenientes a la hora de evaluar la creación y/o

• ¿Para qué se va a hacer?

El análisis de aplicaciones y software de control de inventarios cumple una vital importancia en

optimizar tiempos de diseño y ejecución y a su vez brinden de seguridad al manejo de activos de

• ¿Qué problemáticas resuelve?

Para el caso particular se resolverían las siguientes características: Enrutamiento, Asincronía,

Interoperabilidad, Concurrencia, Centralización de datos, Clasificación de servicios,

Redundancia, Rollback, Abstracción de servicios, Consumo de memoria en la operación,

arquitectura de software dado aspectos tales como la eficiencia, la escalabilidad y la optimización de

de servicios para el enrutamiento de los mensajes.”(REDHAT - ¿Qué es la arquitectura orientada a

los servicios (SOA)).

problema para dar paso al diseño.

aplica a la arquitectura de software de manera abstracta.