Architect Academy Webcast

1
Architect AcademyWebcast 4Diseñando la
arquitectura

• Billy Reynoso Universidad de Buenos Aires
• billyr_at_microsoft.com.ar

2
Roadmap

• Webcast 1 Qué es la Arquitectura de Software?
• Webcast 2 Drilldown en Estilos de Arquitectura
  de Software
• Webcast 3 Arquitectura para distribución y
  agregación Services Oriented Architecture (SOA)
• Webcast 4 Diseñando la arquitectura

3
Objetivos

• Propósito de la serie de Webcasts
• Comprender la teoría y orientar la práctica de la
  Arquitectura de Software
• Vincular concepciones de la academia y la
  industria
• Relacionar los principios teóricos con
  herramientas y ambientes Microsoft
• Propósito de la sesión de hoy
• Conocer conceptos y herramientas de diseño
  arquitectónico de alto nivel, pero con impacto
  sobre código
• Disipar algunos malentendidos comunes
• Proporcionar referencias para profundizar en la
  práctica específica del diseño arquitectónico

4
Diseñando la Arquitectura

• Temario
• Problemas y perspectivas del diseño
  arquitectónico
• Concepciones de diseño de la industria y la
  academia
• Vista rápida de los Lenguajes de Descripción de
  Arquitectura (ADL)
• ACME/Armani, Wright, CHAM, ADLs basados en C2
  xADL, Jacal
• La Arquitectura no es modelado en UML
• Los límites de UML (2) como lenguaje de modelado
  arquitectónico
• Perspectiva académica No es el punto de vista
  de Microsoft
• Arquitectura de software y MDA
• Estado de arte del diseño arquitectónico Sacando
  provecho de herramientas, patrones y prácticas
  Factorías y DSLs
• Estudios de casos
• Visión del futuro Integrando arquitectura,
  diseño y desarrollo en Visual Studio 2005 (Team
  System)

5
Estilos de Arquitectura

• 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 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

6
ADLs

• Herramientas de modelado que soportan desarrollos
  basados en arquitecturas
• Estructura de alto nivel, no detalle de
  implementación
• Poco consenso respecto a definición de ADL,
  aspectos a considerar y adecuación de ADLs a
  estilos
• Poca distinción entre ADL, especificación formal,
  interconexión de módulos (MIL), herramientas de
  modelado y hasta lenguajes de programación

7
Condiciones de la descripción arquitectónica

• Componentes, con aserción de propiedades,
  interfaces e implementaciones
• Conectores, con aserción de protocolos,
  interfaces e implementaciones
• Configuraciones o sistemas, abstracción y
  encapsulamiento
• Propiedades no funcionales
• Restricciones
• Estilos
• Evolución
• Herramientas de verificación

8
(No Transcript)
9
Otras herramientas

• 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)
• Lenguajes específicos de dominio (DSLs)

10
ADLs
11
Acme / Armani

• Lenguaje de intercambio de arquitectura
• 1995, Carnegie Mellon
• Lenguaje Acme
• Acme Tool Developers Library (AcmeLib)
• 4 tipos de arquitectura
• Estructura, propiedades (comportamiento),
  restricciones, tipos y estilos
• Estructura componentes, conectores, sistemas,
  puertos, roles, representaciones y rep-mapas

12
Acme/Armani

• Semántica sólo como comentario
• No genera código
• Maneja estilos (familia)
• Varias herramientas en ambiente Windows
• AcmeStudio
• Armani con front-end Visio
• ISI front-end Powerpoint
• ADML lenguaje de markup de arquitectura,
  derivado de Acme (estándar)
• Armani ?ADL. Declarativo

13
Acme/Armani
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
ADML

• Open Group, 2000
• ADML XML con DTD
• xADL (Zaydal,UCI) Schemas para estilos
  (Aplicación de xArch)
• xArch (UCI/Carnegie Mellon) lenguaje basado en
  XML para descripción de arquitecturas
  Placeholder para implementaciones variables

19
Aesop (inactivo?)
20
C2 SADL, C2SADEL

• C2 SADL (Simulation Architecture Description
  Language)
• ADL que permite describir arquitecturas en estilo
  C2
• C2SADEL Variante. Incluye DRADEL (Development
  of Robust Architectures using a Description and
  Evolution Language)
• xArch, xADL Inicialmente ligados a C2

21
C2 SADL, C2SADEL

• SADL
• Módulos declarativos e imperativos
• 1) IDN Interface Description Notation
• 2) ADN Architecture Description Notation
• 3) ACN Architecture Construction Notation
• Windows
• DRADEL (Int. Para C2SADEL)
• SAAGE (requiere Rose o Dradel)
• ArchStudio Argo (discontinuado)

22
C2
23
C2
24
CHAM

• Chemical Abstract Machine
• Técnica de especificación basada en álgebra de
  procesos
• Moléculas (componentes básicos)
• Soluciones de moléculas (multiconjuntos que
  definen estados)
• Reglas de transformación (cambios de estado) No
  determinismo si hay de una regla para una
  molécula o solución

25
CHAM

• Ejemplo de compilador Lisp

26
(No Transcript)
27
(No Transcript)
28
Jacal (1/2)
http//www.microsoft.com/spanish/msdn/arquitectura
29
Jacal (2/2)
30
(No Transcript)
31
(No Transcript)
32
(No Transcript)
33
(No Transcript)
34
(No Transcript)
35
MetaH / AADL
36
Wright (1/2)

• Herramienta de formalización de conexiones
  arquitectónicas, CMU (parte de proyecto ABLE)
• ABLE herramienta de diseño (Aesop),
  especificación formal (Wright)
• Integración de metodología formal con
  descripciones arquitectónicas
• Aplica procesos formales (álgebra de proceso y
  refinamiento de proceso) a verificación
  automatizada de propiedades de arquitectura

37
Wright (2/2)

• Declara conjunto de tipos de componentes y
  conectores y conjunto de restricciones
• Modelo semántico basado en CSP (Communicating
  Sequential Process de Hoare)
• Verificación mediante verificador comercial FDR
• Restricciones predicado que debe ser satisfecho
  por cualquier configuración que se declare
  miembro del estilo
• Notación de restricciones cálculo de predicados
  de primer orden
• Sub-estilos heredan de estilos
• No posee interfaz gráfica nativa
• No genera código ejecutable

38
(No Transcript)
39
Modelos formales

• Darwin cálculo Pi
• Wright 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

40
Conclusiones respecto de ADLs

• No hay ninguno que sea dominante en la academia o
  la industria
• Deben reformularse para vincularse con XML y UML
  2
• Muchos de ellos sin actividad en los últimos años
• Algunos son específicos de industrias pesadas
• Poco énfasis en desarrollo de ADLs en SEI/CMU
• Momento de transición
• Extensiones arquitectónicas de UML 2, MDA, DSLs
• Adopción de modelos abstractos y factorías en la
  industria
• Modelado comienza a vincularse a herramientas de
  desarrollo
• No se quiere repetir la experiencia de los CASE

41
UML y Arquitectura
42
UML Limitaciones arquitectónicas

• Hofmeister, 1999
• La notación gráfica de UML es deficiente para
  mostrar correspondencias entre elementos en
  diferentes vistas. Esto se logra mejor con una
  tabla.
• Protocolos no se puede mostrar comunicación
  peer-to-peer en UML 1. Hay que utilizar una
  notación externa, como ROOM (Real-time
  Object-Oriented Modeling).
• Puertos en componentes. La notación es confusa y
  requiere (p. ej.) anidamiento. Una notación
  lollipop sería preferible.
• Aspectos dinámicos de la estructura. Diagramas de
  secuencia y de estado describen la conducta
  dinámica, pero no soportan configuración dinámica
  (ni siquiera para estilos basados en objeto).

43
UMLLimitaciones arquitectónicas

• Abdurazik, 2000
• Los diagramas de componentes de UML no
  representan la descomposición lógica de un
  sistema en subsistemas reutilizables y
  combinables
• UML no proporciona concepto de conectores como
  objetos de primera clase
• Estos serían un híbrido de una clase de
  asociación y una dependencia entre una clase y
  una interface de otra clase.
• UML se puede extender para modelar cualquier
  cosa, pero se pierde soporte de herramientas e
  intercambiabilidad

44
UMLLimitaciones arquitectónicas

• Cuestionamientos genéricos (reconocidos por OMG)
• Tamaño excesivo (al mismo tiempo demasiado y
  demasiado poco)
• Semántica ambigua
• Puede parecer visualmente clara, pero las
  intuiciones subyacentes son confusas (Garlan)
• La interpretación de los tipos de UML difiere
  entre stakeholders con distinta formación e
  intereses (Perrouin 2002)
• La semántica no está formalmente definida, sino
  librada a la imaginación del usuario
  (Klaus-Dieter Schewe)
• Relaciones ambiguas y oscuras entre vistas, no
  susceptibles de tratamiento formal
• Extensibilidad a costa del soporte de
  herramientas y de una especificación estándar
• Adaptabilidad (customización) limitada

45
UMLLimitaciones arquitectónicas

• Cuestionamientos genéricos (cont.)
• Soporte insatisfactorio para desarrollo basado en
  componentes
• Posibilidad de incurrir en el síndrome de la
  segunda versión (Brooks)
• Poca orientación semántica para arquitectos
  (p.ej. cuándo usar un diagrama)
• In-analisibilidad (Garlan)
• Aunque se lo pueda representar, y luzca bien, no
  hay nada que se pueda hacer con él, excepto
  usarlo como documentación
• Falta de soporte para estilos
• Como profiles el manejo es pesado como packages
  se soporta agregación, pero no restricciones
  (Garlan)

46
UMLLimitaciones arquitectónicas

• Guéhéneuc-Amiot-Douence-Cointe (2002)
• UML y lenguajes OO tienen conceptos de clase y
  herencia.
• Pero hay nociones que existen en UML y no en
  lenguajes estereotipo, relaciones de clases
  binarias (asociación, agregación, composición)
• La definición de relaciones binarias en UML está
  en lenguaje natural y es ambigua no hay
  lineamientos sobre su implementación.

Ver diagramas en Enterprise Architect,
eventualmente
47
UMLLimitaciones arquitectónicas

• Guéhéneuc-Amiot-Douence-Cointe (2002, cont.)
• Las herramientas (Rational Rose, Together,
  Borland Jbuilder, ArgoUML) no tienen definiciones
  claras de relaciones binarias. Las distinguen
  gráficamente, pero el código generado es el
  mismo.
• Clases Asociadas ocurren juntas (Factura
  Vendedor) 2 elementos tienen una relación- Línea
  continua
• Composición una clase es parte de otra
  (Item-Factura) Línea con rombo lleno en clase
  mayor Forma fuerte de agregación
• Agregación Sin herencia (p.ej. Orden de compra
  tiene un cliente) Rombo sin relleno. Una clase
  es usada por otra.

48
UMLLimitaciones arquitectónicas

• Este diagrama de clases muestra tres clases, una
  relación de herencia y una de agregación
• En Java esto resultaría en
• public class A
• ...
• public class B extends A
• ...
• public class C
• ...
• Cómo se implementa la relación de agregación
  entre B y C? Como campo? Como colección? Como
  par de getter y setter? Como par de métodos
  add()-remove()?

49
UMLLimitaciones arquitectónicas

• En Rational Rose 2001.03.00 este diagrama de dos
  clases con una relación de agregación genera el
  mismo código Java que para relaciones de
  asociación y composición, aunque sus semánticas y
  notaciones sean distintas
• Cuando se reemplaza el array por una colección
  instancia de java.util.vector p.ej. (como se hace
  habitualmente) y se hace ingeniería reversa del
  código para generar UML, desaparece la
  agregación, y aparece una asociación
  inconsistente con el diagrama original

50
UMLLimitaciones arquitectónicas

• Martin Glinz - Deficiencias de UML como lenguaje
  de especificación de requisitos
• UML no puede modelar interacciones iniciadas por
  el sistema (y no por un actor)
• UML prohibe explícitamente establecer relaciones
  entre actores, perdiendo capacidad para expresar
  contextos complejos
• UML no permite expresar estructuras ni jerarquías
  entre casos de uso
• UML no permite relaciones entre casos de uso (p.
  ej. un caso que requiera la finalización de otro)

51
UMLLimitaciones arquitectónicas

• Martin Glinz - Deficiencias de UML como lenguaje
  de especificación de requisitos (Cont.)
• No se pueden modelar máquinas de estado
  gobernadas por un conjunto de casos de uso
• El modelado de flujos de información en un
  sistema consistente en subsistemas no está bien
  resuelto en UML
• UML no puede modelar el comportamiento de
  subsistemas de alto nivel
• UML no puede modelar la descomposición de un
  sistema distribuido
• UML no puede modelar todos los aspectos de un
  sistema complejo en una sola vista

52
UML y arquitectura

• Se recomienda el uso de UML para
• Esbozos genéricos o puntuales.
• White boarding.
• Servilletas.
• Documentación.
• Dibujos conceptuales que no se relacionan con
  código en forma directa.
• Se recomendarían DSLs para
• Abstracciones precisas a partir de las cuales se
  generará código.
• Abstracciones precisas que mapean sobre puntos de
  variacion en frameworks y componentes.
• Mapeados precisos entre DSLs.
• Dibujos conceptuales que tienen mapeados precisos
  y especificables sobre otros DSLs o sobre
  artefactos de código.

53
(No Transcript)
54
(No Transcript)
55
(No Transcript)
56
(No Transcript)
57
OMG - MDA
58
No cubierto por MDA

• Capturar, analizar y administrar requerimientos,
  identificando relaciones entre ellos, el diseño
  arquitectónico y la implementación y permitiendo
  validar si los requerimientos han sido
  satisfechos
• Definir AS de manera que soporte análisis de
  seguridad, performance y confiabilidad y que
  permita transformaciones en dos vías desde el
  requerimiento hasta el despliegue
• Definir empaquetado de componentes ejecutables
  del sistema
• Definir casos de prueba, lotes de prueba y otros
  artefactos, permitiendo administrar y mostrar los
  resultados
• Identificar relaciones trazables entre los
  modelos y otros artefactos, permitiendo evaluar
  impacto de negocios por caída del sistema,
  configurar sistemas para satisfacer
  requerimientos y forzar constraints durante la
  configuración
• Permitir manejo de versión y asociar reportes y
  solicitudes de cambio con versiones específicas

59
DSLs

• Think of a DSL as a small, highly focused
  language for solving some clearly identifiable
  problem that an analyst, architect, developer,
  tester, or system administrator must wrestle
  with. Developers are already familiar with
  examples of DSLs SQL for data manipulation, XSD
  for XML document structure definition, and so on.
  Another example from Visual Studio Team Edition
  for Software Architects is a DSL for modeling the
  logical structure of datacenter hardware and host
  software configurations. This DSL and its related
  graphical designer can be used to validate during
  design time that applications are configured to
  match their intended deployment targets, alerting
  the developer to problems when they can be fixed
  more cheaply.

60
Referencias de Casos

• Len Bass, Paul Clements, Rick Kazman. Software
  Architecture in Practice, 2ª edición
• Estudios de casos en documentación del SEI en
  Carnegie Mellon
• http//www.sei.cmu.edu/publications/publications.h
  tml
• Estudios de casos en Microsoft
• http//www.microsoft.com/resources/casestudies ...

61
(No Transcript)
62
Conclusiones generales

• Importancia de la Arquitectura de Software
• Alto nivel de abstracción
• Vinculada con requerimientos no funcionales
• Criticidad de las decisiones tempranas de
  arquitectura
• 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, MSF

63
Referencias y recursos
64
(No Transcript)
65
(No Transcript)
66
(No Transcript)
67
(No Transcript)
68
(No Transcript)
69
(No Transcript)
70
(No Transcript)
71
Preguntas?

• billyr_at_microsoft.com.ar