Date post: | 03-Jan-2015 |
Category: |
Documents |
Upload: | almudena-marmol |
View: | 11 times |
Download: | 3 times |
Architect AcademyWebcast #4:
Diseñando la arquitectura
Billy Reynoso Universidad de Buenos Aires
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
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
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)
Estilos de Arquitectura
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
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
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
ADL Fecha Investigador - Organismo ObservacionesAcme 1995 Monroe & Garlan (CMU), Wile (USC) Lenguaje de intercambio de ADLsAesop 1994 Garlan (CMU) ADL de propósito general, énfasis
en estilosArTek 1994 Terry, Hayes-Roth, Erman
(Teknowledge, DSSA)Lenguaje específico de dominio -No es ADL
Armani 1998 Monroe (CMU) ADL asociado a AcmeC2 SADL 1996 Taylor/Medvidovic (UCI) ADL específico de estiloCHAM 1990 Berry / Boudol Lenguaje de especificaciónDarwin 1991 Magee, Dulay, Eisenbach, Kramer ADL con énfasis en dinámicaJacal 1997 Kicillof , Yankelevich (Universidad de
Buenos Aires)Adl - Notación de alto nivel paradescripción y prototipado
LILEANNA 1993 Tracz (Loral Federal) Lenguaje de conexión de módulosMetaH 1993 Binns, Englehart (Honeywell) ADL específico de dominioRapide 1990 Luckham (Stanford) ADL & simulaciónSADL 1995 Moriconi, Riemenschneider (SRI) ADL con énfasis en mapeo de
refinamientoUML 1995 Rumbaugh, Jacobson, Booch (Rational) Lenguaje genérico de modelado –
No es ADLUniCon 1995 Shaw (CMU) ADL de propósito general, énfasis
en conectores y estilosWright 1994 Garlan (CMU) ADL de propósito general, énfasis
en comunicaciónxADL 2000 Medvidovic, Taylor (UCI, UCLA) ADL basado en XML
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)
ADLs
Acme / Armani
Lenguaje de intercambio de arquitectura
1995, Carnegie Mellon
• Lenguaje Acme
• Acme Tool Developer’s Library (AcmeLib)
4 tipos de arquitectura
• Estructura, propiedades (comportamiento), restricciones, tipos y estilos
• Estructura: componentes, conectores, sistemas, puertos, roles, representaciones y rep-mapas
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
Acme/Armani
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
Aesop (inactivo?)
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
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)
C2
C2
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
CHAM
Ejemplo de compilador Lisp
Jacal (1/2)
http://www.microsoft.com/spanish/msdn/arquitectura
Jacal (2/2)
MetaH / AADL
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
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
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
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
UML y Arquitectura
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).
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
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
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)
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
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.
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()?
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
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)
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
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 variaci´´on 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.
OMG - MDA
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
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”.
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.html
Estudios de casos en Microsoft
• http://www.microsoft.com/resources/casestudies ...
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…
Referencias y recursos