Introducción a la arquitectura de software

El lunes pasado empezamos a meternos en temas técnicos, más precisamente en cuestiones de diseño de alto nivel, cuestiones comunmente llamadas de arquitectura. A diferencia de la mayoría de la bibliografía decidí saltar las definiciones y presentar el tema a partir de una problemática concreta siguiendo algunas ideas de Mike Cohn y Less Bass.

En clases anteriores habíamos trabajado sobre modelado de negocio, identificación de user stories y especificaciones en forma de features (bdd), para esto trabajamos con un material que yo mismo preparé hace un par de años para un workshop que dicté en un Agile Open.

Cuando realizamos este workshop en clase habíamos debatido sobre algunas user stories que no seguian el criterio INVEST, cosas del estilo “Como responsable de soporte del sistema quiero que el acceso a la base de datos se haga utilizando el componente XYZXYZ” o “Como responsable máximo de la aplicación quiero que la misma esté disponible 99.999% del tiempo“. En su momento clasificamos estas stories como system stories (acorde a la propuesta de Mike Cohn). La particularidad de las system stories es que resultan transversales a todo el sistema. Una forma en que me gusta caraterizar estos distintos tipos de stories es diciendo:

  • Las user stories describen lo que el sistema debe HACER, o mejor dicho lo que deben permitir hacer al usuario.
  • Las system stories describen lo que el sistema debe SER, o sea, describen propiedades del sistema.

Estas propiedades del sistema son inherentemente transversales a las user stories. En una época eran llamadas requerimientos no funcionales y luego fueron renombradas como atributos de calidad que es el nombre técnico con el que se las referencia en la actualidad. En alguna bibliografía recuerdo haberlas visto caraterizadas como *ilities, en referencia al sufijo que suelen tener: scalability, availability, security, portability, interoperability, testeability, etc, etc.

A partir del análisis de estos atributos de calidad en el caso particular de la aplicación en cuestión, es que uno determina ciertas tácticas para cumplir con ellos. En un paso posterior buscaremos un estilo de diseño que nos ayichude implementar las tácticas elegidas.

Veamos un ejemplo concreto. Trabajando en conjunto con nuestro product owner identificamos una system story que hace referencia a cierta disponiblidad de la aplicación. Para intentar asegurar la disponiblidad deberiamos en primer lugar utilizar alguna táctica para ser capaz de detectar fallas en la aplicación que puedan llegar a interrumpir el servicio (fault detection). Al mismo tiempo deberiamos contar con alguna táctica que determine como accionar en caso de detectar que el servicio ha sido interrumpido, o está por ser interrumpido (fault recovery). Complementariamente podriamos utilizar alguna táctica para intentar evitar las fallas (fault prevention).
Algunas tácticas posibles para encarar estas tres cuestiones son:

  • Fault detection: ping/echo y heartbeat
  • Fault recovery: voting, reduncancy y shadow operation
  • Fault prevention: removal from service, transaction y process monitor.

(no traduje estas estrategias para facilitar la búsqueda en caso que alguien pretenda ahondar en el tema)

Finalmente una vez elegidas las tácticas concretas, se elige un estilo de arquitectura de que nos permita implementarlas.

Todo este proceso aqui descripto forma parte de lo que denominamos “Definición de arquitectura”.

Continuará…

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s