Lic. Domigo F. Donadello 2004 Diseño de la Arquitectura u Establecimiento de la estructura completa de un Sistema de Software. u Traducción cap. 13 I Sommerville.

Presentación del tema: "Lic. Domigo F. Donadello 2004 Diseño de la Arquitectura u Establecimiento de la estructura completa de un Sistema de Software. u Traducción cap. 13 I Sommerville."— Transcripción de la presentación:

1 Lic. Domigo F. Donadello 2004 Diseño de la Arquitectura u Establecimiento de la estructura completa de un Sistema de Software. u Traducción cap. 13 I Sommerville 5ta ed y Acotaciones teóricas del Lic. Domingo F. Donadello u UTN – FRBA u MAESTRIA EN INGENIERIA EN SISTEMAS DE INFORMACION u Lic. D.F.Donadello u Ciclo lectivo 2004

2 Lic. Domigo F. Donadello 2004 Objetivos u Introducir el Diseño de la Arquitectura del sistemas y su rol en el Proceso de Software. u Describir los diferentes tipos y de Modelos de Arquitectura. u Mostrar como la arquitectura de un sistema puede ser modelada de diferentes formas. u Discutir como el modelo de referencia de un dominio específico puede ser utilizado para comparar arquitecturas de software.

3 Lic. Domigo F. Donadello 2004 Tópicos. u Estructurando un Sistema. u Modelos de Control. u Descomposición Modular. u Arquitecturas de Dominio Específico.

4 Lic. Domigo F. Donadello 2004 Arquitecturas Paralelas. u Los Arquitectos son la interfase técnica entre el cliente y el contratista que construye el sistema. u Un mal diseño de arquitectura de un edificio no podrá ser rescatado mediante una buena construcción, lo mismo sucede para el Software. u Existen especialistas para construcción de edificios así como para arquitecturas de software. u Existen escuelas o estilos de construcción y arquitectura de software

5 Lic. Domigo F. Donadello 2004 Proceso de Diseño de la Arquitectura u Estructuración del Sistema. El sistema se descompone en varios subsistemas principales y se identifican las comunicaciones entre estos subsistemas. u Modelos de Control. Un modelo de control establece las relaciones entre las diferentes partes de un sistema. u Descomposición Modular. Los subsistemas identificados son descompuestos en módulos.

6 Lic. Domigo F. Donadello 2004 Subsistemas y Módulos. u Un subsistema es un sistema por si mismo y puede operar independientemente de los servicios proporcionados por otros subsistemas. u Un modulo es un componente del sistema que proporciona servicios a otros componentes y normalmente no puede considerarse como parte separada del sistema.

7 Lic. Domigo F. Donadello 2004 Modelos de Arquitectura u La estructura, control y descomposición modular puede ser basada en un modelo o estilo de arquitectura particular. u 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. u El modelo de arquitectura utilizado afecta el desempeño, la robustez, distribución y la mantenibilidad del sistema.

8 Lic. Domigo F. Donadello 2004 Estructurando un Sistema u Se refiere a la descomposición del sistema interactuando con subsistemas. u El diseño de arquitectura es normalmente expresado como un diagrama de bloque, el cual, presenta una vista de la estructura del sistema. u Muchos modelos específicos muestran como los subsistemas comparten los datos, son distribuidos y la interfase con otros subsistemas puede ser desarrollada.

9 Lic. Domigo F. Donadello 2004 Sistema de Control de un Robot Empaquetador Sistema de Visión Sistema de Identificación de Objetos Sistema de Selección de Paquetes Sistema Empaquetador Controlador Convoy Controlador del Brazo Controlador Gripper

10 Lic. Domigo F. Donadello 2004 El Modelo Repositorio u 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. u Cuando grandes cantidades de datos son compartidos, el modelo repositorio es el más utilizado comúnmente.

11 Lic. Domigo F. Donadello 2004 Arquitectura de una herramienta CASE Diseño del Editor Generador de Código Diseño del Trasladador Proyecto Repositorio Editor de Programa Analizador de diseño Generador de Reporte

12 Lic. Domigo F. Donadello 2004 Características del Modelo Repositorio u 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. u 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.

13 Lic. Domigo F. Donadello 2004 Arquitectura Cliente-Servidor u Modelo de Sistemas Distribuido, el cual muestra como los datos y procesamiento están distribuidos entre un rango de componentes. u Conjunto de servidores “stand-alone”, los cuales proporcionan servicios específicos como impresión, manejo de datos, etc. u Conjunto de clientes que llaman a estos servicios. u Redes que permiten que los clientes accedan a los servidores

14 Lic. Domigo F. Donadello 2004 Película y Librería de Películas Cliente 1Cliente 2Cliente 3Cliente 4 Ancho de Banda de la red Servidor de Catálogo Servidor de Vídeo Archivos clip de Película Servidor de Fotografía Digitalizada Servidor de Hipertexto WEB

15 Lic. Domigo F. Donadello 2004 Características Cliente-Servidor u 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. u 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.

16 Lic. Domigo F. Donadello 2004 Modelo de Máquina Abstracta u El modelo es utilizado para interfaces de subsistemas u 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 u Soporta el desarrollo incremental de subsistemas en las diferentes capas. Cuando una interfase cambia en una capa, solamente la capa adyacente se ve afectada u Sin embargo, ofrece dificultad para sistemas estructurados de esta manera.

17 Lic. Domigo F. Donadello 2004 Sistema Administrador de Versiones Administrador de Versiones Administrador de Objetos Sistema de Base de Datos Sistema Operativo

18 Lic. Domigo F. Donadello 2004 Modelos de Control u Se refieren al control de flujo entre subsistemas. Es diferente al modelo de descomposición de sistemas u Control Centralizado Un subsistema tiene sobretodo la responsabilidad de controlar, iniciar y detener otros subsistemas u Control basado en Eventos Cada subsistema puede responder a eventos generados externamente por otros subsistemas o por el ambiente del sistema

19 Lic. Domigo F. Donadello 2004 Control Centralizado u El control de un subsistema es responsable del manejo de la ejecución de otros subsistemas u 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 u 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

20 Lic. Domigo F. Donadello 2004 Modelo Call-Return Programa Principal Rutina 1Rutina 2Rutina 3 Rutina 1.1Rutina 1.2Rutina 3.1Rutina 3.2

21 Lic. Domigo F. Donadello 2004 Sistema de Control en Tiempo Real Proceso de SensorProceso Actuador Controlador del Sistema Procesos de ComputaciónInterfase de UsuarioManejador de Fallas

22 Lic. Domigo F. Donadello 2004 Sistemas Manejadores de Eventos u Manejador de eventos generador externamente donde el tiempo del evento está fuera del control de los subsistemas que lo procesan u 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 u Otros modelos manejadores de eventos incluyen hojas de cálculo y sistemas de producción

23 Lic. Domigo F. Donadello 2004 Modelo de Transmisión (Broadcast) u Es efectivo en la integración de subsistemas en diversas computadoras en una red u 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 u 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 u No obstante, los subsistemas no saben cuando un evento será manejado

24 Lic. Domigo F. Donadello 2004 Transmisión Selectiva Subsistema 1 Subsistema 2 Subsistema 3 Subsistema 4 Manejador de Eventos y Mensajes

25 Lic. Domigo F. Donadello 2004 Sistemas Manejados por Interrupciones u Utilizado en Sistemas de tiempo real donde una respuesta rápida es esencial u Hay tipos de interrupciones con un manejador definido para cada tipo u Cada tipo está asociado con una localidad de memoria y un switch de hardware ocasiona transferencias al manejador u Una respuesta rápida pero compleja de programar y difícil de validar

26 Lic. Domigo F. Donadello 2004 Control de Manejo de Interrupciones Interrupciones Vector de Interrupciones Manejador 1Manejador 2Manejador 3Manejador 4 Proceso 1Proceso 2Proceso 3 Proceso 4

27 Lic. Domigo F. Donadello 2004 Descomposición Modular u Es otro nivel de estructura donde los subsistemas son descompuestos en módulos u 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. u Es posible tomar decisiones acerca de la concurrencia la cual será retrasada hasta que los módulos sean implementados

28 Lic. Domigo F. Donadello 2004 Modelos de Objetos u Estructura el sistema en un conjunto de objetos débilmente acoplados con interfaces bien definidas u La descomposición orientada a objetos se refiere a la identificación de clases de objetos, sus atributos y operaciones u Cuando están implementados, los objetos son creados de esas clases y algunos modelos de control se emplean para coordinar operaciones de los objetos

29 Lic. Domigo F. Donadello 2004 Sistema de Procesamiento de Facturas Cliente Cliente # Nombre Dirección Período de Crédito Recibo Factura # Fecha Cantidad Cliente # Pago Factura # Fecha Cantidad Cliente # Factura Factura # Fecha Cantidad Cliente Emisión Envío de Recordatorio Aceptación de Pago Envío de Recibo

30 Lic. Domigo F. Donadello 2004 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

31 Lic. Domigo F. Donadello 2004 Sistema de Procesamiento de Facturas Lectura de Emisión de Facturas Identificación de Pagos Emisión de Recibos Encontrar pagos duplicados Emisión del Recordatorio de Pago Recordatorios PagosFacturas Recibos

32 Lic. Domigo F. Donadello 2004 Arquitecturas de Dominio Específico u Son modelos de Arquitectura los cuales son específicos para algún dominio de aplicación u 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. u Los modelos genéricos son usualmente modelos bottom- up; los modelos de Referencia son modelos top-down.

33 Lic. Domigo F. Donadello 2004 Modelos Genéricos u 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 u Un modelo de compilador Genérico puede ser organizado de acuerdo a diversos modelos de arquitectura

34 Lic. Domigo F. Donadello 2004 Modelo Compilador Tabla de Símbolos Analizador Léxico Analizador Sintáctico Analizador Semántico Generación de Código

35 Lic. Domigo F. Donadello 2004 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 Analizador Semántico

36 Lic. Domigo F. Donadello 2004 Arquitecturas de Referencia u Los modelos de referencias son derivados del estudio del dominio de una aplicación, en lugar del estudio de sistemas existentes. u 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. u El modelo OSI es un modelo en capas para sistemas de comunicación.

37 Lic. Domigo F. Donadello 2004 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

38 Lic. Domigo F. Donadello 2004 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 QUE EJECUTABAN 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 DECIR QUE 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 MEMORIA COMPITIENDO POR RECURSOS Y COLABORANDO ENTRE SI MEDIANTE INTERFASES ENTRE PROCESOS CON MEMORIA COMPARTIDA EN LA DECADA DEL 90 LA ESTRUCTURACION CLIENTE SERVIDOR SE PUEDE EFECTUAR POR LA APARICION DEL CONCEPTO DE DESCENTRALIZACION DE LOS PROCESOS Y LA COMUNICACIÓN ENTRE LOS MISMOS PUEDE SER EFECTUADA MEDIANTE COMUNICACIÓN DE DATOS POR CONEXIÓN DIRECTA O POR TELECOMUNICACIONES ACTUALMENTE, LA ESTRUCTURACION SE BASA EN EL CONCEPTO DE CAPAS O LAYERS DONDE CADA CAPA ATIENDE ESPECIFICAMENTE UNA PARTE BIEN DISTINGUIDA DEL SISTEMA, EL CLIENTE, EL SERVICIO, LA BASE DE DATOS, LAS COMUNICACIONES Y LOS ALGORITMOS.

39 Lic. Domigo F. Donadello 2004 Resumen u 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. u Los sistemas grandes rara vez conforman un modelo simple de arquitectura. u Los modelos de descomposición de un sistema incluyen modelos repositorios, los modelos cliente- servidor y los modelos de máquina abstracta. u Los modelos de control incluyen control centralizado y modelos manejadores de eventos

40 Lic. Domigo F. Donadello 2004 Resumen u Los modelos de descomposición incluyen modelos de flujo de datos y objetos. u 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.