Contenido del curso. Arquitectura de Software II: Representación. Ejemplo de... qué? II: Representación. En realidad...

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 Calidad Elaboración de arquitecturas Patrones Líneas de productos Procesos y evaluación de arquitecturas Procesos (incl. taller) Prácticas de arquitectura Organizaciones y Mercados Componentes 2 Fuentes de diversidad Vistas Vistas y perspectivas Vistas sincrónicas y diacrónicas Booch, OMT, 4+1, RM-ODP, Zachman Notaciones para vistas UML, lenguajes de RM-ODP, ADLs II: Representación Ejemplo de... qué? 3 4 [*** CORBA ***] Otro ejemplo En realidad... ESTOS SON DIAGRAMAS!!! NO OS!!! 5 6 1

2 Modelos No todo diagrama es un modelo Modelo: representación simplificada de la realidad que puede ser manipulado para comprender mejor la realidad idealmente predictivo 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 (!) analista jefe de projeto specs sistema arquitecto arquitetura arquitetura arquitetura implantador Stakeholders revisor QA sistema admin 7 8 Fuentes de complejidad Imprecisión Intangibilidad Concurrencia en ejecución Concurrencia en construcción Diversificación (líneas de productos) Tamaño Complejidad Vistas 9 Modelo conceptual (Clements et al.) [*** unidades y relaciones ***] Vistas 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 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

3 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 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 Software y computaciones [2] Para aclarar ideas Software: textos Computaciones: acciones Herencia : subclases!= subtipos reuso de código vs. substitutabilidad ( conformance ) Booch y OMT 1. Visión Estructural 2. Visión Dinámica 3. Visión Funcional Booch y OMT OMT: Rumbaugh, Blaha, Premerlani, Eddy, Lorenson (1991) 1. Vista estructural: estructura estática del mundo real sobre: objetos y relaciones 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 dados Semántica dinámica Semántica estática 1. Visión lógica 2. Visión física Estructura de Clase Estructura de Objeto Arquitectura de Módulo Arquitectura de Proceso Booch

4 Kruchten 4+1 [1] Kruchten (1995): 4+1 views 1. Vista lógica: requisitos funcionales 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 (Cont.) Kruchten 4+1 [2] 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 RM-ODP [1/2] Open Distributed Processing Reference Model originalmente para describir sistemas de Telecom Información Empresa p o l í t i c a Ingeniería Tecnología Computación RM-ODP [2/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 de la empresa representación: enterprise language (ver ejemplo) 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 RM-ODP (Cont.) 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 Otros esquemas de vistas

5 Zachman 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) ARCHITECTURE - A FRAMEWORK MOTIVATION PEOPLE DATA FUNCTION NETWORK What How Where Who When Why List of Things Important List of Processes the List of Locations in which List of Organizations List of Events Significant List of Business Goals/Strat to the Business Business Performs the Business Operates Important to the Business to the Business ENTITY = Class of Function = Class of Node = Major Business Ends/Means=Major Bus. Goal/ Business Thing Business Process Location People = Major Organizations Time = Major Business Event Critical Success Factor e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan System Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System e.g. Human Interface e.g. Processing Structure e.g., Business Rule Model Architecture Architecture Node = I/S Function Ent = Data Entity Proc.= Application Function (Processor, Storage, etc) People = Role Time = System Event End = Structural Assertion Reln = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverable Cycle = Processing Cycle Means =Action Assertion 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 Node = Hardware/System Ent = Segment/Table/etc. Proc.= Computer Function Software People = User Time = Execute End = Condition Reln = Pointer/Key/etc. I/O = Data Elements/Sets Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action SYSTEM (LOGICAL) Designer TECHNOLOGY (PHYSICAL) 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 Proc.= Language Stmt Node = Addresses People = Identity Time = Interrupt End = Sub-condition Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step Builder SCOPE (CONTEXTUAL) Planner (CONCEPTUAL) Owner SYSTEM (LOGICAL) Designer TECHNOLOGY (PHYSICAL) Builder DETAILED REPRESEN- TATIONS (OUT-OF- CONTEXT) Sub- Contractor FUNCTIONING Sub- Contractor FUNCTIONING e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY John A. Zachman, Zachman International (810) Figura A.1 Framework de Zachman TIME TM SCOPE (CONTEXTUAL) Planner (CONCEPTUAL) Owner Notaciones para vistas UML son 3 cosas notación meta-modelo de sistemas de software clases, subsistemas, componentes, nodos mecanismo extensible para describir cosas usando orientación a objetos UML 28 Vistas y diagramas Los stakeholders leen/usan documentos Vistas describen aspectos del sistema Diagramas son notación Relación M:N 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 vistas Perfil UML para EAI Existe un perfil UML para EAI UML Profile for 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

6 MM de interfaces de aplicaciones Architecture Description Languages Formales Objetivo: permitir razonamiento automatizado Problemas propios de métodos formales Más difícil (aún) probar que algo está correcto que escribirlo varias veces ADLs ADL: Darwin Darwin [Jazayeri/Ran/van der Linden] 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 component Server { provide p; component Client { require r; component System inst A: Client; B: server; bind A.r B.p; Darwin: pipes [1] 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] Estudio crítico de caso 35 6

7 Ejemplo: Cash-Link Ejemplo publicado OOPSLA 2000 Practitioner Report Comentarios largo (124 pp.) dirigido a múltiples audiencias cuenta una historia y ofrece una metáfora exhibe rastreabilidad (refinamiento derivable) Ejemplo: MINVU Obras Sistema público Requisitos disponibles en sitio Web del curso arquitectura/ejemplos/minvu_obras-bases_tecnicas.pdf arquitectura/ejemplos/minvu_obras-plataforma.pdf Solución propuesta ver notas MINVU_Obras-Propuesta_Tecnica (42 pags) MINVU Obras [2] Propósito Estilo Audiencias Destacamos: Explicación Refinamiento Rastreabilidad Evaluación Ajuste a propósito(s) MINVU Obras Análisis 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) Philippe Kruchten The Rational Unified Process: An Introduction (2nd Ed.), Addison Wesley (2000) Mehdi Jazayeri, Alexander Ran, Frank van der Linden Software Architectures for Product Families, Addison Wesley (2000) 41 7