Architect Academy:

Seminario de Arquitectura
de Software

Billy Reynoso
UNIVERSIDAD DE BUENOS AIRES

Billyr@microsoft.com.ar
Roadmap
 Webcast #1: ¿Qué es la Arquitectura de
Software?
 Webcast #2: Drilldown en Estilos de
Arquitectura
 Webcast #3: Arquitectura para distribución
y agregación: Services Oriented
Architecture (SOA)
 Webcast #4: Diseñando la arquitectura
¿Qué es la Arquitectura de Software?

 Objetivos del curso

 Breve historia y definición
 Principales conceptos arquitectónicos
• Estilos de arquitectura: componentes, conectores, restricciones
(constraints), configuraciones
• Diseñar para calidad de desarrollo: Estilos y Patrones
• Puntos de vista arquitectónicos: componente, concurrencia,
despliegue
• Requerimientos no funcionales: Tácticas y frameworks de
conocimiento
• Más allá de los casos de uso: Escenarios y atributos de calidad
• Lenguajes de Descripción Arquitectónica (ADLs)
 Arquitectura, razonamiento de alto nivel y calidad operacional:
Ejemplo canónico de práctica arquitectónica (Garlan & Shaw)
Objetivos del curso
 Clarificar el carácter distintivo de la Arquitectura de
Software
 Proporcionar lineamientos y recursos para la práctica
arquitectónica
 Vincular visiones de la academia y la industria
 Establecer situación actual y perspectivas, con énfasis en
las herramientas, middleware y sistemas operativos de
Microsoft
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)
• Métodos heterodoxos (2001)
eXtreme Programming, Scrum, Evo, FDD, DSDM, RUP, AM, Crystal,
LD, ASD…)
• Arquitectura de Software (1992)
Surgimiento

 1969 – Conferencia OTAN

 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.
Adoptada por Microsoft en estrategia arquitectónica / MSF
 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.
 La Arquitectura no es…

 Una normativa madura

 Igual en la academia y en la industria
 Diseño de software con UML
 Naturalmente vinculada con 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
 Naturalmente vinculada a metodología (RUP)
 Naturalmente relacionada con modelado Orientado a Objetos
 Hay vínculo “natural” entre requerimientos (casos de uso) y clases
 Las herramientas arquitectónicas generan el código de la
aplicación
Arquitectura es…

 Vista estructural de alto nivel

 Define estilo o combinación de estilos para una solución
 Se concentra en requerimientos no funcionales
• Los requerimientos funcionales se satisfacen mediante modelado
y diseño de aplicación
 Esencial para éxito o fracaso de un proyecto
Corrientes principales
 Arquitectura estructural – SEI – Carnegie Mellon
• Garlan, Shaw, Clements
• Variantes con modelos de datos (Medvidovic), radicales, formales
(Moriconi-SRI), etc
 Arquitectura como etapa de la ingeniería de software orientada
a objetos
• James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3…”), Craig
Larman…
 Arquitectura basada en patrones – SEI
• Redefinición de estilos como patrones POSA
• Microsoft Patterns & Practices
 Arquitectura procesual y metodologías
• Kazman, Bass (SEI)
• Variantes de arquitectura basada en escenarios
Estilos Arquitectónicos

 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”
Estilos – Nueva concepción
 Perry & Wolf, 1992
 Componentes (ahora: Elementos)
 Conectores
 Configuraciones
 Restricciones (Constraints)
 “Mano mágica” (Fielding, 2000)

UML?
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 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
• Arquitecturas Basadas en
Recursos
Estilos derivados
 C2
 GenVoca
 REST
Estilos
 Sirven para sintetizar estructuras de soluciones
 Pocos estilos abstractos encapsulan una enorme variedad
de configuraciones concretas
 Definen los patrones posibles de las aplicaciones
 Permiten evaluar arquitecturas alternativas con ventajas y
desventajas conocidas ante diferentes conjuntos de
requerimientos no funcionales
Ejemplo
 Mala práctica:
• Aplicaciones clientes que consultan si sucedió algo
• Listener de HTTP, Archivo, Colas

 Buena práctica:
• Estilo basado en Eventos
Ejemplo
Arquitectura basada en eventos
Modelo de push a veces se vincula con patrón Observador (Observer
pattern)
Arquitectura basada en eventos
 Ventajas
• Simplicidad
• Evolución: se pueden reemplazar componentes suscriptores
• Modularidad: una sola modalidad para eventos diversos
• Puede mejorar eficiencia, eliminando la necesidad de polling por
ocurrencia de evento
 Desventajas
• Posibilidad de desborde
• Potencial imprevisión de escalabilidad
• Pobre comprensibilidad: Puede ser difícil prever qué pasará en
respuesta a una acción
• No hay garantía del lado del publisher que el suscriptor responderá
al evento
• No hay mucho soporte de recuperación en caso de falla parcial
Arquitectura basada en eventos

 Dos modelos de arquitectura e implementación

 Tightly coupled events (TCE, eventos fuertemente acoplados)
• P. ej. COM Connection Points.
• Requiere que ambos componentes estén corriendo
simultáneamente. No hay forma de filtrar evento (p. ej. cuando
acción alcance cierto valor)
• Requiere conocer ambas interfaces específicas
 Losely coupled events (LCE, eventos débilmente acoplados)
• P. ej. COM+ Events
• Almacenamiento de eventos (COM+ Catalog)
• Referencia: MSDN Library – COM+ Technical Series: Losely
coupled events
Arquitectura basada en eventos
 Permiten invocación implícita de una herramienta cuando otra
herramienta produce un evento
 También se llama Invocación implícita
• Un componente anuncia un evento. Otros registran interés en ese tipo de
evento. Cuando se produce, el sistema (la “mano invisible”) lo comunica a
los suscriptores.
 Algunos incluyen a MVC en esta clase
 Modelo Publish / Subscribe
 MS: Registración de Eventos COM+, eventos (listeners) de BizTalk
Server, Notification Service de SQL Server

Demo
Arquitectura basada en eventos
 Herramientas en ambiente COM+/.NET
 En muchos casos no se requiere programación de bajo
nivel
 También hay profusión de herramientas programáticas y
servicios de “mano mágica”
 Administrative tools
• Component Services
COM+ Applications
 .NET Utilities, Biztalk Server/Interchange
Relación entre Estilos y
Patrones (Patterns)
Patterns

 Christopher Alexander, 1977

 Un patrón es una solución a un problema en un
contexto
 Un patrón codifica conocimiento específico
acumulado por la experiencia en un dominio
 Un sistema bien estructurado está lleno de patrones
Patterns - Alexander

 “Cada patrón describe un problema que ocurre una y

otra vez en nuestro ambiente, y luego describe el
núcleo de la solución a ese problema, de tal manera
que puedes usar esa solución un millón de veces
más, sin hacer jamás la misma cosa dos veces.”
 Ejemplos: galería, paseo, patio compartido,
columnata, estacionamiento
Elementos de un patrón
 Nombre
• Define un vocabulario de diseño
• Facilita abstracción
 Problema
• Describe cuando aplicar el patrón
• Conjunto de fuerzas: objetivos y restricciones
• Prerrequisitos
 Solución
• Elementos que constituyen el diseño (template)
• Forma canónica para resolver fuerzas
 Consecuencias MVC
• Resultados, extensiones y tradeoffs
 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.
Organización de Patrones
 Propuesta por MS para Enterprise Solution Patterns Using Microsoft
.NET (ESP)
 Propósito:
• Identificar relaciones entre patrones
• Agrupar patrones en clusters
• Identificar patrones a diversos niveles de abstracción
• Aplicar patrones a múltiples aspectos de una solución
• Organizar patrones en un frame
• Usar patrones para describir en forma concisa una solución…
Ejemplos de ESP

Niveles de abstracción
Vistas

Documento

Frame
Requerimientos no funcionales
Escenarios, tácticas, frameworks

 Performance
 Disponibilidad
 Modificabilidad
 Seguridad
 Verificabilidad (Testability)
 Gestionabilidad (instrumentación, management, estado)
 Usabilidad
Atributos de Calidad
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.
Ejemplo de metodología
Refinamiento de Escenario

 Los escenarios se refinan considerando:

• 1. Estímulo - La condición que afecta al sistema
• 2. Respuesta - La actividad que resulta del estímulo
• 3. Fuente del estímulo - La entidad que lo genera
• 4. Ambiente - La condición bajo la cual el estímulo ocurre
• 5. Artefacto estimulado
• 6. Medida de respuesta - Para evaluar la respuesta del sistema
 Se describen los objetivos de negocio/misión afectados por el escenario y las
cualidades relevantes asociadas con él
 En funcíón de los escenarios se pueden evaluar los estilos arquitectónicos que
pueden satisfacer los requerimientos
Lenguajes de Descripción Arquitectónica
(ADLs)
 Componentes
 Conectores
 Configuraciones o sistemas
 Propiedades no funcionales
 Restricciones
 Estilos
 Evolución
 Herramientas de verificación
 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
Métodos basados en Arquitectura

 Architecture Tradeoff Analysis Method (ATAM)

 Quality Attribute Workshops (QAW)
 Attribute-Driven Design (ADD)
 Active Reviews for Intermediate Designs (ARID)
 Cost-Benefit Analysis Method (CBAM)
 Software Architecture Comparison Analysis Method (SACAM)
 Quality-Attribute-Driven Software Architecture Reconstruction
(QADSAR)
 Architecture Based Design Method (ABD)
 Software Architecture Analysis Method (SAAM)
 Usos de estilos
Mary Shaw, David Garlan, 1996
• IEEE98SA-Styles-Patterns.pdf
• 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
Paper
Tablas de comparación de
atributos
Asignación de pesos a prioridades
Síntesis
 Arquitectura:
 Visión de alto nivel
 Estilo - Patrón
 Previo a diseño de aplicación
 Requerimientos no funcionales
 Escenarios
 Lenguajes de descripción arquitectónica
Referencias

 Len Bass, Paul Clements, Rick Lazman. Software Architecture in

Practice, 2a edición, Addison-Wesley, 2003
 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad,
Michael Stal. Pattern Oriented Software Architecture, vol. 1. Wiley, 1996
 Documentos en http://www.microsoft.com/spanish/msdn/Arquitectura

Docs…
Webcast # 2 – Drilldown en estilos de arquitectura
 Diseñar desde arriba: La especificidad de la abstracción
arquitectónica
 Estilos: historia, definición, inventario
 Estilos fundamentales
 Práctica arquitectónica
 Implementando estilos con Windows services, Middleware
MS y .NET Framework
 ¿Preguntas?

http://www.microsoft.com/spanish/msdn/arquitectura
Billyr@microsoft.com.ar