Estructura, modelos, diagramas y composición del software a desarrollar.
“La arquitectura del sistema, compuesta por elementos de software, sus propiedades visibles y sus relaciones” - Software Architecture in Practice
<h1>Etapas del proceso de desarrollo de software</h1>EL proceso de desarrollo tradicional tiene etapas muy marcadas, que tienen entradas, procesos y salidas que funcionan como entradas de la siguiente capa.
Es importante diferenciar los ROLES de puestos de trabajo de desarollos
Una empresa va a poder generar estructuras que imitan la vía de comunicación de su organización.
“Las organizaciones dedicadas al diseño de sistemas […] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones”
<h1>Objetivos del arquitecto</h1>El arquitecto va a tener diferentes stakeholder con el sistema a construir. Cada uno de los roles que tienen los SH afectan de diferente forma al sistema
Presentación - Pag 7
<h1>Arquitectura y metodologías</h1>
Una vez que entendemos el espacio del problema y el espacio de la solución, vamos a entrar a analizar los requerimientos de nuestro sistema.
Requerimientos de producto: Los podemos dividir en 3 capas.
Requerimientos de proyecto: Tienen que ver más con el rol de gestor de proyectos, se usan para dar prioridad a los requerimientos del producto.
Por ejemplo: Se necesita una Beta o una prueba para un usuario/evento
<h3>Nota: Definiciones ejemplares de Requerimientos funcionales y no funcionales</h3>Requerimientos funcionales
“Como usuario registrado quiero ingresar al sistema para tener una experiencia personalizada”
“Como personal de enfermería quiero ver la información del estado del paciente para poder reaccionar a cualquier anomalía”
Requerimientos no funcionales
“Como usuario registrado quiero ingresar de forma segura al sistema para tener una experiencia personalizada”
“Como personal de enfermería quiero ver la información en tiempo real del estado del paciente para poder reaccionar a cualquier anomalía”
<h1>Riesgos</h1>Mas allá de los requerimientos, hay que tener en cuenta los riesgos que estos implican para poder priorizarlos y atacarlos en orden.
Hay que lograr describir los riegos y poder identuficarlos, para luego catalogarlos cómo:
Hay un framework (marco de trabajo) que se basa en la toma de requerimientos, atributos de calidad o el dominio que tenemos del problema que estamos por resolver.
Al identificarlos, hay que priorizarlos en base a la importancia que estos requieren en el sistema.
<h1>Restricciones</h1>“Una restricción limita las opciones de diseño o implementación disponibles al desarrollador” - Software Requiremnts
Cuando hablamos de requerimientos, también mencionamos las restricciones. Podemos encontrar con tres tipos de resticciones:
Hay muchas librerías, muchos frameworks y conocimiento arquitectónico implícito en las comunidades. Por ejemplo, si hablamos de palabras como MVC o FLUX (con React) estamos hablando de arquitectura, sin embargo, esta implícito dentro del uso de una tecnología específica, y de repente si hablamos de FLUX estando en Java o C# no tiene ningún sentido, ya que no es una arquitectura que se suele encontrar en esa tecnología, sin embargo arquitectónicamente tiene el mismo valor y podría ser implementado en otra tecnología. Asi también, hay decisiones arquitectónicas tales como si empezar un proyecto con un monolito o iniciarlo con una estructura de microservicio, que se dan por sentado que cualquier cosa seria de mucho mas valor iniciarlo como un microservicio ¿Por qué? Puede ser porque es la tendencia, porque es lo que se da más fácil para el equipo de desarrollo o porque las herramientas mas modernas de hoy están orientados a microservicios, sin embargo, falta un análisis más profundo de que es lo que define ese estilo o patrón de arquitectura y cuáles son los payloads o sacrificios que estamos pagando por usarlos y cuáles son los beneficios que esperamos que traigan.
Ningún patrón tiene solo beneficios, cuando hablábamos de que no hay balas de plata, recordemos que ninguno de estos patrones ni estilos nos va a solucionar todos los softwares, siempre hay beneficios y consecuencias de las decisiones de diseño que tomamos.
Un estilo de arquitectura es una colección de decisiones de diseño, aplicables en un contexto determinado, que restringen las decisiones arquitectónicas específicas en ese contexto y obtienen beneficios en cada sistema resultante
Es el estilo más básico donde se obtiene una rutina y se manda a llamar otra subrutina, en donde la subrutina puede retornar o no un resultado, pero la principal continua hasta que acabe la subrutina.
<h3>Orientado a objetos</h3>Se utiliza para aplicaciones que vamos a mantener por mucho tiempo. Tratamos de abstraer las entidades de nuestro sistema en objetos, logrando tener el estado actual de nuestro objeto, y superficialmente, la de nuestro software
<h3>Multi nivel</h3>Son diferentes componentes y/o capas que se van a comunicar en un orden en especifico. Por ejemplo, la arquitectura Cliente-Servidor.
No estamos preocupados por la secuencia de ejecución sino por como los datos van a ir de un lugar a otro.
<h3>Lote secuencia</h3>Lo importante es ejecutar un proceso y que al final de ese proceso pase a una siguiente etapa
<h3>Tubos y filtros</h3>Se obtiene un flujo de datos continuo en donde cada aplicación recibe continuamente esos datos, lo procesa, y retorna a otra aplicación, capa, proceso o finaliza la misma.
Diferentes componentes que interactúan con un componente central (pizarrón). Cada componente tiene un responsabilidad y una tarea, que al finalizar, se encarga de persistir y centralizar el proceso en el “pizarrón”. Este pizarrón puede tener un proceso de salida.
<h3>Centrada en base de datos</h3>Es muy común en donde diferentes alicaciones utilizan la misma base de datos. Es decir, diferentes componentes se comunican a la misma base de datos. La base de datos no solo funciona como la persistencia de los datos, sino como la comunicación en tre los componentes.
Inconveniente: Abas aplicaciones dependen del rendimiento de la base de datos compartida
<h3>Sistema experto - Basado en reglas</h3>En este caso el sistema que centraliza los datos, tiene la capacidad de entender los datos y consultas que realiza el cliente, generando salidas inteligentes. (inteligencia artificial).
Aplicaciones en donde se dividen en componentes independientes y con diferentes comportanmientos.
<h3>Invocación implícita</h3>Basada en eventos. Diferentes componentes publican eventos a un bus de eventos, y este ultimo comunican a otros componentes el proceso del bus
Tenemos dos familias:
Los componentes se comunican entre sí, teniendo cada componente una comunicación directa o indirectamente con el resto
