Introducción, motivación y contexto Representación de arquitecturas

Transcripción

1 Arquitectura de Software II: Representación Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María <hernan at acm.org> Contenido del curso Introducción, motivación y contexto Representación de arquitecturas Vistas Viewtypes Vistas históricas y en uso Notaciones para vistas Elaboración de arquitecturas Estilos Patrones Líneas de productos Recuperación de arquitectura Principios y evaluación de arquitecturas Principios y axiomas Evaluación de arquitecturas Prácticas de arquitectura Organizaciones y Mercados Componentes 2 1

2 Vistas Vistas y perspectivas Vistas sincrónicas y diacrónicas Booch, OMT, 4+1, RM-ODP, Zachman Viewtypes Notaciones para vistas UML Lenguajes de RM-ODP ADLs II: Representación 3 Ejemplo de... qué? 4 2

3 En realidad... ESTOS SON DIAGRAMAS!!! NO MODELOS!!! 5 In reality These pictures are meant to entertain you. There is no significant meaning to the arrows between the boxes. (Citado en [Clements+ 2002]) 6 3

4 Y esto? 7 No todo diagrama es un modelo Modelos Modelo: representación simplificada de la realidad que puede ser manipulada para comprender mejor la realidad idealmente predictiva Modelos requeridos en arquitectura de SW del dominio (el problema) del sistema (software y computaciones) (la solución) del proceso (para construir el sistema) Los stakeholders hacen lecturas diferentes...pero complementarias...y deben ser consistentes (!) 8 4

5 Stakeholders analista specs sistema arquitetura arquitecto arquitetura arquitetura revisor jefe de projeto implantador QA sistema admin 9 Software y computaciones [1] sw vs. computaciones sw: textos computaciones: run-time en testing se distingue: errores: por personas defectos: en software fallas: en ejecución debemos distinguir: especificación del sistema: descripción razonada del sistema sistema (software): textos a ser escritos sistemas (computaciones): acciones deseadas 10 5

6 Software y computaciones [2] Nos interesan 5 niveles de descripción Computaciones: acciones del sistema dueño: usuario (a diferencia del cliente) Desplegables: binarios, configs para crear computaciones dueño: admindel sistema Software: textos para construir desplegables dueño: desarrollador Especificaciones de arquitectura: para construir software dueño: arquitecto Proceso: actividades para construir especificaciones dueño: jefe de proyecto Otras nociones pueden atarse a estos niveles Calidad Generación 11 Problema: Software y computaciones [3] Queremos poder hablar de defecto de una arquitectura (como en prueba de SW) pero los problemas que nos interesan son problemas sistémicos (no trazables a un lugar único) Idea: (cuadrar el círculo) Describir arquitecturas en que permitan asociar defectos (de arquitectura) y fallas (sistémicas) Posible solución Hablar en políticas y mecanismos 12 6

7 Complejidad Fuentes de complejidad Imprecisión Intangibilidad Concurrencia en ejecución Concurrencia en construcción Diversificación (líneas de productos) Tamaño 13 Vistas y Viewtypes 7

8 Vistas de Arquitectura De requisitos a arquitectura Hay varias soluciones de arquitectura para cada conjunto de requisitos En general, no hay una solución óptima La solución escogida depende de compromisos entre los stakeholders La arquitectura de software debería facilitar las negociaciones entre stakeholders y la captura de decisiones finales ancladas en los compromisos Espacios de decisión para compromisos [Hofmeister00] Tecnológico Organizacional Producto Para justificar los compromisos hay que mirar la arquitectura desde diferentes perspectivas Desde la organización al desarrollo y despliegue 15 Viewtypes [Clements+ 2002] Tipos de vistas Maneras simultáneas de pensar sobre sistemas de software Restringen los elementos y relaciones disponibles en sus vistas 3 maneras propuestas: módulos estructura como conjunto de unidades de implantación componentes-y-conectores estructura como conjunto de elementos con comportamiento e interacciones durante ejecución allocation (asignación) relación con estructuras no-software del ambiente 16 8

9 Viewtype Módulos Módulo: unidad de código que implementa un conjunto de responsabilidades Ejemplos: clase, colección de clases, capa Propiedades: responsabilidades, visibilidad, autor Relaciones: parte-de, hereda-de Estilos de representación Descomposición (en sistemas, subsistemas, etc.) Uso (dependencias) Generalización En Capas 17 Viewtype Componentes+Conectores Expresa comportamiento en ejecución Elementos: componentes y conectores Descomposición: conectores a componentes+conectores, etc. Estilos de representación Pipe and filter Shared data Publish-subscribe Cliente-servidor Peer-to-peer Communicating Processes 18 9

10 Viewtype Asignación Mapeo de elementos de software a elementos del ambiente Estilos de representación Despliegue (deployment) (mapeo de procesos a hardware) Implantación (módulos a infraestructura de desarrollo) Asignación de trabajo (módulos a equipos de desarrollo) 19 Vistas históricas y en uso 10

11 Representación de un (sub-)sistema......parcial...basada en una perspectiva Idea: participantes necesitan razonar sobre el sistema entregar información que suprima detalles irrelevantes Vista Conceptos Vista = representación de un conjunto de elementos y relaciones del sistema [Clements+] Perspectiva = preocupaciones propias de un stakeholder Esquema de vistas = definiciones de vistas y perspectivas asociadas 21 Vistas antes de vistas : Parnas Parnas (1974): estructuras (=unidad + relación) 1. módulos sobre: asignaciones de trabajo, parte-de para: razonar sobre construcción 2. usos sobre: programas, depende-de para: razonar sobre dependencias 3. procesos sobre: procesos, trabaja-con para: razonar sobre ejecución 22 11

12 Booch y OMT 1. Visión Estructural 3. Visión Funcional 2. Visión Dinámica 23 Booch y OMT OMT: Rumbaugh, Blaha, Premerlani, Eddy, Lorenson (1991) 1. Vista estructural: estructura estática del mundo real sobre: objetos y relaciones representación: diagrama de objetos 2. Vista dinámica: comportamiento del sistema sobre: acciones en el tiempo para: describir secuencias de interacciones y eventos representación: diagrama de eventos (escenarios), diagrama de flujo de eventos, diagrama de estados 3. Vista funcional: procesamiento de información sobre: procesamiento de valores para: describir dependencia entre valores y funciones representaci ón: diagrama de flujo de datos 24 12

13 Booch Semántica dinámica Semántica estática 1. Visión lógica Estructura de Clase Estructura de Objeto 2. Visión física Arquitectura de Módulo Arquitectura de Proceso 25 Kruchten (1995): 4+1 views 1. Vista lógica: requisitos funcionales Kruchten 4+1 sobre: abstracciones clave del dominio (objetos/clases) para: completitud de requisitos, síntesis de entidades y funciones 2. Vista de procesos: ejecución sobre: procesos y máquinas para: concurrencia/distribución, integridad, tolerancia a fallas 3. Vista de desarrollo: software y trabajo sobre: módulos, asignación de requisitos, asignación de trabajo para: planificar, evaluar costos, medir progreso, razonar sobre reuso 4.Vista física: requisitos no funcionales sobre: mapeamiento de elementos a máquinas para: razonar sobre requisitos no funcionales (disponibilidad, confiabilidad, rendimiento, escalabilidad...) 5.Vista de escenarios: combinación sobre: casos de uso 26 13

14 ***DIBUJO*** Diferencias Orientado a proceso vs. producto Síncronas vs. diácronas Roles especializados vs. aspectos de un mismo especialista 28 14

15 Open Distributed Processing Reference Model originalmente para describir sistemas de Telecom RM-ODP [1] Visión de Empresa p o l í t i c a Visión de Información Visión de Computación Visión de Ingeniería Visión de Tecnología 29 RM-ODP [2] 1. Vista de la empresa sobre: propósito, ámbito y restricciones que rigen el negocio para: extraer requisitos y estructuras de la organización 2. Vista da información sobre: información (datos) requeridos por el sistema representación: esquemas (estático, invariante, y dinámico) 3. Vista computacional sobre: aplicaciones y objetos de infraestructura (interfaces, actividades, contratos); modelos dinámicos para: descomponer funcionalidad 4. Vista de ingeniería sobre: objetos y canales para: infraestructura de distribución 5. Vista tecnológica sobre: hardware y software específicos para: razonar sobre tecnología y productos 30 15

16 Propuestas por [Hofmeister+] Vista Conceptual Vista Tecnológica Vista Física Vista de Desarrollo Extensión de Rito-Silva para Fénix Vista de Objetivos Vista del Negocio Hofmeister+ 31 Hofmeister

17 Permite [Rito-Silva] Vista de Objetivos Identificación de los factores que influencian la arquitectura Los porqué La definición de estrategias para la solución Los cómo Decisiones de diseño se basarán en las estrategias aquí definidas 33 Marco metodológico para vistas Enfocado a organizaciones Estructura lógica: clasifica y organizar elementos empresariales necesarios para hacer sistemas Vistas 1. Vista contextual (propósito del negocio) 2. Vista conceptual (naturaleza del negocio) 3. Vista arquitectural o lógica 4. Vista física (tecnología) 5. Vista de proyecto 6. Vista del sistema listo (funciones) (ver notas) Zachman 34 17

18 ENTERPRISE ARCHITECTURE - A FRAMEWORK TM PEOPLE MOTIVATION DATA FUNCTION NETWORK What How Where Who When Why TIME SCOPE (CONTEXTUAL) List of Things Important to the Business List of Processes the Business Performs List of Locations in which the Business Operates List of Organizations Important to the Business List of Events Significant to the Business List of Business Goals/Strat SCOPE (CONTEXTUAL) Planner ENTITY = Class of Business Thing Function = Class of Business Process Node = Major Business Location People = Major Organizations Time = Major Business Event Ends/Means=Major Bus. Goal/ Critical Success Factor Planner ENTERPRISE MODEL (CONCEPTUAL) e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics System e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan ENTERPRISE MODEL (CONCEPTUAL) Owner Ent = Business Entity Reln = Business Relationship Proc. = Business Process I/O = Business Resources Node = Business Location Link = Business Linkage People = Organization Unit Work = Work Product Time = Business Event Cycle = Business Cycle End = Business Objective Means = Business Strategy Owner SYSTEM MODEL (LOGICAL) e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System Architecture e.g. Human Interface Architecture e.g. Processing Structure e.g., Business Rule Model SYSTEM MODEL (LOGICAL) Designer Ent = Data Entity Reln = Data Relationship Proc.= Application Function I/O = User Views Node = I/S Function (Processor, Storage, etc) Link = Line Characteristics People = Role Work = Deliverable Time = System Event Cycle = Processing Cycle End = Structural Assertion Means =Action Assertion Designer TECHNOLOGY MODEL (PHYSICAL) e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY MODEL (PHYSICAL) Builder Ent = Segment/Table/etc. Reln = Pointer/Key/etc. Proc.= Computer Function I/O = Data Elements/Sets Node = Hardware/System Software Link = Line Specifications People = User Work = Screen Format Time = Execute Cycle = Component Cycle End = Condition Means = Action Builder DETAILED REPRESEN- TATIONS (OUT-OF- CONTEXT) e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED REPRESEN- TATIONS (OUT-OF CONTEXT) Ent = Field Reln = Address Proc.= Language Stmt I/O = Control Block Node = Addresses Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-condition Means = Step Sub- Contractor Sub- Contractor FUNCTIONING ENTERPRISE e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY FUNCTIONING ENTERPRISE John A. Zachman, Zachman International (810) Figura A.1 Framework de Zachman 35 Notaciones para vistas 18

19 2 grandes formas Gráfica UML, otros Notaciones para vistas Formal Arquitecture Description Languaegs (ADLs) 37 UML UML es 3 cosas Notación para describir cosas con orientación a objetos Meta-modelo de sistemas de software clases, subsistemas, componentes, nodos Mecanismo extensible para describir cosas usando orientación a objetos estereotipos, perfiles lenguaje: OCL ( Object Constraints Language ) 38 19

20 Los stakeholders leen/usan documentos Vistas describen aspectos del sistema Diagramas son notación Relación M:N Vistas y diagramas Una vista puede requerir varios tipos de diagramas Un tipo de diagrama puede ser usado en varias vistas Ejemplos Perfiles de UML EDOC: Enterprise Distributed Object Computing EAI: Enterprise Application Integration RM-ODP Lenguajes para cada vista 39 Existe un perfil UML para EAI UML Profile for EAI Perfil UML para EAI 2 metamodelos: MM de Integración: especializa el Flow Composition Model (que especializa el UML Profile for EDOC ) MM Común de Aplicaciones MM de interfaces de aplicaciones MM de lenguajes MM de representaciones físicas 40 20

21 MM de interfaces de aplicaciones 41 Architecture Description Languages Formales Objetivo: permitir razonamiento automatizado Problemas propios de métodos formales ADLs Más difícil (aún) probar que algo está correcto que escribirlo varias veces 42 21

22 Darwin [Jazayeri/Ran/van der Linden] ADL: Darwin Conceptos componentes con servicios (provistos y requeridos) instanciación y binding configuraciones: guardas y replicación (ver ejemplo) interfaces compuestas tipos genéricos evaluación parcial 43 Darwin: pipes [1] component Server { provide p; } component Client { require r; } component System inst } A: Client; B: server; bind A.r B.p; 44 22

23 component pipeline (int n) { provide input; require output; array F[n] : filter; forall k : 0..n-1 { inst F[k ] (n, k); bind F[k ].output output; when k < n-1 bind F[k].next F[K+1].prev; } bind input F[0].prev; F[n-1].next output; } Darwin: pipes [2] 45 Algunos casos para estudio crítico 23

24 Ejemplo publicado OOPSLA 2000 Practitioner Report Comentarios largo (124 pp.) dirigido a múltiples audiencias cuenta una historia y ofrece una metáfora Ejemplo: Cash-Link exhibe rastreabilidad (refinamiento derivable) 47 Sistema público Ejemplo: MINVU Obras Requisitos disponibles en sitio Web del curso /ejemplos/minvu_obras-bases_tecnicas.pdf /ejemplos/minvu_obras-plataforma.pdf Solución propuesta ver notas MINVU_Obras-Propuesta_Tecnica (42 pags) 48 24

25 MINVU Obras [2] 49 Propósito Estilo Audiencias Destacamos: Explicación Refinamiento Rastreabilidad Evaluación Ajuste a propósito(s) MINVU Obras Análisis 50 25

26 [Clements+ 2002] Referencias Paul Clements (Ed.), Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford Documenting Software Architectures: Views and Beyond Addison Wesley (2002) [Kruchten 2000] Philippe Kruchten The Rational Unified Process: An Introduction (2nd Ed.) Addison Wesley (2000) [Jazayeri+ 2000] Mehdi Jazayeri, Alexander Ran, Frank van der Linden Software Architectures for Product Families Addison Wesley (2000) 51 26