Diseño Arquitectónico. Objetivos. Establecer la arquitectura global del sistema de software. Arquitectura de software.

Transcripción

1 Diseño Arquitectónico Objetivos Estabecer a arquitectura goba de sistema de software Introducir e diseño arquitectónico y discutir su importancia Expicar por qué se requieren mútipes modeos par documentar una arquitectura de software Describir diferentes tipos de modeos de arquitectura que puede ser usados Discutir cómo modeos de referencia específicos de dominio pueden ser usado como una base para íneas de productos y para comparar arquitecturas de software Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 1 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 2 Tópicos cubiertos Arquitectura de software Estructuración de sistema Modeos de contro Descomposición moduar Arquitecturas específicas de dominio E diseño arquitectónico corresponde a proceso de diseño que identifica os subsistemas que conforman un sistema y a infraestructura de contro y comunicación La saida de este proceso de diseño es una descripción de a arquitectura de software Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 3 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 4 Diseño arquitectónico Ventajes de arquitectura expícita Etapa temprana de proceso de diseño de sistema Comunicación entre os Stakehoders Representa e puente entre e proceso de especificación y diseño A menudo se ejecuta en paraeo con agunas actividades de especificación La arquitectura puede ser usada como un foco de discusión por os stakehoders de sistema Anáisis de sistemas Ayuda a estabecer si e sistema puede cumpir os requerimientos no funcionaes. Invoucra a identificación de os componentes principaes de sistema y su comunicación Reutiización a gran escaa La arquitectura puede ser reutiizada a través de un rango de sistemas Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 5 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 6

2 Proceso de diseño arquitectónico Subsistemas y móduos Estructuración de sistema E sistema se descompone en varios subsistemas principaes y a comunicación entre estos subsistemas es identificada Modeado de contro Se estabece un modeo de as reaciones de contro entre as diferentes partes de sistema Descomposición moduar Los subsistemas identificados se descomponen en móduos Un subsistema es un sistema por derecho propio cuya operación es independiente de os servicios provistos por otros subsistemas Un móduo es un componente de sistema que provee servicios a otros componente pero no se consideraría normamente como un sistema separado Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 7 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 8 Modeos arquitectónicos Modeos arquitectónicos Diferentes modeos arquitectónicos pueden ser producidos durante e proceso de diseño Cada modeo presenta diferente perspectivas de a arquitectura Modeo estático estructuraes que muestra os componentes principaes de sistema Modeo dinámico de proceso que muestra a estructura de proceso de sistema Modeo de interfaz que define as interfaces de os subsistemas Modeo de reaciones taes como un modeo de fujo de datos Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 9 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 10 Estios arquitectónicos Atributos de a arquitectura E modeo arquitectónico de un sistema podría estar en conformidad con un modeo más genérico o estio Estar a tanto de estos estios puede simpificar e probema de definir arquitecturas de sistemas Sin embargo, a mayoría de sistemas grandes son heterogéneos y no siguen un único estio arquitectónico Desempeño Locaizar operaciones para minimizar a comunicación entre subsistemas Seguridad Usar una arquitectura de capas con recursos críticos en capas internas Protección Aisar componentes componentes críticos de seguridad Disponibiidad Incuir componentes críticos en a arquitectura Mantenibiidad Usar componentes autocontenidos de grano fino Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 11 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 12

3 Estructuración de sistema Sistema de contro de robot empacador Concerniente con a descomposición de sistema en subsistemas que interactúan E diseño arquitectónico se expresa normamente como un diagrama de boques que representa un visión genera de a estructura de sistema Se pueden desarroar modeos más específicos que muestran cómo os subsistema comparten datos, cómo se distribuyen y cómo se comunican entre si. Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 13 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 14 Modeo de depósito Arquitectura de una herramienta CASE Los subsistemas deben intercambiar datos. Esto puede ser hecho de dos formas: Los datos compartidos se mantiene en una base de datos centra o depósito y puede ser accedida por todos os subsistemas Cada subsistema mantiene su propia base de datos y pasa datos expícitamente a otros subsistemas Cuando grandes cantidades de datos deben ser compartidos, e modeo de depósito es e más comúnmente usado Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 15 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 16 Características de modeo de depósito Arquitectura de ciente-servidor Ventajas Forma eficiente de compartir grandes cantidades de datos Los subsistemas no se deben preocupar sobre cómo os datos son producidos o usados Administración centraizada. Ej. Backup, seguridad E modeo de compartición es visibe a o argo de esquema de depósito Desventajas Los subsistemas deben acordar un modeo de datos de depósito. Lo cua es inevitabemente un compromiso La evoución de datos es difíci y cara No hay campo para poíticas de administración específicas Es difíci distribuir e depósitos eficientemente Modeo de sistema distribuido e cua muestra cómo os datos y e procesamiento se distribuyen a través de un rango de componentes Conjunto de servidores stand-aone que proveen servicios específicos taes como impresión, administración de datos, etc. Conjunto de cientes os cuaes acceden a estos servicios Una red a cua permite a comunicación entre cientes y servidores Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 17 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 18

4 Bibioteca de videos y pinturas Características de modeo ciente-servidor Ventajas La distribución de datos es directa Hace uso efectivo de sistemas interconectados. Podría requerir hardware más barato Es fáci adicionar nuevos servidores o actuaizar servidores existentes Desventajas No hay un modeo de datos compartido, de manera que os subsistemas usan una organización de datos diferente. E intercambio de datos puede ser ineficiente Administración redundante en cada servidor No hay un registro centra de nombres y servicios Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 19 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 20 Modeo de máquina abstracta Sistema de manejo de versiones Usado para modear as interfaces en entre subsistemas Organiza e sistema en un conjunto de capas (o máquinas abstractas) cada una de a cuaes provee un conjunto de servicios Soporta e desarroo incrementa de subsistemas en diferentes capas. Cuando a interfaz de una capa cambia, soo as capas adyacentes son afectadas Sin embargo, es difíci, en genera, estructurar sistemas de esta forma Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 21 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 22 Modeos de contro Contro centraizado Concernientes con e fujo de contro entre subsistemas. Distintos a modeo de descomposición de sistema. Contro centraizado Un subsistema tiene responsabiidad genera de controar y comenzar otros subsistemas Contro basado en eventos Cada subsistema puede responder a eventos generados externamente desde otros subsistemas o e entorno de sistema Un subsistema tiene responsabiidad genera de controar y comenzar otros subsistemas Modeo de amada-retorno Modeo de subrutina top-down donde e contro comienza en e tope de una jerarquía de subrutinas y se mueve hacia abajo. Apicabe a sistemas secuenciaes Modeo de administrador Apicabe a sistemas concurrentes. Un componente de sistema controa a parada, arranque y coordinación de otros procesos de sistema. Puede ser impementado en sistemas secuenciaes como una instrucción switch-case Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 23 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 24

5 Modeo de amada retorno Sistema de contro de tiempo rea Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 25 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 26 Sistemas dirigidos por eventos Modeo de broadcast Dirigidos por eventos generados externamente dodne e tiempo de e evento está fuera de contro de os subsistemas que procesan e evento Tipos: Modeos broadcast. Una evento se transmite a todos os subsistema. E evento puede ser procesado por cuaquier subsistema que esté en capacidad de hacero. Modeos dirigidos por interrupciones. Usados en sistemas de tiempo rea donde as interrupciones son detectadas por un manejador de interrupciones y pasadas a otros componente para ser procesadas. Otros modeos dirigidos por eventos incuyen hojas eectrónicas y sistemas de producción Efectivo para integrar subsistema en diferentes computadores en una red Los subsistemas registran interés en eventos específicos. Cuando esto ocurre, e contro se transfiere a os subsistemas que pueden manejar e evento. La poítica de contro no se embebe en e manejador de eventos y mensajes. Los subsistemas deciden sobre eventos de interés para eos Sin embargo, os subsistemas no conocen si un evento va ser procesado o no Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 27 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 28 Seective broadcasting Sistemas dirigidos por interrupciones Usados en sistemas de tiempo rea donde una respuesta rápida a un evento es esencia Hay diferentes tipos de interrupciones con un manejador definido para cada tipo Cada tipo está asociado con una posición de memoria y un interruptor de hardware causa a transferencia a este manejador Permite una rápida respuesta, pero son compejos de programar y difícies de vaidar Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 29 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 30

6 Interrupt-driven contro Descomposición moduar Un nive estructura adiciona donde os subsistemas son descompuestos en móduos Dos modeos de descomposición moduar cubiertos: Un modeo de objetos donde e sistema es descompuesto en objetos que interactúan Un modeo de fujo de datos donde e sistema es descompuesto en móduos funcionaes os cuaes transforman entradas en saidas. Conocido también como modeo de tubería (pipeine) Si es posibe, as decisiones acerca de a concurrencia deben ser dejadas para a etapa de impementación Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 31 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 32 Modeos de Objetos Invoice processing system Estructura e sistema en un conjunto de objetos débimente acopados con interfaces bien definidas La descomposición orientada a objetos es concerniente con a identificación de cases de objetos, sus atributos y sus operaciones En a impementación, os objetos se crean a partir de estas cases y un modeo de contro determinado es usado para coordinar a operaciones de os objetos Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 33 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 34 Modeos de fujos de datos Invoice processing system Transformaciones funcionaes procesan sus entradas para producir saidas Este modeo se puede ver como un modeo de fitros y tuberías Variaciones de este modeo son bastante comunes. Cuando as transformaciones son secuenciaes, se haba de de modeo de proceso de otes secuencia, e cua es usado extensivamente en sistemas de procesamiento de datos No se adecua muy bien para sistemas interactivos Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 35 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 36

7 Arquitecturas específicas de dominio Modeos genéricos Modeos arquitectónicos específicos a un dominio de apicación Dos tipos de modeos de dominio específico: Modeos genéricos os cuaes son abstracciones de un número de sistemas reaes y que encapsuan as características principaes de estos sistemas Modeos de referencia os cuaes son más abstractos. Modeos ideaizados. Proveen un medio de información acerca de cierta case de sistemas y permiten comparar diversas arquitecturas. Los modeos genéricos son usuamente modeos bottomup; os modeos de referencia son modeos top-down E modeo de un compiador es un ejempo bien conocido, sin embargo existen otros modeos en dominios de apicación más especiaizado: Anaizador éxico Taba de símboos Anaizador sintáctico Árbo de sintaxis Anaizador semántico Generador de código E modeo genérico de compiador podría ser organizado de acuerdo a diferentes modeos arquitectónicos Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 37 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 38 Modeo de Compiador Sistema de procesamiento de enguaje Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 39 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 40 Arquitecturas de referencia Modeo de referencia OSI Los modeos de referencia se derivan a partir de un estudio de dominio de a apicación antes que a partir de sistemas existentes Pueden ser usado como una base para a impementación de sistema o para comparar diferentes sistemas. Actúan como un estándar para evauar sistemas. E modeo OSI es un modeo en capas para sistemas de comunicación Appication Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 41 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 42

8 Puntos caves Puntos caves La responsabiidad de arquitecto de software es derivar un modeo estructura de sistema, un modeo de contro y modeo de descomposición en subsistemas Los sistemas grandes raramente se acomodan a un modeo arquitectónico simpe Los modeos de descomposición de sistema incuyen: modeos de depósito, modeos ciente-servidor y modeos de máquina abstracta Los modeos de descomposición incuyen modeos de fujo de datos y modeos de objetos Los modeos arquitectónicos son abstracciones sobre un dominio de apicación. Pueden ser construidos abstrayendo modeos existentes o pueden ser modeos de referencia ideaizados Los modeos de contro incuyen contro centraizado y modeos dirigidos por eventos Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 43 Ian Sommervie 2000 Software Engineering, 6th edition. Chapter 10 Side 44