Sommerville7spCap11 DisenoArquitectonico

Diseo Arquitectnico
Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11
Slide 1
Objetivos
Introducir el diseo arquitectnico y discutir su importancia Explicar el diseo arquitectnico y las decisiones que tienen que hacerse Introducir tres estilos arquitectnicos, que abarcan la organizacin, la descomposicin y el control Debatir arquitecturas de referencia que se utilizan para comunicar y comparar arquitecturas
Software Engineering, 7th edition. Chapter 11 Slide 2
Tpicos expuestos

Decisiones de diseo arquitectnico Sistema de organizacin Descomposicin estilos Control de estilos Arquitecturas de referencia
Slide 3
Arquitectura de software
El proceso de diseo para la identificacin de los sub-sistemas que componen un sistema y el marco para el sub-sistema de control y comunicacin es el diseo arquitectnico. El resultado de este proceso de diseo es una descripcin de la arquitectura de software.
Slide 4
Diseo arquitectnico
Una fase temprana del proceso de diseo del sistema. Representa el vnculo entre los procesos de especificacin y diseo. Suelen llevarse a cabo en paralelo con las actividades de algunas especificaciones. Se trata de identificar los principales componentes del sistema y sus comunicaciones.
Ventajas de la arquitectura explcita
Comunicacin entre los stakeholders

La arquitectura puede ser utilizada como un foco de discusin del sistema por los stakeholders. Significa que el anlisis de si el sistema puede hacer frente a sus requerimientos no funcionales es posible. La arquitectura puede ser reutilizable a travs de una variedad de sistemas.
Anlisis del sistema
Reutilizacin a gran escala
La arquitectura y caractersticas del sistema
Rendimiento
Localizar y reducir al mnimo las operaciones crticas de comunicaciones. Gran uso en lugar de componentes de grano fino. Use una arquitectura con activos crticos en las capas interiores. La localizacin de las caractersticas esenciales para la seguridad en un pequeo nmero de sub-sistemas. Incluir componentes redundantes y los mecanismos de tolerancia a fallos.
Seguridad
Proteccin
Disponibilidad
Mantenibilidad
Uso de grano fino, los componentes reemplazables.
Conflictos Arquitectnicos
Uso de componentes mejora de gran manera el rendimiento de grano, pero hace ms difcil el mantenimiento. Hace ms difcil la introduccin de los datos redundantes, pero mejora la disponibilidad de seguridad. La localizacin de las caractersticas relacionadas con la seguridad ms medios de comunicacin por lo general degradan el rendimiento.
Estructuracin del sistema
Concerniente a la descomposicin del sistema en sub-sistemas. El diseo arquitectnico se expresa normalmente como un diagrama de bloques que presentan un panorama general de la estructura del sistema. Modelos ms especficos muestran cmo los sub-sistemas comparten los datos, se distribuyen y la interfaz con los dems tambin pueden ser desarrollados.
Sistema de control de robot de embalaje
Slide 10
Box y diagramas
Muy abstracto - que no muestran la naturaleza de los componentes ni las relaciones de las propiedades visibles externamente de los sub-sistemas. Sin embargo, til para la comunicacin con las partes interesadas y para la planificacin de proyectos.
Slide 11
Decisiones de diseo arquitectnico
Diseo arquitectnico es un proceso creativo, por lo que el proceso es diferente dependiendo del tipo de sistema que se est desarrollado. Sin embargo, es comn una serie de decisiones, en todos los procesos de diseo.
Slide 12
Decisiones de diseo arquitectnico
Existe una arquitectura de aplicaciones genricas que se pueden utilizar? Cmo se distribuir el sistema? Qu estilos arquitectnicos son apropiados? Qu enfoque se utilizar para la estructura del sistema? Cmo el sistema se descompone en mdulos? Qu estrategia de control se debe utilizar? Cmo el diseo arquitectnico se evaluar? Cmo debe ser documentada la arquitectura?
Reutilizacin de la arquitectura
Sistemas en el mismo dominio a menudo tienen arquitecturas similares que reflejan conceptos del dominio. La aplicacin de lneas de produccin se construye en torno a un ncleo con arquitectura particular, con variantes que satisfagan las necesidades del cliente. Arquitecturas de aplicacin se tratan en el captulo 13 y las lneas de produccin en el captulo 18.
Estilos arquitectnicos
El modelo arquitectnico de un sistema puede ajustarse a un modelo genrico o estilo arquitectnico. La conciencia de estos estilos puede simplificar el problema de la definicin de arquitecturas de sistemas. Sin embargo, la mayora de los grandes sistemas son heterogneos y no siguen un mismo estilo arquitectnico.
Modelos arquitectnicos

Utilizarse para documentar un diseo arquitectnico. Modelo estructural esttico, que muestra los principales componentes del sistema. Modelo de proceso dinmico que muestra el modelo de proceso de la estructura del sistema. Modelo de interfaz que define las interfaces de subsistemas. Modelo de relaciones, como un modelo de flujo de datos que muestra las relaciones de sub-sistemas. Modelo de distribucin que muestra cmo los subsistemas se distribuyen a travs de computadoras.
Sistema de organizacin
Refleja la estrategia bsica que se utiliza para estructurar un sistema. Tres estilos de organizacin son ampliamente utilizados:
Una reposicin de datos compartida; Servicios compartidos y servidores de estilo; Una mquina abstracta o estilo de capas.
Slide 17
El modelo repositorio
Sub-sistemas de intercambio de datos. Esto puede hacerse de dos maneras:

Datos compartidos se lleva a cabo en un repositorio o base de datos central y puede ser visitada por todos los sub-sistemas; Cada sub-sistema mantiene su propia base de datos y pasa datos explcitamente a otros subsistemas.
Cuando grandes cantidades de datos sean compartidos, el modelo de repositorio compartido es ms comnmente utilizado.
Arquitectura de herramientas CASE
Slide 19
Modelo Repositorio Caractersticas
Ventajas
Manera eficaz de compartir grandes cantidades de datos; Sub-sistemas no tienen por qu preocuparse de cmo los datos se producen, por ejemplo, la gestin centralizada copia de seguridad, seguridad, etc Un modelo a compartir se publica como el esquema del repositorio. Sub-sistemas deben ponerse de acuerdo sobre un modelo repositorio de datos. Inevitablemente, un compromiso; La evolucin de datos es difcil y costosa; No hay lugar para las polticas de gestin especficas; Difcil de distribuir de manera eficiente.
Desventajas
Modelo cliente-servidor
Sistema distribuido que muestra cmo el modelo de datos y procesamiento se distribuye a travs de una gama de componentes. Conjunto de servidores independientes que ofrecen servicios especficos, tales como la impresin, gestin de datos, etc Conjunto de clientes que piden a stos los servicios. Red que permite a los clientes acceder a los servidores.
biblioteca de imgenes y pelculas
Slide 22
Cliente-servidor caractersticas
Ventajas
Distribucin de datos es sencilla; Hace un uso eficaz de los sistemas en red. Puede requerir hardware ms barato; Fcil aadir nuevos servidores o actualizar los servidores existentes. No hay un modelo de datos compartidos, as que los subsistemas utilizan diferentes datos de la organizacin. Intercambio de datos puede ser ineficaz; Redundantes en la gestin de cada servidor; No hay registro central de nombres y servicios - que puede ser difcil de averiguar qu servidores y servicios estn disponibles.
Desventajas

Modelo de mquina abstracta (capas)
Se utiliza para modelar la interaccin de subsistemas. Organiza el sistema en un conjunto de capas (o mquinas abstractas) cada uno de los cuales provee un conjunto de servicios. Apoya el desarrollo gradual de sub-sistemas en diferentes capas. Cuando una capa cambia, slo la capa adyacente se ve afectada.
Slide 24
Versin del sistema de gestin
Slide 25
Estilos de descomposicin modular
Los estilos de la descomposicin de subsistemas en mdulos. No hay distincin rgida entre la organizacin y la descomposicin modular del sistema.
Slide 26
Sub-sistemas y mdulos
Un sub-sistema es un sistema en su propio derecho cuyo funcionamiento es independiente de los servicios prestados por otros subsistemas. Un mdulo es un componente del sistema que proporciona servicios a otros componentes, pero normalmente no se considera como un sistema separado.
Slide 27
Descomposicin modular
Otro nivel estructural en que sub-sistemas se descomponen en mdulos. Dos modelos de descomposicin modular
Un modelo de objetos cuando el sistema se descompone en la interaccin objeto; Una tubera o modelo de flujo de datos cuando el sistema se descompone en mdulos funcionales que transforman las entradas en salidas.
Si es posible, las decisiones acerca de la concurrencia deben retrasarse hasta que los mdulos se apliquen.
Slide 28
Modelo de Objetos
Estructura del sistema en un conjunto de objetos dbilmente acoplados con interfaces bien definidas. La descomposicin orientada a objetos se refiere a la identificacin de clases de objetos, sus atributos y operaciones. Cuando se aplica, los objetos se crean a partir de estas clases y algunos modelos de control para coordinar las operaciones del objeto.
Sistema de procesamiento de la factura
Slide 30
Ventajas del modelo de objetos
Los objetos son dbilmente acoplados por lo que su aplicacin puede ser modificada sin afectar a otros objetos. Los objetos pueden reflejar entidades del mundo real. Implementacin de lenguajes orientados a objetos son extensamente usados. Sin embargo, los cambios de interfaz de objetos puede causar problemas y entidades complejas pueden ser difciles de representar como objetos.
Funcin orientada a pipelining
Transformaciones funcionales transforman sus entradas en salidas. Puede ser denominado un modelo de filtro y tubo (como en el shell de UNIX). Variantes de este enfoque son muy comunes. Cuando las transformaciones son secuenciales, se trata de un modelo secuencial que se utiliza ampliamente en sistemas de procesamiento de datos. En realidad, no adecuado para sistemas interactivos.
Sistema de procesamiento de la factura
Slide 33
Ventajas Modelo de tubos

Apoya la reutilizacin de transformacin. Para la organizacin intuitiva de comunicacin interesados. Fcil de aadir nuevas transformaciones. Relativamente fcil de aplicar, ya sea como un sistema concurrente o secuencial. Sin embargo, requiere de un formato comn para la transferencia de datos a lo largo de la tubera y difcil de apoyo basada en eventos de interaccin.
Control de estilos
Estn relacionadas con el control de flujo entre los sub-sistemas. Distinta de la descomposicin del sistema modelo. Control centralizado
Un sub-sistema tiene la responsabilidad general de control de otros subsistemas. Cada sub-sistema puede responder a eventos generados externamente de los dems subsistemas o del entorno del sistema.
Control basado en eventos
Slide 35
Control centralizado
Un sub-sistema de control tiene la responsabilidad de gestionar la ejecucin de otros subsistemas. Modelo de retorno
Modelo de subrutinas de arriba hacia abajo donde el control se inicia en la cima de una jerarqua de subrutinas y se mueve hacia abajo. Aplicables a los sistemas secuenciales. Aplicable a sistemas concurrentes. Un componente del sistema controla la interrupcin, la puesta en marcha y coordinacin de otros procesos del sistema. Puede ser implementado en sistemas secuenciales como una declaracin.
Modelo administrador
Modelo de control llamada/retorno
Slide 37
Modelo de control centralizado para sistema de tiempo real
Slide 38
Sistema impulsado por eventos
Impulsada por eventos generados externamente en el que la coordinacin del evento est fuera del control de los sub-sistemas que procesan el evento. Dos principales modelos
Modelos de difusin. Un acontecimiento es transmitido a todos los sub-sistemas. Cualquier sub-sistema que puede manejar el evento pueden hacerlo; Modelos de manejo de interrupciones. Utilizados en sistemas de tiempo real donde las interrupciones son detectadas por un manejador de interrupcin y pasan a algn otro componente para la transformacin.
Otros modelos de sistemas impulsados por eventos incluyen a las hojas de clculo y sistemas de produccin.
Modelo de difusin
Eficaz en la integracin de sub-sistemas en diferentes ordenadores en una red. Sub-sistemas de registro de un inters especfico en los acontecimientos. Cuando se producen, el control es transferido a la sub-sistema que puede manejar el evento. Las polticas de control no estn incrustadas en el evento y manejador de mensaje. Sub-sistemas deciden sobre los acontecimientos de inters para ellos. Sin embargo, los sub-sistemas no saben cundo o si un evento se manejar.
Difusin o transmisin selectiva
Slide 41
Sistemas impulsado por interrupciones
Utilizados en sistemas de tiempo real, donde una respuesta rpida a un evento es fundamental. Se conocen los tipos de interrupcin con un manejador definido para cada tipo. Cada tipo se asocia con una ubicacin de memoria y un interruptor de hardware causas de transferencia a su manejador. Permite una respuesta rpida, pero compleja y difcil de programar para validar.
Modelo de control conducido por interrupciones
Slide 43
Arquitecturas de referencia
Modelos arquitectnicos pueden ser especficos para algunas aplicaciones de dominio. Dos tipos de dominio especfico de modelo
Modelos genricos que son abstracciones de una serie de sistemas reales, y que encierran las principales caractersticas de estos sistemas. Contempladas en el Captulo 13. Modelos de referencia que son ms abstractos, modelo idealizado. Proporcionar un medio de informacin acerca de que clase de sistema y de la comparacin de diferentes arquitecturas.
Modelos genricos son por lo general los modelos de abajo hacia arriba, los modelos de referencia son de arriba abajo.
Arquitecturas de referencia
Modelos de referencia se derivan de un estudio de la solicitud de dominio en lugar de los sistemas existentes. Puede utilizarse como base para la aplicacin del sistema o para comparar diferentes sistemas. Acta como un estndar contra el que los sistemas pueden ser evaluados. Modelo OSI es un modelo de capas para los sistemas de comunicacin.
Modelo de referencia OSI
Slide 46
Caso modelo de referencia
Servicios de datos
Almacenamiento y gestin de datos.
Servicios de integracin de datos

Gestin de grupos de entidades.
Definicin y establecimiento de modelos de procesos. Herramienta-herramienta y herramientas de comunicacin y el medio ambiente. Interfaz de usuario de desarrollo.
Servicios de gestin de tareas
Los servicios de mensajera
Servicios de interfaz de usuario
El modelo de referencia ECMA para entornos CASE
Slide 48
Puntos clave
La arquitectura de software es el marco fundamental para la estructuracin del sistema. Decisiones de diseo arquitectnico incluye decisiones sobre la arquitectura de aplicaciones, la distribucin y los estilos arquitectnicos que se utilizar. Diferentes modelos arquitectnicos, como un modelo estructural, un modelo de control y un modelo de descomposicin puede ser desarrollado. Sistema de repositorio de modelos organizativos son modelos cliente-servidor y modelos de mquinas abstractas.
Puntos clave
Modelos de contron incluyen control centralizado y modelos impulsados por eventos. Arquitecturas de referencia pueden ser utilizadas para comunicarse de dominio especfico de las arquitecturas y para evaluar y comparar los diseos arquitectnicos.
Slide 50
Modelos arquitectnicos
Diferentes modelos arquitectnicos pueden producirse durante el proceso de diseo Cada modelo presenta diferentes perspectivas sobre la arquitectura
Slide 51
Atributos de la arquitectura
Rendimiento
La localizacin de las operaciones para reducir al mnimo subsistema de comunicacin
Seguridad
Use una arquitectura con activos crticos en capas internas
Aislar los componentes esenciales para la seguridad fsica Incluir componentes redundantes en la arquitectura Uso de grano fino, autnomo de los componentes
Proteccin
Disponibilidad
Mantenibilidad
Slide 52

Sommerville7spCap11 DisenoArquitectonico

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sommerville7spCap11 DisenoArquitectonico

Uploaded by

Copyright:

Available Formats

Diseo Arquitectnico

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Ventajas de la arquitectura explcita

Comunicacin entre los stakeholders

Anlisis del sistema

Reutilizacin a gran escala

Ian Sommerville 2004

La arquitectura y caractersticas del sistema

Ian Sommerville 2004

Ian Sommerville 2004

Estructuracin del sistema

Ian Sommerville 2004

Sistema de control de robot de embalaje

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Decisiones de diseo arquitectnico

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Decisiones de diseo arquitectnico

Ian Sommerville 2004

Ian Sommerville 2004

Ian Sommerville 2004

Ian Sommerville 2004

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Sub-sistemas de intercambio de datos. Esto puede hacerse de dos maneras:

Ian Sommerville 2004

Arquitectura de herramientas CASE

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Modelo Repositorio Caractersticas

Ian Sommerville 2004

Ian Sommerville 2004

biblioteca de imgenes y pelculas

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Modelo de mquina abstracta (capas)

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Versin del sistema de gestin

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Estilos de descomposicin modular

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11

Ian Sommerville 2004

Sistema de procesamiento de la factura

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 11