octubre de 2007 Arquitectura de Software

Tamaño: px

Comenzar la demostración a partir de la página:

Download "octubre de 2007 Arquitectura de Software"

Ernesto Salazar Suárez
hace 6 años
Vistas:

1 octubre de 2007 Arquitectura de Software

2 Seis mejores Prácticas Desarrollo Iterativo Administrar Requerimientos Usar Arquitecturas basadas en Componentes Modelado Visual (UML) Verificar Continuamente la Calidad Administrar el Cambio

3 Centrado en Proyección la Arquitectura de la organización y estructura de un sistema enfocándose en aspectos particulares Qué es la Arquitectura de un Sistema? La descripción del Sistema a través de vistas utilizando diagramas y modelos Con qué notación?

4 Centrado en la Arquitectura Por qué es importante? Permite una comunicación efectiva entre las personas involucradas (diseñador, desarrollador). Promueve el reuso del software. Permite la prueba individual e integración gradual de los componentes. Permite crear sistemas flexibles y tolerantes a cambios.

5 Arquitectura : Vistas Proceso Unificado 1999 Vista de Modelo de Casos de Uso Vista de Modelo de Análisis Vista de Modelo de Diseño Vista de Modelo de Despliegue Vista de Modelo de Implementación

6 Arquitectura : Vistas (RUP) Krutchen 2000 Vista de los Casos de Uso Vista Lógica Vista de Procesos Vista de Implementación Vista de Entrega.

7 Arquitectura de Software: Modelo de las 4+1 Vistas Vista Lógica Vista de Implementación Analistas/Diseñadores Estructura Usuario Final Funcionalidad Vista de Casos de Uso Programadores Administradores de Software Integradores del Sistema Rendimiento Escalabilidad Throughput Vista de Procesos Vista de Despliegue Ingeniería del Sistema Topología del Sistema Entrega, Instalación

8 Arquitectura: Vistas Para modelar un sistema desde diferentes vistas se debe responder: Qué vistas se requiere? Para cada vista: Qué artefactos producir?

9 Arquitectura: Vistas Vista de los Casos de Uso: Esta vista contiene los escenarios o casos de uso claves, para cada uno de los cuales se describen las secuencias de interacción entre objetos y procesos. Diagramas de Casos de Uso Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.

10 Review: Analysis and Design is Use-Case Driven Los Casos de Uso definidos para un sistema son la base para el proceso entero de desarrollo. Beneficio de los Casos de Uso: Concisos, simples y comprensibles para la gran variedad de involucrados. Ayudan a sincronizar el contenido de los diferentes modelos. Cliente Verificar Balance Depositar

11 Concepto: Realización de Casos de Uso Modelo de Casos de Uso Modelo de Diseño Caso de Uso Realización de Caso de Uso Diagramas de Secuencia Diagramas de Colaboración Caso de Uso Diagramas de Clase

12 Arquitectura: Vistas Vista Lógica o de Diseño: Es una abstracción del modelo de diseño e identificación a gran escala del diseño de paquetes, subsistemas y clases Diagramas de Clases y Objetos Diagramas ER Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.

13 Arquitectura: Vista Lógica Diagrama de Clases

14 Arquitectura: Vista Lógica

15 Arquitectura: Vistas Vista de Procesos: Toma en cuenta algunos requerimientos no-funcionales: Rendimiento, disponibilidad, integridad del sistema, tolerancia a fallas. Captura aspectos de Sincronización y Concurrencia del diseño. Control de los procesos concurrentes.

16 Arquitectura: Vista de Procesos

17 Arquitectura: Vistas Vista de Implementación o Desarrollo: La vista de Implementación se enfoca en la organización de los módulos del software actual en el ambiente de desarrollo de software. Diagramas de Componentes Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.

18 Arquitectura: Vistas de Implementación Diagrama de componentes

19 Arquitectura: Vistas Vista Física o de Despliegue: Describe mapping del SW al HW y refleja su aspecto distribuido. Diagramas de Despliegue Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.

20 Arquitectura: Vista de Despliegue Diagrama de Despliegue

21 Arquitectura de Software Es la organización o estructura de los componentes significativos dentro del sistema, lo cuales interactúan an, a través de interfaces. Los componentes pueden ser usados para formar componentes más grandes Cuáles son las partes principales? Cómo colaboran? Se tiene un marco en el cual el resto de los componentes puede ser agregado?.

22 Arquitectura de Software La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución. IEEE Std

23 Arquitectura de Software Cómo diseñarla? A partir de los escenarios significativos del proyecto Considerando la plataforma sobre la cual se construirá el sistema: sistema operativo, Una secuencia manejador de bases de datos, específica de sistemas existentes, acciones que etc Una solución ilustra a los Utilizando la experiencia arquitecturas previas patrones de diseño. un comportamientos problema común en un contexto dado

24 Arquitectura de Software Cómo especificarla? En dos etapas: Nivel General: se especifican los aspectos generales del sistema a construir (middleware, sistemas existentes, etc.) Nivel Específico: a través de diferentes vistas de los modelos: casos de uso clases y componentes subsistemas colaboraciones interfaces nodos

25 Arquitectura de Software Nivel general (arquitectura por niveles) conjunto de subsistemas que comparten el mismo grado de generalidad El sistema es descrito en términos de varios niveles, donde los subsistemas pertenecientes a un nivel dado, sólo pueden referenciar a los componentes del nivel inmediatamente inferior Los subsistemas de los niveles superiores son construidos a partir de los subsistemas de los niveles inferiores.

26 Evolución de Arquitecturas Aplicaciones Monolíticas Arquitectura Cliente- Servidor Interfaces gráficas de usuario (GUI). Servicios de presentación, negocios y persistencia en la misma máquina. No hay concurrencia de usuarios. Alto acoplamiento entre tiers. Clientes pesados, no estándar Conexiones dedicadas a BD Protocolos pesados Ejecución remota de SQLs Alta administración Bajo rendimiento Alto tráfico de red Baja accesibilidad

27 Evolución de Arquitecturas Arquitectura C/S Mejorada Lógica de negocios en BD Clientes pesados, no estándar. Conexiones dedicadas a la BD. Mejora en rendimiento Alta administración Baja escalabilidad Baja flexibilidad Baja portabilidad Arquitectura de 3 niveles Reutilización de lógica de negocio para diferentes clientes o sistemas. Mejora la escalabilidad. Mejora la flexibilidad. Independencia de la base de datos.

28 Arquitecto de Software Arquitecto es un rol en un proyecto de desarrollo de software el cual es responsable de: Liderar el proceso de arquitectura. Producir los artefactos necesarios: Documento de descripción de arquitectura Modelos y prototipos de arquitectura.

29 La Arquitectura de Software abarca las decisiones más significativas acerca de la organización de un sistema de software La selección de los elementos estructurales que componen un sistema y sus interfaces El comportamiento expresado en términos de colaboración entre estos elementos La composición de estos elementos en subsistemas El estilo arquitectónico que guía su organización, sus elementos e interfaces y su composición Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational Software (derived from Mary Shaw)

30 Arquitectura Vs. Diseño La arquitectura y el diseño difieren en tres áreas: Nivel de Abstracción Entregables Áreas de Enfoque Alto nivel Arquitectura Planear subsistemas, interfaces con sistemas externos, servicios horizontales, frameworks, componentes reutilizables, prototipo arquitectónico Selección de tecnologías, Requerimientos no funcionales (QoS), Manejo de riesgos Diseño Bajo nivel. Enfoque específico en detalles Diseño detallado componentes. Especificaciones de codificación Requerimientos funcionales

31 Arquitectura Vs. Diseño La arquitectura envuelve un conjunto de decisiones estratégicas de diseño, lineamientos, reglas y patrones que restringen el diseño y la implementación de un software. Código Implementación Diseño Las decisiones de arquitectura causan un alto impacto en los proyectos de IT Arquitectura

32 Definición de Arquitectura en Fase de Inicio RUP Con respecto a la arquitectura, en la fase de inicio de los proyectos se establece: Requerimientos nofuncionales Lista de riesgos y restricciones Arquitectura inicial

33 Definición de Arquitectura en RUP Fase de Elaboración Con respecto a la arquitectura, en la fase de elaboración se establece: Arquitectura línea base. Entregables: Documento de Definición de Arquitectura. Prototipo evolutivo de arquitectura. Guías y Estándares de Diseño.

34 RUP en 10 Pasos Rushton Prince. Implementing RUP in 10 steps. (2005): Definir un Caso de Desarrollo para el proyecto. Identificar los casos de uso o funcionalidades para el proyecto. Clasificar los casos de uso según los niveles de riesgo. Clasificar los artefactos por disciplinas. Iterar a través de las disciplinas de RUP para crear los artefactos necesarios para recopilar la información necesaria para el desarrollo del proyecto.

35 RUP en 10 Pasos Rushton Prince. Implementing RUP in 10 steps. (2005): Iterar a través de las disciplinas de RUP para detallar cada uno de estos artefactos. Cumplir el objetivo de la Fase de Inicio: Alcance del proyecto. Cumplir el objetivo de la Fase de Elaboración: Línea Base de la Arquitectura. Cumplir el objetivo de la Fase de Construcción: Primer release del Producto. Cumplir el objetivo de la Fase de Transición: Integrar el producto a la realidad del negocio.

Documentos relacionados

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

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque: Análisis y Diseño O.O. Preguntas del diseño : Cómo podrían asignarse responsabilidades a las clases de los objetos? Cómo podrían interactuar los objetos? Qué deberían hacer las clases? Patrones : Ciertas