Introduccin a la Arquitectura

de Software
Billy Reynoso
UNIVERSIDAD DE BUENOS AIRES
Billyr@microsoft.com.ar
Objetivos
Suministrar una visin estructurada de la
Arquitectura de Software contempornea
No es pedagoga Arquitectura 101, sino ms bien un
survey de lo que significa AS, una evaluacin de lo que
ha llegado a ser y una puntualizacin sobre lo que no es
Despejar malos entendidos sobre arquitectura
como diseo de aplicaciones
Vincular perspectivas de la academia y la industria
Privilegiar elaboraciones de la corriente terica de
CMU/SEI
Describir desarrollos de estado de arte, problemas
pendientes y tendencias
Proporcionar referencias a recursos, documentacin
y herramientas
http://www.microsoft.com/spanish/msdn/arquitectura
Temario
Objetivos
Contexto
Errores de concepto habituales
Antecedentes histricos
Definicin Repositorio de definiciones
Corrientes principales
Conceptos fundamentales (CMU/SEI)
Estilos arquitectnicos
Estilos y patrones
Lenguajes de Descripcin Arquitectnica (ADLs)
Atributos de calidad, escenarios y tcticas
Mtodos basados en arquitectura
Situacin, conclusiones y referencias
Contexto 1995-2005
Los 3 grandes temas de ingeniera 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)
Mtodos heterodoxos (eXtreme Programming, Scrum, Evo,
FDD, DSDM, RUP, AM, Crystal, LD, ASD)
Arquitectura de Software
Otros:
Refactorizacin
AOP, SOA, Grid Computing, Semantic Web...
Conceptos cuestionables (1/2)
Arquitectura como normativa madura
Abundancia de herramientas de diseo arquitectnico
Semntica y lenguajes arquitectnicos iguales en la
academia y la industria
UML como lenguaje formal de modelado arquitectnico
Posicin de la AS bien definida en ingeniera & ciclo de
vida
Ocurre en algn punto entre la elicitacin de requerimientos y la
especificacin de casos de uso, o entre stos y el diseo
Arquitectura vinculada a metodologa 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 arquitectnicas generan
la estructura de la aplicacin e incluso el
cdigo (analoga con modelos CASE)
El dilema del roundtrip engineering est
resuelto
Hay que considerar modelo de DSL
Antecedentes histricos (1/5)
Edsger Dijkstra, 1968
Ciencias de la computacin como rama aplicada de las
matemticas
Niveles de abstraccin
Stacks, abrazos mortales, semforos, algoritmo de
camino ms corto
NATO, 1968
F. L. Bauer Ingeniera de software
NATO, 1969
P. I. Sharp, Arquitectura de software
C.R. Spooner, 1971
Una arquitectura de software para los 70s
Referencia accidental
Antecedentes histricos (2/5)
Niklaus Wirth, 1971
Niveles de abstraccin Stepwise refinement
DeRemer & Kron, 1976
Programming in the large
Fred Brooks, 1975 MMM
Diseador del OS/360, Premio Turing 2000
Arquitectura como interfaz usuario
El arquitecto es un agente del usuario, igual que quien disea
su casa
Importancia de las estructuras de alto nivel y de decisiones
tomadas al principio
Arquitectura: qu hacer - Implementacin: cmo hacerlo

Antecedentes histricos (3/5)
David Parnas
1972: Mdulos Ocultamiento de informacin
1974: Estructuras de software
1976: Familias de programas (rbol de decisin) - Descomposicin
- Alternativa a diagramas de flujo, propensin estructural (no
funcional)
Una familia de programas es un conjunto de programas (no todos los
cuales han sido construidos o lo sern 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 ingeniera de software
y los juegos de video no se consideran usualmente en el mismo dominio,
aunque podran considerarse miembros de la misma familia de
programas en una discusin sobre herramientas que ayuden a construir
interfaces grficas, que ambos casualmente utilizan.
Antecedentes histricos (4/5)
Lnea de Dijkstra-Parnas-Hoare
Fundamentacin matemtica
Mtodos formales
Programa fuerte
Lnea de Brooks
Ambiente humano
Visin cualitativa
Pensamiento no lineal
Programa crtico y heterodoxo
Antecedentes histricos (4/5)
Dewayne Perry, Alexander Wolf 1992
Foundations for the study of software architecture
La dcada de 1990, creemos, ser la dcada de la arquitectura
de software. Usamos el trmino arquitectura en contraste con
diseo, para evocar nociones de codificacin, de abstraccin, de
estndares, 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 ms amplio del proceso de
software y de su administracin, as como sealar las nuevas
tcnicas que han sido adoptadas.
Escuela de Carnegie Mellon (CMU-SEI)
Sin conexin explcita con CMMI
Mary Shaw, David Garlan, Paul Clements, Robert Allen,
Rick Kazman
Definicin
http://www.sei.cmu.edu/architecture/definitions.html
(1) Proceso dentro del ciclo de vida, (2) Topologa, (3) Disciplina.
Arquitectura - IEEE 1471-2000:
La Arquitectura de Software es la organizacin fundamental de
un sistema encarnada en sus componentes, las relaciones entre
ellos y el ambiente y los principios que orientan su diseo y
evolucin.
Adoptada por Microsoft en estrategia arquitectnica / MSF 3 & 4
Ingeniera - IEEE 610.12.1990:
[La Ingeniera de Software es] la aplicacin de una estrategia
sistemtica, disciplinada y cuantificable al desarrollo, aplicacin
y mantenimiento del software; esto es, la aplicacin de la
ingeniera 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 segn se la percibe
desde el resto del sistema y las formas en que los
componentes interactan y se coordinan para alcanzar
la misin del sistema. La vista arquitectnica es una
vista abstracta, aportando el ms alto nivel de
comprensin y la supresin o diferimiento del detalle
inherente a la mayor parte de las abstracciones.
* Vista - * Componente

Desarrollos paralelos
Dcada de 1990:
Metfora de patrones de C. Alexander (1977)
La Banda de los Cuatro (GoF), 1995
POSA, 1996
Desarrollo de UML / OOD
Corrientes tericas en AS
Arquitectura como etapa de la ingeniera 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, anlisis estructurado (Douglas Ross)
Separacin de incumbencias
Habitualmente 2 (funcional y de datos ninguna aparece en
AS)
La AS clsica no habla de vistas
Se basa en vista nica e implcita, de carcter estructural
Muchos arquitectos evitan hablar de vistas
Cuando las vistas proliferan, se requieren lenguajes formales
especficos para cada clase de vista
Las vistas son una abstraccin conveniente, pero su
abundancia involucra problemas de sincronizacin
En AS ortodoxa prevalecen 3: CC, concurrencia y despliegue
(Bass, Clements, Kazman)
Lista corta (3 a 6) Lista larga (8 o 9)
Viewpoints96
Conceptos fundamentales
Vistas & frameworks

Zachman
(Niveles)
TOGAF
(Arquitecturas)
4+1
(Vistas)
[BRJ99]
(Vistas)
POSA
(Vistas)
Microsoft
(Vistas)
Alcance Negocios Lgica Diseo Lgica Lgica
Empresa Datos Proceso Proceso Proceso Conceptual
Sistema lgico Aplicacin Fsica Implementacin Fsica
Tecnologa Desarrollo Despliegue
Representacin
Funcionamiento
Tecnologa
Casos de uso Casos de uso
Desarrollo
Fsica
Tabla 1 - Vistas en los marcos de referencia
Vistas de UML

rea Vista Diagramas Conceptos principales
Vista esttica Diagrama de clases Clase, asociacin, generalizacin,
dependencia, realizacin, interfaz
Vista de casos de
uso
Diagramas de casos de
uso
Caso de uso, actor, asociacin,
extensin, inclusin, generalizacin de
casos de uso
Vista de
implementacin
Diagrama de
componentes
Componente, interfaz, dependencia,
realizacin
Estructural
Vista de despliegue Diagrama de despliegue Nodo, componente, dependencia,
localizacin
Vista de mquinas
de estados
Diagrama de estados Estado, evento, transicin, accin
Vista de actividad Diagrama de actividad Estado, actividad, transicin de
terminacin, divisin, unin
Diagrama de secuencia Interaccin, objeto, mensaje, activacin
Dinmica
Vista de interaccin
Diagrama de
colaboracin
Colaboracin, interaccin, rol de
colaboracin, mensaje
Gestin del
modelo
Vista de gestin del
modelo
Diagrama de clases Paquete, subsistema, 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 estn
homogeneizados en textos y autores
Cuando los 3 hablan de AS, las vistas no
se refieren a viewpoints o concerns, sino a
niveles de abstraccin
Definicin diferente de arquitectura
Interfaces en vez de conectores
Objetos en lugar de componentes (elementos)
Los conectores no son conectores de primera
clase
Estilos Arquitectnicos
Rumbaugh-Booch-Jacobson 1991
(1) transformaciones en lote, (2) transformaciones
continuas, (3) interfaz interactiva, (4) simulacin
dinmica de objetos del mundo real, (5) sistemas
de tiempo real, (6) administrador de transacciones
con almacenamiento y actualizacin de datos
Pero: estilos arquitectnicos, arquitecturas
comunes, marcos de referencia arquitectnicos
prototpicos, formas comunes, clases de
sistemas
Definicin no exhaustiva
Criterios taxonmicos no homogneos
Taxones de distinto nivel de inclusin
Algunos tipos pueden incluir otros (ej. 6 y 3)
Estilos arquitectnicos
Perry & Wolf, 1992
Incluyen:
Componentes (2003, elementos)
Conectores
Estructuras (topologas,
configuraciones)
Restricciones (constraints)

Estilos Arquitectnicos
Estilos de Flujo de Datos
Tubera 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 Cdigo Mvil
Arquitectura de Mquinas
Virtuales
Estilos heterogneos
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
Presentacin separada en esta serie
Arquitectura basada en eventos
Impiden incurrir en el modelo de aplicaciones que
preguntan si sucedi algo.
Generan la ejecucin apenas ocurre el evento o el usuario
se conecta
Modelo de push. A veces se vincula con patrn Observador
(Observer pattern)
Arquitecturas de Pizarra
Arquitectura de Pizarra
H. Penny Nii, 1986 (Blackboard systems)
Cundo se utiliza: Problemas no susceptibles de
tratarse analticamente
Reconocimiento de patrones, aprendizaje de mquina, data
mining
Firmas, huellas digitales, reconocimiento de iris, rostro, etc
Dos formas:
Repositorio
Pizarra pura o tablero de control
Procesamiento de seales
Reconocimiento de habla
Redes neuronales, algoritmo gentico, simulacin de
templado
Agentes autnomos (dbilmente acoplados)
Estilos y patrones
POSA 96, Shaw 96
Patrones: Christopher Alexander 1977
Elementos que se repiten
Como un elemento en el mundo, cada patrn es una relacin
entre cierto contexto, cierto sistema de fuerzas que ocurre
repetidas veces en ese contexto y cierta configuracin
espacial que permite que esas fuerzas se resuelvan. Como
un elemento de lenguaje, un patrn es una instruccin que
muestra la forma en que esta configuracin espacial puede
usarse, una y otra vez, para resolver ese sistema de fuerzas,
donde quiera que el contexto la torne relevante
El patrn es, en suma, al mismo tiempo una cosa que pasa
en el mundo y la regla que nos dice cmo crear esa cosa y
cundo debemos crearla. Es tanto un proceso como una
cosa; tanto una descripcin de una cosa que est viva como
una descripcin del proceso que generar esa cosa.

Comentario

Problemas

Soluciones

Fase de Desarrollo

Patrones de
Arquitectura

Relacionados a la
interaccin de objetos
dentro o entre niveles
arquitectnicos

Problemas arquitectnicos,
adaptabilidad a requerimientos
cambiantes, performance,
modularidad, acoplamiento

Patrones de llamadas
entre objetos (similar a
los patrones de diseo),
decisiones y criterios
arquitectnicos,
empaquetado de
funcionalidad

Diseo inicial

Patrones de
Diseo

Conceptos de ciencia de
computacin en general,
independiente de
aplicacin

Claridad de diseo,
multiplicacin de clases,
adaptabilidad a requerimientos
cambiantes, etc

Comportamiento de
factora, Clase-
Responsabilidad-
Contrato (CRC)

Diseo detallado

Patrones de
Anlisis

Usualmente especficos de
aplicacin o industria

Modelado del dominio,
completitud, integracin y
equilibrio de objetivos mltiples,
planeamiento para capacidades
adicionales comunes

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

Anlisis

Patrones de
Proceso o de
Organizacin

Desarrollo o procesos de
administracin de
proyectos, o tcnicas, o
estructuras de organizacin

Productividad, comunicacin
efectiva y eficiente

Armado de equipo, ciclo
de vida del software,
asignacin de roles,
prescripciones de
comunicacin

Planeamiento

Idiomas

Estndares de codificacin
y proyecto

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

Sumamente especficos
de un lenguaje,
plataforma o ambiente

Implementacin,
Mantemimiento,
Despliegue

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 informacin
Sistema de indexacin de palabras claves
Datos compartidos
Tipos abstractos de datos
Invocacin implcita
Tubera y filtros
Comparacin de versatilidad, dependencia,
modularidad, reutilizacin, refinamiento, ventajas &
desventajas
Antes de escribir una lnea de cdigo
Tablas de comparacin de atributos
Asignacin de pesos a prioridades
Estilos - Conclusiones
Despus de 13 aos, son menos conocidos
y frecuentados que los patrones
Son fundamentales para la toma de
decisiones del diseo, ya que se dispone de
mtodos comparativos que no existen para
el caso de los patterns
Metodologas SACAM, CBAM
Es esencial que se conserve un nmero
pequeo de estilos disponibles
Requerimientos no funcionales

Performance
Disponibilidad
Modificabilidad
Seguridad
Verificabilidad (Testability)
Gestionabilidad (instrumentacin,
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
Estmulo, 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 operacin
normal sin afectar la disponibilidad del sistema.
Lenguajes de Descripcin
Arquitectnica (ADLs)
Lenguajes para el modelado, la descripcin
y (eventualmente) la prueba de la
arquitectura
Representacin de componentes,
conectores, configuraciones y restricciones
Prueba de consistencia arquitectnica
Soporte de evolucin
Gneros emparentados
Lenguajes de especificacn (LARCH, Z)
Lenguajes de prototipado (Modechart,
PSDL)
Lenguajes de modelado (UML)
Lenguajes de programacin (CODE, Ada)
Herramientas para definicin 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 propsito general, nfasis
en estilos
ArTek 1994 Terry, Hayes-Roth, Erman
(Teknowledge, DSSA)
Lenguaje especfico de dominio -
No es ADL
Armani 1998 Monroe (CMU) ADL asociado a Acme
C2 SADL 1996 Taylor/Medvidovic (UCI) ADL especfico de estilo
CHAM 1990 Berry / Boudol Lenguaje de especificacin
Darwin 1991 Magee, Dulay, Eisenbach, Kramer ADL con nfasis en dinmica
Jacal 1997 Kicillof , Yankelevich (Universidad de
Buenos Aires)
Adl - Notacin de alto nivel para
descripcin y prototipado
LILEANNA 1993 Tracz (Loral Federal) Lenguaje de conexin de mdulos
MetaH 1993 Binns, Englehart (Honeywell) ADL especfico de dominio
Rapide 1990 Luckham (Stanford) ADL & simulacin
SADL 1995 Moriconi, Riemenschneider (SRI) ADL con nfasis en mapeo de
refinamiento
UML 1995 Rumbaugh, Jacobson, Booch (Rational) Lenguaje genrico de modelado
No es ADL
UniCon 1995 Shaw (CMU) ADL de propsito general, nfasis
en conectores y estilos
Wright 1994 Garlan (CMU) ADL de propsito general, nfasis
en comunicacin
xADL 2000 Medvidovic, Taylor (UCI, UCLA) ADL basado en XML
Acme/Armani
ADLs: Sustento formal
Darwin: clculo Pi (Milner-Parrow-Walker)
BizTalk primitivo, Polyphonic C#
Wright: Communicating Sequential Processes
(CSP), lgica de primer orden
LILEANNA: programacin parametrizada e hiper-
programacin
Rapide: Posets
SAM: Redes de Petri de transicin de predicados,
lgica temporal de primer orden
Jacal: Redes de Petri
Casi todos los ADLs tienen BNF
Modelo estructural no ligado a OO
Situacin actual de los ADLs
Ninguno se impuso ni en la academia ni en el
mercado
Comps de espera:
UML 2
Domain Specific Languages
XML
Web Semntica
Visin positiva: necesidad de mtodos formales
debido a complejidad de factores
Visin negativa: ADLs obsoletos
La produccin de ADLs se ha desacelerado
Metodologas arquitectnicas
Posicionamiento en ciclo
de vida (AS en RUP)
Atributos de calidad &
escenarios
[Primitivas de atributo]
Architecture Based
Design (ABD)
Tcticas Arquitectnicas
Comparacin de
alternativas (SACAM)
Diseo basado en
atributos (ADD)
Ventajas y desventajas
(ATAM)
Eleccin de arquitectura
Anlisis de arquitectura
(SAAM)
Quality Attribute Workshop
(QAW)
Revisin activa de diseo
parcial (ARID)
Anlisis de costo/beneficio
(CBAM)
Reformulacin: UML & RUP
Campos de AS
Fundamentos formales de la AS
Bases matemticas
Caracterizaciones formales de propiedades extra-funcionales tales
como mantenibilidad
Teoras de la interconexin
Tcnicas arquitectnicas de anlisis
Mtodos de desarrollo basados en arquitectura
Visual Studio 2005 Team System
Recuperacin y reutilizacin de arquitectura
Codificacin y gua arquitectnica
Herramientas y ambientes de diseo arquitectnico
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 antagnicos o no
coordinados
Mtodos giles
Metodologas de ciclo de vida
Patrones, estilos y tcticas
Apropiacin nominal de la AS por estrategias que no
implementan principios arquitectnicos pero se benefician
de su prestigio
Poca masa crtica de herramientas y lenguajes de
modelado arquitectnico (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
justificacin, 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].
Anlisis de consistencia antes de elaborar el
diseo (y escribir el cdigo)
Sistematizacin de la experiencia
Homogeneizacin del lenguaje (IEEE 1471)
Herramientas para la evolucin
Re-utilizacin
Conclusiones generales
Importancia de la Arquitectura de Software
Criticidad de las decisiones tempranas de arquitectura
Alto nivel de abstraccin
Vinculada con requerimientos no funcionales
Fuerte impulso en la academia y la industria
Herramientas arquitectnicas an en proceso de definicin
y desarrollo
Metodologas arquitectnicas, en proceso de elaboracin
preliminar
Resta elaborar: tcticas arquitectnicas, mtodos basados
en arquitectura, vnculo entre conceptos de arquitectura,
DSLs, factoras, building blocks,
Referencias
Artculos 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 edicin
Documentacin 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