TALLER DE ARQUITECTURA DE SOFTWARE GA4-220501095-AA2-EVO 6 APRENDIZ CLAUDIA PATRICIA BONILLA INSTRUCTOR LIZETH HERNANDEZ SALEME SERVICIO NACIONAL DE APRENDIZAJE SENA Centro de servicio de salud FICHA 2721502 FECHA 23/10/2023 • Qué es la arquitectura de software cuando hablamos de arquitectura de aquella disciplina que se encarga de la planificación y diseño para la construcción de edificios y espacios de esparcimiento (como parques o monumentos), sin embargo, la arquitectura es referida al diseño y planificación a un nivel superior de una estructura a un nivel abstracto y a la toma de decisiones antes de pasar a su realización. La arquitectura, referida al software, es un concepto que surge ya en los años 60 y se refiere a una planificación basada en modelos, patrones y abstracciones teóricas, a la hora de realizar una pieza de software de cierta complejidad y como paso previo a cualquier implementación. De esta forma se dispone de una guía teórica detallada que nos permite entender cómo van a encajar cada una de las piezas de nuestro producto o servicio. Por tanto, en arquitectura llamamos patrón a cualquier solución general y reutilizable para problemas recurrentes en ingeniería del software en un contexto dado, son similares a los patrones usados en la programación, pero orientados específicamente a la estructura a un nivel superior y más genérico. • Importancia de la arquitectura de software La arquitectura nos permite planificar a priori nuestro desarrollo y elegir el mejor conjunto de herramientas para llevar a cabo nuestros proyectos, es por tanto un paso crítico antes siquiera de pasar a programar ya que determinará en gran medida el ritmo del desarrollo e incluso los factores económicos y humanos durante el proceso. Por tanto, a la hora de elegir un patrón de arquitectura siempre es necesario pensar en una serie de cuestiones que determinan el uso final que vamos a darle a nuestro software: • • Coste - ¿Cuánto estamos dispuestos a invertir en el desarrollo y mantenimiento de nuestro sistema? Como hemos visto hay ciertos patrones más complejos, que requieren más infraestructura y cuyo desarrollo puede ser más irregular, por tanto, hemos de saber cuánto estamos dispuestos a invertir primero en el desarrollo de nuestra aplicación. Tiempo de desarrollo - Igualmente, y muy relacionado con lo anterior, debemos de preguntarnos cuanto tiempo disponemos para desarrollar el • • producto, y cómo de cerca se encontraría la fecha de entrega o de salida al mercado. Número de usuarios - Sin duda uno de los ítems críticos a la hora de desarrollar el producto es preguntarnos qué tipo de producto es y cuantos usuarios soporta ¿Funciona a través de web? ¿Es stand-alone? ¿Debe de soportar cargas elevadas por diseño?, estas preguntas pueden declinarnos a elegir patrones más o menos distribuidos, pasando, por ejemplo, de uno menos distribuido como el de capas al más distribuido o broker. Nivel de aislamiento - Otro factor importante a tener en cuenta es si nuestro producto funciona de forma aislada al resto de productos del usuario o si debe de integrarse o permitir integraciones de terceros. Algunas arquitecturas, como la de capas, son más cerradas y podrían dificultar estas integraciones si lo escogemos sobre otras. En ocasiones, y cuando tenemos estos hechos bien planteados y razonados, elegir un patrón de arquitectura también puede ser una cuestión de familiaridad, comodidad o simple preferencia, por eso es aconsejable probarlos, para intentar también familiarizarse con ellos y con el diferente flujo de trabajo que proponen. REPRESENTACION MODELOS O VISTAS Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa. Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura: La visión estática: describe qué componentes tiene la arquitectura. La visión funcional: describe qué hace cada componente. La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí. Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible). ARQUITECTURAS MAS COMUNES Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son: • • • Descomposición Modular. Donde el software se estructura en grupos funcionales muy acoplados. Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes, pero sin reparto claro de funciones. Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente. Otras arquitecturas menos conocidas son: • • • • • • • Modelo Vista Controlador. En pipeline. Entre pares. En pizarra. Orientada a servicios (SOA del inglés Service-Oriented Architecture). Arquitectura de microservicios (MSA del inglés MicroServices Architecture). Algunos consideran que es una especialización de una forma de implementar SOA. Dirigida por eventos. REFERENCIAS https://sena.territorio.la/ https://www.youtube.com/watch?v=ssMLecexrsQ&t=979s&pp=ygUiVEFMT EVSIERFIEFSUVVJVEVDVFVSQSBERSBTT0ZUV0FSRQ%3D%3D
