Introducción a la Arquitectura de Software

Carlos ReynosoUNIVERSIDAD DE BUENOS AIRES

Billyreyno@hotmail.com

Temario

• Contexto• Estereotipos• Antecedentes históricos• Definición• Corrientes principales• Conceptos fundamentales• Estilos arquitectónicos• Lenguajes de Descripción Arquitectónica (ADLs)• Métodos clásicos, arquitectónicos y ágiles• Situación & Roadmap• http://www.microsoft.com/spanish/msdn/arquitectura

Paper

Contexto

• Los 3 grandes temas de ingeniería de software– Patrones

• Design patterns (GoF) - 1995– Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides

• Architectural patterns (POSA) - 1996– Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael

Stal

• Organizational patterns (Coplien)

– Arquitectura de Software– Métodos heterodoxos (eXtreme Programming, Scrum, Evo, FDD,

DSDM, RUP, AM, Crystal, LD, ASD…)

• Otros:– Refactorización (Fowler)– AOP..

Estereotipos

• Arquitectura como normativa madura• Herramientas de diseño arquitectónico• Lenguajes arquitectónicos iguales en la academia y la industria• UML como lenguaje formal de modelado• Arquitectura vinculada con ingeniería & ciclo de vida• Arquitectura vinculada a metodología (RUP)• La AS tiene que ver con modelado OO• Hay vínculo “natural” entre requerimientos (casos de uso) y

clases• Las herramientas arquitectónicas generan el código de la

aplicación

Antecedentes históricos

• Edsger Dijkstra, 1968– Ciencias de la computación como rama aplicada de las matemáticas– Niveles de abstracción

• NATO, 1969– P. I. Sharp, “Arquitectura de software”

• Fred Brooks, 1975 – MMM– Arquitectura como interfaz usuario

• David Parnas– 1972: Módulos – Ocultamiento de información– 1974: Estructuras de software– 1976: Familias de programas (Árbol de decisión)

Antecedentes históricos

• Dewayne Perry, Alexander Wolf – 1992– “Foundations for the study of software architecture”– “La década de 1990, creemos, será la década de la arquitectura de

software. Usamos el término “arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de estándares, de entrenamiento formal (de los arquitectos de software) y de estilo. Es tiempo de re-examinar el papel de la arquitectura de software en el contexto más amplio del proceso de software y de su administración, así como señalar las nuevas técnicas que han sido adoptadas”.

• Escuela de Carnegie Mellon (CMU-SEI)– Mary Shaw, David Garlan, Paul Clements, Robert Allen

Bibl…

Definición

• http://www.sei.cmu.edu/architecture/definitions.html – (1) Proceso dentro del ciclo de vida, (2) Topología, (3)

Disciplina.

• Arquitectura - IEEE 1471-2000: – La Arquitectura de Software es la organización fundamental de

un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.

• Ingeniería - IEEE 610.12.1990: – La aplicación de una estrategia sistemática, disciplinada y

cuantificable al desarrollo, aplicación y mantenimiento del software; esto es, la aplicación de la ingeniería al software.

Otras definiciones

• Clements, 1996: – La AS es, a grandes rasgos, una vista del sistema que

incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones.

– * Vista - * Componente

Corrientes principales• Arquitectura como etapa de la ingeniería de software

orientada a objetos– James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3

amigos”), Craig Larman…

• Arquitectura estructural – SEI– Garlan, Shaw, Clements– Variantes con modelos de datos (Medvidovic), variantes

radicales, formales (Moriconi-SRI), etc

• Arquitectura basada en patrones – SEI• Arquitectura procesual

– Kazman, Bass (SEI)

Vistas• 1977, análisis estructurado (Douglas Ross)

– Separación de incumbencias

– Habitualmente 2 (funcional y de datos – ninguna aparece en AS)

• La AS clásica no habla de vistas– Se basa en vista única e implícita, de carácter estructural

– Muchos arquitectos evitan hablar de vistas

– Cuando las vistas proliferan, se requieren lenguajes formales específicos para cada clase de vista

– Las vistas son una abstracción conveniente, pero su abundancia involucra problemas de sincronización

• Lista corta (3 a 6) – Lista larga (8 o 9…)

• Viewpoints’96

Conceptos fundamentalesVistas & frameworks

Zachman (Niveles)

TOGAF (Arquitecturas)

4+1 (Vistas)

[BRJ99] (Vistas)

POSA (Vistas)

Microsoft (Vistas)

Alcance Negocios Lógica Diseño Lógica Lógica Empresa Datos Proceso Proceso Proceso Conceptual Sistema lógico Aplicación Física Implementación Física Tecnología Desarrollo Despliegue Representación Funcionamiento

Tecnología Casos de uso Casos de uso

Desarrollo Física

Tabla 1 - Vistas en los marcos de referencia

Vistas de UML…

Área Vista Diagramas Conceptos principales Vista estática Diagrama de clases Clase, asociación, generalización,

dependencia, realización, interfaz Vista de casos de uso

Diagramas de casos de uso

Caso de uso, actor, asociación, extensión, inclusión, generalización de casos de uso

Vista de implementación

Diagrama de componentes

Componente, interfaz, dependencia, realización

Estructural

Vista de despliegue Diagrama de despliegue Nodo, componente, dependencia, localización

Vista de máquinas de estados

Diagrama de estados Estado, evento, transición, acción

Vista de actividad Diagrama de actividad Estado, actividad, transición de terminación, división, unión

Diagrama de secuencia Interacción, objeto, mensaje, activación

Dinámica

Vista de interacción Diagrama de colaboración

Colaboración, interacción, rol de colaboración, mensaje

Gestión del modelo

Vista de gestión del modelo

Diagrama de clases Paquete, subsistema, modelo

Tabla 2 - Vistas y diagramas de UML, basado en [RJB00: 22]

Vistas de UML…

• Vistas y puntos de vista no están homogeneizados en textos y autores

• Cuando los “3” hablan de AS, las vistas no se refieren a viewpoints o concerns, sino a niveles de abstracción

• Definición diferente de “arquitectura”– Interfaces en vez de conectores– Objetos en lugar de componentes

Estilos Arquitectónicos• Perry & Wolf, 1992• Rumbaugh & al 1991

– (1) transformaciones en lote, (2) transformaciones continuas, (3) interfaz interactiva, (4) simulación dinámica de objetos del mundo real, (5) sistemas de tiempo real, (6) administrador de transacciones con almacenamiento y actualización de datos

– Pero: “estilos arquitectónicos”, “arquitecturas comunes”, “marcos de referencia arquitectónicos prototípicos”, “formas comunes”, “clases de sistemas”

• Incluyen:– Componentes– Conectores– Estructuras (topologías)– Restricciones (constraints)

Estilos• Flujo de datos

– Secuencial en lotes– Red de flujo de datos (tuberías & filtros)– Bucle de control cerrado

• Llamada y Retorno– Programa principal / subrutinas– Ocultamiento de información (ADT, objeto, cliente/servidor elemental)

• Procesos interactivos– Procesos comunicantes– Sistemas de eventos (invocación implícita, eventos puros)

• Repositorio Orientado a Datos– Bases de datos transaccionales (cliente/servidor genuino)– Pizarra– Compilador moderno

• Datos Compartidos– Documentos compuestos– Hipertexto– Fortran COMMON– Procesos LW

• Jerárquicos• - En capas (intérpretes)

Tubería y filtros

Pizarra

Modelo-Vista-Controlador

Arquitectura en Capas

Máquina virtual

Modelo REST

Estilos

• Presentación específica el segundo cuatrimestre

• Documento sobre Estilos Arquitectónicos

• Billyr@microsoft.com.ar

• http://www.microsoft.com/spanish/msdn/arquitectura

Estilos…

Estilos y patrones

• POSA 96, Shaw 96• Patrones: Christopher Alexander 1977

– Elementos que se repiten• Como un elemento en el mundo, cada patrón es una relación

entre cierto contexto, cierto sistema de fuerzas que ocurre repetidas veces en ese contexto y cierta configuración espacial que permite que esas fuerzas se resuelvan. Como un elemento de lenguaje, un patrón es una instrucción que muestra la forma en que esta configuración espacial puede usarse, una y otra vez, para resolver ese sistema de fuerzas, donde quiera que el contexto la torne relevante

• El patrón es, en suma, al mismo tiempo una cosa que pasa en el mundo y la regla que nos dice cómo crear esa cosa y cuándo debemos crearla. Es tanto un proceso como una cosa; tanto una descripción de una cosa que está viva como una descripción del proceso que generará esa cosa.

Comentario Problemas Soluciones Fase de Desarrollo

Patrones de Arquitectura

Relacionados a la interacción de objetos dentro o entre niveles arquitectónicos

Problemas arquitectónicos, adaptabilidad a requerimientos cambiantes, performance, modularidad, acoplamiento

Patrones de llamadas entre objetos (similar a los patrones de diseño), decisiones y criterios arquitectónicos, empaquetado de funcionalidad

Diseño inicial

Patrones de Diseño

Conceptos de ciencia de computación en general, independiente de aplicación

Claridad de diseño, multiplicación de clases, adaptabilidad a requerimientos cambiantes, etc

Comportamiento de factoría, Clase-Responsabilidad-Contrato (CRC)

Diseño detallado

Patrones de Análisis

Usualmente específicos de aplicación o industria

Modelado del dominio, completitud, integración y equilibrio de objetivos múltiples, planeamiento para capacidades adicionales comunes

Modelos de dominio, conocimiento sobre lo que habrá de incluirse (p. ej. logging & reinicio)

Análisis

Patrones de Proceso o de Organización

Desarrollo o procesos de administración de proyectos, o técnicas, o estructuras de organización

Productividad, comunicación efectiva y eficiente

Armado de equipo, ciclo de vida del software, asignación de roles, prescripciones de comunicación

Planeamiento

IdiomasEstándares de codificación y proyecto

Operaciones comunes bien conocidas en un nuevo ambiente, o a través de un grupo. Legibilidad, predictibilidad.

Sumamente específicos de un lenguaje, plataforma o ambiente

Implementación, Mantemimiento, Despliegue

Lenguajes de Descripción Arquitectónica (ADLs)

• Lenguajes para el modelado, la descripción y (eventualmente) la prueba de la arquitectura

• Presentación específica el segundo cuatrimestre…

ADLs

Métodos Clásicos, Arquitectónicos y Ágiles

1. Modelos de proceso y diseño 1.1. Métodos tradicionales y de peso completo – CMM, UPM 1.2. Métodos basados en arquitectura

1.2.1. Métodos de análisis y diseño en el ciclo de vida – Visión general 1.2.2. Arquitectura basada en escenarios (FAAM, ALMA) 1.2.3. El diseño arquitectónico en el ciclo de vida: ABD 1.2.4. Active Review for Intermediate Design (ARID) 1.2.5. Quality Attribute Workshops (QAW) - QASAR 1.2.6. Attribute-Driven Design (ADD) 1.2.7. Evaluación: Architecture Tradeoff Analysis Method (ATAM) 1.2.8. Métodos de evaluación de opciones arquitectónicas (SACAM) 1.2.9. Derivación de tácticas arquitectónicas 1.2.10. Economía de la arquitectura: Cost-Benefits Analysis Method (CBAM) 1.2.11. Documentación de la Arquitectura

1.3. Métodos heterodoxos y de peso ligero: Métodos Agiles, Programación Extrema – Concepción caórdica de los sistemas complejos

Metodología Acrónimo Creación Tipo de modelo Característica Adaptive Software Development

ASD Highsmith 2000 Prácticas + Ciclo de vida

Inspirado en sistemas adaptativos complejos

Agile Modeling AM Ambler 2002 “Metodología basada en la práctica”

Suministra modelado ágil a otros métodos

Crystal Methods CM Cockburn 1998 “Familia de metodologías”

MA con énfasis en modelo de ciclos

Agile RUP dX Booch, Martin, Newkirk 1998

Framework / Disciplina XP dado vuelta con artefactos RUP

Dynamic Solutions Delivery Model

DSDM Stapleton 1997 Framework / Modelo de ciclo de vida

Creado por 16 expertos en RAD

Evolutionary Project Management

Evo Gilb 1976 Framework adaptativo Primer método ágil existente

Extreme Programming

XP Beck 1999 “Disciplina en prácticas de ingeniería”

Método ágil radical

Feature-driven development

FDD De Luca & Coad 1998 Palmer & Felsing 2002

“Metodología” Método ágil de diseño y construcción

Lean Development LD Charette 2001, Mary y Tom Poppendieck

“Forma de pensar” – Modelo logístico

Metodología basado en procesos productivos

Rapid Development RAD McConnell 1996 Survey de técnicas y modelos

Selección de best practices, no método

Rational Unified Process

RUP Kruchten 1996 Proceso unificado Método (¿ágil?) con modelado

Scrum Scrum Sutherland 1994 - Schwaber 1995

“Proceso” (framework de management)

Complemento de otros métodos, ágiles o no

Manifesto ágil (2001)

Estamos poniendo al descubierto formas mejores de desarrollo de software, haciéndolo y ayudando a otros a que lo hagan. A través de este trabajo hemos llegado a valorar:

• Los individuos y la interacción por encima de los procesos y herramientas.

• El software que funciona por encima de la documentación abarcadora.• La colaboración con el cliente por encima de la negociación

contractual.• La respuesta al cambio por encima del seguimiento de un plan. Aunque hay valor en los elementos a la derecha, valorizamos más los

de la izquierda.Documento…

Campos de AS

• Fundamentos formales de la AS (bases matemáticas, caracterizaciones formales de propiedades extra-funcionales tales como mantenibilidad, teorías de la interconexión, etc).

• Técnicas de análisis arquitectónicas• Métodos de desarrollo basados en arquitectura• Recuperación y reutilización de arquitectura• Codificación y guía arquitectónica• Herramientas y ambientes de diseño arquitectónico• Estudios de casos

Situación

Academia Industria

La arquitectura se define explícitamente Prevalece una comprensión conceptual de la arquitectura. Las definiciones explícitas son mínimas, eventualmente mediante notaciones

La arquitectura consiste en componentes y conectores de primera clase

No hay conectores explícitos de primera clase (a veces hay soluciones ad hoc de binding en tiempo de ejecución)

Los lenguajes de descripción de arquitectura (ADLs) describen la arquitectura explícitamente y a veces la generan

Se utilizan lenguajes de programación

Los componentes reutilizables son entidades de caja negra

Los componentes son grandes piezas de software de estructuras interna compleja, no necesariamente encapsulados

Los componentes tienen interfaces con un solo punto de acceso

Las interfaces se proporcionan mediante entidades (clases en los componentes). Las entidades de interfaz no tienen diferencias explícitas de entidades que no son de interfaz

Se otorga prioridad a la funcionalidad y la verificación formal

La funcionalidad y los atributos de calidad (performance, robustez, tamaño, reusabilidad, mantenibilidad) tienen igual importancia

Problemas de AS

• Falta de criterio unificado• Desarrollo en paralelo de conceptos antagónicos o

no coordinados– Métodos ágiles– Metodologías de ciclo de vida– Patrones

• Poca masa crítica de herramientas y lenguajes de modelado arquitectónico (de alto nivel, con conectores de primera clase)

Beneficios• Decisiones tempranas• Análisis de consistencia• Análisis de tradeoff antes de escribir código

– Mary Shaw y David Garlan [1996] comparan una misma solución de indexación de palabras claves en cuatro estilos diferentes (datos compartidos, tubería y filtro, tipos abstractos de datos e invocación implícita). El modelo permite estimar relaciones de dependencia, modularidad, refinamiento, reutilización, ventajas y desventajas de cada arquitectura antes de escribir una sola línea de código; demuestra también de qué manera los diferentes estilos definen tácticas específicas de descomposición funcional y establecen la pauta que habrá de seguirse en el desarrollo. Finalmente, SG aplican diversas tablas de comparación de atributos, en un ejercicio de evaluación de decisiones estilísticas que se ha convertido en un modelo en su género

• Re-utilización

Oportunidades de carrera-Programación .NET

-Arquitectura de Software .NET

http://www.microsoft.com/spanish/msdn/arquitectura

Billyr@microsoft.com.ar

¿Preguntas?

• Billyr@microsoft.com.ar