Lic. Domigo F. Donadello 2004 Diseño de la Arquitectura u Establecimiento de la estructura completa...

Lic. Domigo F. Donadello 2004

Diseño de la Arquitectura

Establecimiento de la estructura completa de un Sistema de Software.

Traducción cap. 13 I Sommerville 5ta ed y Acotaciones teóricas del Lic. Domingo F. Donadello

UTN – FRBA MAESTRIA EN INGENIERIA EN SISTEMAS

DE INFORMACION Lic. D.F.Donadello Ciclo lectivo 2004


Objetivos

Introducir el Diseño de la Arquitectura del sistemas y su rol en el Proceso de Software.

Describir los diferentes tipos y de Modelos de Arquitectura.

Mostrar como la arquitectura de un sistema puede ser modelada de diferentes formas.

Discutir como el modelo de referencia de un dominio específico puede ser utilizado para comparar arquitecturas de software.


Tópicos.

Estructurando un Sistema. Modelos de Control. Descomposición Modular. Arquitecturas de Dominio Específico.


Arquitecturas Paralelas.

Los Arquitectos son la interfase técnica entre el cliente y el contratista que construye el sistema.

Un mal diseño de arquitectura de un edificio no podrá ser rescatado mediante una buena construcción, lo mismo sucede para el Software.

Existen especialistas para construcción de edificios así como para arquitecturas de software.

Existen escuelas o estilos de construcción y arquitectura de software


Proceso de Diseño de la Arquitectura

Estructuración del Sistema.• El sistema se descompone en varios

subsistemas principales y se identifican las comunicaciones entre estos subsistemas.

Modelos de Control.• Un modelo de control establece las relaciones

entre las diferentes partes de un sistema. Descomposición Modular.

• Los subsistemas identificados son descompuestos en módulos.


Subsistemas y Módulos.

Un subsistema es un sistema por si mismo y puede operar independientemente de los servicios proporcionados por otros subsistemas.

Un modulo es un componente del sistema que proporciona servicios a otros componentes y normalmente no puede considerarse como parte separada del sistema.


Modelos de Arquitectura

La estructura, control y descomposición modular puede ser basada en un modelo o estilo de arquitectura particular.

Sin embargo, muchos sistemas son heterogéneos, diferentes partes del sistema se basan en diferentes modelos y en algunos casos, el sistema puede seguir un modelo compuesto.

El modelo de arquitectura utilizado afecta el desempeño, la robustez, distribución y la mantenibilidad del sistema.


Estructurando un Sistema

Se refiere a la descomposición del sistema interactuando con subsistemas.

El diseño de arquitectura es normalmente expresado como un diagrama de bloque, el cual, presenta una vista de la estructura del sistema.

Muchos modelos específicos muestran como los subsistemas comparten los datos, son distribuidos y la interfase con otros subsistemas puede ser desarrollada.


Sistema de Control de un Robot Empaquetador

Sistema deVisión

Sistema deIdentificaciónde Objetos

Sistema de Selección dePaquetes

SistemaEmpaquetador

ControladorConvoy

Controladordel Brazo

ControladorGripper


El Modelo Repositorio

Muchos Subsistemas intercambian datos. Esto puede darse de dos maneras:• Los datos compartidos se colocan en una base de datos

central o repositorio y pueden ser accedidos por todos los subsistemas.

• Cada subsistema mantiene su propia base de datos y pasa datos explícitos a otros subsistemas.

Cuando grandes cantidades de datos son compartidos, el modelo repositorio es el más utilizado comúnmente.


Arquitectura de una herramienta CASE

Diseñodel Editor

Generador deCódigo

Diseño delTrasladador

Proyecto RepositorioEditor dePrograma

Analizadorde diseño

Generador de Reporte


Características del Modelo Repositorio

Ventajas• Es una forma eficiente de compartir grandes cantidades de

datos. • Los Subsistemas no necesitan proporcionar un manejo

centralizado de como los datos son producidos. Por ejemplo: respaldo, seguridad, etc.

• El modelo de compartimiento se conoce como Modelo Repositorio.

Desventajas• Los subsistemas deben coincidir en modelo de datos del

repositorio, lo cual es inevitablemente un compromiso• La evolución de los datos es difícil y cara.• No existen políticas para un manejo específico.• Se dificulta una distribución eficiente.


Arquitectura Cliente-Servidor

Modelo de Sistemas Distribuido, el cual muestra como los datos y procesamiento están distribuidos entre un rango de componentes.

Conjunto de servidores “stand-alone”, los cuales proporcionan servicios específicos como impresión, manejo de datos, etc.

Conjunto de clientes que llaman a estos servicios. Redes que permiten que los clientes accedan a los

servidores


Película y Librería de Películas

Cliente 1 Cliente 2 Cliente 3 Cliente 4

Ancho de Banda de la red

Servidor deCatálogo

Catálogo

Servidor deVídeo

Archivos clip de Película

Servidor deFotografía

FotografíaDigitalizada

Servidor deHipertexto

Hipertexto WEB


Características Cliente-Servidor

Ventajas• La Distribución de datos es directa.• Permite el uso efectivo de sistemas de red. Puede requerir

hardware barato. • Es fácil añadir nuevos servidores o actualizar los existentes.

Desventajas• El modelo no comparte datos con los diferentes subsistemas

empleados en la organización. El intercambio de datos puede ser ineficiente.

• Administración redundante en cada servidor.• No existen registros centrales de nombres y servicios - esto

hace difícil encontrar los servidores y servicios disponibles.


Modelo de Máquina Abstracta

El modelo es utilizado para interfaces de subsistemas

El sistema se organiza en base a un conjunto de capas (o máquinas abstractas) cada una de las cuales proporcionan un conjunto de servicios

Soporta el desarrollo incremental de subsistemas en las diferentes capas. Cuando una interfase cambia en una capa, solamente la capa adyacente se ve afectada

Sin embargo, ofrece dificultad para sistemas estructurados de esta manera.


Sistema Administrador de Versiones

Administrador de Versiones

Administrador de Objetos

Sistema de Base de Datos

SistemaOperativo


Modelos de Control

Se refieren al control de flujo entre subsistemas. Es diferente al modelo de descomposición de sistemas

Control Centralizado• Un subsistema tiene sobretodo la responsabilidad de

controlar, iniciar y detener otros subsistemas

Control basado en Eventos• Cada subsistema puede responder a eventos generados

externamente por otros subsistemas o por el ambiente del sistema


Control Centralizado

El control de un subsistema es responsable del manejo de la ejecución de otros subsistemas

Modelo Call-return• Un modelo de subrutina Top-down donde el control inicia

en lo más alto de la jerarquía de una subrutina y se mueve hasta la parte más baja en la jerarquía. Es aplicable a sistemas secuenciales

Modelo Administrador• Es aplicable a sistemas concurrentes. Un componente

del sistema controla el inicio, coordinación y el alto de procesos de otro sistema. Puede ser implementado en sistemas secuenciales como una instrucción case


Modelo Call-Return

Programa Principal

Rutina 1 Rutina 2 Rutina 3

Rutina 1.1 Rutina 1.2 Rutina 3.1 Rutina 3.2


Sistema de Control en Tiempo Real

Proceso de Sensor Proceso Actuador

Controlador del Sistema

Procesos de Computación Interfase de Usuario Manejador de Fallas


Sistemas Manejadores de Eventos

Manejador de eventos generador externamente donde el tiempo del evento está fuera del control de los subsistemas que lo procesan

Dos de los principales modelos manejadores de eventos• Modelo de Transmisión (Broadcast). Un evento es

transmitido a todos los subsistemas. Cualquier subsistema puede manejar el evento

• Modelos manejadores de interrupciones. Utilizados en sistemas en tiempo real donde una interrupción es detectada por un manejador de interrupciones y es pasada a otros componentes para ser procesada

Otros modelos manejadores de eventos incluyen hojas de cálculo y sistemas de producción


Modelo de Transmisión (Broadcast)

Es efectivo en la integración de subsistemas en diversas computadoras en una red

Los subsistemas registran la petición de eventos específicos. Cuando esto ocurre, el control es transferido a los subsistemas que pueden manejar el evento

Las políticas de control no están contenido dentro del evento o del manejador de eventos. Los subsistemas deciden cuales eventos son de su interés

No obstante, los subsistemas no saben cuando un evento será manejado


Transmisión Selectiva

Subsistema 1

Subsistema 2

Subsistema 3

Subsistema 4

Manejador de Eventos y Mensajes


Sistemas Manejados por Interrupciones

Utilizado en Sistemas de tiempo real donde una respuesta rápida es esencial

Hay tipos de interrupciones con un manejador definido para cada tipo

Cada tipo está asociado con una localidad de memoria y un switch de hardware ocasiona transferencias al manejador

Una respuesta rápida pero compleja de programar y difícil de validar


Control de Manejo de InterrupcionesInterrupciones

Vector deInterrupciones

Manejador 1 Manejador 2 Manejador 3 Manejador 4

Proceso 1 Proceso 2 Proceso 3 Proceso 4


Descomposición Modular

Es otro nivel de estructura donde los subsistemas son descompuestos en módulos

Dos modelos de descomposición modular son• Un modelo de objeto donde el sistema es descompuesto

en objetos interactuando.• Un modelo de flujo de datos donde el sistema es

descompuesto en módulos funcionales, los cuales, transforman entradas en salidas. Esto es conocido como el modelo pipeline.

Es posible tomar decisiones acerca de la concurrencia la cual será retrasada hasta que los módulos sean implementados


Modelos de Objetos

Estructura el sistema en un conjunto de objetos débilmente acoplados con interfaces bien definidas

La descomposición orientada a objetos se refiere a la identificación de clases de objetos, sus atributos y operaciones

Cuando están implementados, los objetos son creados de esas clases y algunos modelos de control se emplean para coordinar operaciones de los objetos


Sistema de Procesamiento de Facturas

Cliente

Cliente #NombreDirecciónPeríodo de Crédito

Recibo

Factura #FechaCantidadCliente #

Pago

Factura #FechaCantidadCliente #

Factura

Factura #FechaCantidadCliente

EmisiónEnvío de RecordatorioAceptación de PagoEnvío de Recibo


Modelos de Flujo de Datos

Las entradas a procesos de transformaciones funcionales producen salidas

Puede ser referido como un tubo (pipe) o modelo de filtro (como un shell de UNIX)

Las variaciones de este enfoque son muy comunes. Cuando las transformaciones son secuenciales nos encontramos con un modelo batch (en lotes) secuencial, el cual es muy utilizado en sistemas de procesamiento de datos sobre todo los más antiguos

No es realmente conveniente para sistemas interactivos


Sistema de Procesamiento de Facturas

Lectura de Emisión de Facturas

Identificación dePagos

Emisión deRecibos

Encontrar pagosduplicados

Emisión delRecordatorio dePago

Recordatorios

PagosFacturas

Recibos


Arquitecturas de Dominio Específico

Son modelos de Arquitectura los cuales son específicos para algún dominio de aplicación

Dos tipos de modelo de dominio específico son:• Modelos Genéricos, los cuales, son abstracciones de un

número de sistemas reales y que encapsulan las características principales de estos sistemas

• Los modelos de referencia son más abstractos, son modelos idealistas. Proporcionan un significado de información con respecto a sistemas de clases y comparación de diversas arquitecturas.

Los modelos genéricos son usualmente modelos bottom-up; los modelos de Referencia son modelos top-down.


Modelos Genéricos

Un modelo de Compilador es un ejemplo conocido a través de otros modelos que existen en dominios de aplicaciones especializadas:• Analizador Léxico• Tabla de Símbolos• Analizador de Sintaxis• Arbol de Sintaxis• Analizador Semántico• Generador de Código

Un modelo de compilador Genérico puede ser organizado de acuerdo a diversos modelos de arquitectura


Modelo Compilador

Tabla de Símbolos

AnalizadorLéxico

AnalizadorSintáctico

AnalizadorSemántico

Generaciónde Código


Sistema de Procesamiento de un Lenguaje

Repositorio

Arbol de Sintaxis Abstracto

Definición de la Gramática

Tabla de Símbolos

Definición de la Salida

Optimizador

Generador de Código

Impresor

Editor

Analizador Léxico

Analizador Sintáctico

AnalizadorSemántico


Arquitecturas de Referencia

Los modelos de referencias son derivados del estudio del dominio de una aplicación, en lugar del estudio de sistemas existentes.

Pueden ser utilizados como una base para la implementación de un sistema o para comparar sistemas diversos. Actúan como un estándar en contraste con sistemas que pueden ser evaluados.

El modelo OSI es un modelo en capas para sistemas de comunicación.


Modelo de referencia OSI

1

2

3

4

5

6

7

Presentación

Sesión

Transporte

Red

Liga de Datos

Físico

Presentación

Sesión

Transporte

Red

Liga de Datos

Físico

Aplicación

Medio de Comunicación

Red

Liga de Datos

Físico

Aplicación


ANTECEDENTES DE LA ESTRUCTURACION DE LOS PROCESOS Y TAREAS

EN LA PRIMER ETAPA DE LA UTILIZACION DE LOS SISTEMAS DE COMPUTACION LA UNICA MANERA DE ESTRUCTURAS LOS PROGRAMAS, TAREAS Y PROCESOS ERA SECUENCIAL ES DECIR: ORGANIZAR EL PROCESO EN BASE A LA SUCESIÓN SECUENCIAL DE PROGRAMAS QUEEJECUTABAN SU COMPUTACION MEDIANTE INTERFASES DE ARCHIVOS DE DATOS

EN LA DECADA DEL 70 SE PUDO COMENZAR A ESTRUCTURAR LOS PROCESOS CON EL CONCEPTO JERARQUICO MEDIANTE EL USO DE MENUES DE OPOCIONES ES DECIRQUE LOS PROCESOS SE EJECUTABAN UNO A LA VEZ Y DENTRO DEL PROCESO SE ESTRUCTURABAN SECUENCIALMENTE

EN LA DECADA DEL 80 COMIENZA A SER POSIBLE ESTRUCTURAR LOS PROCESOS DE MANERA CONCURRENTE ES DECIR VARIOS PROCESOS EJECUTANDO EN LA MEMORIACOMPITIENDO POR RECURSOS Y COLABORANDO ENTRE SI MEDIANTE INTERFASES ENTRE PROCESOS CON MEMORIA COMPARTIDA

EN LA DECADA DEL 90 LA ESTRUCTURACION CLIENTE SERVIDOR SE PUEDE EFECTUARPOR LA APARICION DEL CONCEPTO DE DESCENTRALIZACION DE LOS PROCESOS Y LA COMUNICACIÓN ENTRE LOS MISMOS PUEDE SER EFECTUADA MEDIANTE COMUNICACIÓNDE DATOS POR CONEXIÓN DIRECTA O POR TELECOMUNICACIONES

ACTUALMENTE, LA ESTRUCTURACION SE BASA EN EL CONCEPTO DE CAPAS O LAYERSDONDE CADA CAPA ATIENDE ESPECIFICAMENTE UNA PARTE BIEN DISTINGUIDA DEL SISTEMA, EL CLIENTE, EL SERVICIO, LA BASE DE DATOS, LAS COMUNICACIONES Y LOS ALGORITMOS.


Resumen La arquitectura de software es la responsable de la

derivación de un modelo de sistema estructural, un modelo de control y un modelo de descomposición en subsistemas.

Los sistemas grandes rara vez conforman un modelo simple de arquitectura.

Los modelos de descomposición de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de máquina abstracta.

Los modelos de control incluyen control centralizado y modelos manejadores de eventos


Resumen

Los modelos de descomposición incluyen modelos de flujo de datos y objetos.

Los modelos de Dominio de arquitectura específica son abstracciones sobre el dominio de una aplicación. Estos pueden ser construidos mediante la abstracción de sistemas existentes o pueden ser modelos de referencia idealizados.

Lic. Domigo F. Donadello 2004 Diseño de la Arquitectura u Establecimiento de la estructura completa...

Documents

Transcript of Lic. Domigo F. Donadello 2004 Diseño de la Arquitectura u Establecimiento de la estructura completa...