Arquitectura de Software

Documentos relacionados
Documento de Arquitectura

Arquitectura de Software

Arquitectura y Diseño de Software

Diseño y Evaluación de Arquitecturas de Software. Meta-modelos de diseño

Arquitectura de Software

MÓDULOS DE DISEÑO EN INGENIERÍA

2.5 DISEÑO ARQUITECTONICO

Diseño de la Arquitectura Lógica con Patrones. mayo de 2008

DISEÑO ARQUITECTURA DEL SOFTWARE

octubre de 2007 Arquitectura de Software

Arquitectura de Software

Diseño estructural y propuesta de actividades

Curso Aseguramiento de la Calidad De los Procesos y Productos de Software

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

Proceso Unificado de Desarrollo de Software. 13 de sep de 2006

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

DOCUMENTO DE ARQUITECTURA DE SOFTWARE JAVIER FELIPE VASQUEZ ROLDAN PABLO ROBAYO RODRIGUEZ

Sistemas de Información II. Análisis de Sistemas Orientado a Objetos

El sistema será definido como SACP (Sistema de Administración de Clientes y Proveedores).

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:

Análisis y Diseño Orientado a Objetos. 2 - Análisis

DEPARTAMENTO DE SISTEMAS. Evaluación de Arquitecturas de Software (ATAM)

SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA

Pruebas de Software. Agenda. Pruebas de Programas Los Niveles de Prueba Diseño de Casos de Prueba

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

A continuación se describe con mayor detalle cada una de tales unidades:

Unidad IV: Modelo de Diseño 4.1. Estrategias de diseño

Introducción a los patrones de Software

Figure 12-1: Phase D: Technology Architecture

Líneas de Producto de Software Modelo de Variabilidad Ortogonal

Gestion por Procesos Oficina Central de Desarrollo Organizacional (OCDO)

Diagramas De Casos De Uso

DOCUMENTACIÓN REQUERIMIENTOS

LABORATORIO DE INTERACCION HUMANO COMPUTADORA MANUAL DE PRÁCTICAS. Practica #1. Identificación del proyecto a Desarrollar

Daniel Laco Director Ejecutivo

Alumnos BAJO ACOPLAMIENTO Y ALTA COHESION. Un patrón intenta codificar el conocimiento, expresiones y los principios existentes.

SDD SDD Software Design Description. V0.1

CLASE # 2 PLANEACIÓN DE PRUEBAS

DIAGRAMAS UML ANDRÉS ESTEBAN MARTÍNEZ HUTA CICLO DE VIDA DEL SOFTWARE GLORIA CECILIA RÍOS MUÑOZ

M. C. Felipe Santiago Espinosa

Diagrama de despliegue

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS Y SISTEMAS

SDD-Documento de diseño del sistema

Tema 4g: Proceso Unificado: Implementación

MODELOS PRESCRIPTIVOS

Lenguaje Unificado de Modelado

ESQUEMA DEL TRABAJO DE INVESTIGACIÓN (TI)

TEMA 1. Introducción a las arquitecturas distribuidas

ANÁLISIS DE SISTEMAS. Prof. Eliz Mora

Lenguaje de Modelamiento Unificado.

Ingeniería de Software. UML.

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

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

Métodos para el diseño de soluciones

Ingeniería de Aplicaciones Web

Arquitectura de Empresa. Herramienta de gobierno para el alineamiento de las TI con la estrategia de negocio

Planificaciones Análisis de la Información. Docente responsable: GONZALEZ NORBERTO DANIEL. 1 de 6

MÓDULO 1.4 ARQUITECTURA DE SOFTWARE CON UML

Programación de Aplicaciones Distribuidas

DISEÑO CURRICULAR BASE DE DATOS I

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES MANUAL TÉCNICO

Análisis y modelado de sistemas de software. Diseño Interfaces de usuario. Blanca A. Vargas Govea

Diagramas UML JUAN CARLOS CONDE RAMÍREZ INTRODUCTION TO PROGRAMMING

TEMA 4. PROCESO UNIFICADO

Sistema de Información y Control para el Sindicato de Grúas, Montacargas y Equipo Pesado LA PAZ, Montacargas y Equipo Pesado La Paz

APLICACIONES MOVILES NATIVAS. Sesión 3: Introducción al paradigma de programación orientada a objetos

Transcripción:

Arquitectura de Software Puntos de Vista Departamento de Ingeniería de Sistemas y Computación

Agenda del día 1. El proceso de definición de arquitectura 2. Viewpoints / Views 3. Ejercicio 2

1. El proceso de Definición de la Arquitectura Normalmente comienza Con un conocimiento inicial del problema y su alcance Sin conocer el tamaño total del producto Sin conocer todos los riesgos Sin entender los conflictos internos entre los Stakeholders 3

4 1. El proceso de Definición de la Arquitectura Principios Basado en las necesidades de los Stakeholders Comunicación de las decisiones Debe ser un proceso estructurado Debe ser pragmatico (tiempo, dinero, etc.) Debe ser flexible Debe ser independiente de tecnología Debe ser integrado al proceso de desarrollo Estar alineado con las políticas de calidad

5 1. El proceso de Definición de la Arquitectura Productos Esperados Principal Documento de Arquitectura Secundarios Claridad en los requerimientos Expectativas de los Stakeholders Indentificación y evaluación de posibles arquitecturas Criterios de aceptación de la arquitectura Un conjunto de artefactos para iniciar el diseño detallado

1. El proceso de Definición de la Arquitectura Entradas Salidas Definir contexto y alcance inicial Involucrar Stakeholders Arquitectura del Sistema (AD) Concerns Identificar Concerns Relevantes Contexto y alcance Definir Arquitectura Lineamientos y Restricciones 6 Tomado de [1] pag 78

1. El proceso de Definición de la Arquitectura Definición de la arquitectura del sistema 1. Consolidar Entradas 4. Producir Arquitectura Candidata 2. Identificar Escenarios 3. Identificar Estilos de Arquitectura 5. Explorar Opciones Arquitecturales 6. Evaluar la Arquitectura con los Stakeholders 7a. Modificar la Arquitectura 7b. Revisar Requerim. KEY: FlowChart Aceptada No aceptada 7 Tomado de [1] pag 81

1. El proceso de Definición de la Arquitectura Producir Arquitectura Candidata Objetivos Producir una primera versión de la arquitectura Entradas Concerns Architectural Styles Viewpoints Perspectives Salidas Architectural Views (Draft) 8

Agenda 1. El proceso de definición de arquitectura 2. Viewpoints / Views 3. Ejercicio 9

2. Viewpoints / Views Algunas preguntas relevantes durante la definición de la arquitectura 10 Cuáles son los principales elementos funcionales? Cómo interactuan entre ellos? Qué información almacenar y presentar? Qué hardware y software se va a necesitar? Cómo serán los ambientes de desarrollo, pruebas y producción?

2. Viewpoints / Views Opciones para responder estas y otras preguntas Hacer un único modelo Utilizar las vistas arquitecturales 11

2. Viewpoints / Views Estrategia Describir un sistema complejo, utilizando un conjunto de vistas interrelacionadas para ilustrar sus carácterísticas funcionales y propiedades de calidad.[1] 12

2. Viewpoints / Views A view is a representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by one or more stakeholders [1] 13

2. Viewpoints / Views Qué información incluir en una vista? A cuál stakeholder esta orientada? Qué tanto entiende de tecnología el stakeholder? Cuáles concerns se pretenden resolver en dicha vista? 14

2. Viewpoints / Views A viewpoint is a collection of patterns, templates, and conventions for construncting one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views [1] 15

2. Viewpoints / Views Beneficios al utilizar vistas Separación de Concerns Comunicacción con los Stakeholders Reducción de complejidad Facilidad en el diseño y desarrollo del sistema 16

2. Viewpoints / Views Problemas al utilizar vistas Inconsistencia entre las vistas Error en la selección de las vistas Fragmentación de la información 17

2. Viewpoints / Views El catálogo de Puntos de vista [1] Functional Viewpoint Information Viewpoint Concurrency Viewpoint Development Viewpoint Deployment Viewpoint Operational Viewpoint 18

2. Viewpoints / Views Viewpoint Functional Information Propósito Describir los elementos funcionales del sistema, sus responsabilidades, interfaces e interacciones. Describe la manera como la arquitectura guarda, manipula, maneja y distribuye información. 19 Concurrency Development Deployment Operational Describe la estructura de concurrencia del sistema y relaciona elementos funcionales con unidades de concurencia y como serán coordinadas y controladas. Describe la arquitectura que soporta el proceso de desarrollo del sistema. Describe el ambiente dentro del cual el sistema será instalado, incluyendo las dependencias con el ambiente de ejecución, incluyendo una correspondencia de los elementos de software con el ambiente de su ejecución. Describe como el sistema será operado, administrado y soportado cuando este ejecutandose en su ambiente de producción.

Agenda 1. El proceso de definición de arquitectura 2. Viewpoints / Views 3. Ejercicio 20

Caso de Estudio WWW Para cada una de las vistas identifique: Que concerns abordan? Si las pudiera clasificar en alguna de los 6 tipos propuestos, cuál sería, y porqué? A cuál (es) stakeholders les puede interesar cada vista? Qué tipo de elementos arquitecturales presenta?

Caso de Estudio WWW Para cada una de las vistas identifique: Cuáles son sus responsabilidades? Qué conjunto de interfaces deben ofrecer? Qué relaciones existen entre los elementos? Corresponden a estructuras estáticas o dinámicas?

Caso de Estudio WWW El primer párrafo de la pagina 339 describe el proceso de manejo de una solicitud de un CGI por parte del servidor. Qué relación puede encontrar entre la descripción del proceso y los elementos los elementos de la figura 13.5?

Caso de Estudio WWW Construya una diagrama de secuencia del flujo de datos y de control entre los varios componentes del servidor HTTP para cumplir la solicitud (vista dinámica) Comience el diagrama con un evento del HTTP Client llamado request

Diagrama de Secuencia Request Stream Manager Request HTTP Server Path Resolver Access Control Request Analysis OutputStream OutputStream Resolve path and type Consult Access List User Valid Write Request OutputStream

Caso WWW Relacione los componentes de la figura 13.5 con las capas de las que dependen para ejecutar sus servicios. Piense en el tipo de servicios que debe usar cada componente de la figura 13.5 y que capa debería ser la encargada de ofrecerlos.

Vista por capas de libwww Application Modules Access Modules Stream Modules Core Generic Utilities

Vista Despliegue HTTP Client HTTP Server Access Control Cache Manager Stream Manager Presentation Manager UI Manager Protocol Manager Logging Stream Manager Path Resolver Access Control Request Analysis

Relaciones

Material preparado por Darío Correal Nicolás López 30

Bibliografía [1] Rozanski N, Woods E. Software Systems Architecture Addison- Wesley. 2005 31