0
Architect Academy:
Seminario de Arquitectura
de Software
Billy Reynoso
UNIVERSIDAD DE BUENOS AIRES

Billyr@microsoft.com.a...
Roadmap

 Webcast #1: ¿Qué es la Arquitectura de
Software?
 Webcast #2: Drilldown en Estilos de
Arquitectura
 Webcast #...
¿Qué es la Arquitectura de Software?
 Objetivos del curso
 Breve historia y definición
 Principales conceptos arquitect...
Objetivos del curso
 Clarificar el carácter distintivo de la Arquitectura de
Software
 Proporcionar lineamientos y recur...
Contexto
 Los 3 grandes temas de ingeniería de software
• Patrones
Design patterns (GoF) - 1995
 Erich Gamma, Richard He...
Surgimiento
 1969 – Conferencia OTAN
 Dewayne Perry, Alexander Wolf – 1992
• “Foundations for the study of software arch...
Definición
 http://www.sei.cmu.edu/architecture/definitions.html
• (1) Proceso dentro del ciclo de vida, (2) Topología, (...
La Arquitectura no es…
 Una normativa madura
 Igual en la academia y en la industria
 Diseño de software con UML
 Natu...
Arquitectura es…

 Vista estructural de alto nivel
 Define estilo o combinación de estilos para una solución
 Se concen...
Corrientes principales
 Arquitectura estructural – SEI – Carnegie Mellon
• Garlan, Shaw, Clements
• Variantes con modelos...
Estilos Arquitectónicos
 Rumbaugh & al 1991
• (1) transformaciones en lote, (2) transformaciones
continuas, (3) interfaz ...
Estilos – Nueva concepción
 Perry & Wolf, 1992
 Componentes (ahora: Elementos)
 Conectores
 Configuraciones
 Restricc...
Estilos Arquitectónicos
Estilos de Flujo de Datos
• Tubería y filtros

Estilos Centrados en Datos
• Arquitecturas de Piz...
Estilos derivados
 C2
 GenVoca
 REST
Estilos
 Sirven para sintetizar estructuras de soluciones
 Pocos estilos abstractos encapsulan una enorme variedad
de co...
Ejemplo
 Mala práctica:
• Aplicaciones clientes que consultan si sucedió algo
• Listener de HTTP, Archivo, Colas

 Buena...
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
• Modul...
Arquitectura basada en eventos

 Dos modelos de arquitectura e implementación
 Tightly coupled events (TCE, eventos fuer...
Arquitectura basada en eventos
 Permiten invocación implícita de una herramienta cuando otra
herramienta produce un event...
Arquitectura basada en eventos
 Herramientas en ambiente COM+/.NET
 En muchos casos no se requiere programación de bajo
...
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 conoc...
Patterns - Alexander
 “Cada patrón describe un problema que ocurre una y
otra vez en nuestro ambiente, y luego describe e...
Elementos de un patrón
 Nombre
• Define un vocabulario de diseño
• Facilita abstracción

 Problema
• Describe cuando apl...
Comentario

Problemas

Soluciones

Fase de Desarrollo

Patrones de
Arquitectura

Relacionados a la
interacción de objetos
...
Organización de Patrones
 Propuesta por MS para Enterprise Solution Patterns Using
Microsoft .NET (ESP)
 Propósito:
• Id...
Ejemplos de ESP

Niveles de abstracción
Vistas

Documento
Frame
Requerimientos no funcionales
Escenarios, tácticas, frameworks
 Performance
 Disponibilidad
 Modificabilidad
 Segurida...
Atributos de Calidad
Escenarios
 Estímulo, ambiente, respuesta


Escenario de caso de uso:
•



Escenario de crecimiento:
•



Un usuario r...
Ejemplo de metodología
Refinamiento de Escenario



Los escenarios se refinan considerando:
•

1. Estímulo - La condición...
Lenguajes de Descripción Arquitectónica
(ADLs)
 Componentes
 Conectores
 Configuraciones o sistemas
 Propiedades no fu...
ADL
Acme
Aesop

Fecha
1995
1994

Investigador - Organismo
Monroe & Garlan (CMU), Wile (USC)
Garlan (CMU)

ArTek

1994

Arm...
Métodos basados en Arquitectura


Architecture Tradeoff Analysis Method (ATAM)



Quality Attribute Workshops (QAW)



...
Usos de estilos
Mary Shaw, David Garlan, 1996
•

IEEE98SA-Styles-Patterns.pdf

•

Inspirado en trabajo de Parnas, 1972 (“...
Síntesis
 Arquitectura:
 Visión de alto nivel
 Estilo - Patrón
 Previo a diseño de aplicación
 Requerimientos no func...
Referencias

 Len Bass, Paul Clements, Rick Lazman. Software Architecture in
Practice, 2a edición, Addison-Wesley, 2003
...
Webcast # 2 – Drilldown en estilos de arquitectura
 Diseñar desde arriba: La especificidad de la abstracción
arquitectóni...
¿Preguntas?
http://www.microsoft.com/spanish/msdn/arquitectura
Billyr@microsoft.com.ar
Upcoming SlideShare
Loading in...5
×

050608 architect academy webcast 1

171

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
171
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "050608 architect academy webcast 1"

  1. 1. Architect Academy: Seminario de Arquitectura de Software Billy Reynoso UNIVERSIDAD DE BUENOS AIRES Billyr@microsoft.com.ar
  2. 2. 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
  3. 3. ¿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)
  4. 4. 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
  5. 5. 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)
  6. 6. 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…
  7. 7. 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.
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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”
  12. 12. Estilos – Nueva concepción  Perry & Wolf, 1992  Componentes (ahora: Elementos)  Conectores  Configuraciones  Restricciones (Constraints)  “Mano mágica” (Fielding, 2000) UML?
  13. 13. 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
  14. 14. Estilos derivados  C2  GenVoca  REST
  15. 15. 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
  16. 16. Ejemplo  Mala práctica: • Aplicaciones clientes que consultan si sucedió algo • Listener de HTTP, Archivo, Colas  Buena práctica: • Estilo basado en Eventos
  17. 17. Ejemplo Arquitectura basada en eventos Modelo de push a veces se vincula con patrón Observador (Observer pattern)
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. Relación entre Estilos y Patrones (Patterns)
  23. 23. 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
  24. 24. 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
  25. 25. 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 • Resultados, extensiones y tradeoffs MVC
  26. 26. 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 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, ClaseResponsabilidadContrato (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 Está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 Idiomas Diseño inicial
  27. 27. 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…
  28. 28. Ejemplos de ESP Niveles de abstracción Vistas Documento Frame
  29. 29. Requerimientos no funcionales Escenarios, tácticas, frameworks  Performance  Disponibilidad  Modificabilidad  Seguridad  Verificabilidad (Testability)  Gestionabilidad (instrumentación, management, estado)  Usabilidad
  30. 30. Atributos de Calidad
  31. 31. Escenarios  Estímulo, ambiente, respuesta  Escenario de caso de uso: •  Escenario de crecimiento: •  Un usuario remoto de web requiere un reporte de base de datos en hora pico y lo recibe dentro de los 5 segundos. 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.
  32. 32. 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
  33. 33. Lenguajes de Descripción Arquitectónica (ADLs)  Componentes  Conectores  Configuraciones o sistemas  Propiedades no funcionales  Restricciones  Estilos  Evolución  Herramientas de verificación
  34. 34. ADL Acme Aesop Fecha 1995 1994 Investigador - Organismo Monroe & Garlan (CMU), Wile (USC) Garlan (CMU) ArTek 1994 Armani C2 SADL CHAM Darwin Jacal 1998 1996 1990 1991 1997 LILEANNA MetaH Rapide SADL 1993 1993 1990 1995 Terry, Hayes-Roth, Erman (Teknowledge, DSSA) Monroe (CMU) Taylor/Medvidovic (UCI) Berry / Boudol Magee, Dulay, Eisenbach, Kramer Kicillof , Yankelevich (Universidad de Buenos Aires) Tracz (Loral Federal) Binns, Englehart (Honeywell) Luckham (Stanford) Moriconi, Riemenschneider (SRI) UML 1995 Rumbaugh, Jacobson, Booch (Rational) UniCon 1995 Shaw (CMU) Wright 1994 Garlan (CMU) xADL 2000 Medvidovic, Taylor (UCI, UCLA) Observaciones Lenguaje de intercambio de ADLs ADL de propósito general, é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 - 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, énfasis en conectores y estilos ADL de propósito general, énfasis en comunicación ADL basado en XML
  35. 35. 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)
  36. 36. 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 Tablas de comparación de atributos Asignación de pesos a prioridades Paper
  37. 37. 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
  38. 38. 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…
  39. 39. 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
  40. 40. ¿Preguntas? http://www.microsoft.com/spanish/msdn/arquitectura Billyr@microsoft.com.ar
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×