Introducción a la Arquitectura de Software

Billy Reynoso

UNIVERSIDAD DE BUENOS AIRES

Billyr@microsoft.com.ar

Objetivos
Suministrar una visión estructurada de la Arquitectura de Software contemporánea
No es pedagogía Arquitectura 101, sino más bien un survey de lo que significa AS, una evaluación de lo que ha llegado a ser y una puntualización sobre lo que no es

Despejar malos entendidos sobre arquitectura como diseño de aplicaciones Vincular perspectivas de la academia y la industria Privilegiar elaboraciones de la corriente teórica de CMU/SEI Describir desarrollos de estado de arte, problemas pendientes y tendencias Proporcionar referencias a recursos, documentación y herramientas
http://www.microsoft.com/spanish/msdn/arquitectura

Temario
Objetivos Contexto Errores de concepto habituales Antecedentes históricos Definición – Repositorio de definiciones Corrientes principales Conceptos fundamentales (CMU/SEI) Estilos arquitectónicos Estilos y patrones Lenguajes de Descripción Arquitectónica (ADLs) Atributos de calidad, escenarios y tácticas Métodos basados en arquitectura Situación, conclusiones y referencias

Contexto – 1995-2005
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)

Métodos heterodoxos (eXtreme Programming, Scrum, Evo, FDD, DSDM, RUP, AM, Crystal, LD, ASD…) Arquitectura de Software

Otros:
Refactorización AOP, SOA, Grid Computing, Semantic Web...

Kazman. Kruchten et al 2004) . o entre éstos y el diseño Arquitectura vinculada a metodología y proceso RUP La AS está formalmente desarrollada las disciplinas de RUP (cf.Conceptos cuestionables (1/2) Arquitectura como normativa madura Abundancia de herramientas de diseño arquitectónico Semántica y lenguajes arquitectónicos iguales en la academia y la industria UML como lenguaje formal de modelado “arquitectónico” Posición de la AS bien definida en ingeniería & ciclo de vida Ocurre en algún punto entre la elicitación de requerimientos y la especificación de casos de uso.

Conceptos cuestionables (2/2) La AS tiene que ver con modelado OO La AS no admite ni requiere otros paradigmas No hay urgencia en considerar otros paradigmas (Berners-Lee) Las herramientas arquitectónicas generan la estructura de la aplicación e incluso el código (analogía con modelos CASE) El dilema del roundtrip engineering está resuelto Hay que considerar modelo de DSL .

1971 “Una arquitectura de software para los 70s” Referencia accidental . 1969 P. Sharp. semáforos. Bauer “Ingeniería de software” NATO. Spooner. algoritmo de camino más corto NATO. 1968 F.R. I. abrazos mortales. “Arquitectura de software” C. L. 1968 Ciencias de la computación como rama aplicada de las matemáticas Niveles de abstracción Stacks.Antecedentes históricos (1/5) Edsger Dijkstra.

igual que quien diseña su casa Importancia de las estructuras de alto nivel y de decisiones tomadas al principio Arquitectura: qué hacer . 1976 Programming in the large Fred Brooks.Antecedentes históricos (2/5) Niklaus Wirth. 1971 Niveles de abstracción  Stepwise refinement DeRemer & Kron. Premio Turing 2000 Arquitectura como interfaz usuario El arquitecto es un agente del usuario.Implementación: cómo hacerlo . 1975 – MMM Diseñador del OS/360.

Por ejemplo. propensión estructural (no funcional) “Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o lo serán alguna vez) a los cuales es provechoso o útil considerar como grupo. que ambos casualmente utilizan”.Alternativa a diagramas de flujo.Antecedentes históricos (3/5) David Parnas 1972: Módulos – Ocultamiento de información 1974: Estructuras de software 1976: Familias de programas (Árbol de decisión) . los ambientes de ingeniería de software y los juegos de video no se consideran usualmente en el mismo dominio.Descomposición . . aunque podrían considerarse miembros de la misma familia de programas en una discusión sobre herramientas que ayuden a construir interfaces gráficas. Esto evita el uso de conceptos ambiguos tales como “similitud funcional” que surgen a veces cuando se describen dominios.

Antecedentes históricos (4/5) Línea de Dijkstra-Parnas-Hoare Fundamentación matemática Métodos formales Programa fuerte Línea de Brooks Ambiente humano Visión cualitativa Pensamiento no lineal Programa crítico y heterodoxo .

será la década de la arquitectura de software. Escuela de Carnegie Mellon (CMU-SEI) Sin conexión explícita con CMMI® Mary Shaw.  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. de abstracción.Antecedentes históricos (4/5) Dewayne Perry. así como señalar las nuevas técnicas que han sido adoptadas”. creemos. Robert Allen. Rick Kazman . de estándares. Usamos el término “arquitectura” en contraste con “diseño”. Paul Clements. David Garlan. de entrenamiento formal (de los arquitectos de software) y de estilo. Alexander Wolf – 1992 “Foundations for the study of software architecture” “La década de 1990. para evocar nociones de codificación.

12.IEEE 610.html (1) Proceso dentro del ciclo de vida. Arquitectura .1990: [La Ingeniería de Software es] la aplicación de una estrategia sistemática. Adoptada por Microsoft en estrategia arquitectónica / MSF 3 & 4 Ingeniería . esto es. aplicación y mantenimiento del software.edu/architecture/definitions. la aplicación de la ingeniería al software. disciplinada y cuantificable al desarrollo.sei. (3) Disciplina.cmu. (2) Topología. las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. .Definición http://www.IEEE 1471-2000: La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes.

Otras definiciones Paul Clements. 1996: “La AS es. a grandes rasgos. La vista arquitectónica es una vista abstracta. * Vista .* Componente . 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. 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”. una vista del sistema que incluye los componentes principales del mismo.

Desarrollos paralelos Década de 1990: Metáfora de patrones de C. 1996 Desarrollo de UML / OOD . Alexander (1977) La Banda de los Cuatro (GoF). 1995 POSA.

Grady Booch.Corrientes teóricas en AS Arquitectura como etapa de la ingeniería de software orientada a objetos James Rumbaugh. formales (Moriconi-SRI) Arquitectura basada en patrones – SEI Arquitectura procesual (Kazman. Shaw. Craig Larman… Arquitectura estructural – SEI Corriente principal: Garlan. Clements Variantes con modelos de datos (Medvidovic) Variantes radicales. Ivar Jacobson (“los 3 amigos”). Bass) .

concurrencia y despliegue (Bass.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 En AS ortodoxa prevalecen 3: CC. Kazman) Lista corta (3 a 6) – Lista larga (8 o 9…) Viewpoints’96 . Clements.

Conceptos fundamentales Vistas & frameworks Zachman (Niveles) Alcance Empresa Sistema lógico Tecnología Representación Funcionamiento TOGAF (Arquitecturas) Negocios Datos Aplicación Tecnología 4+1 (Vistas) Lógica Proceso Física Desarrollo Casos de uso [BRJ99] (Vistas) Diseño Proceso Implementación Despliegue Casos de uso POSA (Vistas) Lógica Proceso Física Desarrollo Microsoft (Vistas) Lógica Conceptual Física Tabla 1 .Vistas en los marcos de referencia .

interfaz. ni conectores. transición de terminación. asociación. transición. rol de colaboración. dependencia. ni configutraciones . acción Estado. ni constraints. interacción. asociación. subsistema. actor. división. generalización. objeto. componente. mensaje. mensaje Paquete. realización Nodo. interfaz Caso de uso. actividad.Vistas y diagramas de UML. extensión. generalización de casos de uso Componente. activación Colaboración. evento. unión Interacción.Vistas de UML… Área Estructural Vista Vista estática Vista de casos de uso Vista de implementación Vista de despliegue Dinámica Vista de máquinas de estados Vista de actividad Vista de interacción Diagramas Diagrama de clases Diagramas de casos de uso Diagrama de componentes Diagrama de despliegue Diagrama de estados Diagrama de actividad Diagrama de secuencia Diagrama de colaboración Diagrama de clases Conceptos principales Clase. dependencia. basado en [RJB00: 22] No hay componentes. modelo Gestión del modelo Vista de gestión del modelo Tabla 2 . realización. inclusión. dependencia. localización Estado.

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 (“elementos”) Los conectores no son conectores de primera clase .

“formas comunes”. “marcos de referencia arquitectónicos prototípicos”. 6 y 3) . (6) administrador de transacciones con almacenamiento y actualización de datos Pero: “estilos arquitectónicos”. (3) interfaz interactiva. “arquitecturas comunes”. (2) transformaciones continuas. (5) sistemas de tiempo real. “clases de sistemas” Definición no exhaustiva Criterios taxonómicos no homogéneos Taxones de distinto nivel de inclusión Algunos tipos pueden incluir otros (ej. (4) simulación dinámica de objetos del mundo real.Estilos Arquitectónicos Rumbaugh-Booch-Jacobson 1991 (1) transformaciones en lote.

“elementos”) Conectores Estructuras (topologías.Estilos arquitectónicos Perry & Wolf. configuraciones) Restricciones (constraints) . 1992 Incluyen: Componentes (2003.

Estilos Arquitectónicos Estilos de Flujo de Datos Tubería y filtros Estilos de Código Móvil Arquitectura de Máquinas Virtuales Estilos Centrados en Datos Arquitecturas de Pizarra o Repositorio Estilos heterogéneos Sistemas de control de procesos Arquitecturas Basadas en Atributos Estilos de Llamada y Retorno Model-View-Controller (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes Estilos Peer-to-Peer Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios (SOA) Arquitecturas Basadas en Recursos Estilos Derivados C2 GenVoca REST .

Tres ejemplos significativos Arquitectura basada en eventos Arquitectura de pizarra Arquitecturas orientadas a servicios Presentación separada en esta serie… .

Generan la ejecución apenas ocurre el evento o el usuario se conecta Modelo de push. A veces se vincula con patrón Observador (Observer pattern) .Arquitectura basada en eventos Impiden incurrir en el modelo de aplicaciones que preguntan si sucedió algo.

Arquitecturas de Pizarra .

data mining Firmas. 1986 (Blackboard systems) Cuándo se utiliza: Problemas no susceptibles de tratarse analíticamente Reconocimiento de patrones. huellas digitales. simulación de templado Agentes autónomos (débilmente acoplados) . Penny Nii. algoritmo genético. rostro. reconocimiento de iris. etc Dos formas: Repositorio Pizarra pura o tablero de control Procesamiento de señales Reconocimiento de habla Redes neuronales.Arquitectura de Pizarra H. aprendizaje de máquina.

Shaw 96 Patrones: Christopher Alexander 1977 Elementos que se repiten Como un elemento en el mundo. un patrón es una instrucción que muestra la forma en que esta configuración espacial puede usarse. 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. donde quiera que el contexto la torne relevante El patrón es. una y otra vez. . Como un elemento de lenguaje. cada patrón es una relación entre cierto contexto. para resolver ese sistema de fuerzas. 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. en suma. cierto sistema de fuerzas que ocurre repetidas veces en ese contexto y cierta configuración espacial que permite que esas fuerzas se resuelvan.Estilos y patrones POSA 96.

adaptabilidad a requerimientos cambiantes. integración y equilibrio de objetivos múltiples. multiplicación de clases. o estructuras de organización Productividad. prescripciones de comunicación Diseño detallado Patrones de Análisis Usualmente específicos de aplicación o industria Análisis Patrones de Proceso o de Organización Desarrollo o procesos de administración de proyectos. ClaseResponsabilidadContrato (CRC) Modelos de dominio. adaptabilidad a requerimientos cambiantes. planeamiento para capacidades adicionales comunes Comportamiento de factoría. independiente de aplicación Claridad de diseño. o técnicas. ciclo de vida del software. logging & reinicio) Armado de equipo. conocimiento sobre lo que habrá de incluirse (p. comunicación efectiva y eficiente Planeamiento Idiomas Estándares de codificación y proyecto Operaciones comunes bien conocidas en un nuevo ambiente. performance. asignación de roles.Comentario Problemas Soluciones Patrones de llamadas entre objetos (similar a los patrones de diseño). decisiones y criterios arquitectónicos. plataforma o ambiente Implementación. completitud. Mantemimiento. modularidad. etc Modelado del dominio. Legibilidad. ej. empaquetado de funcionalidad Fase de Desarrollo Patrones de Arquitectura Relacionados a la interacción de objetos dentro o entre niveles arquitectónicos Problemas arquitectónicos. acoplamiento Diseño inicial Patrones de Diseño Conceptos de ciencia de computación en general. o a través de un grupo. Sumamente específicos de un lenguaje. Despliegue . predictibilidad.

1996 Inspirado en trabajo de Parnas. modularidad. dependencia. refinamiento. reutilización. David Garlan.Usos de estilos Mary Shaw. ventajas & desventajas Antes de escribir una línea de código Tablas de comparación de atributos Asignación de pesos a prioridades . 1972 (“On the criteria to be used in decomposing systems into modules”) – Datos compartidos vs ocultamiento de información Sistema de indexación de palabras claves Datos compartidos Tipos abstractos de datos Invocación implícita Tubería y filtros Comparación de versatilidad.

Estilos . son menos conocidos y frecuentados que los patrones Son fundamentales para la toma de decisiones del diseño. CBAM Es esencial que se conserve un número pequeño de estilos disponibles . ya que se dispone de métodos comparativos que no existen para el caso de los patterns Metodologías SACAM.Conclusiones Después de 13 años.

management. estado) Usabilidad .Requerimientos no funcionales Performance Disponibilidad Modificabilidad Seguridad Verificabilidad (Testability) Gestionabilidad (instrumentación.

Atributos de Calidad .

5 segundos dentro de una persona-semana. ambiente.Escenarios Equivalente no funcional de los casos de uso No contemplados en UML / RUP Cuantificables . respuesta Escenario de caso de uso: Un usuario remoto de web requiere un reporte de base de datos en hora pico y lo recibe dentro de los 5 segundos. Escenario de crecimiento: Agregar un nuevo servidor de base de datos para reducir latencia en escenario 1 a 2. Escenario exploratorio: La mitad de los servidores se bajará durante operación normal sin afectar la disponibilidad del sistema.No hay diagramas de escenarios Estímulo. .

Lenguajes de Descripción Arquitectónica (ADLs) Lenguajes para el modelado. conectores. configuraciones y restricciones Prueba de consistencia arquitectónica Soporte de evolución . la descripción y (eventualmente) la prueba de la arquitectura Representación de componentes.

Z) Lenguajes de prototipado (Modechart. Ada) Herramientas para definición de ciclo de vida (UNAS/SALE) .Géneros emparentados Lenguajes de especificacíón (LARCH. PSDL) Lenguajes de modelado (UML) Lenguajes de programación (CODE.

Erman (Teknowledge. Eisenbach. Kramer Kicillof . Booch (Rational) Shaw (CMU) Garlan (CMU) Medvidovic. Riemenschneider (SRI) Rumbaugh.ADL Acme Aesop ArTek Armani C2 SADL CHAM Darwin Jacal LILEANNA MetaH Rapide SADL UML UniCon Wright xADL Fecha 1995 1994 1994 1998 1996 1990 1991 1997 1993 1993 1990 1995 1995 1995 1994 2000 Investigador . UCLA) Observaciones Lenguaje de intercambio de ADLs ADL de propósito general. Taylor (UCI. Yankelevich (Universidad de Buenos Aires) Tracz (Loral Federal) Binns.Organismo Monroe & Garlan (CMU). Englehart (Honeywell) Luckham (Stanford) Moriconi. énfasis en conectores y estilos ADL de propósito general. Dulay. Jacobson. DSSA) Monroe (CMU) Taylor/Medvidovic (UCI) Berry / Boudol Magee.Notación de alto nivel para descripción y prototipado Lenguaje de conexión de módulos ADL específico de dominio ADL & simulación ADL con énfasis en mapeo de refinamiento Lenguaje genérico de modelado – No es ADL ADL de propósito general. Hayes-Roth. énfasis en estilos Lenguaje específico de dominio No es ADL ADL asociado a Acme ADL específico de estilo Lenguaje de especificación ADL con énfasis en dinámica Adl . Wile (USC) Garlan (CMU) Terry. énfasis en comunicación ADL basado en XML .

Acme/Armani .

.

lógica de primer orden LILEANNA: programación parametrizada e hiperprogramación Rapide: Posets SAM: Redes de Petri de transición de predicados.ADLs: Sustento formal Darwin: cálculo Pi (Milner-Parrow-Walker) BizTalk primitivo. Polyphonic C# Wright: Communicating Sequential Processes (CSP). lógica temporal de primer orden Jacal: Redes de Petri Casi todos los ADLs tienen BNF Modelo estructural no ligado a OO .

Situación actual de los ADLs Ninguno se impuso ni en la academia ni en el mercado Compás de espera: UML 2 Domain Specific Languages XML Web Semántica Visión positiva: necesidad de métodos formales debido a complejidad de factores Visión negativa: ADLs “obsoletos” La producción de ADLs se ha desacelerado .

Metodologías arquitectónicas Posicionamiento en ciclo de vida (AS en RUP) Atributos de calidad & escenarios [Primitivas de atributo] Architecture Based Design (ABD) Tácticas Arquitectónicas Comparación de alternativas (SACAM) Diseño basado en atributos (ADD) Ventajas y desventajas (ATAM) Elección de arquitectura Análisis de arquitectura (SAAM) Quality Attribute Workshop (QAW) Revisión activa de diseño parcial (ARID) Análisis de costo/beneficio (CBAM) Reformulación: UML & RUP .

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 Técnicas arquitectónicas de análisis Métodos de desarrollo basados en arquitectura Visual Studio 2005 Team System 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 .

estilos y tácticas Apropiación nominal de la AS por estrategias que no implementan principios arquitectónicos pero se benefician de su prestigio Poca masa crítica de herramientas y lenguajes de modelado arquitectónico (de alto nivel.Problemas pendientes en AS Falta de criterio unificado No hay un modelo de proceso de punta a punta Desarrollo en paralelo de conceptos antagónicos o no coordinados Métodos ágiles Metodologías de ciclo de vida Patrones. con conectores de primera clase) .

el proyecto no debe empezar el desarrollo en gran escala.Beneficios Decisiones tempranas Barry Boehm. Análisis de consistencia antes de elaborar el diseño (y escribir el código) Sistematización de la experiencia Homogeneización del lenguaje (IEEE 1471) Herramientas para la evolución Re-utilización . se la puede usar a lo largo de los procesos de desarrollo y mantenimiento [Boe95]. incluyendo su justificación. 1995 Si un proyecto no ha logrado una arquitectura del sistema. Si se especifica la arquitectura como un elemento a entregar.

vínculo entre conceptos de arquitectura. building blocks.Conclusiones generales Importancia de la Arquitectura de Software Criticidad de las decisiones tempranas de arquitectura Alto nivel de abstracción Vinculada con requerimientos no funcionales Fuerte impulso en la academia y la industria Herramientas arquitectónicas aún en proceso de definición y desarrollo Metodologías arquitectónicas. métodos basados en arquitectura. en proceso de elaboración preliminar Resta elaborar: tácticas arquitectónicas. … . factorías. DSLs.

2ª edición Documentación del SEI en Carnegie Mellon http://www. Software Architecture in Practice. CMU/SEI-2004TR-011 Recomendaciones IEEE 1471/2000 . Paul Clements.microsoft.cmu.Referencias Artículos de Arquitectura de Software en http://www. 2003. “Integrating Software-Architecture-centric methods into the Rational Unified Process”.com/spanish/msdn/arquitec tura Len Bass.sei.html Rick Kazman. Rick Kazman. Philippe Kruchten et al.edu/publications/publications. 2004.

com.¿Preguntas? Billyr@microsoft.ar .

Sign up to vote on this title
UsefulNot useful