Analizando Quiper - Compará precios descuidados

Quiper[0], es una aplicación móvil desarrollada en la empresa donde trabajo, que se llama Quicuo[1].

Su nombre es principalmente una fusión de la palabra Quicuo y Super. Es una aplicación que permite comparar los precios de todo tipo de productos en los supermercados más grandes del país y en principio funciona bastante bien para los que son de Capital y Gran Buenos Aires.

Aplicación Movil
La aplicación móvil está desarollada en HTML, CSS y Javascript. Con una terrible ayuda de PhoneGap [2] para hacerla multi plataforma. Principalmente fue creada para Android[3] pero con muy pocos cambios puede ser y va a ser generada para IPhone muy pronto.

Backend - API
La API de consulta está desarrollada sobre node.js[4], con expressjs[5] como Framework de desarrollo y sequelize[6] como ORM[7] para las consultas a la base de datos.
Todo esto es servido a tráves de pm2[15] como supervisor de procesos en nodejs y con Nginx[16] como WebServer.

Backend - DB, Extracción y Analisis
La extracción que es parte principal del desarrollo está escrita sobre Python[9], en principio se analizó un Scrappeador profesional pero para los primeros intentos nos pareció un poco complejo así que se optó por hacer un Scrapper propio bien amoldado para nuestro propósito. Por consiguiente, se utilizaron diferentes librerías que son bastante típicas en verdad para esto. BeautifulSoup[10] como parseador de las respuestas HTML para extracción de datos. Mechanize[11] como generador de requests dinamicas y crawler de webs, en principio fue generado todo con Mechanize y luego en algunos casos simples se usó requests[12] una librería con una API mucho más elegante. Además para guardar estos datos de forma más programática se uso SQLObject[13] como ORM en esta etapa.

Finalmente el análisis y unión de datos fue escrito en PHP[14] y se usó su conector para MySQL limpio sin ORM.

Servidores
Básicamente los servidores están en Amazon EC2[17] y por el momento son Dos uno como WebServer para los servicios que corren Nodejs. La Api que consume la app móvil y la Web que todavia no se lanzó.
Y otro server que es el más grande y es el de la DB que tiene MySQL y corre periódicamente la extracción y análisis de datos.
Los servidores fueron ambos desplegados con Ansible [18]

Un crisol de tecnologías libres que unidas generan una aplicación que funciona y cumple su objetivo, principalmente participaron de este proyecto Dos Desarrolladores(principalmente uno para Phonegap css html y js y otro para el Analisis de datos con PHP), un ProjectLeader, el CEO de Quicuo y un SysAdmin/Desarrollador Python (este soy yo).

[0] http://www.quiper.com.ar
[1] http://www.quicuo.com.ar
[2] http://phonegap.com/
[3] https://play.google.com/store/apps/details?id=com.quicuo.quiper
[4] http://nodejs.org/
[5] http://expressjs.com/
[6] http://sequelizejs.com/
[7] http://en.wikipedia.org/wiki/Object-relational_mapping
[8] http://www.mysql.com/
[9] https://www.python.org/
[10] http://www.crummy.com/software/BeautifulSoup/
[11] http://wwwsearch.sourceforge.net/mechanize/
[12] http://docs.python-requests.org/en/latest/
[13] http://sqlobject.org/
[14] http://php.net/
[15] https://github.com/Unitech/pm2
[16] http://nginx.org/
[17] http://aws.amazon.com/es/ec2/
[18] http://www.ansible.com/home

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.

OpenStack - Arquitectura

El proyecto OpenStack es una plataforma de computación en la nube de código abierto para todo tipo de nubes, que apunta a ser simple de implementar, masivamente escalable, y rica en caracteristicas.

OpenStack provee una solución de  Infraestructura como Servicio (IaaS) a través de un conjunto de servicios interrelacionados.

Servicios de OpenStack

Servicio: DashBoard
Nombre de proyecto: Horizon
Descripción:  Provee una portal de auto-servicio con interfaz Web para interactuar con los servicios subyacentes de OpenStack, como el lanzamiento de una instancia, la asignación de direcciones IP y la configuración de control de acceso.

Servicio: Compute
Nombre de Proyecto: Nova
Descripción: Administrar el ciclo de vida de las instancias computacionales en el ambiente OpenStack. Responsabilidades incluyen la ejecución de nuevos procesos, la programación y el cierre de máquinas a demanda.

Servicio: Networking
Nombre de proyecto: Neutron
Descripción: Permitir la conectividad de redes como un servicio para otros servicios OpenStack, como son OpenStack Compute. Proveer una API para que los usuarios definan las redes y los acoplamientos en ellos.

Almacenamiento
Servicio: Object Storage
Nombre de proyecto: Swift
Descripción: Almacena y recupera objetos de datos no estructurados arbitrarios via RESTful, una API basada en el protocolo HTTP. Este es altamente tolerante a fallos con su replicación de datos y arquitectura de escalabilidad horizontal. Esta implementación no es como un servidor de archivos con directorios montables.

Servicio: Block Storage
Nombre de proyecto: Cinder
Descripción: Provee un bloque de almacenamiento persistente para correr instancias. Este arquitectura de controlador adaptable facilita la creación y administración de dispositivos de almacenamiento en bloque.

Servicios Compartidos
Servicio: Identity Service
Nombre de proyecto: Keystone
Descripción: Provee una autenticación y servicio de autorización para otros servicios OpenStack. Provee un catalogo de extremos para todos los servicios OpenStack.

Servicio: Image Service
Nombre de proyecto: Glance
Descripción: Almacena y recupera imagenes de disco de máquinas virtuales. OpenStack Compute hace uso de esto durante el aprovisionamiento de las instancias.

Servicio: Telemetry Service
Nombre de proyecto: Ceilometer
Descripción: Monitorea y mide la facturación de la nube OpenStack, evaluación comparativa, escalabilidad, y propósitos estadísticos.

Servicios de alto nivel
Servicio: Orchestration Service
Nombre de proyecto: Heat
Descripción: Organiza múltiples aplicaciones en la nube compuestas por el uso de el formato nativo HOT o el formato de plantilla de AWS CloudFormation, Tanto a través de una API REST OpenStack nátiva y una API de consultas compatibles con CloudFormation.

Arquitectura Conceptual

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.

Rendimiento Capitulo 8

Redimiento o Performance es sobre la administración de los recursos de un sistema frente a tipos particulares de demanda para lograr un comportamiento aceptable en el tiempo. 

El rendimiento puede ser medido en términos de caudal y latencia para sistemas de tiempo real interactivos y embebidos, aunque el caudal es más importante en un sistema interactivo y la latencia es más importante en sistemas embebidos.

Los eventos pueden arribar en patrones predecibles, distribuciones matemáticas o ser inpredecibles.

Eventos de arribo periodico son aquellos que arriban a nuestro sistema en intervalos regulares de tiempo. Por ejemplo un evento podría llegar cada 10 milisegundos. Los eventos de arribo periodico son los más vistos en sistemas de tiempo real.

Arribo Estocastico significa que los eventos llegan de acuerdo a alguna distribución probabilistica.

Eventos de arribo esporadico, es de acuerdo a un patrón que no es ni periodico ni estocástico. Incluso estos, en ciertas circunstancias pueden ser caracterizados. Por ejemplo, podriamos saber que tendrá lugar algo así como 600 eventos en un minuto, o que habrá al menos 200 milisegundos entre el de arribo de dos eventos cualesquiera. (Esto podría describir un sistema en el que los eventos corresponden a tecleos de un usuario).

Escenario general de Rendimiento.

Origen del Estimulo: El estimulo llega ya sea de un origen (posiblemente multiple) externo o un origen interno.
Estimulo:  El estimulo son eventos llegando. El patrón de arribo puede ser periódico, estocástico, o esporádico,  caracterizado por parametros numericos.
Artefacto: El artefacto es el sistema, uno o más de sus componentes.
Ambiente: El sistema puede estar en varios modos operacionales, como ser, normal, emergencia, carga máxima, o sobrecarga.
Respuesta: El sistema debe procesar los eventos que llegan. Estos puede causar un cambio en el ambiente del sistema ( de modo normal a modo de sobrecarga.)
Medida de respuesta: Son el tiempo que toma el procesamiento de un evento que llega al sistema (latencia o un tiempo de entrega máximo), la variación en este tiempo (jitter), la cantidad de eventos que puede ser procesados en un intervalo de tiempo particular (caudal) o una caracterización de los eventos que no pueden ser procesados (tasa de fallos).

El rendimiento puede ser mejorado reduciendo la demanda o administrando los recursos de manera más apropiada. Reduciendo la demanda tendrá el efecto colateral de reducir la fidelidad o denegar el servicio a algún pedido. Administrar los recursos más apropiadamente se puede hacer mediante la programación/agendado, replicación, o simplemente incrementando los recursos disponibles.

Modificabilidad Capitulo 7

La modificabildad se trata del cambio y el costo en tiempo o dinero de hacer un cambio, incluyendo el grado en que esta modificación afecta otras funciones o atributos de calidad.

Los cambios puede ser realizados por desarrolladores, instaladores o usuarios finales, y estos cambios necesitan estar preparados para esto. Hay un costo de preparación para el cambio así como también hay un costo para hacer el cambio. Las tácticas de modificabilidad son diseñadas para prepararse para los cambios posteriores.

Las tacticas reducen el costo de generar un cambio incluyendo hacer modulos más pequeños, incrementando la cohesion, y reduciendo el emparejamiento.

Reducir el emparejamiento es una categoria estandar de tácticas que incluyen encapsulación, uso de un intermediario, restricción de dependencias, ubicación conjunta de responsabilidades relacionadas, refactorización, y abstracción de servicios comunes.

Incrementar la cohesión es otra táctica estandar que involucra a la separación de responsabilidades que no sirven al mismo proposito.

Defer binding es una categoria de tácticas que afecta el tiempo de construcción, tiempo de carga, tiempo de inicialización o tiempo de ejecución!

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

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