Arquitecturas de Software



Documentos relacionados
Estilos Arquitectónicos

ARQUITECTURAS DE SOFTWARE

Arquitecturas de Software

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

Arquitectura de Software


Estilos Arquitectónicos

Estilos Arquitectónicos

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

Capítulo 5. Cliente-Servidor.

Tema 1. Conceptos fundamentales de los Sistemas Operativos

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

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Proceso de desarrollo del software modelo en cascada

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

Arquitectura de Software III: Elaboración. Contenido del curso. III: Elaboración

Proceso de Arquitectura de Software. Segunda. Semana. Dr. Cuauhtémoc Lemus Olalde. Noviembre 7, Informática

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

SISTEMAS DE INFORMACIÓN II TEORÍA

Diseño de Base de Datos

PROCEDIMIENTO ESPECÍFICO. Código G Edición 0

El Proceso Unificado de Desarrollo de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, Introducción al Diseño de Software

Comunicación entre procesos

4. Programación Paralela

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

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

Arquitectura de Aplicaciones

Ciclo de vida y Requerimientos de software. Laboratorio de Programación

Arquitectura. 1.- Aplicaciones Web. Definición. Arquitectura clásica. Contenidos. 1.- Aplicaciones Web

TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA

Grado en Ingeniería Informática

Asignaturas antecedentes y subsecuentes

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

CARRERA TITULO DEL TRABAJO CURSO

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

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

Interacción Persona - Ordenador

Patrones de software y refactorización de código

El Software. Es lo que se conoce como el ciclo de vida del software.

Ingeniería de Software. Pruebas

Programación orientada a

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

Estilos y Patrones Arquitectónicos

GUÍA DOCENTE 1. DESCRIPCIÓN DE LA ASIGNATURA

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

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

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

Unidad 1: Conceptos generales de Sistemas Operativos.

Competencias generales vinculadas a los distintos módulos Módulo de Formación Básica

Ingeniería de Software en SOA

Resumen General del Manual de Organización y Funciones

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

Estándares y lenguajes de marcado para el desarrollo de aplicaciones web orientadas a dispositivos moviles Esteban Saavedra Lopez

Asignaturas antecedentes y subsecuentes

RBAC4WFSYS: Modelo de Acceso para Sistemas Workflow basado en RBAC

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez

MARCO DE REFERENCIA SISTEMAS DE INFORMACIÓN PARA LA GESTIÓN DE TI EN EL ESTADO COLOMBIANO

SISTEMAS DE INFORMACIÓN I TEORÍA

Windows Server 2012: Identidad y Acceso. Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services.

INGENIERÍA INFORMÁTICA

Pattern Oriented Software Architecture. Whole-Part. Jamir Antonio Avila Mojica César Julio Bustacara Medina. Patrones de Software

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

SISTEMAS DE INFORMACIÓN II TEORÍA

Ingeniería de Software

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0

Arquitecturas Software. Arquitecturas Software. Arquitecturas Software. Juan José Moreno Navarro. Motivación: Idea principal: Características:

Capitulo III. Diseño del Sistema.

DEPARTAMENTO DE INFORMÁTICA CICLO FORMATIVO DE GRADO SUPERIOR ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS MÓDULO: REDES DE ÁREA LOCAL CURSO:

Ingeniería de Software Repaso de Requerimientos y Diseño

Figure 7-1: Phase A: Architecture Vision

Sesión No. 12. Contextualización: Nombre de la sesión: SAP segunda parte PAQUETERÍA CONTABLE

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

INTEGRACIÓN DE SISTEMAS HEREDADOS

A continuación resolveremos parte de estas dudas, las no resueltas las trataremos adelante

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño.

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

CICLO DE VIDA DEL SOFTWARE

Medellín, martes 27 de octubre del 2015

CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software

Elementos requeridos para crearlos (ejemplo: el compilador)

Bechtle Solutions Servicios Profesionales

Visión General de GXportal. Última actualización: 2009

ARQUITECTURAS DE SOFTWARE ORIENTADAS A SERVICIOS

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

Service Oriented Architecture

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

Modelado arquitectónico con UML

PLANIFICACIÓN Y PRESENTACIÓN MATERIA/MÓDULO

Universidad Autónoma del Perú Ingeniería de Sistemas. Ing. Heyner Ninaquispe Castro Sesión 1

Ciclo de vida del Software

En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6

DISEÑO DE COMPONENTES DE SOFTWARE *

2.2.- Paradigmas de la POO

Tema 4. Diseño arquitectónico.

PACS. Picture Archiving and Communication Systems


Componentes de Integración entre Plataformas Información Detallada

Transcripción:

Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es

Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO Invocación Implícita Basada en Eventos Sistemas en Capas Sistemas basados en depósitos Máquina Virtual o Interprete 2

Introducción Motivación Incremento en el tamaño y complejidad del software Necesidad de aprender de la experiencia: reutilización de estructuras asociadas a problemas similares Una adecuada estructura general es tan importante como las implementaciones concretas de las partes. Definición La arquitectura de software de un programa o de un sistema computacional esta definida por la estructura, comprendida por los elementos de software, la propiedades visibles de esos elementos y las relaciones entre ellos. 3

Introducción Incluyendo: la descripción de los componentes con los cuales se construyen los sistemas las interacciones entre esos componentes patrones para guiar la composición restricciones sobre dichos patrones Componentes: servidores, clientes, bases de datos, filtros, capas en un sistema jerárquico, etc. Interacciones: llamadas a procedimientos, protocolos C/S, protocolos de acceso a BD, etc. 4

Introducción De qué se ocupa Diseño preliminar o de alto nivel. Organización a alto nivel del sistema, incluyendo aspectos como la descripción y análisis de propiedades relativas a su estructura y control global, los protocolos de comunicación y sincronización utilizados, la distribución física del sistema y sus componentes, etc. Otros aspectos relacionados con el desarrollo del sistema y su evolución y adaptación al cambio: composición, reconfiguración, reutilización, escalabilidad, mantenibilidad, etc. 5

Introducción De qué no se ocupa Diseño detallado. Diseño de algoritmos. Diseño de estructuras de datos. 6

Indican: Los tipos de componentes y conectores involucrados. Patrones y restricciones de interconexión o composición entre ellos: Invariantes del estilo (restricciones) Asociados a cada estilo hay una serie de propiedades que lo caracterizan, determinando sus ventajas e inconvenientes, condicionando la elección de uno u otro estilo. 7

Clasificación General de los Estilos Sistemas Basados en Flujos de Datos Máquinas Virtuales Interpretes Pipes and filters (tuberías y filtros) Sistemas basados en el conocimiento Batch Sequential Sistemas Call/Return Sistemas Centrados en Datos (repositorios) Sistemas Principal/subrutinas Bases de Datos Sistemas OO Sistemas de HiperTexto Capas jerárquicas Sistemas de pizarra Componentes Independientes Procesos de comunicación Sistemas de Acontecimientos 8

Pipes and Filters (tuberías y filtros) Filters Pipes 9

Pipes and Filters (tuberías y filtros) 10 Descripción Cada componente tiene un conjunto de entradas y un conjunto de salidas. Cada componente lee las entradas y las transforma en salidas. Restricciones: Los filtros deben ser independientes. No deben compartir estado con otros filtros. Los filtros realizan la labor independientemente del flujo de entrada. Especializaciones Pipelines Bounded pipes Typed pipes

Pipes and Filters (tuberías y filtros) 11 Ventajas Permite entender el sistema global en términos de la combinación de componentes Soporta de buena manera la reutilización. Los filtros son idependientes de sus vecinos Facilidad de Mantenimiento y mejora Facilidad de diagnóstico (rendimiento, deadlocks) Soportan la ejecución concurrente Desventajas No aconsejado para cuando se necesita interactividad Problemas de performance ya que los datos se transmiten en forma completa entre filtros

Tipos Abstractos de Datos y OO Obj: objetos Op:invocaciones a métodos 12

Tipos Abstractos de Datos y OO Descripción Las representaciones de los datos y las operaciones están encapsulados en un tipo abstracto de datos u objeto Los componentes son objetos Las invocaciones de métodos son los conectores Restricciones: Ventajas Los objetos son responsables de la integridad de sus representaciones Dicha representación es ocultada al resto de los objetos Gracias al invariante de ocultación es posible reemplazar la Implementación si que afecte a los clientes 13

Tipos Abstractos de Datos y OO Desventajas Para invocar métodos de un objeto se debe conocer su identidad Efectos colaterales 14

Invocación Implícita Basada en Eventos!!!!!!! Objetos o Procesos Invocación Implícita 15

Invocación Implícita Basada en Eventos Descripción En lugar de invocaciones de procedimientos explicitas o directas, un componente anuncia uno o más eventos y otros componentes registran el interés en un evento asociando un procedimiento a dicho evento. La ocurrencia de un evento causa la invocación implicita de procedimientos en otros módulos. Los componentes son los módulos cuyas interfaces ofrecen un conjunto de procedimientos y de eventos Los conectores incluyen llamadas a procedimientos tradicionales así como el ligado de eventos con llamadas a procedimientos!!!!!!! 16

Invocación Implícita Basada en Eventos Restricciones: Quien anuncia el evento no conoce a que componentes afecta el evento No se pueden hacer asunciones acerca del orden de procesamiento Ventajas Provee un robusto soporte de reusabilidad Facilita la evolución del sistema Desventajas Perdida de control en el comportamiento del sistema Problemas en el intercambio de datos Es difícil asegurar la corrección global del sistema!!!!!!! 17

Sistemas en Capas Aplicaciones Llamadas a Procedimientos Utilidad básica Nivel Núcleo Usuarios 18

Sistemas en Capas Descripción Organizado jerárquicamente en capas, donde cada capa provee servicios a la capa superior y es servido por la capa inferior Los componentes son cada una de las capas Los conectores son los protocolos de interacción entre las capas Restricciones: Ventajas La interacción está limitada a las capas adyacentes Facilita la descomposición del problema en varios niveles de abstracción. Aplicaciones 19

Sistemas en Capas Soporta la mejora, los cambios solo afectan a las capas vecinas Se pueden cambiar las implementaciones respetando las interfaces con las capas adyacentes. Desventajas No todos los sistemas pueden estructurarse en capas. Es difícil encontrar la separación en capas adecuada Aplicaciones 20

Sistemas basados en depósitos ks1 ks2 Procesamiento ks8 ks7 Pizarra (datos Compartidos) ks3 ks4 Accesos Directos ks6 ks5 Memoria 21

Sistemas basados en depósitos Descripción Existen dos tipos de componentes Una estructura central de datos (representa el estado del proceso) Componentes independientes (operan en función del depósito de datos) Las interacciones entre el repositorio y los demás componentes es variable: La entrada de los datos es seleccionada por los componentes El estado de los datos del repositorio selecciona el proceso a ejecutar (pizarra) ks8 ks1 ks2 ks3 ks7 Pizarra (datos Compartidos) ks4 22 ks6 ks5

Sistemas basados en depósitos Ventajas Posibilita la integración de agentes. Adecuado para la resolución de problemas no deterministas. Se puede resumir el estado de conocimiento en cada momento del proceso Desventajas Estructura de datos común a todos los agentes Problemas de carga a la hora de chequear y vigilar el estado de la pizarra. ks1 ks2 ks8 ks7 Pizarra (datos Compartidos) ks3 ks4 23 ks6 ks5

Máquina virtual o intérprete Entradas Datos (Estado del programa) Programa siendo interpretado Salidas Máquina de Interpretación simulada Instrucción seleccionada Datos seleccionados Estado Interno Del Interprete 24

Máquina virtual o intérprete Descripción Formado por cuatro componentes Ventajas Un motor de simulación o interpretación Una memoria que contiene el código a interpretar Una representación del estado de la interpretación Una representación del estado del programa que se esta simulando Solución software a problemas hardware. Desventajas No siempre es aplicable Reducido a lenguajes de programación 25

Otros Estilos Procesos distribuidos Sistemas cliente/servidor Sistemas en 3 capas Programa Principal/Subrutinas Típica de lenguajes procedurales Un programa principal gestiona el control de ejecución de las subrutinas Transición de Estados Arquitecturas Heterogéneas Se da por la mezcla de estilos Existen diferentes maneras de combinar 26

Lenguajes de Descripción de Arquitecturas (LDAs) Un LDA es un lenguaje o notación para describir una arquitectura software: Descripción de componentes, conectores y enlaces entre ellos. Herramientas para la verificación de la arquitectura y el prototipado rápido. Existen LDAs de propósito general y otros de dominio específico (DSLs) Requisitos Composición Debe describir el sistema como una composición de partes 27

Lenguajes de Descripción de Arquitecturas (LDAs) Configuración Debe describir la arquitectura independientemente de los componentes Abstracción Debe describir los roles abstractos que juegan los componentes Reutilización Debe permitir reutilizar componentes, conectores, y arquitecturas Heterogeneidad Debe permitir combinar descripciones heterogéneas Análisis Debe permitir diversas formas de análisis de la arquitectura 28

Lenguajes de Descripción de Arquitecturas (LDAs) Ejemplos Lenguaje Unificado de Modelado (UML) Lenguajes de interconexión de módulos y de descripción de interfaz (CORBA-IDL) Lenguajes de descripción de arquitectura: Unicon (Mary Shaw y colaboradores - CMU) Wright (Allen y Garlan) Darwin (Magee y Kramer - IC) Rapide (Luckham) C2 (Medvidovic) LEDA (U. Málaga) 29

Bibliografía Software Architecture Perspective on an Emerging discipline M. Shaw, D. Garlan Ed. Prentice Hall. Software Architecture in Practice (2nd Edition) L. Bass, P. Clements, R. Kazman Ed. Addison Wesley Arquitecturas de SW: http://lml.ls.fi.upm.es/~jjmoreno/sbc/arquitecturas_sw.ppt Servicios Avanzados Multimedia Basados en Componentes: http://www.lcc.uma.es/~av/misconfs/p1- arquitecturas.ppt 30