Un poco de historia de la arquitectura del software

Hoy en día el término “arquitectura” en el desarrollo de software se está consolidando cada vez, esto debido al alto porcentaje de proyectos que fracasan en este sector según un estudio realizado por la página de techbizdesign. El concepto se empezó a conocer en la década de 60’s en los círculos de investigación (por ejemplo, por Edsger Dijkstra). Sin embargo, empieza a tomar popularidad en la década de los 90’s tras reconocer la denominada crisis del software, éste se refiere a los problemas que va experimentando un software debido principalmente a la poca eficacia de la realización del mismo.

En el sector de tecnologías de la información hay diferentes tipos de áreas a las que va orientada una arquitectura como: arquitectura de hardware, arquitectura de sistemas, arquitectura de microprocesadores, entre otros. Todos estos van orientados al mismo término “arquitectura”, el que se refiere específicamente al arte y a la técnica de proyectar, diseñar y construir edificios.

El concepto de arquitectura de software se ha definido desde 2016 como la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Al desarrollar un software primero se debe definir la base en la que se va a crear, considerando la tecnología a incorporar, algún patrón de diseño y las diferentes implementaciones que el software pueda tener, dependiendo la necesidad para lo que se desarrollará. Al crear un tipo de arquitecturas de software, se debe definir la tecnología adecuada con una base sólida que se adapte a diferentes proyectos de innovación que permita ajustarse a las necesidades, esto permitirá un mejor uso de los métodos que se implementen, optimo mantenimiento del software y alto rendimiento del mismo.

 

Tecnología API REST

Hoy en día la tecnología “API REST” es una de la más utilizadas al desarrollar aplicaciones web, ya que permite comunicación entre sistemas sin depender de un lenguaje de programación especifico. La “arquitecturas Rest” (de las siglas en inglés, Representational State Transfer) se define como un estilo de arquitectura cuando se realiza una comunicación entre cliente y servidor. Esta comunicación permite el poder intercambiar información de forma más práctica.

En la actualidad, algunos proyectos o aplicaciones que se encuentran en la web, dispone de una API REST para la creación de servicios, Twitter, Spotify, Facebook y demás aplicaciones por mencionar las más populares que manejan este tipo de tecnología en su arquitectura. Ésta se maneja por capas y se divide la aplicación en back-end y front- end. Al precisar esta estructura tenemos que el back-end como su nombre lo indica, es todo lo que va detrás de la aplicación, es donde tenemos toda la programación lógica y funcional de la misma. Por otro lado, el front-end es donde se recibirán todos los datos que serán enviados por el back-end y se colocarán de forma que el usuario tenga una interfaz fácil de visualizar y manipular.

Teniendo la arquitectura con API REST ya planteada, se detallará cada una de sus capas teniendo en cuenta su estructura Back-end que contará con la base de datos, el DAL (Data Access Layer), las entidades y el Controller. Con Front-end es donde se podrán ver los datos ya procesados haciendo uso del Framework Angular.

 

BACK-END

La base de datos es un elemento importante del “Back-End” conformada con una estructura básica o típica en la que se puedan gestionar los datos, en esta arquitectura se recomienda tener incluida la lógica utilizando Stored Procedure, que son procedimiento almacenados en el cual se puede crear algo parecido a funciones de programación pero en este caso lleva la lógica para poder crear el CRUD, en cada una de las tablas, así como también manejar los datos de una manera abstracta y crear el código SQL, adecuado para algunas situaciones dependiendo de las necesidades de la aplicación. Los Stored Procedures tienen la ventaja de que se ejecutan directamente en el motor de base de datos atendiendo peticiones del usuario, evitando la sobrecarga resultante de comunicar grandes cantidades de datos, así como recibir y generar parámetros de salida.

 

DAL

“Data Access Layer”, como su nombre lo indica es la capa de acceso a datos, como todo desarrollador, sabemos que es muy importante tener una buena conexión con la base de datos en la que se pueda mantener una buena comunicación con los datos, el DAL usualmente en esta arquitectura contiene esa conexión implementada con métodos en donde se puede crear directamente scripts SQL, para así poder recuperar y modificar los datos que estaremos utilizando en nuestra aplicación.

Al tener Stored Procedure en nuestra arquitectura, prácticamente la lógica de los scripts SQL estarán directamente en el motor de base de datos y no en el Data Access Layer, por lo que solo se procederá a llamar esos procedimientos almacenados, así como enviarles los datos que éste requiera, éste hará su procesamiento y tendremos los resultados esperados.

 Arquitectura de software con Api Rest

ENTIDADES

Básicamente en la capa “entidades”, estarán los modelos de los objetos que manejarán los Stored Procedures, comunicándose directamente con el Data Access Layer y facilitando la manipulación de datos. Un modelo es una abstracción de algo, cuyo objetivo es comprenderlo antes de construirlo. Dado que los modelos omiten los detalles no esenciales, es más sencillo manipularlos que operar la entidad original. La abstracción permite enfrentarse a la complejidad. Los ingenieros, artistas y artesanos han estado construyendo modelos durante miles de años para probar los diseños antes de ejecutarlos.

 

CONTROLLER

El “controller” manejará cada una de las acciones de toda la arquitectura para poder así exponer los datos o recursos a los usuarios finales, a través de las APIS REST, todo esto gracias a los métodos HTTP que permiten comunicar al servidor, lo que se requiere realizar a través de una URL. Los métodos más aplicados a aplicaciones REST son:

 

• “Get”: que se utiliza para leer una representación de un recurso, éste te devuelve el resultado en un formato concreto que en este caso sería el formato JSON.
• “Post”: normalmente en el método Get se tienen algunas limitaciones, como por ejemplo al momento de mandar más cantidades de datos, mientras que el método post puede enviarlos estableciendo un body (cuerpo), dentro del request (datos enviados) que contendrá cada uno de los datos.
• “Put”: este método funciona de manera similar al post, pero se utiliza para actualizar los datos, al igual que el post este maneja un body y no muestra información al enviar los datos.
• “Delete”: este método, básicamente elimina un recurso identificado en la URI.

 

FRONT-END

Angular es un “framework” de desarrollo para JavaScript creado por Google, cuya finalidad es facilitarnos el desarrollo de aplicaciones web SPA, proporcionando herramientas para representar los datos de una manera sencilla y óptima.

Este framework ofrece herramientas al programador para poder consumir los datos de una API REST, permitiendo manipularlos de manera dinámica y crear modelo de datos correspondientes. Al implementarlo podemos detallar como queremos visualizar los datos ya que toda la lógica queda a cargo del Back-End

 

Software: una arquitectura por capas

Como se puede observar, ésta es una arquitectura por capas que implica una estructura más fácil de visualizar de cada uno de los componentes del software. Al detallarlas, se comprende un poco más la comunicación que maneja cada una de éstas entre sí, ya que se implementa correctamente esta arquitectura, utilizando cada uno de los métodos http de manera adecuada. A partir de ello, tendremos APIS que podremos consumir directamente a través de un EndPoint definido; al llamar una API tendremos como respuesta un formato JSON, que contendrá los datos que nosotros utilizaremos para poder ser comprobados por diferentes herramientas, como por ejemplo, Postman, en el cual podemos ver claramente la respuesta del EndPoint que solicitamos.

Una de las ventajas, es que al momento de realizar mantenimiento o cambio de datos en la aplicación, el desarrollador solo debe dirigirse directamente a la capa que debe ser manipulada y así no tratar con los otros componentes de la aplicación, lo que ayuda a que la aplicación no tenga muchos fallos e inconsistencias y pueda ser actualizada de manera sencilla y dinámica. Esto, ofrece la separación entre cliente-servidor para mejorar la portabilidad que la aplicación pueda tener a otras plataformas, aumentando la posibilidad de expansión del proyecto y permitiendo que los diferentes componentes desarrollados puedan evolucionar de forma independiente.

 

BBVA API_Market. (2016). API REST: qué es y cuáles son sus ventajas en el desarrollo de proyectos

https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas-en-el-desarrollo-de-proyectos

 

Romero P.A. (2006). Arquitectura de software, esquemas y servicios. Ingeniería Industrial, XXVII(1):19-21. https://www.redalyc.org/pdf/3604/360433560001.pdf

Álvarez-Caules C. (2018). Arquitecturas REST y sus niveles. ArquitecturaJava. https://www.arquitecturajava.com/arquitecturas-rest-y-sus-niveles/

 

techbizdesign (2018). ¿Por qué fracasan hoy el 70% de los proyectos de software? https://www.techbizdesign.com/biz/fracaso-proyectos-software/

 

Rossi B., Brtios P. y García-Martínez R. (s.a.) Modelado de objetos. CAPIS - Centro de Actualización Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. http://laboratorios.fi.uba.ar/lsi/rgm/articulos/R-ITBA-26-objetos.pdf. 

 

Rodrigo Sánchez Peregrino, Ingeniero en Sistemas Computacionales, estudiante de Maestría en Tecnologías de la Información, Instituto Tecnológico Nacional de México, Instituto Tecnológico de Villahermosa, Departamento de Investigación y Posgrado.

Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

 

M.C.T. Miguel Pérez Vasconcelos, Instituto Tecnológico Nacional de México, Instituto Tecnológico de Villahermosa, Departamento de Investigación y Posgrado.

Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.