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



Documentos relacionados
SISTEMAS DE INFORMACIÓN II TEORÍA


Arquitectura de Aplicaciones

Capítulo 5. Cliente-Servidor.

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:

Tema 1. Conceptos fundamentales de los Sistemas Operativos

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

TEMA: PROTOCOLOS TCP/IP

4. Programación Paralela

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

ARC 101 Architecture Overview Diagram

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

Diseño orientado al flujo de datos

IDeP. Service Oriented Network Architecture SONA. IDeP SA La Punta, San Luis, Agosto 2008

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

Capas del Modelo ISO/OSI

Diseño orientado a los objetos

Comunicación entre Procesos y Sockets

Unidad III. Software para la administración de proyectos.

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Comunicación entre procesos

Tema 4. Diseño arquitectónico.

Patrones de software y refactorización de código

Metodología Orientada a Objetos Clave Maestría en Sistemas Computacionales

ITIL FOUNDATION V3 2011

Redes de alta velocidad. William Stallings Traducido por Horacio Goetendía Bonilla

Sistema de SaaS (Software as a Service) para centros educativos

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

El Modelo de Referencia OSI

Fundamentos del diseño 3ª edición (2002)

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

RBAC4WFSYS: Modelo de Acceso para Sistemas Workflow basado en RBAC

1 EL SISTEMA R/3 DE SAP AG

TELECOMUNICACIONES Y REDES

M.T.I. Arturo López Saldiña

Project Ing. Christian Ovalle

INTRODUCCIÓN. Que es un sistema operativo? - Es un programa. - Funciona como intermediario entre el usuario y los programas y el hardware

El gráfico siguiente muestra un uso básico de DNS, consistente en la búsqueda de la dirección IP de un equipo basada en su nombre.

La implantación de un sistema de inteligencia de negocio

Configuración de Software

COMO CONFIGURAR UNA MAQUINA VIRTUAL EN VIRTUALBOX PARA ELASTIX

DATA WAREHOUSING (ENERO DE 2003) Documento creado por Ing. Héctor H. Martínez Orpinel

Presupuestos. Qué lugar ocupa el proceso presupuestario dentro del ciclo BPM? Estrategia Financiera. Nº 254 Octubre 2008

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Nivel aplicación Interacción Cliente Servidor. ELO322: Redes de Computadores Agustín J. González

Enterprise Analyst: Taller de Bautizo

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Capitulo III. Diseño del Sistema.

Ingeniería de Software. Pruebas

Autenticación Centralizada

DISEÑO DE FUNCIONES (TRATAMIENTOS)

CMMI (Capability Maturity Model Integrated)

Ing. Ma. Eugenia Macías Ríos. Administración de Redes

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

Sistemas Multimedia Distribuidos. Juan A. Sigüenza Departamento de Ingeniería Informática UAM

Service Oriented Architecture: Con Biztalk?

Software Computacional y su clasificación

Introducción a las redes de computadores

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

LICITACIÓN N L13045 NUEVO SISTEMA LEY DE TRANSPARENCIA

Ingeniería de Sistemas. Administración de Proyectos. Objetivos. Tópicos cubiertos. Procesos de software (tema anterior) Administración de proyecto

Taller de Sistemas de Información 1. Clase 2 Sistemas de información Arquitectura

Comunicación a través de la red


1. Introducción 2. Historia 3. Características clave 4. Cuestiones de diseño

PORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto

Unidad VI: Dispositivos de comunicaciones

Gestión de Proyectos

Metodologías de diseño de hardware

Informática 4º ESO Tema 1: Sistemas Informáticos. Sistemas Operativos (Parte 2)

Redes de Computadores Contenido.

6 Anexos: 6.1 Definición de Rup:

Capa de red de OSI. Semestre 1 Capítulo 5 Universidad Cesar Vallejo Edwin Mendoza emendozatorres@gmail.com

Estilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura

6.8 La Arquitectura del Sistema. [Proceso]

Figure 7-1: Phase A: Architecture Vision

Anexo a las guías 1 y 2 Notación y convenciones para tensores

CAS-CHILE. Líder en Software de Gestión Pública

UNIVERSIDAD DE ORIENTE FACULTAD DE ICIENCIAS ECONOMICAS LAS REDES I. Licda. Consuelo Eleticia Sandoval

CAPÍTULO 3 VISUAL BASIC

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

Arquitectura de sistema de alta disponibilidad

La vida en un mundo centrado en la red

INTRODUCCION. Ing. Camilo Zapata Universidad de Antioquia

SISTEMAS DE INFORMACIÓN I TEORÍA

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

Efectos de los dispositivos de Capa 2 sobre el flujo de datos Segmentación de la LAN Ethernet

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Comunicación a través de la red

Arquitecturas cliente/servidor

2.4 Modelado conceptual

EL MODELO DE ESTRATIFICACIÓN POR CAPAS DE TCP/IP DE INTERNET

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

Transcripción:

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

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

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

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

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

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

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

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