Arquitectura de Software

1. ¿Que es?

1.1. Subdisciplina de ingeniería de software

1.2. Relevancia de la materia en el campo del software

1.3. Relativo desconocimiento del concepto

1.4. Realmente no hay una definición ampliamente aceptada en la industria. Para entender su diversidad, habría que referirse a la lista mantenida por el instituto de ingeniería de software.

1.5. Su definición se puede extraer al analizar la literatura y sus diferentes enfoques. Desde uno más general de arquitectura (IEEE), a otros más específicos como los de: "An Introduction to Software Architecture" y "Software Architecture in Practice".

2. Arquitectura define estructura

2.1. Una arquitectura debe ser diseñada para cubrir requerimientos específicos y limitantes de la aplicación que se quiere implementar.

2.2. En esta arquitectura es una conjunción de requerimientos funcionales y no funcionales, las limitantes y los componentes.

2.3. Se asignan responsabilidades a los componentes y se definen sus interacciones y dependencias para cumplir roles específicos que aporten a la solución del sistema.

2.4. Existen técnicas como “Responsibility-driven design” para definir los componentes clave de una arquitectura.

2.5. Una problemática esencial es la minimización de las dependencias entre los componentes, debido a su interacción, cambios en una significan cambios en la otra y esto es un problema para la mantención y posteriores mejoras.

3. Arquitectura define comunicación de componentes

3.1. Se torna necesario pensar como los componentes comunican datos y controlan la información.

3.2. El control de eventos, los mecanismos de sincronización, y la notificación de eventos a componentes deben ser pensados, debido a que existen muchas posibilidades.

3.3. Para lo anterior existen patrones que funcionan como guía y son reutilizables en la arquitectura.

3.4. El poder de los patrones reside en su utilidad y habilidad para abarcar diseños de información.

4. La arquitectura abarca requerimientos no funcionales

4.1. Los requerimientos no funcionales son los que no aparecen en los casos de uso.

4.2. Existen tres áreas de requerimientos no funcionales:

4.2.1. Limitaciones técnicas: usualmente no negociables, ellos limitan opciones de diseño al especificar ciertas tecnologías que la aplicación debe utilizar.

4.2.2. Limitaciones de negocio: también limitan las opciones de diseño, pero enfocados en la factibilidad de ciertas decisiones y el tipo de negocio, ya que afectan su viabilidad económica y el enfoque del software.

4.2.3. Atributos de calidad: es la definición de términos como escalabilidad, disponibilidad, usabilidad, portabilidad, rendimiento, entre otras.

5. La arquitectura es una abstraccion

5.1. Una de las descripciones más útiles pero escasas desde un enfoque de arquitectura es algo llamado coloquialmente “Marketecture”.

5.2. Marketecture es una herramienta para facilitar la discusión con los Stakeholders durante el diseño, construcción, revisión y el proceso de ventas. Es fácil de entender y explicar, y marca un hito para avanzar hacia un análisis más profundo.

5.3. Uno de sus recursos es describir los componentes como cajas negras con entradas y salidas, como también la descomposición jerárquica.

6. Vistas Arquitectónicas

6.1. Una arquitectura de software representa un artefacto de diseño complejo. Como todo artefacto complejo, hay un número de formas de mirar y entender una arquitectura.

6.2. El termino vistas de arquitectura es acuñado del paper de Philippe Krutchen en 1995, llamado "4+1 View Model"

6.3. Lo anterior presenta una forma de describir y entender una arquitectura basada en las siguientes 4 vistas:

6.3.1. Vista Lógica: Esto describe los arquitectónicamente los elementos significantes de la arquitectura y la relación entre ellos.

6.3.2. Vista de Proceso: Esto se enfoca en describir la concurrencia y los elementos de comunicaciones de la arquitectura.

6.3.3. Vista Física: Esto ilustra como los procesos principales y los componentes son mapeados en el hardware de las aplicaciones.

6.3.4. Vista de Desarrollo: Esto captura la organización interna de los elementos de software propias del ambiente de desarrollo.

6.4. Estas vistas se unen entre sí por casos de uso arquitectonicamente significativos llamados comúnmente escenarios.

6.5. También existen recomendaciones para la captura de modelos arquitectónicos usando estos tres enfoques:

6.5.1. Modulo: Esta es la vista estructural de una arquitectura, comprimiendo el código en módulos como clases, paquetes, y subsistemas en el diseño.

6.5.2. Componente y conector: Esta vista describe aspectos del comportamiento de la arquitectura. Los componentes son típicamente objetos, hilos o procesos y los conectores describen su interacción.

6.5.3. Locación: Esta vista muestra como los procesos de la arquitectura son mapeados en hardware y como se comunican con redes y/o bases de datos.

6.6. - Esta terminología emanada de la literatura “Views and Beyond” está fuertemente influenciada por la arquitectura de descripción de lenguaje (ADL).

7. ¿Qué hace un arquitecto de software?

7.1. El ambiente en que se desenvuelve un arquitecto de software tiende a definir sus roles y responsabilidades.

7.2. Como resumen, podemos extraer 4 roles principales sin importar el ambiente del trabajo:

7.2.1. Enlace: El arquitecto tiene diferentes roles de enlace, como el enlace entre clientes y consumidores, entre clientes de la aplicación y equipo técnico, analistas de negocios y requerimientos, entre diferentes equipos ingenieriles de un proyecto, entre el área comercial, el de ventas y finalmente los diferentes Stakeholders.

7.2.2. Ingeniería de Software: Deben poseer buenas habilidades de diseño, usar y promover buenas prácticas ingenieriles, diseños adecuadamente documentados y comunicados con el equipo, y sus planes deben ser explícitos y justificados. Conocer el impacto de sus decisiones y trabajar con apropiadamente con los equipos de Testing, de documentación y de lanzamiento.

7.2.3. Conocimiento Tecnológico: Los arquitectos deben tener un vasto conocimiento de los dominios de tecnologías que son relevantes a los tipos de aplicaciones en que trabajan. Saben evaluar y escoger tecnologías externas, siguen los desarrollos en tecnologías y entienden como los nuevos estándares, cualidades y productos pueden serles útiles.

7.2.4. Manejo de Riesgo: Los Buenos arquitectos tienden a ser cautos. Constantemente enumeran y evalúan riesgos asociados a las decisiones de diseño y tecnologías. Ellos documentan y manejan estos riesgos en conjunto a las directivas del proyecto. Ellos desarrollan e investigación estrategias para la mitigación de riesgos. Tratan de asegurarse de que no ocurran desastres inesperados.

8. Arquitectura y Tecnologías

8.1. Los arquitectos deben hacer decisiones de diseño tempranamente en el ciclo de vida del proyecto, muchas de estas son difíciles de validar hasta que el sistema ya está construido. La meticulosa elaboración de componentes clave puede incrementar la confianza en el diseño, pero aun así es difícil conocer el éxito de una particular decisión de diseño en un contexto de aplicación dado.

8.2. Para esto confían en los patrones arquitectónicos, que permiten la reducción de riesgos con atributos ingenieriles conocidos.

8.3. Los patrones son una representación abstracta de una arquitectura, en el sentido de que pueden realizarse de múltiples formas concretas siempre y cuando se consideren los detalles de la implementación.

8.4. Desafortunadamente, estas descripciones abstractas de arquitecturas todavía no se ejecutan directamente en computadores o a través de rigurosas transformaciones. Hasta que lo anterior sea posible, siguen siendo los ingenieros de software que deben validar las arquitecturas a través de implementaciones de software concretas.

8.5. Deben lidiar con la elección de diferentes aplicaciones y evaluar sus ventajas y desventajas. Es muy poco probable encontrar un producto que satisfaga todas las necesidades sin perder ninguna ventaja (todas tienen sus fortalezas, debilidades y costos asociados).

8.6. La dificultad del arquitecto es el entendimiento de estas fortalezas y debilidades tempranamente en el ciclo de desarrollo de un proyecto, los riesgos y costos asociados a una mala elección de tecnologías son altos, la historia de la industria de software está llena de malas elecciones seguidas de proyectos fallidos.