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...
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, 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.
Kazman, Kruchten et al 2004)
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
Antecedentes históricos (1/5)
Edsger Dijkstra, 1968
Ciencias de la computación como rama aplicada de las
matemáticas
Niveles de abstracción
Stacks, abrazos mortales, semáforos, algoritmo de
camino más corto
NATO, 1968
F. L. Bauer “Ingeniería de software”
NATO, 1969
P. I. Sharp, “Arquitectura de software”
C.R. Spooner, 1971
“Una arquitectura de software para los 70s”
Referencia accidental
Antecedentes históricos (2/5)
Niklaus Wirth, 1971
Niveles de abstracción  Stepwise refinement
DeRemer & Kron, 1976
Programming in the large
Fred Brooks, 1975 – MMM
Diseñador del OS/360, Premio Turing 2000
Arquitectura como interfaz usuario
El arquitecto es un agente del usuario, igual que quien diseña
su casa
Importancia de las estructuras de alto nivel y de decisiones
tomadas al principio
Arquitectura: qué hacer - Implementación: cómo hacerlo
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) - Descomposición
- Alternativa a diagramas de flujo, 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. Esto evita el uso de conceptos
ambiguos tales como “similitud funcional” que surgen a veces cuando se
describen dominios. Por ejemplo, los ambientes de ingeniería de software y
los juegos de video no se consideran usualmente en el mismo dominio,
aunque podrían considerarse miembros de la misma familia de programas
en una discusión sobre herramientas que ayuden a construir interfaces
gráficas, que ambos casualmente utilizan”.
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
Antecedentes históricos (4/5)
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)
Sin conexión explícita con CMMI®
Mary Shaw, David Garlan, Paul Clements, Robert Allen,
Rick Kazman
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.
Adoptada por Microsoft en estrategia arquitectónica / MSF 3 & 4
Ingeniería - IEEE 610.12.1990:
[La Ingeniería de Software es] 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
Paul 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
Desarrollos paralelos
Década de 1990:
Metáfora de patrones de C. Alexander (1977)
La Banda de los Cuatro (GoF), 1995
POSA, 1996
Desarrollo de UML / OOD
Corrientes teóricas en AS
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
Corriente principal: Garlan, Shaw, Clements
Variantes con modelos de datos (Medvidovic)
Variantes radicales, formales (Moriconi-SRI)
Arquitectura basada en patrones – SEI
Arquitectura procesual (Kazman, 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, concurrencia y despliegue
(Bass, Clements, Kazman)
Lista corta (3 a 6) – Lista larga (8 o 9…)
Viewpoints’96
 Conceptos fundamentales
Vistas & frameworks

Zachman TOGAF 4+1 [BRJ99] POSA Microsoft

(Niveles) (Arquitecturas) (Vistas) (Vistas) (Vistas) (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 Física
Tecnología Tecnología Desarrollo Despliegue Desarrollo
Representación Casos de uso Casos de uso
Funcionamiento
Tabla 1 - Vistas en los marcos de referencia
 Vistas de UML…
Área Vista Diagramas Conceptos principales
Estructural Vista estática Diagrama de clases Clase, asociación, generalización,
dependencia, realización, interfaz
Vista de casos de Diagramas de casos de Caso de uso, actor, asociación,
uso uso extensión, inclusión, generalización de
casos de uso
Vista de Diagrama de Componente, interfaz, dependencia,
implementación componentes realización
Vista de despliegue Diagrama de despliegue Nodo, componente, dependencia,
localización
Dinámica Vista de máquinas Diagrama de estados Estado, evento, transición, acción
de estados
Vista de actividad Diagrama de actividad Estado, actividad, transición de
terminación, división, unión
Vista de interacción Diagrama de secuencia Interacción, objeto, mensaje, activación
Diagrama de Colaboración, interacción, rol de
colaboración colaboración, mensaje
Gestión del Vista de gestión del Diagrama de clases Paquete, subsistema, modelo
modelo modelo
Tabla 2 - Vistas y diagramas de UML, basado en [RJB00: 22]

No hay componentes, ni conectores, ni constraints, ni configutraciones

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
Estilos Arquitectónicos
Rumbaugh-Booch-Jacobson 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”
Definición no exhaustiva
Criterios taxonómicos no homogéneos
Taxones de distinto nivel de inclusión
Algunos tipos pueden incluir otros (ej. 6 y 3)
Estilos arquitectónicos
Perry & Wolf, 1992
Incluyen:
Componentes (2003, “elementos”)
Conectores
Estructuras (topologías,
configuraciones)
Restricciones (constraints)
Estilos Arquitectónicos
Estilos de Flujo de Datos
Tubería y filtros
Estilos Centrados en Datos
Arquitecturas de Pizarra o
Repositorio
Estilos de Llamada y Retorno
Model-View-Controller (MVC)
Arquitecturas en Capas
Arquitecturas Orientadas a
Objetos
Arquitecturas Basadas en
Componentes
Estilos Derivados
C2
GenVoca
REST
Estilos de Código Móvil
Arquitectura de Máquinas
Virtuales
Estilos heterogéneos
Sistemas de control de
procesos
Arquitecturas Basadas en
Atributos
Estilos Peer-to-Peer
Arquitecturas Basadas en
Eventos
Arquitecturas Orientadas a
Servicios (SOA)
Arquitecturas Basadas en
Recursos
Tres ejemplos significativos
Arquitectura basada en eventos
Arquitectura de pizarra
Arquitecturas orientadas a servicios
Presentación separada en esta serie…
Arquitectura basada en eventos
Impiden incurrir en el modelo de aplicaciones que
preguntan si sucedió algo.
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)
Arquitecturas de Pizarra
Arquitectura de Pizarra
H. Penny Nii, 1986 (Blackboard systems)
Cuándo se utiliza: Problemas no susceptibles de tratarse
analíticamente
Reconocimiento de patrones, aprendizaje de máquina, data mining
Firmas, huellas digitales, reconocimiento de iris, rostro, etc
Dos formas:
Repositorio
Pizarra pura o tablero de control
Procesamiento de señales
Reconocimiento de habla
Redes neuronales, algoritmo genético, simulación de
templado
Agentes autónomos (débilmente acoplados)
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
Relacionados a la
Patrones de interacción de objetos
Arquitectura dentro o entre niveles
arquitectónicos
Conceptos de ciencia de
Patrones de computación en general,
Diseño independiente de
aplicación
Patrones de Usualmente específicos de
Análisis aplicación o industria
Desarrollo o procesos de
Patrones de
administración de
Proceso o de
proyectos, o técnicas, o
Organización
estructuras de organización
Estándares de codificación
Idiomas
y proyecto
Problemas Soluciones Fase de Desarrollo
Patrones de llamadas
entre objetos (similar a
Problemas arquitectónicos,
los patrones de diseño),
adaptabilidad a requerimientos
decisiones y criterios Diseño inicial
cambiantes, performance,
arquitectónicos,
modularidad, acoplamiento
empaquetado de
funcionalidad
Claridad de diseño, Comportamiento de
multiplicación de clases, factoría, Clase-
Diseño detallado
adaptabilidad a requerimientos Responsabilidad-
cambiantes, etc Contrato (CRC)
Modelado del dominio,
Modelos de dominio,
completitud, integración y
conocimiento sobre lo
equilibrio de objetivos múltiples, Análisis
que habrá de incluirse (p.
planeamiento para capacidades
ej. logging & reinicio)
adicionales comunes
Armado de equipo, ciclo
de vida del software,
Productividad, comunicación
asignación de roles, Planeamiento
efectiva y eficiente
prescripciones de
comunicación
Operaciones comunes bien
Sumamente específicos Implementación,
conocidas en un nuevo ambiente,
de un lenguaje, Mantemimiento,
o a través de un grupo.
plataforma o ambiente Despliegue
Legibilidad, predictibilidad.
Usos de estilos
Mary Shaw, David Garlan, 1996
Inspirado en trabajo de Parnas, 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, dependencia,
modularidad, reutilización, refinamiento, ventajas &
desventajas
Antes de escribir una línea de código
Tablas de comparación de atributos
Asignación de pesos a prioridades
Estilos - Conclusiones
Después de 13 años, son menos conocidos y
frecuentados que los patrones
Son fundamentales para la toma de
decisiones del diseño, ya que se dispone de
métodos comparativos que no existen para
el caso de los patterns
Metodologías SACAM, CBAM
Es esencial que se conserve un número
pequeño de estilos disponibles
Requerimientos no funcionales

Performance
Disponibilidad
Modificabilidad
Seguridad
Verificabilidad (Testability)
Gestionabilidad (instrumentación,
management, estado)
Usabilidad
Atributos de Calidad
Escenarios
Equivalente no funcional de los casos de uso
No contemplados en UML / RUP
Cuantificables - No hay diagramas de escenarios
Estímulo, ambiente, 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.5 segundos dentro de una persona-semana.
Escenario exploratorio:
La mitad de los servidores se bajará durante operación normal sin afectar
la disponibilidad del sistema.
Lenguajes de Descripción
Arquitectónica (ADLs)
Lenguajes para el modelado, la descripción
y (eventualmente) la prueba de la
arquitectura
Representación de componentes,
conectores, configuraciones y restricciones
Prueba de consistencia arquitectónica
Soporte de evolución
Géneros emparentados
Lenguajes de especificacíón (LARCH, Z)
Lenguajes de prototipado (Modechart,
PSDL)
Lenguajes de modelado (UML)
Lenguajes de programación (CODE, Ada)
Herramientas para definición de ciclo de
vida (UNAS/SALE)
 ADL Fecha Investigador - Organismo Observaciones
Acme 1995 Monroe & Garlan (CMU), Wile (USC) Lenguaje de intercambio de ADLs
Aesop 1994 Garlan (CMU) ADL de propósito general, énfasis
en estilos
ArTek 1994 Terry, Hayes-Roth, Erman Lenguaje específico de dominio -
(Teknowledge, DSSA) No es ADL
Armani 1998 Monroe (CMU) ADL asociado a Acme
C2 SADL 1996 Taylor/Medvidovic (UCI) ADL específico de estilo
CHAM 1990 Berry / Boudol Lenguaje de especificación
Darwin 1991 Magee, Dulay, Eisenbach, Kramer ADL con énfasis en dinámica
Jacal 1997 Kicillof , Yankelevich (Universidad de Adl - Notación de alto nivel para
Buenos Aires) descripción y prototipado
LILEANNA 1993 Tracz (Loral Federal) Lenguaje de conexión de módulos
MetaH 1993 Binns, Englehart (Honeywell) ADL específico de dominio
Rapide 1990 Luckham (Stanford) ADL & simulación
SADL 1995 Moriconi, Riemenschneider (SRI) ADL con énfasis en mapeo de
refinamiento
UML 1995 Rumbaugh, Jacobson, Booch (Rational) Lenguaje genérico de modelado –
No es ADL
UniCon 1995 Shaw (CMU) ADL de propósito general, énfasis
en conectores y estilos
Wright 1994 Garlan (CMU) ADL de propósito general, énfasis
en comunicación
xADL 2000 Medvidovic, Taylor (UCI, UCLA) ADL basado en XML
Acme/Armani
ADLs: Sustento formal
Darwin: cálculo Pi (Milner-Parrow-Walker)
BizTalk primitivo, Polyphonic C#
Wright: Communicating Sequential Processes (CSP),
lógica de primer orden
LILEANNA: programación parametrizada e hiper-
programación
Rapide: Posets
SAM: Redes de Petri de transición de predicados, 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 Ventajas y desventajas
de vida (AS en RUP) (ATAM)
Atributos de calidad & Elección de arquitectura
escenarios Análisis de arquitectura
[Primitivas de atributo] (SAAM)
Architecture Based Quality Attribute Workshop
Design (ABD) (QAW)
Tácticas Arquitectónicas Revisión activa de diseño
Comparación de parcial (ARID)
alternativas (SACAM) Análisis de costo/beneficio
Diseño basado en (CBAM)
atributos (ADD) 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
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, 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, con conectores de
primera clase)
Beneficios
Decisiones tempranas
Barry Boehm, 1995
Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su
justificación, el proyecto no debe empezar el desarrollo en gran escala.
Si se especifica la arquitectura como un elemento a entregar, se la
puede usar a lo largo de los procesos de desarrollo y mantenimiento
[Boe95].

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
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, en proceso de elaboración
preliminar
Resta elaborar: tácticas arquitectónicas, métodos basados
en arquitectura, vínculo entre conceptos de arquitectura,
DSLs, factorías, building blocks, …
Referencias
Artículos de Arquitectura de Software en
http://www.microsoft.com/spanish/msdn/arquitec
tura
Len Bass, Paul Clements, Rick Kazman. 2003.
Software Architecture in Practice, 2ª edición
Documentación del SEI en Carnegie Mellon
http://www.sei.cmu.edu/publications/publications.html
Rick Kazman, Philippe Kruchten et al. 2004.
“Integrating Software-Architecture-centric methods
into the Rational Unified Process”, CMU/SEI-2004-
TR-011
Recomendaciones IEEE 1471/2000
¿Preguntas?
Billyr@microsoft.com.ar