Introducción al curso

1

Introducción al curso de Profesional de Arquitectura de Software

Atributos de calidad

2

Definición

3

Atributos: Idoneidad funcional

4

Atributos: Eficiencia de ejecución

5

Atributos: Compatibilidad

6

Atributos: Usabilidad

7

Atributos: Confiabilidad

8

Atributos: Seguridad

9

Atributos: Mantenibilidad

10

Atributos: Portabilidad

11

Tensiones entre atributos

12

Analizando PlatziServicios

Patrones de arquitectura

13

Patrones monolíticos vs distribuidos

14

Patrones: Modelo Vista Controlador

15

Patrones: Capas

16

Patrones: Orientado a eventos / Provisión de eventos.

17

Patrones: Microkernel - Plug-ins

18

Patrones: Comparte-nada

19

Patrones: Microservicios

20

Patrones: CQRS

21

Patrones: Hexagonal - Puertos y adaptadores

22

Patrones: Diseño orientado al dominio

23

Combinando patrones de arquitectura

24

Analizando nuevamente PlatziServicios

Diseño de una arquitectura

25

Pararse en hombros de gigantes

26

Herramientas y partes de un diseño: Tipos de conectores

27

Conectores: Llamado asincrónico / sincrónico. Modelo Cliente servidor.

28

Conectores: Enrutador, difusión

29

Conectores: Pizarra, repositorio, colas, modelo PUBSUB

30

Escenarios y tácticas

31

Escenarios: Disponibilidad, detección, reparación

32

Escenarios: Reintroducción y prevención

33

Escenarios: Mantenibilidad

34

Escenarios: Prevenir efectos dominó y diferir enlace

35

Escenarios: Eficiencia de ejecución

36

Escenarios: Seguridad

37

Escenarios: Capacidad de prueba

38

Escenarios: Usabilidad

39

Validar las decisiones de diseño: Arquitectura en evolución

40

Último análisis a PlatziServicios

Modelado y documentación de arquitectura

41

Cómo comunicar la arquitectura: Vistas y Puntos de vista

42

Documentación vs implementación

43

Conclusiones del curso

No tienes acceso a esta clase

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

Validar las decisiones de diseño: Arquitectura en evolución

39/43
Recursos

¿Cómo validamos todas estas desiciones de diseño y de arquitectura que estamos tomando?.

La validación es muy compleja y en general depende del contexto en el que estamos trabajando.

ATAM - para analizar las estrategias y desiciones vemos como los objetivos del negocio, los tributos de calidad y los escenarios se combinan con la arquitectura, las estrategias de arquitectura y las desiciones de arquitectura. A partir del entendimiento de los puntos mas sensibles y cuáles son o no son los riesgos.

Aportes 16

Preguntas 1

Ordenar por:

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

Cómo validamos que estas estas decisiones de arquitectura y que este diseño que acabamos de hacer, tiene sentido?.

Dependiendo en el contexto en el que estemos, la validación de una decisión de arquitectura va a ser un proceso que vamos tener que hacer antes de entrar a desarrollo o bien un proceso que va a ser continuo y va a suceder cada vez que iteramos, así es en metodologías tradicionales en donde la decisión de arquitectura es muy importante antes de empezar a desarrollar o en metodologías ágiles en donde vamos estar reevaluando la arquitectura en cada iteración.

Metodología para evaluar la Arquitectura “ATAM” (Trade-offs de Arquitecturas)

Un ejemplo de una Metodología para Evaluar Arquitecturas en momento de diseño es “ATAM”. Este método se llama Método de análisis de “Trade-offs de Arquitectura” o por sus siglas en inglés ATAM.

En este método vemos como, tanto los objetivos de negocio, los atributos de calidad y los escenarios que planteamos para nuestra arquitectura se van a combinar con la arquitectura que definamos sus estrategias y sus decisiones.

Todo esto se va a analizar de tal manera que todos los stakeholders, todas las partes interesadas de esta arquitectura puedan tener una voz y un voto y decidir qué es importante y a que no se le daría importancia.

Este análisis se profundiza y se destila en diferentes decisiones. Ejemplos:

El entender los Trade off de darle importancia a la mantenibilidad por sobre la eficiencia.

Entender los puntos sensibles de tener una traza de auditoría porque podemos tener problemas legales.

El entender cuales de estos no son realmente riesgos. Por ejemplo, quizás al principio no tenemos un riesgo en nuestra disponibilidad ya que todavía no tenemos ningún contrato de nivel de servicio, mientras que hay riesgos que si también los vamos a entender qué van hacer un feedback y van a volver a entrar a este método como decisiones nuevas de arquitectura.

Estos riesgos quizás fueron atendidos con algunos atributos de calidad o quizás no y los encontramos al analizar todas estas decisiones.

Usar este framework implica el hacer un proceso formal de el análisis de la arquitectura y esto implica también que todavía no tenemos todavía el sistema en ejecución entonces todo esto sólo es un ejercicio intelectual y no es todavía medido en el software mismo.

Medición para nuestro Diseño de Software

Si queremos medir qué es lo que pasa en nuestro software, lo más importante que tenemos que hacer es tener una forma de métrica, es decir todas estas decisiones que estamos tomando como vamos a saber si el sistema las está implementando o no y cómo vamos a saber que esa implementación realmente tuvo sentido?

Entonces para cada uno de los atributos de calidad deberíamos encontrar una métrica que tenga sentido en nuestra aplicación, luego tener una prueba automatizada para esa métrica es decir alguna forma de obtener en tiempo real la información de cómo está nuestro sistema con respecto a esa métrica y luego umbrales configurados de tolerancia o de cuán bien o mal estamos respecto a eso.

Por ejemplo en el caso de la disponibilidad si podemos medir a través de un ping o a través de un Health check nuestra disponibilidad, tenemos que tener esa métrica visible y saber cuál es el porcentaje o el umbral que queremos poner para decir que tenemos una disponibilidad acorde a nuestra arquitectura. Si dijéramos que la disponibilidad es del 95% y luego en el período de un mes tenemos más del 5% de sistema fuera de servicio, entonces ese umbral debería disparar una alerta y poder hacernos trabajar nuevamente sobre ese atributo de calidad. Lo mismo podría pasar con la seguridad si tenemos ataques, lo mismo podría pasar con cualquier otro atributo de calidad y es súper importante recordar cómo medirlos para poder accionar sobre ellos

Arquitectura en Evolución

La arquitectura en evolución es un desafío especialmente para las metodologías ágiles ya que en una metodología más tradicional se asume que la arquitectura es lo suficientemente detallada como para funcionar en todo la especificación del desarrollo que se va hacer sin embargo la metodología ágil plantea que la arquitectura se va a ir construyendo, va a emerger del equipo autogestionado.

¿Entonces cómo hacemos para que emerja la arquitectura correcta y a su vez que a medida que el sistema evoluciona la arquitectura, evolucione junto al sistema?

Como vimos en fundamentos de arquitectura es importante incluir la arquitectura en nuestro ciclo, entonces cómo es que la incluimos? Por un lado en el planeamiento del Sprint tenemos que hablar de arquitectura, tenemos que hablar de estas métricas que tenemos, tenemos que ser conscientes de estos umbrales y de cuán bien o mal estamos en todos los atributos de calidad que estamos priorizando.

Luego cuando priorizamos el backlog y decidimos en que vamos a trabajar vamos a priorizar todas esas áreas de arquitectura, en donde encontramos que deberíamos trabajar nuevamente, esto va a requerir esfuerzo para implementarlo.

Una vez que se despliegue esta nueva implementación, vamos a través de retrospectivas dondé fueron los puntos en donde no pudimos trabajar correctamente, es decir donde tenemos todavía problemas en la mantenibilidad o tenemos problemas de seguridad que todavía no podemos cubrir o detectamos algún problema en nuestra eficiencia de ejecución qué tenemos que volver a priorizar.

Este feedback se da no solamente por encontrar nosotros proactivamente problemas, sino de nuevo con métricas y con alertas programadas en el sistema.

Los test automatizados también pueden ser buenas alertas incorporarlas en nuestro pipeline de despliegue para saber si alguna de estas métricas no sólamente en ejecución sino métricas del código mismo están siendo comprometidas y luego este feedback se cierra cuando volvemos a planear el sprint y reevaluamos nuestras decisiones de arquitectura .

Así Cada vez que avanzamos encontramos los puntos en donde nuestra nuestra arquitectura ya no está cumpliendo con las expectativas que teníamos y volvemos a pensar qué es lo que hay que hacer para mejorarla.

Validar decisiones.
Dependiendo el contexto, la validación de arquitectura, es un proceso que tenemos que hacer antes de entrar en desarrollo o bien como un proceso continuo cada vez que desarrollamos.
En metodologías tradicionales, el diseño de la arquitectura es importante antes de empezar a desarrollar
En metodologías ágiles se revalúa la arquitectura en cada iteración.

Método ATAM (Método de análisis de Trade-off) ->
Los objetivos de negocio, atributos de calidad y los escenarios planteados se combinan con la arquitectura que definamos, sus estrategias y decisiones. Se analizan para que las partes interesadas tengan voz y voto y decidir sobre la misma

Sprint Sprint es el nombre que va a recibir cada uno de los ciclos o iteraciones que vamos a tener dentro de dentro de un proyecto Scrum.

Nos van a permitir tener un ritmo de trabajo con un tiempo prefijado, siendo la duración habitual de un Sprint unas cuatro semanas, aunque lo que la metodología dice es que debería estar entre dos semanas y un máximo de dos meses.

En cada Sprint o cada ciclo de trabajo lo que vamos a conseguir es lo que se denomina un entregable o incremento del producto, que aporte valor al cliente.

La idea es que cuando tenemos un proyecto bastante largo, por ejemplo un proyecto de 12 meses, vamos a poder dividir ese proyecto en doce Sprints de un mes cada uno. En cada uno de esos Sprints vamos a ir consiguiendo un producto, que siempre, y esto es muy importante, sea un producto que esté funcionando.

Backlog El Backlog es una lista ordenada de todo el trabajo pendiente.

Dependiendo del método ágil utilizado, los elementos incluidos en el Backlog se denominan ítems, historias de usuario, unidades de trabajo, etc.

Método de análisis de arquitectura: ATAM (Método de análisis de trade): sirve para evaluar las desiciones de arquitectura en momento de diseño. Aquí se combinan los objetivos de negocios, los atributos de calidad y los escenarios, con el fin de poder evaluar entre todas las partes (stakeholders ):

  • Cuales son los riesgos
  • Poder definir que atributos de calidad son más prioritarios
  • Que estrategía de arquitectura aplica mejor

La arquitectura en evolución es un desafío especialmente para las metodologías ágiles ya que en una metodología más tradicional se asume que la arquitectura es lo suficientemente detallada como para funcionar en todo la especificación del desarrollo que se va hacer sin embargo la metodología ágil plantea que la arquitectura se va a ir construyendo, va a emerger del equipo autogestionado.

Para cada uno de nuestros atributos de calidad debemos tener una métrica que haga sentido.

Metodología ATAM

Medir la arquitectura del software

Arquitectura en evolución

Decisiones de diseño de arquitectura con metodologías ágiles

Un ejemplo de una Metodología para Evaluar Arquitecturas en momento de diseño es “ATAM”. Este método se llama Método de análisis de “Trade-offs de Arquitectura” o por sus siglas en inglés ATAM.
En este método vemos como, tanto los objetivos de negocio, los atributos de calidad y los escenarios que planteamos para nuestra arquitectura se van a combinar con la arquitectura que definamos sus estrategias y sus decisiones.
Todo esto se va a analizar de tal manera que todos los stakeholders, todas las partes interesadas de esta arquitectura puedan tener una voz y un voto y decidir qué es importante y a que no se le daría importancia.

)

En la mayoría de las clases, se resalta la ventaja de tener test automatizados. Automatizar es el futuro 😄

que es más conveniente para un aplicativo decidir antes la arquitectura o en el camino re evaluarla.