ARQUITECTURAS DE SOFTWARE

Documentos relacionados
Estilos Arquitectónicos

Arquitecturas de Software

Introducción histórica

octubre de 2007 Arquitectura de Software

Diseño arquitectónico 1ª edición (2002)

Ingeniería de Software Arquitectura y Diseño [2]

Solución 1: Funcional. Estilos arquitectónicos. Solución 1: Funcional (2) Key word in context

Programación Orientada a Objetos. Conceptos Básicos

Diseño y Evaluación de Arquitecturas de Software Introducción Arquitectura de Software

Autor: Amhed Sinue Pérez Valdéz

Tipos Abstractos de Datos (TAD) Lección 1

Metodologías para Sistemas Multi-agente

Guía para la documentación de proyectos de software

2.5 DISEÑO ARQUITECTONICO

Intuitivamente es el proceso que se trata de formular y evaluar una solución para un problema dado

INGENIERÍA DEL SOFTWARE

Diagramas De Casos De Uso

Sistemas Distribuidos. Prog. Distribuida bajo Internet

Modelo de Orientación a Aspectos

Sistema de Administración de Farmacias Descripción de la Arquitectura Versión 1.1. Historia de revisiones

Diseño y Evaluación de Arquitecturas de Software. Estilos Arquitectónicos

ARQUITECTURAS. Carlos Reveco D. IN73J Arquitectura, Diseño y Construcción de un Negocio con Apoyo TI.

PATRONES DE DISEÑO FRAMEWORKS

Diseño: Arquitectura de Software. IF 7100 Ingeniería del Software

Tema I: Introducción a las bases de datos. Curso Introducción a las bases de datos.

El ciclo de vida de un sistema de información

Arquitectura de Software

Código: J63.01 Nivel: 3. Actividades de servicios de información. Tecnología hardware y software

M. C. Felipe Santiago Espinosa

GOBIERNO ELECTRÓNICO

Ingeniería del Software 2

2. Codificar de forma sistemática la secuencia de instrucciones en un lenguaje.

ANÁLISIS DE SISTEMAS. Prof. Eliz Mora

Control del Documento

Guía del Curso Analista Programador Java: Business Apps Expert

Tema 2.- Caracterización de la informática La informática como disciplina científica Sub-áreas de la disciplina.

Principios de Análisis Informático. Tema 3: Fase de inicio

Ingeniería a de Software CC51A

TEMA 6: INTRODUCCIÓN A UML

TECNOLOGÍAS DE LA INFORMACIÓN Y LA COMUNICACIÓN I

Crear diagramas basados en UML para la representación de la solución a un problema mediante el Paradigma Orientado a Objetos.

ARQUITECTURA SOFTWARE (AS)

Ingeniería de Software

Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

CALIDAD DE SISTEMAS DE INFORMACIÓN WEB. Introducción a los métodos de evaluación de arquitecturas

Modelo y Análisis 179

PROGRAMA ANALÍTICO DE ASIGNATURA

Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema

Tema II: Metodología para la construcción de programas. Profesora: Nelly García Mora

Ingeniería del Software II

Guía práctica de estudio 09: UML

ARQUITECTURAS DE SOFTWARE ESPECIALIZADAS

Contenido del curso. Arquitectura de Software III: Elaboración. III: Elaboración. Estilos y patrones. Estilos y patrones. Estilos de arquitectura

Programación Orientada a Objetos

Interacción Persona - Ordenador

Modelado conceptual de aplicaciones web. Tecnologías web

Diseño Estructurado. Diseños eran los antes. Lic. Ariel Trellini 28/07/2015

Modelo Dinámico del Diseño del Software y Representación en UML. UNIDAD 9 Análisis y Diseño de Sistemas de Información

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

INGENIERÍA WEB. Dr. Mario Rossainz López Fac. de Cs. de la Computación Benemérita Universidad Autónoma de Puebla Otoño de 2017

Un importante problema para sistemas de la nueva generación

Introducción a la programación: Contenido. Introducción

Materia compuesta por 6 asignaturas programadas entre el 3º y el 6º semestre, tal y como se recoge a continuación en la tabla de asignaturas

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

1. Secuencia y temporalización de los contenidos.

Ingeniería del Software Herramientas CASE Que es CASE? Ingeniería de sistemas asistida por computadoras (Computer-aised system engineering, o CASE)

METODOLOGÍA DE LA PROGRAMACIÓN

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Diseño de casos de prueba. Pruebas de SI OO

INGENIERÍA DEL SOFTWARE I Práctica 5 Modelado de Diseño

INTRODUCCION AL DISEÑO EDUCATIVO Andrea Paola Leal Rivero. La Academia al servicio de la Vida

Tema II: Metodología para la construcción de programas

Patrones Arquitectónicos de Software

Introducción a UML Información tomada de: - Jacobson et al, El proceso unificado de desarrollo de software

NÚMERO DE HORAS: 160H PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE OBJETIVO

Ingeniería del Software I

Ingeniería del Software Ingeniería del Software de Gestión. Tema 3 Metodologías de Desarrollo de Software

Arquitectura de Software

Productos de Software

Programación Concurrente y Paralela. Unidad 1 Introducción

DIAGRAMAS DE CASOS DE USO. Prof. Hooberth Chávez Bedoya

Temas de proyectos recepcionales

UNT INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE

SILABO DEL CURSO DISEÑO DE SOFTWARE 1. DATOS GENERALES

12/08/2017. Diagrama de secuencia. Diagrama de secuencia. Diagrama de secuencia. Diagrama de secuencia

Qué es SGBD? Mencionar 4 tipos de SGBD. SGBD de red. Román Gutiérrez Sosa. SGBD jerárquicos. Modelo de datos relacionales.

Es un conjunto de palabras y símbolos que permiten al usuario generar comandos e instrucciones para que la computadora los ejecute.

UNIDAD I: INTRODUCCIÓN A LA ARQUITECTURA DE SOFTWARE

Fundamentos de Programación. Sabino Miranda-Jiménez

CONSEJO DE NORMALIZACIÓN Y CERTIFICACIÓN DE COMPETENCIA LABORAL NORMAS TÉCNICAS DE COMPETENCIA LABORAL

Sistemas Operativos. Introducción. Tema 6

METRICA VERSION MÉTRICA versión 3. Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información

Components & Connectors Viewtype. Introducción

PA JOSÉ MANUEL BURBANO CARVAJAL



Tipos de Diseño. Ing. Elizabeth Guerrero V.

Aplicaciones en el Web y redes inhalámbricas. Universidad del Valle Cali - Colombia

CLASE 3: UML DIAGRAMAS CASOS DE USO. Universidad Simón Bolívar. Ingeniería de Software. Prof. Ivette Martínez

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES SYLLABUS DE INGENERIA DE SOFTWARE I

DESARROLLO DE APLICACIONES WEB EN EL ENTORNO SERVIDOR 90h

Transcripción:

ARQUITECTURAS DE SOFTWARE 1. DEFINICIÓN: La arquitectura de software de un programa o de un sistema computacional está definida por la estructura, comprendida por los elementos de software, las propiedades visibles de esos elementos y las relaciones entre ellos. Se incluyen los siguientes elementos: La descripción de los componentes (servidores, clientes, bases de datos, filtros, capas en un sistema jerárquico, etc. ) con los cuales se construyen los sistemas Las interacciones (llamadas a procedimientos, protocolos C/S, protocolos de acceso a BD, etc) entre esos componentes Patrones para guiar la composición Restricciones sobre dichos patrones 1 2. OBJETIVOS: Algunos de los objetivos que se buscan alcanzar al diseñar una arquitectura de software son los siguientes: Comprender y mejorar la estructura de las aplicaciones complejas. Reutilizar dicha estructura (o partes de ella) para resolver problemas similares. Planificar la evolución de la aplicación, identificando las partes que cambian y las que permanecen constantes de la misma, así como los costos de los posibles cambios. Analizar la corrección de la aplicación y su grado de cumplimiento respecto a los requisitos iniciales. Permitir el estudio de algunas propiedades específicas del dominio. Una de las mayores utilidades de utilizar una arquitectura es que un mismo diseño arquitectónico puede servir para dos aplicaciones distintas (ej. los patrones de diseño). Esto facilita el desarrollo de nuevas aplicaciones y reduce el tiempo que se invierte en dicho proceso. Pero así como trae beneficios, toca tener mucho cuidado en el momento de elegir una arquitectura ya que, una arquitectura errónea puede traer consigo muchos problemas. 3. LDA Un LDA es un lenguaje o notación para describir una arquitectura software e incluye principalmente : La descripción de componentes, conectores y enlaces entre ellos. 2 Las herramientas para la verificación de la arquitectura y el prototipado rápido. 3 1 Acuña César Javier. Arquitecturas de Software. Universidad Rey Juan Carlos. 2 Moreno Navarro Juan José. Arquitecturas de Software. Curso de Software basado en Componentes. 3 Moreno Navarro Juan José. Arquitecturas de Software. Curso de Software basado en Componentes.

Existen LDAs de propósito general y otros de dominio específico (DSLs). Los requisitos que debe tener estos lenguajes se pueden clasificar de la siguiente manera 4 : Composición o Debe describir el sistema como una composición de partes Configuración o Debe describir la arquitectura independientemente de los componentes Abstracción o Debe describir los roles abstractos que juegan los componentes Reutilización o Debe permitir reutilizar componentes, conectores, y arquitecturas Heterogeneidad o Debe permitir combinar descripciones heterogéneas Análisis o Debe permitir diversas formas de análisis de la arquitectura Algunos ejemplos de los LDAs son: 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) 4. ESTILOS ARQUITECTÓNICOS Un estilo de arquitectura es una clasificación de los sistemas software en grandes familias cuyos integrantes comparten un patrón estructural común. Este estilo captura paradigmas de computación y comunicación utilizados para tratar con los problemas de programación de una clase en particular 5. En otras palabras, indican los tipos de componentes y conectores involucrados en una arquitectura. Los diferentes estilos de las arquitecturas tiene sus fortalezas y debilidades y, ciertos estilos hacen que sea más fácil o más difícil trabajar con diferentes obstáculos Las propiedades que caracterizan cada estilo es lo que determina la elección de uno u otro. Un estilo de arquitectura debe tener tres elementos básicos: Una notación bien definida para capturar el estilo de desarrollo de la arquitectura. Un método bien definido para producir y analizar formalmente modelos basados en la especificación capturada en la notación. 4 Acuña César Javier. Arquitecturas de Software. Universidad Rey Juan Carlos. 5 Honeywell. What is a Domain-Specific Software Architecture? En http://www.htc.honeywell.com/projects/dssa/dssa_whatis.html

Un método bien definido para producir una implementación basada en la especificación capturada en la notación. Un estilo provee la semántica para realizar los diagramas de arquitectura. Es decir, un estilo establece el significado de los diferentes conectores que se pueden dibujar entre los componentes funcionales. Los sistemas complejos, en su mayoría, son descritos mediante la combinación de dos o más estilos básicos de arquitectura. 5. CLASIFICACIÓN DE ESTILOS Los estilos arquitectónicos se clasifican en los siguientes grupos:. 1. SISTEMAS BASADOS EN FLUJOS 1. Filtros y Pipes 2. Procesamiento por lotes 2. SISTEMAS CALL/RETURN 1. Sistemas Principal/subrutinas 2. Sistemas OO 3. Capas jerárquicas 3. COMPONENTES INDEPENDIENTES 1. Procesos de comunicación 2. Cliente / Servidor 3. Sistemas de Acontecimientos o Eventos 4. MÁQUINAS VIRTUALES 1. Interpretes 2. Sistemas basados en el conocimiento 5. SISTEMAS CENTRADOS EN DATOS 1. Bases de Datos (Repositorios) 2. Sistemas de HiperTexto 3. Sistemas de pizarra

5.1 Filtros y Pipes 5.1.1 Descripción Cada componente tiene un conjunto de entradas y un conjunto de salidas. Cada componente lee las entradas y las transforma en salidas. 5.1.2 Restricciones Los filtros deben ser independientes. No deben compartir estado con otros filtros. Los filtros realizan la labor independientemente del flujo de entrada. 5.1.3 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 independientes de sus vecinos Facilidad de Mantenimiento y mejora Facilidad de diagnóstico (rendimiento, deadlocks) Soportan la ejecución concurrente 5.1.4 Desventajas No aconsejado para cuando se necesita interactividad Problemas de performance ya que los datos se transmiten en forma completa entre filtros

5.2 Sistemas OO 5.2.1 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 5.2.2 Restricciones: Los objetos son responsables de la integridad de sus representaciones Dicha representación es ocultada al resto de los objetos 5.2.3 Ventajas Gracias al invariante de ocultación es posible reemplazar la Implementación sin que afecte a los clientes 5.2.4 Desventajas Para invocar métodos de un objeto se debe conocer su identidad Efectos colaterales

5.3 Capas jerárquicas 5.3.1 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 (Llamadas a procedimientos. Llamadas a métodos) entre las capas. Cada nivel tiene asociado una funcionalidad: o Niveles bajos: Funciones simples, ligadas al hardware o al entorno. o Niveles altos: Funciones más abstractas. 5.3.2 Restricciones: La interacción está limitada a las capas adyacentes 5.3.3 Ventajas Facilita la descomposición del problema en varios niveles de abstracción. Soporta la mejora, los cambios solo afectan a las capas vecinas Se pueden cambiar las implementaciones respetando las interfaces con las capas adyacentes. 5.3.4 Desventajas No todos los sistemas pueden estructurarse en capas. Es difícil encontrar la separación en capas adecuada 5.3.5 Aplicación: Torres de protocolos de comunicación. Sistemas operativos. Compiladores.

5.4 Sistemas de Acontecimientos o Eventos 5.4.1 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 implícita 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 5.4.2 Restricciones: Quien anuncia el evento no conoce a que componentes afecta el evento No se pueden hacer asunciones acerca del orden de procesamiento 5.4.3 Ventajas Provee un robusto soporte de reusabilidad Facilita la evolución del sistema 5.4.4 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

5.5 Sistemas de pizarra 5.5.1 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) 5.5.2 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 5.5.3 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.