Patrones y Tácticas Arquitecturales

Un patrón arquitectural

• Es un paquete de decisiones de diseño que es encontrado repetidamente en la práctica.
• tiene propiedades conocidas que permiten reusarlo, y
• describe una clase de arquitecturas

Por que los patrones son (por definición) encontrados repetidamente en la práctica, uno no los inventa; uno los descubre.

Las tácticas son más simples que los patrones. Las tácticas tipicamente usan solo una simple estructura o mecanismo computacional, y están destinados a significar una simple fuerza arquitectónica. Por esta razón se les da un control más preciso a un arquitecto cuando hace decisiones de diseño de patrones, que tipicamente combina múltiples decisiones de diseño en un paquete. Las tácticas son los "bloques de construcción" de diseño a partir del cual los patrones arquitecturales son creados. Las tácticas son átomos y los patrones son moléculas. 

Un patrón arquitectural establece una relación entre ellos:

• Un contexto. Una recurrente, situación común en el mundo que da a plantear un problema.
• Un problema. El problema, apropiadamente generalizado, que surge en el contexto dado.
• Una solución. Una resolución arquitectural exitosa a el problema.

Sistemas complejos exhiben múltiples patrones de una sola vez.

Los patrones pueden ser categorizados por el tipo de elementos dominante que muestran. patrones de módulos, muestran módulos. patrones de conectores-componentes muestran componentes y conectores. y los patrones de asignación muestran una combinación de elementos de software (módulos, componentes, conectores ) y elementos que no son de software. Los patrones más publicados son los patrones C&C, pero hay patrones de módulos y de asignación también. 

Un patrón es descrito como una solución a una clase de problemas en un contexto general. Cuando un patrón es elegido y aplicado, el contexto de esta aplicación se vuelve muy especifico. Un patrón documentado por lo tanto es poco especifico con respecto a la aplicación de una situación especifica. Podemos hacer un patrón más especifico a nuestro problema añadiéndole tácticas. Aplicando tácticas sucesivas es como pasar a través de un espacio de juego, y es un poco como el ajedrez: las consecuencias de el siguiente movimiento son importantes y observas varios movimientos por adelantado es útil.

Otros Atributos de Calidad Capitulo 12

Variabilidad

La variabilidad es una forma especial de modificabilidad. Se refiere a la habilidad de un sistema y sus artefactos tales como requerimientos, planes de test y especificación de configuración de soportar la producción de un conjunto de variantes que difieran entre si planeado de antemano.

Portabilidad

Es un caso especial de modificabilidad. La portabilidad se refiere a la facilidad con que un Software que fue construido para correr en una plataforma puede ser cambiada a correr en una plataforma diferente. La portabilidad se logran minimizando las dependencias con la plataforma en el programa, aislando las dependencias a ubicaciones bien definidas, y escribiendo el programa para que corra sobre una "máquina virtual" (como lo es Java Virtual Machine).

Desarrollo distribuido

La capacidad del desarrollo distribuido es la calidad del diseño para soportar el desarrollo de software distribuido. Muchos sistemas en estos días son desarrollados por equipos distribuidos globalmente. Uno de los problemas que debe ser superado con equipos distribuidos es coordinar sus actividades.

Escalabilidad

Dos tipos de escalabilidad son escalabilidad horizontal y escalabilidad vertical. La escalabilidad horizontal (scaling out) s refiere a la agregación de más recursos a unidades lógicas, como ser agregar otro server a un cluster de servidores. La escalabilidad vertical (scaling up) se refiere a la agregación de más recursos a una unidad física, como sería agregar más memoria a una computadora. En ambientes Cloud la escalabilidad horizontal es llamada elasticidad. Elasticidad es la propiedad que permite a los clientes agregar o remover maquinas virtuales a un pool de recursos.

Capacidad de despliegue

Capacidad de despliegue (deployability) se refiere a como un ejecutable llegar a la plataforma del host y como esta es subsecuentemente invocada. Algunos de los inconvenientes involucgrados en el despliege de software son: Como hacer para llegar al host (push, donde las actualizaciones son enviadas a los usuarios sin ser pedidos, o pull, donde los usuarios deben explicitamente pedir las actualizaciones)? Como este es integrado al sistema existente? Puede esto realizarse cuando el sistema existente está en ejecución?

Movilidad

Movilidad aborda el problema de movimiento y prestaciones de una plataforma (ej, tamaño, tipo de pantalla, tipo de dispositivos de entrada, disponibilidad, volumen de ancho de banda, y vida de la batería). Los problemas en movilidad incluyen administración de la batería, reconexión después de un periodo de desconexión, y el número de diferentes interfaces de usuario necesarias para soportar múltiples plataformas.

Capacidad de Monitoreo

(Monitorability) trata de la habilidad del equipo de operaciones para monitorear el sistema mientras se está ejecutando. Cosas como longitudes de cola, tiempo promedio de procesamiento de transacciones, y la salud de varios componentes deberían ser visibles al equipo de operaciones de manera que puedan tomarse las acciones correctivas en caso de problemas potenciales.

Seguridad

La seguridad del software es acerca de la habilidad del software para evitar entrar en estados que causen o provoquen daños, lesiones, o perdida de la vida a los actores en el ambiente del software, y a recuperar o limitar el daño cuando lo hace entrar en un mal estado. Otro manera de decir esto es que la seguridad tiene que ver con la prevención de y recuperación de fallas peligrosas.
La seguridad no es lo mismo que confiabilidad. Un sistema puede ser confiable (consistente con sus especificaciones) pero todavía inseguro (por ejemplo, cuando la especificación ignora condiciones que dan lugar a una acción insegura)

Testeabilidad

*Pido licencia para traducir Testable a Testeable

Asegurar que un sistema sea fácilmente testeable tiene dos beneficios en términos del costo de testeo y en la confiabilidad del sistema.  Un vehículo a menudo usado para ejecutar las pruebas es un framework de pruebas automatizado. Este es un programa que encapsula los recursos para la prueba como los casos de prueba y la infraestructura de prueba de modo que sea fácil reaplicar las pruebas a través de las iteraciones y que sea fácil aplicar la infraestructura de prueba a los nuevos incrementos del sistema. Otro manera es la creación de casos de prueba antes del desarrollo de un componente, de modo que los desarrolladores sepan que pruebas sus componentes deben pasar.

Controlar y observar el estado del sistema son dos clases importantes de tacticas de testeabilidad. Proporcinar la habilidad de hacer inyección de fallas, registrar el estado del sistema en las partes clave, aislar el sistema del ambiente, y abstraer varios recursos son todas tácticas diferentes para soportar el control y observación de un sistema y sus componentes.

Los sistemas complejos son difíciles de probar por el gran espacio de estado en que sus ejecución tiene lugar, y por el gran número de conexiones entre elementos del sistema. Consecuentemente, mantener el sistema simple es otra clase principal de táctica que soporta la testeabilidad.

Seguridad Capitulo 9

El ataque contra un sistema puede ser caracterizado como un ataque contra la confidencialidad, integridad o disponibilidad de un sistema o sus datos.

La confidencialidad es la manutención de los datos lejos de aquellos que no deberían tener acceso mientras se concede el acceso a quienes si deberían tenerlo.

La integridad significa que no existen modificaciones no autorizadas o eliminación de los datos.

Y disponibilidad significa que el sistema está accesible a aquellos que tienen que usarlo.

El énfasis en la distinción de varias clases de actores en la caracterización lleva a muchas de las tácticas usadas a lograr seguridad.  Identificando, y autorizando actores estás tácticas intentan determinar que usuarios o sistemas tienen derecho a usarlo o que tipo de acceso tienen a un sistema.

Hay una suposición de que no hay táctica de seguridad a prueba de todo y que los sistemas se verán comprometidos. Por lo tanto, las tácticas existen para detectar un ataque, limitar la propagación de cualquier ataque, y para reaccionar y recuperarse de un ataque.

La recuperación de un ataque involucra muchas de las mismas tácticas como las de disponibilidad y, en general, involucra devolver el sistema a un estado consistente antes de cualquier ataque.

Interoperabilidad Capitulo 6

La interoperabilidad refiere a la habilidad de dos o más sistemas de intercambiar información útil.

Interoperabilidad sintáctica
Significa que los sistemas tienen la habilidad de intercambiar datos.

Interoperabilidad semántica
Significa que además interpreta correctamente esos datos que han sido intercambiados.

Estos sistema debe ser construidos con la intención de intercambiar información o deben proveer un servicio general sin conocer los detalles del sistema que va utilizar sus servicios.

Por que los sistemas buscarían interoperar?

• Tu sistema provee un servicio que va a ser usado por una cantidad de sistemas desconocidos. Estos sistemas necesitan interoperar con tu sistema a pesar de que no sepas nada sobre ellos. Un ejemplo es el servicio de Mapas de google (GoogleMaps).
• Estás construyendo capacidades de un sistema existente. Por ejemplo, uno de los sistemas es responsable por el monitoreo de su ambiente, otro es responsable para el procesamiento de los datos en crudo, un tercero es responsable de la interpretación de los datos, y finalmente uno es responsable de producir y distribuir la representación de lo que fue sensado. Un ejemplo es un sistema de monitoreo del tráfico donde la entrada llega de vehiculos individuales, el dato crudo es procesado en unidades de medida comunes, es interpretado y combinado y la información de congestión del tráfico es trasmitida.

Estos ejemplo nos muestra dos aspectos importantes de la interoperabilidad.

1. Discovery. El consumidor de un servicio debe descubrir (posiblemente en tiempo de ejecución o antes) la ubicación, identidad. y la interfaz del servicio.
2. Manejo de la respuesta: Hay tres posibilidades distintas:
   * El servicio reporta al solicitante con una respuesta.
   * El servicio envia su respuesta a otro sistema.
   * El servicio transmite su respuesta a todos los interesados.

Escenario General de la Interoperabilidad

• Origen del estimulo. Un sistema que inicia el pedido.
• Estimulo: Un pedido de intercambio de información entre sistemas.
• Artefacto. El sistema que desea interoperar.
• Ambiente. El sistema que desea interperar está descubriendo en tiempo de ejecución o lo conoce de antemano.
• Respuesta. El pedido para interoperar resulta en el intercambio de información. La información es comprendida por el receptor sintactica y semanticamente. Alternativamente, el pedido es rechazado y las entidades apropiadas son notificadas. En cualquiera de los casos, el pedido debe ser registrado.
• Medida de respuesta. El porcentaje de intercambio de información correctamente procesada o el porcentaje de intercambio de información correctamente rechazada.

SOAP vs Rest [0] dos formas distintas de interoperabilidad en el ambiente del desarrollo Web.

Como siempre cabe aclarar que estos Post son parte o resumen del libro Software Architecture In Practice Tercera Edición [1]

[0] http://stackoverflow.com/a/8983122

[1] http://www.amazon.com/Software-Architecture-Practice-Edition-Engineering/dp/0321815734

Tácticas de disponibilidad - Recuperación de fallas - Capitulo 5

Las tacticas de recuperación de fallas son refinadas en tácticas de preparación y reparación y tácticas de reintroducción.

Las tácticas de preparación y reparación están basadas en una variedad de combinaciones de reintentos computacionales o introducción de redundancia. Estos incluyen los siguientes.

Redundancia Activa (Hot Spare). Esta refiera a una configuración donde todo los nodos (activos o redundantes extras ) en un grupo de protección [0] reciben y procesan entradas identicas en paralelo, permitiendo la redundancia extra al mantener un estado sincronico con los nodos activos. Por que el redundante de respuesto posee un estado identica a el procesador activo, este puede asumir el rol de activo ante una falla en cuestión de milisegundos.

Redundancia pasiva (warm spare) Esto refiere a una configuración donde solo los miembros activos del grupo de protección procesan el trafico de entrada. una de sus funciones es la de proveer a los respuestos redundantes de las actualizaciones de estado periodicas. Por que el estado mantenido por los servicios redundantes está menos emparejado que el de los nodos activos en el grupo de protección.

Spare (cold spare) Cold Sparing refiera a una configuración donde el servicio redundante de un grupo de protección se mantiene fuera de servicio hasta que un intercambio por error (fail-over) ocurr, momento en el que un procedimiento de prendido y reinicio es iniciado en el servicio redundante antes de ser puesto en servicio.

Manejo de excepciones Una vez que una excepción ha sido detectada, el sistema deberia manejarla de algún modo. La cosa más sencilla, es dejar caer el sistema, pero por supuesto que es una idea terrible desde el punto de vista de la disponibilidad, usabilidad, capacidad de prueba, etc. El mecanismo utilizado para el manejo de la excepción depende largamente del ambiente de programación empleado, desde una simple función que devuelve un código de error a el uso de clases de excepción que contienen información de ayuda en relación a la falla, tal como el nombre, el origen y la causa que lanza la excepción.

Rollback Esta táctica permite al sistema revertir a un estado previo que estaba funcionando correctamente. después de la detección de una falla. Una vez que un buen estado es alcanzado, entonces la ejecución puede continuar. Esta táctica es a veces combinada con la táctica de redundancia activo o pasivo por lo que una vez que un rollback ocurre, una versión "en espera" del componente fallado es promovida al estado activo. El rollback depende de la copia de que un buen estado previo (un punto de chequeo) esté disponible del componente que está haciendo rollback.

Actualización de Software, es otra táctica de preparación y reparación que tiene como objetivo lograr una actualización "en servicio" de las imagenes de código executables de una manera que no afecte al servicio. Esto debe ser realizado como una función "parche" o una clase "parche" o una actualización de software "en-servicio" de poco impacto.

Reintento, La táctica de reintento asume que la falla es causada por una falla transitoria y el reintento de la operación debería resolverla. Esta táctica es usada en redes y en granjas de servidores donde las fallas son esperables y comunes.

Ignorar el comportamiento defectuoso esta táctica llama a ignorar los mensajes enviados de un origen particular cuando nosotros determinamos que esos mensajes son espurios.

La táctica de Degradación mantiene las funciones criticas del sistema en la presencia de fallas de componentes, dejando caer las funciones menos criticas. Esto se hace en circunstancias donde un componente falla "bonitamente" (licencia bestialistica del autor del Blog)

Reconfiguración intenta recuperar la falla de un componente reasignando responsabilidades a los recursos que dejaron de funcionar mientras mantiene alguna funcionalidad como sea posible.

[0] Un grupo de protección es un grupo de nodos procesando donde uno o más nodos son "activos", con los nodos restantes  en el grupo de protección sirviendo como un servicio redundante.

Disponibilidad - Capitulo 5

Resumen del Libro

La disponibilidad refiere a la habilidad del sistema de estar disponible para el uso, especialmente luego de que ocurra un error. El error debe ser reconocido (o prevenido) y entonces el sistema debe responder de algún modo. La respuesta deseada dependerá de la criticidad de la aplicación y el tipo de error, que puede ir desde 'ignorarlo' a 'seguir adelante como si no hubiera pasado nada'-

Las tácticas para la disponibilidad son categorizadas dentro de los siguientes:
Detectar errores, recuperarse de errores y prevenirlos. Las tácticas de detección dependen esencialmente, de la detección de signos vitales de varios componentes. Las tácticas de recuperación son alguna combinación de re intentos de una operación o el mantenimiento de datos y procesamiento redundantes. Las tácticas de prevención dependerán tanto de remover elementos del servicio o utilizar mecanismos para limitar el alcance del error.

Todas las tácticas de disponibilidad involucran al modelo de coordinación por que este debe estar al tanto de las fallas que ocurren para generar una respuesta apropiada.

Este es el resumen que el libro ofrece para el Capitulo 5 pero voy a tratar de agregar algo más ya que hay temas que son bastante amplios y el libro tiene un detalle interesante para este cápitulo.

SLA (Service Level Agreement): La disponibilidad prevista por un sistema de computación o servicio de Hosting es frecuentemente expresada como un "Acuerdo de Nivel de Servicio" (Service Level Agreement). Este SLA especifica el nivel de disponibilidad que es garantizado y, usualmente, las penalidades que el sistema de computación o servicio de hosting sufrirán si el SLA es violado.

Como se lee en el capitulo anterior [0] los atributos de calidad son analizados en un Escenario que define varias cuestiones con respecto al contexto. Aquí lo haremos en base a la Disponibilidad.

Origen del estimulo: Interno o externo: personas, hardware, software, infraestructura física, ambiente, etc.
Estimulo: Error, omission, error grave, sincronización incorrecta, respuesta incorrecta.
Artefacto: Procesadores, canales de comunicación, almacenamiento persistente, procesos.
Ambiente: Operación normal, inicio, apagado, modo de reparación, operación degradada, operación en sobrecarga.
Respuesta: Prevenir que la falta se convierta en una falla.
                    Detectar la falla:

• Registrar la falla.
• Notificar a las entidades apropiadas (personas o sistemas)

Recuperarse de la falla:

• Deshabilitar el origen de los eventos que causan la falla.
• Estar temporalmente no disponible mientras se hace la reparación.
• Resolver o enmascarar la falta/falla o contener los daños que esta causa.
• Operar en modo degradado mientras se hace la reparación.

Medida de respuesta: Tiempo o intervalo de tiempo cuando el sistema debe estar disponible.

Porcentaje de disponibilidad (como por ejemplo el SLA de muchos Hostings que es del 99,999%)

Tiempo para detectar la falta.

Tiempo para reparar la falta.

Tiempo o intervalo de tiempo en que el sistema puede estar en modo degradado.

Proporción (99%) o ritmo (arriba de 100 por segundo) de una cierta clase de falla que el sistema previene o maneja sin salir de servicio.

Para seguir profundizando en un Post Posterior :D. Siempre quise decir eso. Se analizarán las tacticas de disponibilidad que son varias y que en el libro están muy bien detalladas. Estás como vimos al principio van a estar categorizadas en Detección, recuperación y prevención de una falla.

[0] http://gonzamartinez.blogspot.com.ar/2013/09/entendiendo-los-atributos-de-calidad_23.html

Entendiendo los Atributos de Calidad Capitulo 4 (2)

En el Post anterior de Atributos de calidad [0] se hablaba sobre el escenario de atributos de calidad y se hablo sobre sus partes en esta sección vamos a detallar cada uno de estos.

Origen del estimulo: Esta es alguna entidad (un humano, un sistema, o cualquier otro actuador) que generó el estimulo.

Estimulo: El estimulo es una condición que requiere una respuesta cuando esta llega al sistema.

Ambiente: El estimulo occurre bajo ciertas condiciones.  El sistema puede ser in una condición de sobrecarga o en condiciones normales, o algún otro estado relevante. Para algunos sistemas, la operación "normal" puede referirse de uno a varios modos. Para este tipos de sistemas, el ambiente debería especificar en que modo el sistema esta ejecutándose.

Artefacto: Algún artefacto es estimulado. Este puede ser una colección de sistemas, todo el sistema o alguna pieza o piezas de este.

Respuesta: La respuesta es la actividad realizada como el resultado de el arribo de el estimulo.

Medida de respuesta: Cuando la  decisiones de diseño respuesta ocurre, esta deberia ser medible en cierto modo para que el requerimiento pueda ser probado.

Según el libro "Software Architecture in Practice" una táctica arquitectural es una decisión de diseño que afecta a la respuesta de un atributo de calidad. Estas son dividas en siete categorias que tratare de resumirles a continuación.

Asignación de responsabilidades: Las decisiones que participan de la asignación de responsabilidades incluyen las siguientes:

• Identificar las responsabilidades importantes, incluyendo las funciones básicas del sistema, infraestructura arquitectonica, y la satisfacción de los atributos de calidad.
• Determinar como estas responsabilidades son asignadas a non-runtime y elementos runtime. (es decir, modulos, componentes y conectores).

Las estrategias para hacer estas decisiones incluyen descomposición funcional, modelado de objetos del mundo real, agrupación basada en los modos principales de operación del sistema o agrupación basada en requerimientos de calidad similares. 

Modelo de Coordinación:  

Los programas trabajan por tener elementos que interactuan entre sí a través de mecanismos diseñados. Estos mecanismos son colectivamente referidos como modelo de coordinación. Estos incluyen:

• Identificar los elementos del sistema que deben coordinarse, o que tienen prohibido coordinarse.
• Determinar las propiedades de la coordinación, tales como la puntualidad, vigencia, completitud, exactitud, y consistencia.
• Seleccionar los mecanismos de comunicación (entre sistemas, entre nuestro sistema y entidades externas, entre elementos de nuestro sistema) que realizan estas propiedades.

En el próximo post tratare de resumir las otras 5 propiedades que todavia faltan. que son Modelo de Datos, Administración de Recursos, Mapeo entre elementos arquitectonicos, decisiones de fusión de tiempo, elección de tecnología.

[0] http://gonzamartinez.blogspot.com/2013/09/entendiendo-los-atributos-de-calidad.html

Los muchos contextos de la Arquitectura de Software Capitulo 3

La arquitectura reside en cuatro contextos deferentes:

1. Técnico. El contexto técnico incluye el logro de los requerimientos de atributos de calidad. También incluye la tecnología actual.
2. El ciclo de vida del proyecto. Independientemente de la metodología de desarrollo de software que utilices, deberías hacer un análisis de rentabilidad para el sistema. comprendiendo los requerimientos de gran importancia en la arquitectura, analizar o evaluar la arquitectura, implementar y probar el sistema basado en la arquitectura, y asegurar que la implementación  se ajusta a la arquitectura.
3. Negocio. El sistema creado desde la arquitectura debe satisfacer los objetivos de negocio de una amplia variedad de las partes interesadas, cada uno de los cuales tiene diferentes expectativas para el sistema. La arquitectura es también influenciada por e influye la estructura de desarrollo de la organización.
4. Profesional. Usted debe tener ciertas habilidades y conocimientos para ser un arquitecto, y hay ciertas obligaciones que debe realizar como un arquitecto. Estas son influenciadas no solo por el curso y lectura sino también por tus experiencias.

Los StakeHolders o Partes Interesadas.

Una arquitectura tiene algunas influencias que conducen a su creación, y su existencia tiene un impacto en el arquitecto, la organización y potencialmente, la industria. Nosotros llamaremos a estos ciclo el Ciclo de Influencia de la Arquitectura (Arquitecture Influence Cycle).

Gracias por leer mi traducción que vengo haciendo de los resumenes de cada cápitulo del Libro Software Architecture in Practice. Espero que sepan disculpar algunas debilidades de mi traducción (y/o del Google Translate en varias ocasiones) que no es la mejor pero mi objetivo es dejar algún tipo de aporte de un libro que me parece interesante. 

En el Proximo Post arranca la Parte 2 con los Atributos de Calidad con el Capitulo 4 Entendiendo los Atributos de Calidad.

Por que la arquitectura de software es importante Capitulo 2

La arquitectura de software es importante por una amplia variedad de razones técnicas y no técnicas.
Nuestra lista incluye las siguientes:

1. Una arquitectura inhibirá o habilitará en un sistema el manejo de los atributos de calidad.
2. Las decisiones tomadas en una arquitectura te permitirá pensar y administrar los cambios mientras el sistema evolucione.
3. El análisis de una arquitectura permite predecir tempranamente las cualidades de un sistema.
4. Una arquitectura documentada mejora la comunicación entre las partes interesadas.
5. La arquitectura es el portador de las más tempranas y por lo tanto más fundamentales decisiones de diseño más-difíciles-de-cambiar.
6. Una arquitectura define un conjunto de restricciones y su posterior implementación.
7. La arquitectura dicta la estructura de una organización, o vice versa.
8. Una arquitectura puede proveer la base del prototipado evolutivo. [0]
9. Una arquitectura es el artefacto clave que permite al arquitecto y al administrador del proyecto razonar acerca del costo y de las estimaciones de tiempo.
10. Una arquitectura puede ser creada como un modelo transferible, reusable que forma el corazón de una linea de producto.
11. El desarrollo basado-en-arquitectura enfoca la atención en el ensamblado de componentes, más que en la simple creación.
12. Una arquitectura canaliza la creatividad de los desarrolladores, reduciendo la complejidad  y diseño del sistema.
13. Una arquitectura puede ser la base para el entrenamiento de los nuevos miembros del equipo.

[0] Cabe aclarar que en este sentido se dice que la arquitectura puede ser analizada y prototipada como un sistema esquelético. Que como tal puede ser la base para la creación de otros sistemas similares. 

Parte 1 Capitulo 2

Software Architecture in Practice.

La proxima en Capitulo 3 es Los contextos de la arquitectura de software.

Capitulo que me resulto pesado de leer o que no lei con mucha atención así que me ayudará a repasar.

Arquitectura de Software en Práctica Cápitulo 1

No estoy estudiando no estoy yendo a la facultad entonces me animé despues de leer "Dive Into Python" completo, que fue el primer libro completo que leé en inglés. Me animé y me traje del laburo un libro recién traído de USA que se llama "Software Architecture in Practice". Tratare de hacer un resumen pobre dado que no soy un experto ni en arquitectura de software ni en inglés pero con el fin de afianzar mis conocimientos y brindarles una pequeña traducción.

Introducción.

Que es la arquitectura de software?
La arquitectura de un sistema es un conjunto de estructuras necesarias a razonar acerca de un sistema, que comprende elementos de software, las relaciones ellos y las propiedades de ambos.

Que es una estructura y una vista.
Una estructura es un conjunto de elementos y las relaciones entre ellos.
La vista es una representación de la estructura.

Los neurólogos, ortopedistas,  hematólogos y los dermatologos tienen diferentes vistas de la estructura del cuerpo humano. Los oftalmológos, cardiologos y podologos tienen que ver con diferentes aspectos de todo un comportamiento. Aunque estas vistas son fotos y tienen propiedades diferentes todas están intrinsecamente relacionadas, juntas describen la arquitectura del cuerpo humano.

Hay tres categorias de estructuras:
Estructuras Modulo muestra como un sistema es estructurado como un conjunto de código o unidades de datos que tienen que ser construidos o adquiridos.

Estructuras componente-y-conector muestra como un sistema es estructurado como un conjunto de elementos que tienen un comportamiento en tiempo de ejecución (componentes) e interacciones (conectores).

Estructuras de asignación muestra como el sistema se relacionará a las estructuras que no son de software en su entorno (tal como CPUs, sistema de archivos, redes, equipos de desarrollo.)

Ejemplo:
Es un pequeño sistema cliente-servidor
Un sistema donde la vista de módulos es una vista de descomposición (submodulos o subsistemas de un sistema mayor). Y como en tiempo de ejecución van a ser 10 las máquinas clientes accediendo al servidor entonces podemos ver que van a ser 2 módulos (cliente y servidor) y 11 componentes (10 clientes, 1 servidor ) y 10 conectores que son las relaciones entre los componentes que se observan en la vista Cliente-Servidor.

Esto es todo por esta vez. Me sirvió para repasar un poco lo que había leído y para practicar mi traducción :S del inglés espero que les haya servido aunque sea poco.

El próximo capitulo será Por que es importante la arquitectura de software.

Resumen y ejemplos basados en
Software Architecture in Practice Third Edition. Len Bass, Paul Clements, Rick KazMan
http://amzn.to/15RIscN