Arquitectura del software - ING del software

 

¿Qué es la arquitectura de software?

En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado arquitectura de software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".

La arquitectura de software representa la estructura o las estructuras del sistema, que consta de componentes de software, las propiedades visibles externamente y las relaciones entre ellas.

 

Estilos y patrones de arquitectura de software

El contenido de esta entrada es un resumen de la información sobre estilos y patrones de arquitectura de software presentados por Nenad Medvidovic en una conferencia dictada en el marco del Máster Europeo de Ingeniería de Software de la Universidad Politécnica de Madrid, en abril de 2011.

 

Estilos de Arquitectura de Software

Un estilo de arquitectura es un conjunto de decisiones de diseño arquitectural que son aplicables en un contexto de desarrollo específico, restringen las decisiones de diseño de un sistema a ese contexto y plantean como objetivo ciertas cualidades para el sistema resultante.

Establecen un vocabulario común, donde se dan nombres a los componentes y conectores, así como a los elementos de datos Establecen un conjunto de reglas de configuración, como la topología del sistema Definen una semántica para las reglas de composición de los elementos Posibilitan el análisis de los sistemas construidos sobre el estilo Algunos ejemplos de estilos arquitecturales:

Influenciados por los Lenguajes de Programación

Programación estructurada

Orientado a Objetos

Capas

Máquinas Virtuales

Cliente Servidor

n-Tier

Peer-to-Peer

Flujo de Datos

Batch

Pipes and Filters

Memoria Compartida

Blackboard

Rule Based

Interprete

Invocación Implícita

Event-based

Publisher-suscriber

 

Patrones de Arquitecturas de Software

Un Patrón de Arquitectura de Software es un conjunto de decisiones de diseño que se pueden aplicar a un problema de diseño recurrente y que pueden parametrizarse para diferentes contextos donde ese problema de diseño aparece.

Estructuras

Capas

Pipes and Filters

Blackboard

Sistemas Interactivos

Model-View-Controller

Presentation-Abstraction-Communication

Sistemas Distribuidos

Broker

Trader

Sistemas Adaptables

Reflection

Microkernel

Entonces, ¿Cuál es la diferencia entre un estilo y un patrón de Arquitectura de software? Tal como yo lo entiendo, un patrón es una solución prediseñada para un problema que puede aplicarse en cualquier contexto donde se presente el  problema. Un estilo es un modelo conceptual que define un vocabulario común.  algunas decisiones de diseño arquitectural pueden actuar al mismo tiempo como estilos y patrones.

¿Cuál es la diferencia entre un Patrón de Diseño y un Patrón Arquitectural? Un patrón arquitectural expresa un esquema de organización estructural fundamental de un sistema mientras que un patrón de diseño provee un esquema para refinar los subsistemas o componentes de un sistema y las relaciones entre ellos.

 

Vistas de kructhen

El modelo “4+1” de Kruchten, es un modelo de vistas [1] diseñado por el profesor Philippe Kruchten y que encaja con el estándar “IEEE 1471-2000” (Recommended Practice for Architecture Description of Software-Intensive Systems [5]) que se utiliza para describir la arquitectura de un sistema software intensivo basado en el uso de múltiples puntos de vista.

lo que propone Kruchten es que un sistema software se ha de documentar y mostrar (tal y como se propone en el estándar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4 vistas se han de relacionar entre sí con una vista más, que es la denominada vista “+1”. Estas 4 vista las denominó Kruchten como: vista lógica, vista de procesos, vista de despliegue y vista física y la vista “+1” que tiene la función de relacionar las 4 vistas citadas, la denominó vista de escenario.

 

Cada una de estas vistas ha de mostrar toda la arquitectura del sistema software que se esté documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del sistema software. A continuación, pasamos a explicar que información ha de haber en la documentación de cada una de estas vistas.

Vista Lógica: En esta vista se representa la funcionalidad que el sistema proporcionara a los usuarios finales. Es decir, se ha de representar lo que el sistema debe hacer, y las funciones y servicios que ofrece. Para completar la documentación de esta vista se pueden incluir los diagramas de clases, de comunicación o de secuencia de UML.

Vista de Despliegue: En esta vista se muestra el sistema desde la perspectiva de un programador y se ocupa de la gestión del software; o en otras palabras, se va a mostrar como esta dividido el sistema software en componentes y las dependencias que hay entre esos componentes. Para completar la documentación de esta vista se pueden incluir los diagramas de componentes y de paquetes de UML.

Vista de Procesos: En esta vista se muestran los procesos que hay en el sistema y la forma en la que se comunican estos procesos; es decir, se representa desde la perspectiva de un integrador de sistemas, el flujo de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. Para completar la documentación de esta vista se puede incluir el diagrama de actividad de UML.

 

Vista Física: En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los componentes físicos del sistema así como las conexiones físicas entre esos componentes que conforman la solución (incluyendo los servicios). Para completar la documentación de esta vista se puede incluir el diagrama de despliegue de UML.

 

“+1” Vista de Escenarios: Esta vista va a ser representada por los casos de uso  software y va a tener la función de unir y relacionar las otras 4 vistas, esto quiere decir que desde un caso de uso podemos ver como se van ligando las otras 4 vistas, con lo que tendremos una trazabilidad de componentes, clases, equipos, paquetes, etc., para realizar cada caso de uso. Para completar la documentación de esta vista se pueden incluir el diagramas de casos de uso de UML.

Clasificación de los patrones arquitectónicos:

https://medium.com/@maniakhitoccori/los-10-patrones-comunes-de-arquitectura-de-software-d8b9047edf0b

1 - estilo de capas

Este patrón se puede utilizar para estructurar programas que se pueden descomponer en grupos de subtareas, cada una de las cuales se encuentra en un nivel particular de abstracción. Cada capa proporciona servicios a la siguiente capa superior.

Las 4 capas más comúnmente encontradas de un sistema de información general son las siguientes.

Capa de presentación (también conocida como capa UI )

Capa de aplicación (también conocida como capa de servicio )

Capa de lógica de negocios (también conocida como capa de dominio )

Capa de acceso a datos (también conocida como capa de persistencia )

Uso

Aplicaciones de escritorio generales.

Aplicaciones web de comercio electrónico.

2 - estilo basado en repositorios

Este patrón es útil para problemas para los que no se conocen estrategias de solución deterministas. El patrón de pizarra consta de 3 componentes principales.

pizarra : una memoria global estructurada que contiene objetos del espacio de solución

fuente de conocimiento : módulos especializados con su propia representación

componente de control : selecciona, configura y ejecuta módulos.

Todos los componentes tienen acceso a la pizarra. Los componentes pueden producir nuevos objetos de datos que se agregan a la pizarra. Los componentes buscan tipos particulares de datos en la pizarra, y pueden encontrarlos por coincidencia de patrones con la fuente de conocimiento existente.

Uso

Reconocimiento de voz

Identificación y seguimiento del vehículo

Identificación de la estructura proteica

Sonar señala la interpretación.

 

Patrón de pizarra

Consta de dos (2) tipos de componentes: una estructura central de datos que refleja el estado actual y una colección independiente de componentes que operan sobre el almacén central.

• Las interacciones entre los componentes pueden variar significativamente. El tipo de control seleccionado puede llevar a dos categorías:

– Si el tipo de transacción es una entrada que dispara la selección del proceso a ejecutarse, se está hablando de las tradicionales bases de datos.

– Si el estado actual de la estructura central de datos es el principal activador de los procesos a ejecutarse, se habla de un estilo de repositorio tipo pizarrón (blackboard).

Son muy utilizados para aplicaciones que requieren interpretaciones complejas de procesamiento de señales, tales como reconocimiento del habla y de patrones.

3 - estilo cliente - servidor

Este patrón consiste en dos partes; un servidor y múltiples clientes . El componente del servidor proporcionará servicios a múltiples componentes del cliente. Los clientes solicitan servicios del servidor y el servidor proporciona servicios relevantes a esos clientes. Además, el servidor sigue escuchando las solicitudes de los clientes.

Uso

Aplicaciones en línea como correo electrónico, uso compartido de documentos y banca.

4 - estilos para sistemas distribuidos

La organización de los sistemas distribuidos depende mayormente de los componentes de software que constituyen al sistema. Estas arquitecturas de software establecen como son organizados varios componentes del software y cómo interactúan entre ellos.

La implementación de un sistema distribuido requiere de la división e identificación de los componentes de software y su instalación en máquinas reales. La implementación e instalación final de la arquitectura de software se conoce como arquitectura de software.

Existen varias configuraciones de componentes y conectores que definen el estilo arquitectónico

de un sistema distribuido. Los estilos más importantes son:

• Arquitecturas en capas

• Arquitecturas basadas en objetos

• Arquitecturas centradas en datos

La idea básica tras el estilo arquitectónico en capas es simple: los componentes están organizados en forma de capas, en la que un componente en una determinada capa puede llamar a componentes en la capa inmediata inferior. Una observación clave es que el control generalmente fluye de capa en capa: las peticiones van de arriba abajo y los resultados de abajo a arriba, tal como se puede observar en la Figura 1(a). Una organización, por mucho más suelta, se tiene en arquitecturas basadas en objetos, tal como se muestra en la Figura 1(b). En esencia, cada objeto corresponde a lo que hemos definido como componente, y estos componentes están conectados mediante un mecanismo RPC. No es de sorprender que esta arquitectura de software se adapte al modelo cliente-servidor que trataremos más adelante.

5 - estilos para arquitecturas

Un estilo arquitectónico es un conjunto de restricciones arquitectónicas colaborativas que restringen los roles y funciones de los elementos arquitectónicos, y entre elementos que pueden existir en cualquier arquitectura que siga ese estilo. Relación

 

La descripción de Martin Flower en el artículo de microservicios también apoya indirectamente esta definición. El artículo primero deja en claro que "microservicios" es un estilo arquitectónico, y luego da las características de microservicios (es decir, restricciones). ¡Se puede decir que un sistema con estas restricciones usa el estilo arquitectónico de microservicios!

 

(Presentación con Prezi u otra herramienta dinámica)

 

Últimas tendencias de arquitectura del software

 

 

diagrama de arquitectura (funcional, UML de implementación)

funcional

En esta vista se representan los componentes lógicos que conforman el sistema tanto de la aplicación nower_client como nower_user. Cada componente está debidamente descrito indicando cuáles son sus responsabilidades dentro de la estructura general. Para ambas aplicaciones se utiliza el susbsitema nower_server, que es en donde se administra toda la lógica del negocio, se da la comunicación entre nower_client y nower_user, y se encuentran los servicios que permiten llevar a cabo las operaciones que garantizan el correcto funcionamiento del sistema general.

Uml de implementación

Los diagramas de implementación permiten visualizar la arquitectura física del hardware, el software y los artefactos del sistema. Los diagramas de implementación pueden entenderse como lo contrario de los casos de uso, porque ilustran la forma física del sistema, en lugar de representar conceptualmente los usuarios y dispositivos que interactúan con el sistema.

 

La barra de herramientas de los diagramas de implementación de UModel incorpora cubos 3D de colores para representar cada nodo, ejecución, entorno y dispositivo existente en el sistema. Como en otros diagramas de UModel, los paquetes, componentes y diagramas de implementación cuentan con botones de edición rápida, ayudantes de entrada y todas las opciones de alineación disponibles en la barra de herramientas de diseño. También puede añadir notas con información relevante a cualquier diagrama.

 

En la documentación de sistemas los diagramas de implementación son un elemento importante que puede ser útil a la hora de planificar proyectos complejos con artefactos, como archivos ejecutables, archivos de datos, documentos XML y archivos de configuración que en última instancia se encontrarán en distintas plataformas de hardware. Los diagramas de implementación claros y detallados también ayudan a los equipos más grandes a entender el conjunto de la arquitectura del proyecto.

Diagramas de Implementación

• Diagramas que muestran los aspectos de implementación del sistema, ya sea a nivel lógico

(código fuente) como a nivel de estructura física (hardware)

• Permiten una visión general del sistema, sin entrar en detalles de implementación o

comportamiento

• Existen 3 diagramas:

• Diagrama de Componentes. Muestra los diferentes componentes software existentes así como la

relación entre los mismos

• Diagrama de Despliegue/Distribución. Muestra los diferentes componentes hardware existentes así

como la relación entre los mismos

 

JUSTIFICACIÓN DEL ESTILO SELECCIONADO

Arquitectura de Software donde reposa la Aplicación

Según Reynoso (2004, p. 5) la arquitectura de software es la organización de un sistema de acuerdo a sus componentes, las relaciones entre ellos, el ambiente y los principios que orientan su diseño y evolución. Por esto, la aplicación de una arquitectura, es una estrategia sistemática, disciplinada y cuantificable para el desarrollo, aplicación y mantenimiento del software. Dentro de la arquitectura de software, existen patrones, los cuales estructuran un sistema dentro de subsistemas, para soportar el refinamiento de esos componentes y la relación entre ellos. Entre estos patrones, se encuentran los sistemas interactivos, los cuales apoyan la estructuración de sistemas de software que ofrecen interacción usuario-computadora. Estos se desarrollan alrededor de los requerimientos funcionales del sistema, que normalmente permanecen estables. Las interfaces de usuario, sin embargo, pueden cambiar.

Entre estos patrones interactivos, existe el Modelo-Vista-Controlador (MVC), el cual fue empleado para el desarrollo del software A Bocado’s. De acuerdo a Bascón (2004, p. 4), MVC es un patrón que considera dividir una aplicación en tres módulos con funcionalidad bien definida: El modelo, las vistas y los controladores. El modelo se encarga del control central de los datos, las vistas muestran la información contenida en el modelo a los usuarios, y los controladores manejan las entradas de los usuarios. Este patrón de arquitectura fue seleccionado para el desarrollo del software ya que ofrece muchas ventajas: La aplicación está implementada modularmente, por lo que su implementación presenta una extensibilidad y una mantenibilidad únicas comparada con otros patrones. Por otra parte, cada vista se actualiza de manera automática, y las modificaciones a las vistas no afectan en absoluto a los otros módulos de la aplicación. Además, si se desea hacer una modificación al modelo, solo debe modificarse el mismo y sus interfaces, no todo el mecanismo de comunicación y de actualización entre modelos. En general, es una arquitectura estable pero adaptable, ideal para este tipo de proyecto.