# Software Architecture in Practice - Resumen

## ¿De qué nos sirve la Arquitectura de Software?
* Herramienta de comunicación con stakeholders
* Forma iterativa de encontrar la mejor forma de diseñar un sistema en la fase de inicio de un proyecto.
* Referencia para el diseño y limitaciones de un sistema

## Structure
Elementos relacionados que componen a una arquitectura

## View
Una forma de ver la arquitectura

## ¿Cómo elegir una arquitectura?
Se debe tener varias arquitectura distintas, y dependiendo del contexto y las necesidades del sistema elegirse una considerando los atributos de calidad que son necesarias.

## Preguntas para considerar en fase de inicio para una arquitectura
* Will the system run on one processor or be distributed across multiple processors?
* Will the software be layered? If so, how many layers will there be? What will each one do?
* Will components communicate synchronously or asynchronously? Will they interact by transferring control or data or both?
* Will the system depend on specific features of the operating system or hardware?
* Will the information that flows through the system be encrypted or not?
* What operating system will we use?
* What communication protocol will we choose?

## Manual de Arquitectura
El manual de arquitectura debe ser reemplazar a Stack Overflow al momento de tener dudas y problemas con el sistema. Si no hay respuesta en el manual, se debe agregar a ella.

## Atributos de Calidad

Componentes de un atributo de calidad
* Source
* Actor de donde proviene el stimulus. Puede ser una persona, una accion, u otro sistema.
* Stimulus
* Lo que ocasiona el artifact.
* Environment
* En qué estado o ambiente del sistema se provoca.
* Artifact
* El producto que es generado.
* Response
* La salida del artifact en un environment.
* Response Measure
* La forma de medir el atributo de calidad.

### Availability
La disponibilidad que tiene el sistema. Incluye tiempos de mantenimiento, tiempo de recuperación en caso de falla o ataque, y otros factores que pueden hacer que el sistema no esté disponible.


### Interoperability
Capacidad de intercambiar información con otros sistemas por medio de abstracciones.


### Modifiability
Facilidad de hacer cambios sin tener que dedicar mucho tiempo ni esfuerzo y a la vez teniendo una probabilidad muy baja de que estos cambios provocan un defecto.


### Performance
La velocidad en la que el sistema puede procesar las actividades que debe de hacer.


### Security
Prácticas para proteger la información sensible y prevenir ataques que pueden afectar la disponibilidad del sistema.


### Testability
Testability se refiere a la facilidad de encontrar fallas en un sistema. Si existe una falla en el sistema entonces es importante que falle lo más pronto posible.

La clave para testability es tener control y monitoreo.

Para que un sistema sea testeable, debe ser posible controlar las entradas de cada componente y generar una salida sin tener que utilizar una interfaz gráfica o alguna dependencia.


### Usability
Facilidad del usuario para completar alguna tarea y el soporte que este mismo otorga.

Es considerado de los cambios más fáciles de mejorar la calidad de un sistema (desde el punto de vista del usuario).

La mejor forma de perfeccionar este atributo es facilitar la experimentacion con prototipos. Para esto, la mejor forma es diseñar el software para que la interfaz grafica pueda ser cambiada rapidamente. Por lo tanto, usability y modifiability van de la mano.

La usabilidad en ocasiones puede costar Performance. Por ejemplo, en una forma que se valida lo ingresado desde servidor. Lo anterior indica mejor usabilidad, pero menor rendimiento.



### Atributos adicionales
* Variability
* Portability
* Development Distributability
* Scalability
* Horizontal
* Vertical (Elasticity en cloud environments)
* Deployability
* Monitorability
* Safety

### Otras categorias de atributos de calidad

Estas miden la calidad de otras cosas aparte del producto final.

##### Conceptual Integrity of Architecture
Consistencia en el diseño de la arquitectura. Contribuye al entendimiento de la arquitectura y provoca que haya menos errores.

"Less is More"

Debe existir consistencia en toda la arquitectura. Es decir, que una cosa se haga de la misma forma en toda la arquitectura.

##### Quality in Use
* Efectivness
* Medida que indica si el sistema esta correcto (el sistema funciona en la manera que el usuario desea)
* Eficiency
* Tiempo y esfuerzo para desarollar el sistema.
* Ejemplo: Que tan facil es compilar despues de un cambio.
* Freedom from risk
* El grado en el que el producto o el sistema afecta el estado economico, la vida humana, o el ambiente.

##### Marketability
La percepcion que se tiene de una arquitectura independientemente de otros atributos de calidad.
Ejemplo: La tendencia de sistemas basados en la nube.

## Architectural Tactics and Patterns

Las tacticas o atributos de calidad mencionados anteriorment son los que componen un patron de arquitectura.

Un patron de arquitectura establece:
* Contexto:
* Situacion comun que provoca el problema
* Problema:
* El problema que surge del contexto. Describe normalmente los atributos calidad que deben cumplirse.
* Solucion:
* Solucion apropiadamente abstracta. Define las estructuras de arquitectura que resuelven el problema. Describe las responsabilidades de los elementos y la relacion entre ellas (usando un Module Structure) o describe el comportamiento en runtime (utilizando Component-and-Connector Structure o Allocation Structure)

### Module Patterns
#### Layered Pattern
##### Contexto
Todos los sistemas complejos necesitan desarollar y evolucionar porciones del sistema independientemente. Por lo anterior, los desarolladores de un sistema necesitan una documentacion clara sobre la separacion del sistema para que los modulos del sistema puedan ser desarolladores y mantenidos independientemente.

##### Problema
El software debe estar segmentado de cierta forma para que los modulos puedan ser desarollados de forma separada con la mas minima interaccion entre ellos soportando asi portabillity, modifiablity, y reuse.

##### Solucion
Para lograr esto, el software es dividio en "capas". Cada capa agrupa un set de modulos relacionados. La relacion entre las capas debe ser unidireccional. Normalmente una capa solo puede interactuar con capas inferiores a su nivel. Cada capa debe ser expuesta utilizando una interfaz publica.


### Component-and-Connector Patterns
#### Broker Pattern

##### Contexto
Muchos sistemas estan hechos con una collecion de servicios distribuidos en muchos servidores. Implementar estos sistemas es complicado ya que se debe verificar como estos sistemas operan entre si.

##### Problema
Como estructurar software distribuido para que usuarios de un servicio no tengan que conocer sobre la naturaleza y la ubicacion de los proveedores del servicio haciendo asi que sea mas facil cambiar dinamicamente la union entre usuarios y proveedores?

##### Solucion
Broker pattern separa los usuarios de los servicios de los proveedores de los servicios al insertar un intermediario llamado "broker". Cuando el usuario necesita un servicio, esta peticion le llega al broker con una interfaz de servicio. Posteriormente, el broker envia la peticion de servicio del usuario a un servidor. La respuesta sigue el mismo proceso de una manera vice versa. De esta forma, el usuario o cliente desconoce la identidad, ubicacion, y caracteristicas del servidor. Si el servidor llegara a dejar de funcionar, el broker podria dinamicamente buscar otro servidor. La desventaja de los brokers es que agregan complejidad y aumenta la latencia.


#### Model-View-Controller Pattern
##### Contexto
La interfaz es la porcion mas modificada en una aplicacion interactiva. Por esta razon, es importante separar el codigo de la interfaz grafica del resto del sistema. Por otro lado, los usuarios normalmente desean ver informacion o datos de modelos en distintas formas o perpsectivas.

##### Problema
Separar la funcionalidad de la interfaz grafica.
Crear, mantener, y coordinar varias vistas distintas aun cuando los datos de la aplicacion cambien.

##### Solucion
El patron model-view-controller (MVC) separa la funcionalidad de un software en tres distintos componentes

* Model
* Contiene los datos de la aplicacion
* View
* Despliega una porcion de los datos e interactua con el usuario
* Controller
* Intermediario entre el modelo y la vista que maneja las notificaciones (eventos o callbacks) de un cambio de estado.


#### Pipe-and-Filter Pattern
##### Contexto
Muchos sistemas requieren transformar flujos de informaciones desde input hasta ouput. Muchos tipos de transformaciones se repiten en pracitca asi que es recomendable de crear partes independientes y reutilizables.

##### Problema
Estos sistemas deben ser divididos en componentes reutilizables con mecanismos de interacciones genericas y simples.

##### Solucion
El pipe-and-filter pattern se caracteriza por transformaciones exitosas de flujos de informacion. Los datos llegan a un puerto de un filtro, es transformado, y sale por un puerto del filtro hacia al siguiente.


#### Client-Server Pattern
##### Contexto
Existen recursos compartidos y servicios que varios clientes distribuidos desean acceder.

##### Problema
Al manejar un arreglo de recursos y servicios compartidos, podemos promover modifiability y reutilizacion con servicios comunes/genericos. Deseamos mejorar scalability y availability al centrealizar el control de estos recursos y sericios, mientras distribuimos estos serivcios a traves de varios servidores fisicos.

##### Solucion
Los clientes interactuan haciendo peticiones a los servidores.

El cliente debe saber la identidad del servidor para invocarlo, el es el que siempre inicia la interaccion al invocar los servicios de los servidores.


#### Peer-to-Peer Pattern
##### Contexto
Dispositivos distribuidos con propiedades equitativas deben cooperar y colaborar para proveer un servicio a una comunidad distribuida de usuarios.

##### Problema
Conectar dispositivos distribuidos que tienen las mismas caracteresticas con un protocolo comun para que puedan organizar y compartir sus servicios con alta disponiblidad y escalabilidad.

##### Solucion
En P2P, componentes interactuan directamente y bidireccionalmente como peers. Todo los peers deben ser iguales. Es diferente a la asimetria del patron client-server. Los peers pueden ser agregados o eliminados de una red peer-to-peer sin un cambio drastico. La desventaja de P2P es el manejo de la seguridad, la consistencia de los datos, y la disponibilidad.


#### Service-Oriented Architecture Pattern

#### Publish-Subscribe Pattern

#### Shared Data

### Allocation Patterns
#### Map-Reduce Pattern

##### Contexto
Compañias tienen una necesidad de rapidamente analizar volumenes enormes de datos que generan. Ejemplos incluyen logs de interaciones en una red social, documento masivo de repositorios de datos, y pares de <source, target> web links para un motor de busqueda. Programas para el analisis de estos datos debe ser facil de escribir, correr rapido, y adaptarse a fallas de hardware.

##### Problema
Para varias aplicaciones con muchos datos, organizar la informacion y despues analizar la informacion agrupada es suficiente. El problema que resuelve el map-reduce pattern es realizar un ordenamiento distribuido y paralelo de los datos y proveer una forma sencilla al programador de especificar que tipo de analisis realizar.

##### Solucion
El map-reduce pattern requiere de tres partes:
1. Una infraestuctura especial se encarga de alocar el software a los nodos de hardware en un ambiente masivo paralelo de computacion que maneja el ordenamiento de la informacion necesaria. Puede ser un procesor independiente o un nucleo en un chip multi nucleo.
2. Funcion programada llamada map. Se encarga de filtrar y ordenra la informacion de entrada.
3. Funcion programada llamada reduce. Todo el analisis pesado ocurre aqui.


#### Multi-tier Pattern