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

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Escenarios: Mantenibilidad

33/43
Recursos

Aportes 11

Preguntas 0

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

Mantenibilidad
En este caso el estimulo es un pedido de cambio (llega un requerimiento y tenemos que cambiar el sistema).

Familias de t谩cticas:
1.- Confinar modificaciones. Las t谩cticas van a intentar trabajar sobre nuestros m贸dulos para que cada cambio que nos pidan est茅 confinado a s贸lo un m贸dulo. Cuando logramos esto logramos que las dependencias entre m贸dulos sean m谩s ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia sem谩ntica. Habla de la relaci贸n entre las responsabilidades de los m贸dulos. Hablamos de acoplamiento y cohesi贸n. Si logramos encontrar la cohesi贸n en un m贸dulo entonces vamos a poder hacer que ese m贸dulo sea m谩s mantenible. De lo contrario es posible que ese m贸dulo cambie por diferentes razones.

Abstraer servicios comunes. Cuando encontramos que la aplicaci贸n tiene servicios m谩s gen茅ricos de no necesario podemos abstraerlos a un punto com煤n y que las dependencias vayan de los m贸dulos cohesivos a un servicio o modulo externo.

b) Generalizar. Al generalizar un m贸dulo podemos separar lo espec铆fico de lo gen茅rico.
c) Limitar opciones disponibles. Limitar el rango de modificaci贸n nos ayuda a que sea m谩s mantenible.
d) Anticipar cambios. Prepararnos para alg煤n cambio que nosotros mismo sepamos que se deber谩 de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de dise帽o suelen estar orientados a esto (Patr贸n estrategia).

2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generar铆a problemas en otros m贸dulos o dependencias.

3.- Diferir enlace. Como podemos hacer para que un cambio en el c贸digo no requiera desplegar toda la aplicaci贸n.

Demasiada teor铆a hasta el momento a mi punto de vista, hubiera estado bien tener m谩s ejemplos reales o en una pizarra para explicar de forma m谩s din谩mica.

Escenario: Mantenibilidad

Estimulo: Pedido de cambio / Nuevo requerimiento
T谩cticas para que la respuesta sea que se pudo hacer el cambio, probarlo y desplegarlo
Familias de t谩cticas

  • Confinar modificaciones
    • Coherencia sem谩ntica
      ** Abstraer servicios comunes
    • Generalizar
    • Limitar las opciones disponibles
    • Anticipar los cambios
  • Prevenir efectos domino
  • Diferir enlace

Para extender un poco el tema de Acomplamiento / Cohesi贸n:

Escenarios: Mantenibilidad

El estimulo es un pedido de cambio. dentro de la mantenibilidad hay tres familias de t谩cticas:

  • Confinar Modificaciones: Van a trabajar sobre nuestros m贸dulos para que cada cambio solo se limite a un modulo. esto hace que las dependencias entre m贸dulos sean m谩s ligeras.
    T谩cticas:
  1. Coherencia Sem谩ntica.
    1.1 Abstraer servicios comunes
  2. Limitar Opciones
  3. Anticipar Cambios
  • Prevenir efecto domino: Trabaja estrictamente con las dependencias, se trata de conocer cuando puede detectar cuando alg煤n cambio generar铆a problemas en uno o varios m贸dulos o dependencias.
  • Diferir enlace: Se trata de como hacer que alg煤n cambio en el c贸digo no requiera de desplegar toda la aplicaci贸n entera.

Apuntes:

Mantenibilidad

Confinar modificaciones. Las t谩cticas van a intentar trabajar sobre nuestros m贸dulos para que cada cambio que nos pidan est茅 confinado a s贸lo un m贸dulo. Cuando logramos esto logramos que las dependencias entre m贸dulos sean m谩s ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
鈥 Coherencia sem谩ntica. Habla de la relaci贸n entre las responsabilidades de los m贸dulos. Hablamos de acoplamiento y cohesi贸n. Si logramos encontrar la cohesi贸n en un m贸dulo entonces vamos a poder hacer que ese m贸dulo sea m谩s mantenible. De lo contrario es posible que ese m贸dulo cambie por diferentes razones.
o Abstraer servicios comunes.
鈥 Generalizar. Al generalizar un m贸dulo podemos separar lo espec铆fico de lo gen茅rico. 鈥 Limitar opciones disponibles. Limitar el rango de modificaci贸n nos ayuda a que sea m谩s mantenible.
鈥 Anticipar cambios.

Demasiada teor铆a, solo estoy tomando notas porque se que lo puedo necesitar, la informaci贸n tiene valor, lo puedo ver pero creo que podr铆an haber recomendado leer un pdf y tendr铆a el mismo resultado que ver los videos

Ponerle Profesional al curso, y no considerar un estudio exhaustivo fue un error, como se puede observar para mi, cada clase explicada, requiere quiz谩s hasta una hora entera viendo ejemplos y probando punto a punto lo explicado.

Familias de t谩cticas:
1.- Confinar modificaciones. Las t谩cticas van a intentar trabajar sobre nuestros m贸dulos para que cada cambio que nos pidan est茅 confinado a s贸lo un m贸dulo. Cuando logramos esto logramos que las dependencias entre m贸dulos sean m谩s ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia sem谩ntica. Habla de la relaci贸n entre las responsabilidades de los m贸dulos. Hablamos de acoplamiento y cohesi贸n. Si logramos encontrar la cohesi贸n en un m贸dulo entonces vamos a poder hacer que ese m贸dulo sea m谩s mantenible. De lo contrario es posible que ese m贸dulo cambie por diferentes razones.
Abstraer servicios comunes. Cuando encontramos que la aplicaci贸n tiene servicios m谩s gen茅ricos de no necesario podemos abstraerlos a un punto com煤n y que las dependencias vayan de los m贸dulos cohesivos a un servicio o modulo externo.
b) Generalizar. Al generalizar un m贸dulo podemos separar lo espec铆fico de lo gen茅rico.
c) Limitar opciones disponibles. Limitar el rango de modificaci贸n nos ayuda a que sea m谩s mantenible.
d) Anticipar cambios. Prepararnos para alg煤n cambio que nosotros mismo sepamos que se deber谩 de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de dise帽o suelen estar orientados a esto (Patr贸n estrategia).
2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generar铆a problemas en otros m贸dulos o dependencias.
3.- Diferir enlace. Como podemos hacer para que un cambio en el c贸digo no requiera desplegar toda la aplicaci贸n.

馃
Escenario Mantenibilidad
En este caso el estimulo es un pedido de cambio (llega un requerimiento y tenemos que cambiar el sistema).

<h3>Mantenibilidad</h3>
  • Confinar modificaciones: Aunque no necesariamente existe una relaci贸n precisa entre el n煤mero de m贸dulos afectados por un conjunto de cambios y el costo de implementar esos cambios, restringir las modificaciones a un peque帽o conjunto de m贸dulos generalmente reducir谩 el costo. El objetivo de las t谩cticas en este conjunto es asignar responsabilidades a los m贸dulos durante el dise帽o de modo que los cambios anticipados tengan un alcance limitado.
  • Prevenir efectos domin贸: Un efecto domin贸 de una modificaci贸n es la necesidad de realizar cambios en los m贸dulos que no se ven directamente afectados por 茅l. Por ejemplo, si el m贸dulo A se cambia para lograr una modificaci贸n particular, entonces el m贸dulo B se cambia solo debido al cambio al m贸dulo A. B tiene que modificarse porque depende, en cierto sentido, de A.
  • Diferir enlace: Las dos categor铆as t谩cticas que hemos discutido hasta ahora est谩n dise帽adas para minimizar la cantidad de m贸dulos que requieren cambios para implementar modificaciones. Nuestros escenarios de modificabilidad incluyen dos elementos que no se satisfacen al reducir la cantidad de m贸dulos que se van a cambiar: el tiempo de implementaci贸n y permitir que los no desarrolladores realicen cambios. Aplazar el tiempo de enlace es compatible con ambos escenarios a costa de requerir infraestructura adicional para soportar el enlace tard铆o.