Este documento presenta una introducción a la arquitectura de software. Explica conceptos como estilos arquitectónicos, patrones de diseño e idioms. Describe estilos como cliente-servidor, capas jerárquicas y tubos y filtros. También cubre la importancia de documentar la arquitectura y como esta afecta requisitos como rendimiento, seguridad y mantenibilidad.
El documento describe la metodología RUP (Rational Unified Process). RUP es un proceso de desarrollo de software iterativo e incremental desarrollado por IBM que utiliza el lenguaje UML. El RUP se divide en cuatro fases (Inicio, Elaboración, Construcción y Transición) dentro de las cuales se realizan iteraciones enfocadas en diferentes actividades. El objetivo del RUP es entregar software de alta calidad que satisfaga las necesidades del usuario dentro de tiempo y presupuesto predecibles.
Este documento define la arquitectura de software y discute brevemente su evolución. Define la arquitectura de software como la organización fundamental de un sistema encarnada en sus componentes y las relaciones entre ellos. Luego resume la evolución de la arquitectura de software desde las arquitecturas monolíticas hasta las arquitecturas orientadas a servicios de hoy en día.
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareDaniel Guaycha
El documento describe la estructura estándar de un Documento de Requisitos de Software (ERS) según el IEEE 830-1998, incluyendo las siguientes secciones: Introducción, Descripción General, Requisitos Específicos, Apéndice e Índice. La Introducción presenta el propósito, alcance, definiciones y visión general del documento. La Descripción General no describe requisitos sino su contexto, incluyendo perspectivas del producto, funciones, usuarios y restricciones. Los Requisitos Específicos detallan
Este documento describe el Lenguaje de Modelado Unificado (UML), incluyendo su historia, objetivos, características y extensiones. UML fue creado por tres expertos para modelar sistemas usando conceptos de orientación a objetos de una manera estandarizada. Consiste en vistas, diagramas, elementos del modelo y mecanismos generales. También describe sus extensiones como valores etiquetados, restricciones y estereotipos.
Este documento presenta el análisis, diseño y desarrollo de un sistema para controlar rutas, encomiendas, reservación y venta de tickets para la cooperativa de transportes "Pullman Carchi". El sistema será desarrollado utilizando UML y OOHDM siguiendo los lineamientos de IEEE 830. Se realizará un análisis de requerimientos, diseño conceptual, de navegación, interfaces abstractas y la implementación del sistema. El sistema permitirá administrar rutas, buses, clientes, personal, encomiendas, reservaciones y ventas
El documento describe los pasos en el proceso de diseño arquitectónico de sistemas. Estos incluyen determinar el estilo arquitectónico apropiado, descomponer el sistema en módulos, seleccionar una estrategia de control, evaluar el diseño y documentar la arquitectura final. El diseño arquitectónico debe satisfacer los requisitos funcionales y no funcionales del sistema y puede basarse en uno o más estilos arquitectónicos.
Este documento presenta los conceptos fundamentales del diseño orientado a objetos. Explica que un sistema orientado a objetos está compuesto de objetos que interactúan y mantienen su propio estado y operaciones. Luego describe los pasos clave del proceso de diseño orientado a objetos, incluida la identificación de objetos, el desarrollo de modelos y la especificación de interfaces. Finalmente, resalta la importancia de comprender el contexto del sistema y diseñar una arquitectura apropiada.
El documento describe la metodología RUP (Rational Unified Process). RUP es un proceso de desarrollo de software iterativo e incremental desarrollado por IBM que utiliza el lenguaje UML. El RUP se divide en cuatro fases (Inicio, Elaboración, Construcción y Transición) dentro de las cuales se realizan iteraciones enfocadas en diferentes actividades. El objetivo del RUP es entregar software de alta calidad que satisfaga las necesidades del usuario dentro de tiempo y presupuesto predecibles.
Este documento define la arquitectura de software y discute brevemente su evolución. Define la arquitectura de software como la organización fundamental de un sistema encarnada en sus componentes y las relaciones entre ellos. Luego resume la evolución de la arquitectura de software desde las arquitecturas monolíticas hasta las arquitecturas orientadas a servicios de hoy en día.
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareDaniel Guaycha
El documento describe la estructura estándar de un Documento de Requisitos de Software (ERS) según el IEEE 830-1998, incluyendo las siguientes secciones: Introducción, Descripción General, Requisitos Específicos, Apéndice e Índice. La Introducción presenta el propósito, alcance, definiciones y visión general del documento. La Descripción General no describe requisitos sino su contexto, incluyendo perspectivas del producto, funciones, usuarios y restricciones. Los Requisitos Específicos detallan
Este documento describe el Lenguaje de Modelado Unificado (UML), incluyendo su historia, objetivos, características y extensiones. UML fue creado por tres expertos para modelar sistemas usando conceptos de orientación a objetos de una manera estandarizada. Consiste en vistas, diagramas, elementos del modelo y mecanismos generales. También describe sus extensiones como valores etiquetados, restricciones y estereotipos.
Este documento presenta el análisis, diseño y desarrollo de un sistema para controlar rutas, encomiendas, reservación y venta de tickets para la cooperativa de transportes "Pullman Carchi". El sistema será desarrollado utilizando UML y OOHDM siguiendo los lineamientos de IEEE 830. Se realizará un análisis de requerimientos, diseño conceptual, de navegación, interfaces abstractas y la implementación del sistema. El sistema permitirá administrar rutas, buses, clientes, personal, encomiendas, reservaciones y ventas
El documento describe los pasos en el proceso de diseño arquitectónico de sistemas. Estos incluyen determinar el estilo arquitectónico apropiado, descomponer el sistema en módulos, seleccionar una estrategia de control, evaluar el diseño y documentar la arquitectura final. El diseño arquitectónico debe satisfacer los requisitos funcionales y no funcionales del sistema y puede basarse en uno o más estilos arquitectónicos.
Este documento presenta los conceptos fundamentales del diseño orientado a objetos. Explica que un sistema orientado a objetos está compuesto de objetos que interactúan y mantienen su propio estado y operaciones. Luego describe los pasos clave del proceso de diseño orientado a objetos, incluida la identificación de objetos, el desarrollo de modelos y la especificación de interfaces. Finalmente, resalta la importancia de comprender el contexto del sistema y diseñar una arquitectura apropiada.
La metodología RAD (Rapid Application Development) es un método ágil para el desarrollo de software que consta de 4 etapas: planificación de requisitos, diseño, construcción e implementación. RAD permite crear aplicaciones de alta calidad en poco tiempo a través del uso de herramientas CASE y la colaboración estrecha entre desarrolladores y usuarios. Aunque RAD puede resultar en bajos costos y calidad, se debe asegurar el compromiso de todas las partes y que el proyecto sea adecuado para esta metodología.
Los diagramas son fundamentales en el diseño de sistemas y el desarrollo de programas. Un buen diseño se caracteriza por módulos independientes con un acoplamiento mínimo, mientras que una buena documentación proporciona una visión de alto nivel del sistema y mejora la comprensión. Las métricas como la cohesión y el acoplamiento miden la calidad estructural del software.
Este documento presenta una introducción a los fundamentos de la arquitectura de software. En primer lugar, brinda una breve historia de la arquitectura de software y sus conceptos fundamentales como estilos, lenguajes de descripción de arquitecturas y vistas. Luego, explica conceptos como marcos de referencia, procesos, metodologías, abstracción y escenarios. Por último, enumera algunos de los campos de investigación de la arquitectura de software.
Este documento apresenta os principais conceitos da Linguagem de Modelagem Unificada (UML). Resume os principais métodos de engenharia de software orientados a objetos que levaram ao desenvolvimento da UML e descreve os tipos de modelos e diagramas que compõem a UML, incluindo classes, sequências, casos de uso e máquinas de estados.
UML (Lenguaje Unificado de Modelado) es un lenguaje gráfico estándar para visualizar, especificar, construir y documentar un sistema de software. UML incluye diagramas de clases, secuencia, actividades y despliegue. Los diagramas de clases muestran la estructura estática de un sistema, mientras que los diagramas de secuencia, actividades y despliegue muestran el comportamiento dinámico. El documento proporciona ejemplos de cada tipo de diagrama UML para un sistema de red social.
Este documento presenta el Plan de Desarrollo de Software para el proyecto de desarrollo de un nuevo Sistema para la Gestión del Registro de Nombres de Dominio de Internet bajo ".es". Se describe el alcance, objetivos y entregables del proyecto. Se detallan las fases e iteraciones propuestas siguiendo la metodología RUP. Finalmente, se incluyen secciones sobre la organización del proyecto y la gestión del proceso de desarrollo.
El documento describe el modelo cascada, una metodología para el desarrollo de software que consiste en fases secuenciales como la especificación de requisitos, diseño, implementación, pruebas e implementación. El modelo es exitoso cuando los requisitos están bien definidos y se conocen las herramientas, pero puede tardar mucho tiempo y es rígido si cambian los requisitos.
El documento habla sobre los sistemas de información y los requerimientos en la ingeniería de requerimientos. Explica que un sistema de información es un conjunto de componentes que permiten procesar y distribuir información para apoyar la toma de decisiones. También describe los diferentes tipos de requerimientos como los de proceso, usuarios, análisis y gestión. Finalmente, resalta la importancia de la ingeniería de requerimientos para definir de manera clara y sin ambigüedades las necesidades de un sistema.
Proceso, modelos y metodos de ingenieria de softwaresergio
El documento describe los procesos de software, incluyendo las fases del proceso de software como la especificación, el diseño e implementación, y la validación. También discute los modelos de procesos de software como el modelo en cascada y el desarrollo evolutivo, así como la ingeniería de software basada en componentes. Finalmente, compara los procesos, modelos y métodos de ingeniería de software.
El documento describe varios modelos de procesos de software, incluyendo tres modelos secuenciales (lineal secuencial, iterativo basado en prototipos, y de desarrollo rápido de aplicaciones), tres modelos evolutivos (espiral, de desarrollo concurrente e incremental) y tres modelos ágiles (Scrum, Crystal y Programación Extrema). Define cada modelo y resume brevemente sus características principales.
El documento presenta una introducción al uso de métricas como Puntos de Función y Puntos de Casos de Uso para estimar el esfuerzo requerido en proyectos de desarrollo de software. Explica que los Puntos de Función miden el tamaño funcional del software basado en los requerimientos del usuario, mientras que los Puntos de Casos de Uso también consideran la complejidad de las funcionalidades. Además, proporciona detalles sobre cómo calcular ambas métricas y cómo pueden usarse para mejorar la precisión de las estimaciones
Este documento presenta un resumen del modelo 4+1 para diagramas arquitectónicos. El modelo 4+1 incluye cinco vistas: la vista lógica, la vista de despliegue, la vista de procesos, la vista física y la vista +1 de escenarios. Cada vista se documenta con diagramas UML específicos como diagramas de clases, componentes y casos de uso. El modelo 4+1 es un estándar reconocido para la descripción de arquitecturas de sistemas de software.
Trabajo final diseño y análisis de sistemas.docx1Juleysi China
El documento describe un proyecto de modelado de una tienda de venta de chalinas peruanas utilizando UML. El proyecto tiene como objetivo desarrollar un modelo UML de la empresa SCARVES y una plataforma que facilite las compras de usuarios y proveedores. La tienda compra chalinas a proveedores, las vende a clientes y controla el inventario. El modelo UML representará los procesos de compra y venta, los roles de clientes, proveedores y el control de inventario.
The document discusses the definition of software architecture as comprising the structure of a system including its software elements, externally visible properties, and relationships between elements. It notes that software architecture is influenced by technical, business, and social factors such as immediate business investments, long-term infrastructure investments, strategic investments, and current environmental standards. The architecture affects the developing organization's structure and goals as well as customer requirements for future systems, and the development process can influence the architect's experience on subsequent projects and potentially the software engineering culture. The key steps in architecting a system are outlined as creating the business case, understanding requirements, creating/selecting an architecture, documenting/communicating it, analyzing/evaluating it, implementing based on the architecture
El documento describe el ciclo de vida clásico para el desarrollo de sistemas, el cual consta de 6 fases: investigación preliminar, determinación de requerimientos, diseño del sistema, desarrollo de software, pruebas de sistemas e implementación y evaluación. También se mencionan tres estrategias para el desarrollo de sistemas y se describe el ciclo de vida moderno, el cual añade una fase de planificación.
SQA involucra a varios roles para garantizar la calidad del software a través de las distintas fases de su desarrollo. Establece planes para evaluaciones, auditorías y seguimiento de errores, y proporciona comentarios para mejorar el proceso. El propósito de SQA es proveer visibilidad sobre los procesos y productos de software para asegurar el cumplimiento de estándares y procedimientos.
Este documento describe diferentes métricas y modelos para evaluar la calidad de sistemas de información. Introduce las métricas y su clasificación, incluyendo métricas de calidad de software. Explica modelos de calidad como ISO 9126 que evalúa atributos como funcionalidad, fiabilidad y usabilidad. También cubre métricas internas, externas y de calidad en uso, así como modelos específicos para sitios web y portales.
Este documento presenta los contenidos de una unidad sobre diseño de sistemas de información. Explica que el diseño de software es un proceso iterativo para crear un plan que guíe la construcción del software a partir de los requisitos. Describe las fases del diseño y los cuatro modelos de diseño requeridos: diseño de datos, arquitectónico, de interfaces y a nivel de componentes. También cubre principios como la modularidad y la importancia de lograr calidad en el diseño.
Este documento define los conceptos clave de la ingeniería de requerimientos, incluyendo lo que definen los requerimientos, los problemas al determinarlos y sus soluciones. Explica que los requerimientos describen lo que el sistema debe hacer, sus interacciones y restricciones, y que su determinación temprana reduce costos. También destaca la importancia de entender el problema del negocio para alinear la solución a través del modelado de procesos antes de definir requerimientos.
Este documento presenta un resumen de la arquitectura de desarrollo de software. Explica brevemente la historia y evolución de la arquitectura de software, introduce conceptos clave como estilos, vistas y marcos arquitectónicos, y describe tipos de arquitecturas como flujo de datos. También discute investigación actual y temas relacionados a la arquitectura de software.
Este documento trata sobre el diseño de software. Incluye varios diagramas que muestran ejemplos de vistas modulares, vistas de componentes y conectores, y vistas de despliegue de sistemas de software. También discute conceptos clave como módulos, componentes, conectores, descomposición, encapsulamiento e interfaz.
La metodología RAD (Rapid Application Development) es un método ágil para el desarrollo de software que consta de 4 etapas: planificación de requisitos, diseño, construcción e implementación. RAD permite crear aplicaciones de alta calidad en poco tiempo a través del uso de herramientas CASE y la colaboración estrecha entre desarrolladores y usuarios. Aunque RAD puede resultar en bajos costos y calidad, se debe asegurar el compromiso de todas las partes y que el proyecto sea adecuado para esta metodología.
Los diagramas son fundamentales en el diseño de sistemas y el desarrollo de programas. Un buen diseño se caracteriza por módulos independientes con un acoplamiento mínimo, mientras que una buena documentación proporciona una visión de alto nivel del sistema y mejora la comprensión. Las métricas como la cohesión y el acoplamiento miden la calidad estructural del software.
Este documento presenta una introducción a los fundamentos de la arquitectura de software. En primer lugar, brinda una breve historia de la arquitectura de software y sus conceptos fundamentales como estilos, lenguajes de descripción de arquitecturas y vistas. Luego, explica conceptos como marcos de referencia, procesos, metodologías, abstracción y escenarios. Por último, enumera algunos de los campos de investigación de la arquitectura de software.
Este documento apresenta os principais conceitos da Linguagem de Modelagem Unificada (UML). Resume os principais métodos de engenharia de software orientados a objetos que levaram ao desenvolvimento da UML e descreve os tipos de modelos e diagramas que compõem a UML, incluindo classes, sequências, casos de uso e máquinas de estados.
UML (Lenguaje Unificado de Modelado) es un lenguaje gráfico estándar para visualizar, especificar, construir y documentar un sistema de software. UML incluye diagramas de clases, secuencia, actividades y despliegue. Los diagramas de clases muestran la estructura estática de un sistema, mientras que los diagramas de secuencia, actividades y despliegue muestran el comportamiento dinámico. El documento proporciona ejemplos de cada tipo de diagrama UML para un sistema de red social.
Este documento presenta el Plan de Desarrollo de Software para el proyecto de desarrollo de un nuevo Sistema para la Gestión del Registro de Nombres de Dominio de Internet bajo ".es". Se describe el alcance, objetivos y entregables del proyecto. Se detallan las fases e iteraciones propuestas siguiendo la metodología RUP. Finalmente, se incluyen secciones sobre la organización del proyecto y la gestión del proceso de desarrollo.
El documento describe el modelo cascada, una metodología para el desarrollo de software que consiste en fases secuenciales como la especificación de requisitos, diseño, implementación, pruebas e implementación. El modelo es exitoso cuando los requisitos están bien definidos y se conocen las herramientas, pero puede tardar mucho tiempo y es rígido si cambian los requisitos.
El documento habla sobre los sistemas de información y los requerimientos en la ingeniería de requerimientos. Explica que un sistema de información es un conjunto de componentes que permiten procesar y distribuir información para apoyar la toma de decisiones. También describe los diferentes tipos de requerimientos como los de proceso, usuarios, análisis y gestión. Finalmente, resalta la importancia de la ingeniería de requerimientos para definir de manera clara y sin ambigüedades las necesidades de un sistema.
Proceso, modelos y metodos de ingenieria de softwaresergio
El documento describe los procesos de software, incluyendo las fases del proceso de software como la especificación, el diseño e implementación, y la validación. También discute los modelos de procesos de software como el modelo en cascada y el desarrollo evolutivo, así como la ingeniería de software basada en componentes. Finalmente, compara los procesos, modelos y métodos de ingeniería de software.
El documento describe varios modelos de procesos de software, incluyendo tres modelos secuenciales (lineal secuencial, iterativo basado en prototipos, y de desarrollo rápido de aplicaciones), tres modelos evolutivos (espiral, de desarrollo concurrente e incremental) y tres modelos ágiles (Scrum, Crystal y Programación Extrema). Define cada modelo y resume brevemente sus características principales.
El documento presenta una introducción al uso de métricas como Puntos de Función y Puntos de Casos de Uso para estimar el esfuerzo requerido en proyectos de desarrollo de software. Explica que los Puntos de Función miden el tamaño funcional del software basado en los requerimientos del usuario, mientras que los Puntos de Casos de Uso también consideran la complejidad de las funcionalidades. Además, proporciona detalles sobre cómo calcular ambas métricas y cómo pueden usarse para mejorar la precisión de las estimaciones
Este documento presenta un resumen del modelo 4+1 para diagramas arquitectónicos. El modelo 4+1 incluye cinco vistas: la vista lógica, la vista de despliegue, la vista de procesos, la vista física y la vista +1 de escenarios. Cada vista se documenta con diagramas UML específicos como diagramas de clases, componentes y casos de uso. El modelo 4+1 es un estándar reconocido para la descripción de arquitecturas de sistemas de software.
Trabajo final diseño y análisis de sistemas.docx1Juleysi China
El documento describe un proyecto de modelado de una tienda de venta de chalinas peruanas utilizando UML. El proyecto tiene como objetivo desarrollar un modelo UML de la empresa SCARVES y una plataforma que facilite las compras de usuarios y proveedores. La tienda compra chalinas a proveedores, las vende a clientes y controla el inventario. El modelo UML representará los procesos de compra y venta, los roles de clientes, proveedores y el control de inventario.
The document discusses the definition of software architecture as comprising the structure of a system including its software elements, externally visible properties, and relationships between elements. It notes that software architecture is influenced by technical, business, and social factors such as immediate business investments, long-term infrastructure investments, strategic investments, and current environmental standards. The architecture affects the developing organization's structure and goals as well as customer requirements for future systems, and the development process can influence the architect's experience on subsequent projects and potentially the software engineering culture. The key steps in architecting a system are outlined as creating the business case, understanding requirements, creating/selecting an architecture, documenting/communicating it, analyzing/evaluating it, implementing based on the architecture
El documento describe el ciclo de vida clásico para el desarrollo de sistemas, el cual consta de 6 fases: investigación preliminar, determinación de requerimientos, diseño del sistema, desarrollo de software, pruebas de sistemas e implementación y evaluación. También se mencionan tres estrategias para el desarrollo de sistemas y se describe el ciclo de vida moderno, el cual añade una fase de planificación.
SQA involucra a varios roles para garantizar la calidad del software a través de las distintas fases de su desarrollo. Establece planes para evaluaciones, auditorías y seguimiento de errores, y proporciona comentarios para mejorar el proceso. El propósito de SQA es proveer visibilidad sobre los procesos y productos de software para asegurar el cumplimiento de estándares y procedimientos.
Este documento describe diferentes métricas y modelos para evaluar la calidad de sistemas de información. Introduce las métricas y su clasificación, incluyendo métricas de calidad de software. Explica modelos de calidad como ISO 9126 que evalúa atributos como funcionalidad, fiabilidad y usabilidad. También cubre métricas internas, externas y de calidad en uso, así como modelos específicos para sitios web y portales.
Este documento presenta los contenidos de una unidad sobre diseño de sistemas de información. Explica que el diseño de software es un proceso iterativo para crear un plan que guíe la construcción del software a partir de los requisitos. Describe las fases del diseño y los cuatro modelos de diseño requeridos: diseño de datos, arquitectónico, de interfaces y a nivel de componentes. También cubre principios como la modularidad y la importancia de lograr calidad en el diseño.
Este documento define los conceptos clave de la ingeniería de requerimientos, incluyendo lo que definen los requerimientos, los problemas al determinarlos y sus soluciones. Explica que los requerimientos describen lo que el sistema debe hacer, sus interacciones y restricciones, y que su determinación temprana reduce costos. También destaca la importancia de entender el problema del negocio para alinear la solución a través del modelado de procesos antes de definir requerimientos.
Este documento presenta un resumen de la arquitectura de desarrollo de software. Explica brevemente la historia y evolución de la arquitectura de software, introduce conceptos clave como estilos, vistas y marcos arquitectónicos, y describe tipos de arquitecturas como flujo de datos. También discute investigación actual y temas relacionados a la arquitectura de software.
Este documento trata sobre el diseño de software. Incluye varios diagramas que muestran ejemplos de vistas modulares, vistas de componentes y conectores, y vistas de despliegue de sistemas de software. También discute conceptos clave como módulos, componentes, conectores, descomposición, encapsulamiento e interfaz.
El documento describe el proceso de estimación de costos para un proyecto de desarrollo de software. Explica que el diseño modular reduce la complejidad y facilita los cambios. Luego, introduce el método de puntos de caso de uso para estimar el esfuerzo requerido, el cual se basa en identificar las transacciones en cada caso de uso. Finalmente, discute los desafíos en definir y contar estas transacciones de caso de uso, ya que esto afecta directamente los resultados de la estimación.
Los patrones de diseño permiten resolver problemas comunes de diseño de software de forma reutilizable. Se describen tres patrones: el patrón Singleton, que asegura que una clase tenga una única instancia, el patrón Estrategia, que define una familia de algoritmos y los hace intercambiables, y el patrón Observer, que define una dependencia uno a muchos para notificar cambios en el estado de objetos. Conocer y aplicar patrones de diseño mejora la calidad del software al promover el reuso y la flexibilidad.
Este documento describe los patrones de diseño de software orientado a objetos. Explica que los patrones de diseño son soluciones a problemas comunes en el diseño de software que pueden ser aplicados repetidamente. Describe tres tipos principales de patrones: patrones creacionales que se enfocan en la creación de objetos, patrones estructurales que describen cómo relacionar objetos y clases, y patrones de comportamiento que distribuyen responsabilidades entre objetos. También presenta el patrón Observer como un ejemplo, explicando sus participantes, colaboración y consec
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTECAMILO
El documento describe métodos para estimar el costo de un proyecto de desarrollo de software. Explica que la estimación de costos es importante para la toma de decisiones al comenzar un proyecto. Señala que los casos de uso ayudan a definir claramente los requisitos funcionales y el alcance del sistema. Luego introduce el método de puntos en casos de uso como un enfoque prometedor para estimar el tamaño y costo de un proyecto basado en su descripción mediante casos de uso.
Este documento presenta una introducción al seminario de arquitectura de software dictado por Billy Reynoso de la Universidad de Buenos Aires. El seminario consta de 4 webcasts que cubren temas como los estilos de arquitectura, la arquitectura orientada a servicios y el diseño de la arquitectura. Además, el primer webcast introduce conceptos clave de la arquitectura de software como estilos, puntos de vista, requerimientos no funcionales y lenguajes de descripción arquitectónica.
Este documento describe los conceptos clave del diseño arquitectónico de sistemas de información. Explica diferentes estilos arquitectónicos como la arquitectura centrada en datos, en capas y distribuida. También cubre temas como la descomposición modular, estilos de control y documentación de la arquitectura.
Presentacion de Software y Estimacion de CosteCAMILO
El diseño es el proceso clave para la calidad del software. Requiere modularidad efectiva para reducir complejidad y facilitar cambios, resultando en una implementación más sencilla. Los principios de diseño orientado a objetos incluyen abstracción, encapsulamiento, modularidad y jerarquía. Estimar correctamente el costo de un proyecto de software es importante, y los casos de uso y el método de puntos de casos de uso pueden ayudar a definir el alcance y tamaño del proyecto para una estimación inicial.
El documento describe el método de puntos de caso de uso para la estimación de costos de desarrollo de software. Este método se basa en identificar los casos de uso del sistema y sus transacciones, y asignar un peso a cada caso de uso en función del número de transacciones. El peso de los casos de uso se usa para calcular los puntos de caso de uso iniciales, los cuales luego se ajustan considerando factores técnicos y ambientales para estimar el esfuerzo de desarrollo requerido. La definición de una transacción de caso de uso y la met
presentacion de software y estimacion de dosteCAMILO
El diseño es el proceso clave para la calidad del software. Requiere un enfoque modular que reduzca la complejidad y facilite cambios, resultando en una implementación más sencilla. Los principios del modelo orientado a objetos como la abstracción, encapsulación, modularidad y jerarquía son fundamentales para el diseño. Estimar correctamente el costo de un proyecto de software desde el inicio es importante, y métodos como los puntos de caso de uso ayudan a definir el alcance del proyecto y realizar estimaciones iniciales.
El documento describe el método de puntos de caso de uso para la estimación de costos de desarrollo de software. Este método se basa en identificar los casos de uso del sistema y sus transacciones, y asignar un peso a cada caso de uso en función del número de transacciones. El peso de los casos de uso se usa para calcular los puntos de caso de uso iniciales, los cuales luego se ajustan considerando factores técnicos y ambientales para estimar el esfuerzo de desarrollo requerido. La definición de una transacción de caso de uso y la met
El documento describe el método de puntos de caso de uso para la estimación de costos de desarrollo de software. Este método se basa en identificar los casos de uso del sistema y sus transacciones, y asignar un peso a cada caso de uso en función del número de transacciones. El peso de los casos de uso se usa para calcular los puntos de caso de uso iniciales, los cuales luego se ajustan considerando factores técnicos y ambientales para estimar el esfuerzo de desarrollo requerido. La definición de una transacción de caso de uso y la met
El documento habla sobre el desarrollo de sistemas de información y la ingeniería de software. Explica que existen dos enfoques principales para el desarrollo de software: el enfoque estructurado y el enfoque orientado a objetos. También describe los conceptos clave del paradigma orientado a objetos como abstracción, encapsulamiento, herencia y polimorfismo.
Este documento describe varios modelos de desarrollo de software, incluyendo el modelo en cascada, RAD, incremental, en espiral y basado en reutilización. Explica las actividades clave en el proceso de desarrollo de software como el análisis de requerimientos, diseño, programación, pruebas e integración. Además, compara los diferentes modelos y discute sus ventajas y desventajas.
El documento describe los conceptos clave de la arquitectura de software, incluyendo sus principales componentes y cómo especificarla a través de diferentes vistas y modelos. También explica la evolución de las arquitecturas de software y el rol del arquitecto de software.
El documento describe los conceptos clave de la arquitectura de software, incluyendo sus principales componentes y cómo especificarla a través de diferentes vistas y modelos. También explica la evolución de las arquitecturas de software y el rol del arquitecto de software.
Este documento presenta información sobre arquitectura orientada a microservicios y manejo de estados. Explica brevemente los objetivos de desarrollo sostenible de las Naciones Unidas y los resultados de aprendizaje relacionados con el diseño de software robusto, fácil de mantener y modificar. Además, proporciona contexto sobre los temas clave de ingeniería de software como patrones, métodos ágiles y arquitectura de software.
Ingenieria de sistemas basada en modelosBryan Thomas
Este documento describe los conceptos fundamentales de la ingeniería de sistemas basada en modelos (MBSE). La MBSE se centra en la creación y uso de modelos como principal medio de intercambio de información entre ingenieros. Los modelos representan el sistema de manera simplificada y abstraída. La MBSE cubre cuatro dominios: requisitos, comportamiento, arquitectura y verificación/validación. Un lenguaje de modelado de sistemas claro es fundamental para representar el modelo de manera precisa. Los modelos incluyen las perspectivas oper
Se establece un recorrido por elementos fundamentales del diseño de software. Elementos como la funcionalidad, la facilidad de uso, la soportabilidad, entre otras.El refinamiento, la refabricación y las diversas clases de diseño pueden se encontradas en este documento.
2. 2
Bibliografía
• Software Engineering 7ed
Addison Wesley
Ian Sommerville
• Documenting Software Architectures – Views and Beyond
Addison-Wesley
Paul Clements et al.
• Software Systems Architecture – Working with stakeholders using
viewpoints and perspectives
Addison-Wesley
Nick Rozanski y Eoin Woods
3. 3
Arquitectura de Software
Especificación de Requerimientos del sistema (SRS)
Sistema instalado y funcionando
En este camino hay mucho por
hacer.
¿Comenzamos a programar
para terminar lo antes posible?
- ¿Cuáles serían los riesgos?
4. 4
Arquitectura de Software
Especificación de Requerimientos del sistema (SRS)
Sistema instalado y funcionando
-Arquitectura de Software
-Diseño detallado
-Implementación
-Verificación
No es un
proceso en
cascada. No se
está definiendo
un proceso.
5. 5
Arquitectura de Software
Los sistemas complejos están compuestos de
subsistemas que interactúan bajo el control de un
diseño de sistema
Arquitectura de Software
Los subsistemas que componen el sistema,
las interfaces y
las reglas de interacción entre ellos.
6. 6
Definición
A software architecture for a system is the structure or
structures of the system, which consist of elements, their
externally visible properties, and the relationships among
them.
Documenting software architectures, views and beyond
7. 7
Importancia
Ventajas de diseñar y documentar explícitamente
una arquitectura de software:
Comunicación entre stakeholders
Decisiones tempranas de diseño
Reuso a gran escala
Bass, et al, Software Architecture in
Practice 2ed.
Addison-Wesley.
8. 8
¿Qué Afecta y qué la Determina?
• La arquitectura de software afecta la
Performance
Seguridad (security y safety)
Disponibilidad
Mantenibilidad
…
• Entonces, el estilo y estructura particular elegido
para una aplicación dependen fuertemente de
los requerimientos no funcionales.
9. 9
Conflictos entre Soluciones
• El sistema debe ser “muy” performante y “muy”
mantenible
• ¿Cuál es el conflicto al momento de elegir el
estilo arquitectónico?
• ¿Cómo se puede solucionar?
Solución de compromiso
Diferentes estilos para distintas partes del sistema
10. 10
¿Qué tan Fácil es Modificarla?
• Sears
EEUU
527 metros
• Petronas
Malasia
452 metros
• Taipei 101
China
508 metros
11. 11
¿Qué tan Fácil es Modificarla?
Me gustaría que el
ascensor quedara del
otro lado
Estaría bárbaro que el
puente estuviera 23
pisos más arriba, la
vista sería mejor
12. 12
¿Qué tan Fácil es Modificarla?
Burj Dubai, otros metros más arriba, Emiratos Árabes
14. 14
Patrones de Software
• Propósito
Compartir una solución probada,
ampliamente aplicable
a un problema particular de diseño.
El patrón se presenta en una forma estándar que
permite que sea fácilmente reutilizado.
• Cinco piezas importantes de un patrón
Nombre
Contexto
Problema
Solución
Consecuencias (positivas y negativas)
15. 15
Estilos, Patrones e Idioms
• Los patrones de diseño se agrupan en tres tipos
Estilos arquitectónicos: Soluciones de organización
a nivel del sistema
Patrones de diseño: Soluciones a problemas
detallados de diseño de software
Idioms: Soluciones útiles para problemas específicos
en algún lenguaje de programación
16. 16
Estilos Arquitectónicos
• Un estilo arquitectónico
expresa un esquema de organización estructural para
sistemas de software.
Provee un conjunto de tipos de elementos
predefinidos,
especifica sus responsabilidades e
incluye reglas y guías para organizar las relaciones
entre ellos Capa n
Capa n - 1
Capa 2
Capa 1
17. 17
Patrones de Diseño
• Un patrón de diseño
provee un esquema para refinar los elementos de un
sistema de software o las relaciones entre ellos.
Describe una estructura recurrente de elementos de
diseño interconectados que soluciona un problema
general de diseño dentro de un contexto particular
• Mencionen algún patrón de diseño que
conozcan
18. 18
Idioms
• Un idiom
es un patrón de bajo nivel, específico para un
lenguaje de programación.
Describe como implementar aspectos particulares de
elementos o de las relaciones entre ellos usando las
características de un lenguaje particular.
20. 20
Beneficios de Usar Estilos
• Permite seleccionar una solución entendible y
probada a ciertos problemas, definiendo los
principios organizativos del sistema
• Al basar la arquitectura en estilos que son
conocidos las personas entienden más
fácilmente las características importantes de la
misma
21. 21
Formas de Uso de los Estilos
• Solución para el diseño del sistema
Algún estilo sirve.
Se adopta y se usa como una de las estructuras
centrales de la arquitectura.
• Base para una adaptación
Algún estilo soluciona parcialmente los problemas.
Se puede buscar adaptar el estilo para las
restricciones particulares que se tienen.
22. 22
Formas de Uso de los Estilos (2)
• Inspiración para una solución relacionada
Ningún estilo sirve.
Sin embargo, entender problemas que solucionan
ciertos estilos puede llevar a entender mejor el
problema actual.
Entonces, se puede encontrar una solución que de
alguna forma está relacionada con estilos existentes
• Motivación para un nuevo estilo
El problema no es atacado por ningún estilo
encontrado
Es una buena oportunidad para encontrar una
solución general al problema y crear un nuevo estilo
23. 23
Algunos Estilos
• Shared Data (Datos Compartidos)
Pizarrón (Blackboard)
• Cliente-Servidor
• Capas Jerárquicas
• Descomposición Orientada a Objetos
• Tubos y Filtros
• Control Centralizado
• Control Basado en Eventos
• Arquitecturas de Sistemas Distribuidos
Cliente-Servidor
Objetos Distribuidos
Peer-To-Peer
Service Oriented Architecture (SOA)
24. 24
Shared-Data
• Generalidades
Hay un almacenamiento central de datos y un
conjunto de componentes que operan sobre éste.
Interacción - intercambio de datos persistentes
Múltiples accesos a los datos
Al menos un almacenamiento compartido
Si se avisa al consumidor de nuevos datos de interés
es un Pizarrón (Blackboard)
Si es el consumidor quien busca los datos es un
Repositorio
25. 25
Ventajas y Desventajas
• Forma eficiente de compartir grandes cantidades de
datos.
No se transmiten datos de un componente a otro.
• Sin embargo, los subsistemas deben estar de acuerdo
en el modelo de datos del repositorio.
• Las componentes que producen datos no necesitan
conocer como van a ser usados esos datos.
• Actividades como respaldos, seguridad, control de
acceso y recuperación están centralizadas.
• Sin embargo, diferentes componentes podría tener
distintas políticas de recuperación, respaldo, etc.
26. 26
Pizarrón (Blackboard)
• Fuentes de Conocimiento
Procesos independientes que corresponden a particiones del
conocimiento del mundo y del dominio dependientes de la
aplicación
Responden a cambios en el pizarrón
• Estructura de datos del Pizarrón
Estado completo de la solución del problema
único medio por el cual las Fuentes de conocimiento interactúan
para llegar a la solución
• Control
Guiado enteramente por el estado del pizarrón
Las Fuentes de conocimiento responden oportunamente cuando
los cambios en el pizarrón aplican
Puede implementarse en las FC, en el pizarrón, en un
componente separado o cualquier combinación de éstos.
28. 28
Cliente-Servidor
• El sistema se descompone en servicios y sus
servidores asociados y en clientes que acceden y usan
dichos servicios.
• Estilo compuesto por:
Servidores que ofrecen servicios.
Clientes que usan servicios ofrecidos por los servidores.
Una red que permite que los clientes accedan a los servidores.
• Esto no es estrictamente necesario ya que clientes y servidores
pueden estar en una misma máquina.
• Los clientes conocen a los servidores pero no a otros
clientes y los servidores no tienen porqué conocer a los
clientes
• la asignación de procesos a procesadores no tiene
porqué ser 1:1
30. 30
Capas Jerárquicas
• El sistema se organiza en capas.
• Cada una provee un conjunto de servicios a las
capas superiores y requiere servicios de las
inferiores.
Capa n
Capa n - 1
Capa 2
Capa 1
31. 31
Capas Jerárquicas (2)
• Modelo estricto: una capa sólo utiliza servicios
de la inmediata inferior.
• Modelo relajado: se pueden “saltar” capas.
• Definición de protocolos mediante los que
interactúan las capas
32. 32
Ventajas y Desventajas
• Ventajas
Facilita la comprensión
Facilita mantenimiento
Facilita reutilización
Facilita portabilidad
• Desventajas
No siempre es fácil estructurar en capas ni identificar
los niveles de abstracción a partir de los
Requerimientos.
la interpretación de comandos en múltiples niveles
puede afectar el desempeño.
33. 33
Descomposición O.O.
• Se descompone el sistema en un conjunto de
objetos que se comunican.
• Representación de datos y operaciones
asociadas se encapsulan en un objeto.
• Herencia, polimorfismo, sobrecarga de
operadores, enlace dinámico.
34. 34
Ventajas y Desventajas
• Ventajas
La implementación de los objetos puede ser
cambiada sin afectar a otros objetos.
Promueve la reutilización de componentes.
Muchos objetos representan entidades de la realidad
por lo que es fácil entender la estructura del sistema.
• Desventajas
Para usar servicios se debe conocer el nombre de la
interface de otro objeto.
Los cambios en las interfaces afectan a todos los
objetos que la usan.
35. 35
Tubos y Filtros
• Se descompone el sistema en módulos funcionales
• Interacción - sucesiva transformación de flujos de datos
• Los datos llegan a un filtro, se transforman y son pasados a través
de tubos al siguiente filtro
• Un único filtro puede pasar datos a múltiples tubos y recibir datos
de múltiples tubos
• Cada filtro es independiente del resto y no conoce la identidad de
los otros filtros
• La transformación del filtro puede comenzar antes de terminar de
leer la entrada
• Respetando el grafo, no importa la secuencia (paralelismo)
Filtro
Tubo
36. 36
Ventajas y Desventajas
• Ventajas
Se pueden reutilizar los filtros.
Es intuitivo pensar en secuencias de procesamientos
de datos.
Agregar nuevas transformaciones de forma que el
sistema evolucione es sencillo.
• Desventajas
Acordar cuál es el formato de los datos.
• Tiene que ser “genérico” si las componentes son
reusadas.
Sistemas interactivos son difíciles de construir con
este estilo.
Ineficiente si hace más de lo que debe o si los filtros
repiten chequeos
37. 37
Modelos de Control
• Modelos de control a nivel de la arquitectura se
preocupan del flujo de control entre subsistemas
Control centralizado
• Un subsistema controla al resto
Control basado en eventos
• Cada subsistema puede responder a eventos externos
– Eventos generados por otros subsistemas
– Eventos generados por el ambiente del sistema
38. 38
Control Centralizado (1)
• El control centralizado se puede dividir en dos
clases
Llamada-Retorno Principal
Subr. A Subr.B Subr.C
Subsistema
Llamado/Retorno
39. 39
Control Centralizado (2)
• Modelo Gerente
Una componente es el gerente del sistema y controla
a los otros procesos del sistema
Controlador del Sistema
A
B
F
E
C
D
40. 40
Control Basado en Eventos
• En los modelos centralizados las decisiones de
control suelen estar determinadas por valores
de alguna variable de estado del sistema
• En cambio, el control basado en eventos es
guiado por eventos generados externamente
• Ejemplos
Modelos emisión (broadcast). Se emiten los eventos
a todos los subsistemas.
Modelos guiados por interrupciones. Se usan en
sistemas de tiempo real. Las interrupciones son
pasadas por un manejador de interrupciones a otras
componentes para su procesamiento.
41. 41
Publicar-Suscribir
• Sistema de componentes independientes que
anuncian y se suscriben a eventos
• Interacción vía eventos anunciados
• Los componentes se suscriben a eventos
• Es trabajo del run-time asegurarse que cada
evento publicado sea entregado a todos los
suscriptores de dicho evento
• Una forma es la invocación implícita
42. 42
Arquitecturas de Sistemas Distribuidos
• Ventajas
Se comparten recursos.
Apertura. Normalmente estos sistemas están
diseñados con protocolos estándar.
Concurrencia.
Escalabilidad
Tolerancia a fallas
El procesamiento de la información es distribuido entre varias
computadoras.
43. 43
Arquitecturas de Sistemas Distribuidos (2)
• Desventajas
Complejidad
Seguridad
Difíciles de gestionar
Muy poco predecibles
• Ejemplos
Cliente-servidor
Objetos distribuidos
Peer-to-peer
Service oriented architecture (SOA)
44. 44
Middleware
• Las componentes pueden ser
Implementadas en diferentes lenguajes
Ejecutarse en distintos tipos de procesadores
Usar diferentes modelos de datos
Representar de forma diferente la información
Usar distintos protocolos de comunicación
• Entonces, se necesita software para gestionar la
comunicación y el intercambio de datos entre
componentes
Dicho software se denomina middleware
• Esta en el medio de las diferentes componentes distribuidas
46. 46
Cliente-Servidor
• El diseño de sistemas cliente-servidor debería
reflejar la estructura lógica de la aplicación.
• Una forma de mirar a una aplicación es la
siguiente:
Capa de Presentación
Capa de Procesamiento
Capa Gestión de Datos
47. 47
Cliente-Servidor (2)
• Capa de presentación
Presentación de información al usuario e interacción
con el mismo
• Capa de procesamiento
Implementación de la lógica de la aplicación
• Capa gestión de datos
Operaciones de bases de datos y archivos
• En sistemas distribuidos es importante distinguir
claramente esta separación ya que es posible
distribuir cada capa en computadoras diferentes
48. 48
Cliente-Servidor en 2 Niveles
• Es la arquitectura más simple cliente-servidor
• Varios clientes y un servidor (o varios servidores
idénticos)
• 2 formas diferentes:
Cliente fino
• El procesamiento de la información y la gestión de los datos
ocurre en el servidor. El cliente sólo es responsable de
ejecutar el software de presentación.
Cliente grueso
• El servidor es responsable sólo de la gestión de los datos. El
cliente ejecuta el procesamiento de la aplicación (la lógica
de la aplicación) y la presentación.
49. 49
Cliente Fino, Grueso y Applet
• Cliente fino
Procesamiento pesado del lado del servidor
Procesamiento pesado en la red
• Cliente grueso
Mejor distribución del procesamiento
La administración del sistema es más compleja
• Cuando el software de aplicación cambia hay que reinstalar
la aplicación en cada computadora cliente
• Java Applets descargables
Están en el medio entre cliente fino y grueso
Luego de descargar el applet se ejecuta parte de la
lógica de la aplicación en el cliente
50. 50
Algunos Problemas
• En 2 niveles hay que distribuir las tres capas
(presentación, lógica y datos) en dos sistemas
de computadoras
Pueden surgir problemas de
• escalabilidad y rendimiento con el cliente fino
• o de gestión del sistema si se usa cliente grueso
• Para evitar estos problemas una alternativa es
usar una arquitectura cliente-servidor en 3
niveles
51. 51
Cliente-Servidor en 3 Niveles
• La presentación, la lógica y los datos se
separan como procesos lógicos diferentes
distribuidos en distintas máquinas
• Ejemplo: Sistema bancario por internet
Client
e
Client
e
Client
e
Client
e
Servidor web
Provisión de
servicios
de cuenta
Servidor de BD
SQL
Base Datos
Cuenta
Cliente
HTTP
Consulta SQL
52. 52
Comparación
• La arquitectura en 3 niveles
Es más escalable que la de 2 niveles
Reduce el tráfico en la red en comparación con
cliente fino
La capa de procesamiento de la aplicación es
fácilmente actualizada ya que está localizada
centralmente
• Cliente servidor en múltiples niveles
Ejemplo: aplicación que necesita acceder a múltiples
fuentes de datos (integración de datos)
53. 53
Ejemplos
Arquitectura Aplicaciones
Arquitectura C/S
dos niveles
cliente fino
• Aplicaciones legadas en las cuales no se puede separar el
procesamiento de la gestión de los datos
• Aplicaciones intensivas en las computaciones con poco o
nada de gestión de datos (ej: compiladores)
• Aplicaciones intensivas en manejo de datos (browsing y
consultas) con poco o nada de procesamiento de aplicación
Arquitectura C/S
dos niveles
cliente grueso
• Aplicaciones donde el procesamiento de la aplicación es
provisto off-the-shelf en el cliente
• Aplicaciones donde se hacen intensivos procesamientos
computacionales de los datos (ej: visualización de datos)
Arquitectura C/S
tres niveles o
múltiples niveles
• Aplicaciones de gran escala con cientos o miles de clientes
• Aplicaciones en donde tanto los datos como el
procesamiento son volátiles
• Aplicaciones con fuentes de datos múltiples
54. 54
Objetos Distribuidos
• En la arquitectura cliente-servidor los clientes y los
servidores son distintos
Los clientes reciben servicios de los servidores y no de otros
clientes
Los servidores pueden actuar como clientes de otros servidores
pero no requieren servicios de clientes
Los clientes deben conocer los servicios ofrecidos por
servidores específicos y deben conocer como contactar a estos
servidores
• Enfoque más general
Remover la distinción entre clientes y servidores
Diseñar la arquitectura como una de objetos distribuidos
55. 55
Objetos Distribuidos (2)
• Se compone de objetos que proveen servicios a
otros objetos y usan servicios de otros objetos
No hay distinción entre clientes y servidores
Pueden ser distribuidos entre distintas computadoras
en una red y se comunican a través de middleware
• Este tipo de middleware se conoce como Object Request
Broker (ORB), por ejemplo, CORBA.
Es más complejo de diseñar que cliente-servidor
Software bus
o1 o2 o3 o4
o5 o6
S(o1) S(o2) S(o3) S(o4)
S(o5) S(o6)
56. 56
Peer-to-Peer
• Sistemas descentralizados donde las
computaciones pueden ser realizadas en
cualquier nodo de la red
En principio no hay distinción entre clientes y
servidores
El sistema se diseña para usar el poder de
almacenamiento y procesamiento de múltiples
computadoras en una red
Los protocolos que permiten la comunicación entre
nodos están embebidos en la propia aplicación
• Cada nodo debe correr una copia de la aplicación
57. 57
Peer-to-Peer (2)
• Ejemplos
Sistemas para compartir archivos
Mensajería instantánea
Seti@home
• Y otros @home
Se está comenzando a usar también en el área de
negocios
• Intel y Boeing han implementado sistemas intensivos en las
computaciones con arquitecturas p2p
• Se pueden clasificar en sistemas
descentralizados o semi-centralizados
58. 58
Peer-to-Peer (3)
• Algunos problemas
Overhead
Seguridad
Confianza
• Entonces, son más usados en sistemas que no
son críticos respecto a la información
59. 59
Service Oriented Architecture (SOA)
• Organizaciones que quieren hacer su
información accesible a otros programas
pueden hacerlo definiendo y publicando una
interface de servicio web
• Un servicio web es una representación
estándar para algún recurso computacional o de
información que puede ser usado por otros
sistemas
60. 60
SOA (2)
• El servicio es independiente de las aplicaciones
que lo usan
• Se pueden construir aplicaciones mediante el
uso de distintos servicios
• Hay varios modelos de servicios distintos.
Conceptualmente todos operan de acuerdo al
siguiente modelo
61. 61
Comparación SOA y Objetos Distribuidos
• Propaganda pública de la disponibilidad del servicio
• Potencialmente el enlace con el servicio puede ser en
tiempo de ejecución
• Oportunidad de crear nuevos servicios a través de
composición de otros servicios
• Pago por uso de servicios, por su uso más que por su
provisión
Esto sustituye componentes caras raramente usadas
• Aplicaciones más chicas y compactas
• Aplicaciones que pueden ser reactivas y adaptar su
operación de acuerdo a su medio mediante el cambio de
enlaces a servicios durante la ejecución
62. 62
Web Services Estándares
• Los servicios se basan en estándares basados
en XML
Entonces, pueden funcionar en cualquier plataforma y
ser escritos en cualquier lenguaje
• Estándares más conocidos:
SOAP - Simple Object Access Protocol
WSDL - Web Services Description Language
UDDI - Universal Description, Discovery and
Integration.
63. 63
Ejemplo
• Un sistema de información para un auto provee
al conductor con información acerca del clima,
las condiciones del tráfico, información local,
etc. Esto está vinculado con la radio del auto de
forma que la información es entregada como
una señal en un canal específico de la radio
• El auto está equipado con un recibidor GPS
para conocer su posición y, basado en esa
posición, el sistema accede a un rango de
servicios de información. La información debe
ser entregada en el lenguaje especificado por el
conductor
64. 64
Ejemplo (2)
User inter face
Locator
Discovers car
position
Weather
info
Receives request
from user
Receiver
Receives
information stream
from services
Transmitter
Sends position and
information request
to services
Radio
Translates dig ital
info stream to
radio signal
In-car software system
Mobile Info Service
Facilities
info
Translator
Road
locator
Traffic
info
Collates information
Road traffic info
command
gps coord
gps
coord gps coordgps coord
Language
info
Info
stream
Service discovery
Finds available
services
65. 65
Evaluación de Arquitecturas
• Cambiar la arquitectura de un producto ya construido
requiere mucho esfuerzo
• Entonces, es importante evaluar la arquitectura antes de
implementarla completamente
• Verificar los requisitos de calidad establecidos
• Evaluaciones a posteriori resultan útiles como forma de
aprendizaje y estudio de posibilidades de mejora, por ej.
para una nueva versión del producto
• Software Engineering Institute (SEI) propone:
Architecture Tradeoff Analysis Method (ATAM)
Software Architecture Analysis Method (SAAM)