Introducción al curso

1

Diseño y Documentación de Arquitectura de Software

Atributos de calidad

2

Atributos de Calidad en Sistemas: Definición y Medición

3

Idoneidad Funcional: Completitud, Exactitud y Pertinencia

4

Eficiencia de Ejecución en Sistemas Informáticos

5

Compatibilidad en Sistemas: Interoperabilidad y Coexistencia

6

Subcaracterísticas de Usabilidad en Desarrollo de Software

7

Confiabilidad de Sistemas: Madurez, Disponibilidad, Resiliencia y Recuperación

8

Seguridad de Usuarios en Desarrollo de Software

9

Subcaracterísticas de Mantenibilidad en Sistemas de Software

10

Medición de Adaptabilidad en Sistemas de Software

11

Relación y Tensión entre Atributos de Calidad en Sistemas de Software

12

Atributos de Calidad en Arquitectura de Software

Patrones de arquitectura

13

Patrones de Arquitectura Monolítica y Distribuida

14

Modelo Vista Controlador: Separación de Responsabilidades en Aplicaciones

15

Arquitectura de Capas: Diseño y Comunicación entre Niveles

16

Patrones de Arquitectura Orientada a Eventos y Event Sourcing

17

Patrón de Arquitectura MicroKernel y su Implementación en IDEs

18

Arquitectura "Comparte Nada": Optimización y Procesamiento de Datos

19

Patrón de Microservicios en Arquitectura de Software

20

Patrón CQRS para Separación de Consultas y Comandos

21

Arquitectura Hexagonal: Diseño y Aplicación Práctica

22

Diseño Orientado al Dominio: Conceptos y Aplicaciones Prácticas

23

Patrones de Arquitectura para Aplicaciones Escalables y Modulares

24

Patrones de Arquitectura en Proyectos de Crecimiento Empresarial

Diseño de una arquitectura

25

Diseño de Arquitecturas a Medida: Herramientas y Estrategias

26

Tipos de Conectores en Arquitectura de Software

27

Conectores Asíncronos y Sincrónicos: Implementación y Uso Práctico

28

Diferencias entre Enrutadores y Difusores en Comunicación de Mensajes

29

Conexión de Productores y Consumidores con Colas de Mensajes

30

Framework de Diseño Orientado a Atributos: Escenarios y Tácticas

31

Tácticas para Mejorar la Disponibilidad de Sistemas

32

Tácticas para Mejorar la Disponibilidad del Sistema

33

Tácticas para Mejorar la Mantenibilidad del Software

34

Prevención de Efectos Dominó en Mantenibilidad de Software

35

Estrategias para Mejorar la Eficiencia de Ejecución en Sistemas

36

Tácticas de Seguridad Informática para Detectar, Resistir y Recuperarse de Ataques

37

Estrategias para Mejorar la Capacidad de Prueba de Software

38

Tácticas de Usabilidad en Diseño de Interfaces de Usuario

39

Validación de Arquitectura con ATAM y Métricas de Calidad

40

Diseño de Arquitectura para Startups y Empresas Escalables

Modelado y documentación de arquitectura

41

Documentación Efectiva de Arquitectura de Software

42

Sincronización de Modelos de Arquitectura y Código Fuente

43

Evaluación de Atributos de Calidad en Arquitectura de Software

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Sincronización de Modelos de Arquitectura y Código Fuente

42/43
Recursos

¿Cómo documentar una arquitectura de software efectivamente?

Documentar la arquitectura de software es un proceso crítico para garantizar que la implementación del software sea coherente con el diseño original. Sin embargo, con el tiempo, es común que la arquitectura planificada y el código fuente empiecen a divergir. Este desafío surge debido a que la abstracción de la arquitectura no siempre coincide con los elementos del código, como funciones o clases. ¿La clave? Establecer estrategias que armonicen estos dos mundos sin perder el rumbo.

¿Qué estrategias podemos adoptar para sincronizar código y arquitectura?

Ignorar la divergencia

Una estrategia, aunque controvertida, es ignorar inicialmente la divergencia entre el código y el modelo arquitectónico. En equipos pequeños o cuando todos comprenden la diferencia, se puede permitir que la documentación permanezca parcialmente desactualizada.

Modelado ad hoc

Este enfoque se basa en el conocimiento tácito. Los miembros del equipo mantienen en mente las discrepancias entre el modelo y el código fuente, lo que les permite explicar la arquitectura cuando se les consulta, aunque no esté completamente documentada.

Modelar solo arquitectura de alto nivel

Enfocarse en documentar solamente los modelos de alto nivel resulta menos propenso a cambios frecuentes. Esta táctica ayuda a que la documentación arquitectónica se mantenga más cercana a la realidad técnica de la aplicación, dado que las abstracciones más amplias suelen cambiar menos.

Sincronización periódica

Aquí, se establece un ritmo fijo para actualizar la documentación arquitectónica. Por ejemplo, en un entorno ágil, podría hacerse cada sprint o cada dos sprints. Esto permite que las actualizaciones se integren orgánicamente en el ciclo de desarrollo, y al mismo tiempo, permite versionar para saber cómo estaba la arquitectura en cada momento clave.

Sincronizar durante crisis

A veces, la necesidad de actualizar la arquitectura surgirá durante una crisis. Cuando se enfrenta un problema severo que afecta el núcleo arquitectónico, es posible que se requiera una revisión exhaustiva del documento para asegurar que refleje el estado actual después de aplicar las correcciones necesarias.

Sincronización constante

La opción menos eficiente y más costosa es mantener una sincronización constante entre el modelo y el código. Implica dedicar recursos continuos a este proceso, asegurándose de que cualquier cambio en el código se refleje de inmediato en la documentación arquitectónica.

¿Cómo seleccionar la estrategia adecuada?

No hay una única solución para todas las situaciones. La elección de la estrategia correcta dependerá de varios factores como el tamaño del equipo, la complejidad del proyecto y los métodos de trabajo utilizados.

  1. Evalúa el tamaño y dinámica del equipo: Equipos grandes pueden requerir sincronizaciones más formales que pequeños grupos de trabajo.
  2. Considera la complejidad del proyecto: Proyectos más complejos podrían beneficiarse de modelos periódicos de actualización o sincronización en momentos de crisis.
  3. Define los ciclos de desarrollo: En entornos ágiles, las actualizaciones periódicas suelen integrarse mejor en el flujo de trabajo.

Cada estrategia tiene su lugar en el ciclo de vida del desarrollo de software, y comprender cuándo y cómo aplicarlas puede ahorrar tiempo, esfuerzo y frustraciones a largo plazo.

Aportes 8

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Los Estilos de Arquitectura son Modelos, módulos, componentes conectores, restricciones, etc. Que nos permiten tener una guía de como aplicar el desarrollo del software y sobretodo como hacerlo a la hora de programar.

La fuente de la verdad siempre será el código Entonces queda a nuestro criterios basarnos en estrategias para poder mantener este equilibrio con nuestra arquitectura.

  • Modelodo Ad Hoc: Sabemos como es la arquitectura, sin embargo esta no se ha establecido programado.

  • Modelar solo arquitecturas de alto nivel: Modelar estar arquitectura tienden a ser mas permisivos durante el tiempo y son más baratos.

  • Actualizar el modelo a medida de que se programa.

¿Cómo comunicar la arquitectura?

“Esencialmente, todo modelo es incorrecto. Pero algunos son útiles.”
Empirical Model-Building and Response Surfaces (George Box, 1987)

  • Arquitectura restrictiva Restringe las decisiones que quedan por tomar (por ejemplo cuándo se le da a un equipo de desarrollo) <span style=“color:red”>Politicas a futuro
  • Arquitectura descriptiva Documenta las decisiones tomadas y describe el estado actual del sistema, restricciones del pasado más las actuales <span style=“color:red”>Imagen actual

El arquitecto va a trabajar con diferentes personas para garantizar que la arquitectura se ejecute correctamente:

  • Analista: Negociación de requerimientos
  • Operaciones: Cálculo de recursos (costos) $$
  • Desarrolladores: Restricciones y libertades para desarrollar
  • Diseñadores de productos dependientes (Product Managers): Definición de interoperabilidad. Comunicación entre productos. Requerimientos de comunicación como una API. Sincronizar equipos
  • Gestores de proyecto (Project Manager): Gestión de equipos y recursos
  • Equipo de calidad (QA): Métricas y conformidad

Documentación vs implementación

  • Modelo de Arquitectura: Se compone de elementos tales como módulos, componentes, conetores, restricciones, estilo, patrones, atributos de calidad.
  • Código fuente: Hace referencia a paquetes, clases, interfaces, métodos, funciones, parámetros, tipos.

La “fuente de la verdad” va a ser el código y no el documento de arquitectura. Se deben buscar estrategias para sincronizar el estado actual del código con el documento de arquitectura.

Las posibles estrategias son las siguientes:

  • Ignorar la divergencia:
    Aplica cuando el equipo de trabajo es pequeño y mientras todos conozcan la difernecia entre el modelo de la arquitecura y la implementación consiste en mantener el documento de arquitectura tal y como se encuentra concebido, sabiendo que es lo que hace falta completar y que está en el código fuente.
  • Modelado Ad-hoc:
    Se tiene una idea de la diferencia entre el modelado y el código fuente, de tal forma que se puede enunciar el modelo de arquitectura a pesar de que no se encuentra en el documento.
  • Modelos de alto nivel:
    Se puede seguir modelando la arquitectura con modelos de alto nivel que tienden a cambiar menos y por ende, son más baratos.
  • Sincronización en hitos del ciclo de vida:
    Consiste en actualizar el modelo de arquitectura en algún punto del ciclo de vida de la aplicación. Permite versionar el modelo de arquitectura y saber en cada momento del proyecto cual era el estado del modelo de arquitectura.
  • Sincronizar en una crisis:
    Actualizar el modelo de arquitectura cuando dentro del desarrollo, el codigo fuente riñe contra alguna definición plasmada en el modelo arquitectónico.
  • Sincronización constante:
    Es la estrategia mas obvia, pero la menos eficiente de todas porque es la mas costosa y mas complicada de ejecutar porque es bastante complicado tener el modelo actualizado contra el código fuente.

Antes del examen es muy útil este tutorial sobre el Modelo de Arquitectura “4+1”, salen preguntas de dicho tema.
https://platzi.com/tutoriales/1248-pro-arquitectura/4142-modelo-de-arquitectura-41/

Modelo de Arquitectura:
⭐️⭐️⭐️
Se compone de elementos tales como módulos, componentes, conetores, restricciones, estilo, patrones, atributos de calidad.
🤖
Código fuente:
Hace referencia a paquetes, clases, interfaces, métodos, funciones, parámetros, tipos.
🤖
La “fuente de la verdad” va a ser el código y no el documento de arquitectura. Se deben buscar estrategias para sincronizar el estado actual del código con el documento de arquitectura.
🤖
Las posibles estrategias son las siguientes:
-Ignorar la divergencia:
Aplica cuando el equipo de trabajo es pequeño y mientras todos conozcan la difernecia entre el modelo de la arquitecura y la implementación consiste en mantener el documento de arquitectura tal y como se encuentra concebido, sabiendo que es lo que hace falta completar y que está en el código fuente.
-Modelado Ad-hoc:
Se tiene una idea de la diferencia entre el modelado y el código fuente, de tal forma que se puede enunciar el modelo de arquitectura a pesar de que no se encuentra en el documento.
-Modelos de alto nivel:
Se puede seguir modelando la arquitectura con modelos de alto nivel que tienden a cambiar menos y por ende, son más baratos.
-Sincronización en hitos del ciclo de vida:
Consiste en actualizar el modelo de arquitectura en algún punto del ciclo de vida de la aplicación. Permite versionar el modelo de arquitectura y saber en cada momento del proyecto cual era el estado del modelo de arquitectura.
-Sincronizar en una crisis:
Actualizar el modelo de arquitectura cuando dentro del desarrollo, el codigo fuente riñe contra alguna definición plasmada en el modelo arquitectónico.
-Sincronización constante:
Es la estrategia mas obvia, pero la menos eficiente de todas porque es la mas costosa y mas complicada de ejecutar porque es bastante complicado tener el modelo actualizado contra el código fuente.

La documentación de software es uno de los aspectos fundamentales del proceso de desarrollo de software.
Una sólida herramienta de documentación de software le permite realizar las modificaciones necesarias en su software sin grandes complicaciones.

La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto de trabajo que está en relación de las demandas del software, en esta etapa se realizan las pruebas de caja blanca y caja negra.

Es bien sabido que para equipos agiles es más importante un software funcional a una amplia documentación. De las estrategias mencionadas creo que la única que pudiera funcionar es la de mantener una documentación de arquitectura a un alto nivel, para dar flexibilidad a los detalles de implementación