Arquitectura de Software - LDC Noticiasmgoncalves/IS2/sd07/clase7.pdf · 9Iterar a través de las...

35
octubre de 2007 Arquitectura de Software

Transcript of Arquitectura de Software - LDC Noticiasmgoncalves/IS2/sd07/clase7.pdf · 9Iterar a través de las...

octubre de 2007

Arquitectura de Software

Seis mejores Prácticas

• Desarrollo Iterativo• Administrar Requerimientos•• Usar Arquitecturas basadas en Usar Arquitecturas basadas en

ComponentesComponentes• Modelado Visual (UML)• Verificar Continuamente la Calidad• Administrar el Cambio

Centrado en la Arquitectura

¿Qué es la Arquitectura de un Sistema?

La descripción del Sistema a través de vistas

utilizando diagramas y modelos

Proyección de la organización y estructura de un sistema enfocándose en aspectos particulares

¿Con qué notación?

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.

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

Arquitectura : Vistas (RUP)

Krutchen 2000• Vista de los Casos de Uso • Vista Lógica • Vista de Procesos • Vista de Implementación • Vista de Entrega.

Vista de Procesos Vista de Despliegue

Vista Lógica

Vista de Casos de Uso

Vista de Implementación

Usuario Final Funcionalidad

ProgramadoresAdministradores

de Software

RendimientoEscalabilidadThroughput

Integradores del SistemaTopología del SistemaEntrega, Instalación

Ingeniería del Sistema

Analistas/DiseñadoresEstructura

Arquitectura de Software: Modelo de las “4+1 Vistas”

Para modelar un sistema desde diferentes vistas se debe responder:

¿Qué vistas se requiere?

Para cada vista:

¿Qué artefactos producir?

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.

Arquitectura: Vistas

Review: Analysis and Design is Use-Case Driven• Los Casos de Uso definidos para un

sistema son la base para el procesoentero 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.

ClienteVerificar Balance

Depositar

Diagramas de Clase

Diagramas de Secuencia

Caso de Uso

Diagramas de Colaboración

Concepto: Realización de Casos de UsoModelo de Casos de Uso Modelo de Diseño

Caso de Uso Realización de Caso de Uso

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 ObjetosDiagramas ER

Se complementa con vistas del Área DinámicaDiagramas de Actividad, Diagramas de Interacción,Diagramas de Estado.

Arquitectura: Vista LógicaDiagrama de Clases

Arquitectura: Vista Lógica

• 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.

Arquitectura: Vistas

Arquitectura: Vista de Procesos

• 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ámicaDiagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.

Arquitectura: Vistas

• Diagrama de componentes

Arquitectura: Vistas de Implementación

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.

Arquitectura: Vista de Despliegue

• Diagrama de Despliegue

Arquitectura de Software– Es la organización o estructura de los

componentescomponentes significativos dentro delsistema, lo cuales interactinteractúúanan, a través de interfaces. Los componentes pueden serusados para formar componentes másgrandes

• ¿Cuáles son las partes principales? • ¿Cómo colaboran?• ¿Se tiene un marco en el cual el resto de los

componentes puede ser agregado?.

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 1471-2000

Arquitectura de Software

¿Cómo diseñarla?A partir de los escenariosescenarios significativos del proyecto

Una secuenciaespecífica de acciones que

ilustra loscomportamientos

Considerando la plataforma sobre la cual se construiráel sistema:

sistema operativo, manejador de bases de datos, sistemas existentes,etc

Utilizando la experienciaarquitecturas previaspatronespatrones de de disediseññoo.

Una solución a un problemacomún en un contexto dado

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

Arquitectura de Software

Nivel general (arquitectura por niveles)El sistema es descrito en términos de varios nivelesniveles, donde los subsistemas pertenecientes a un niveldado, sólo pueden referenciar a los componentes delnivel inmediatamente inferior

Los subsistemas de los niveles superiores son construidos a partir de los subsistemas de los nivelesinferiores.

conjunto de subsistemas

que compartenel mismo gradode generalidad

Evolución de Arquitecturas• Aplicaciones

Monolíticas

• 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.

Arquitectura Cliente-Servidor

• 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

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.

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.

• 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)

Arquitectura Vs. Diseño• La arquitectura y el diseño difieren en tres áreas:

Requerimientos funcionales

Selección de tecnologías, Requerimientos no funcionales (QoS), Manejo de riesgos

Áreas de Enfoque

Diseño detallado componentes.

Especificaciones de codificación

Planear subsistemas, interfaces con sistemas externos, servicios horizontales, frameworks, componentes reutilizables, prototipo arquitectónico

Entregables

Bajo nivel. Enfoque específico en detalles

Alto nivelNivel de Abstracción

DiseñoArquitectura

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.

Las decisiones de arquitectura causan un alto impacto en los proyectos de IT

Arquitectura

Diseño

Implementación

Código

Definición de Arquitectura en RUP

Fase de Inicio• Con respecto a la

arquitectura, en la fase de inicio de los proyectos se establece:

– Requerimientos no-funcionales

– Lista de riesgos y restricciones

– Arquitectura inicial

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.

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.

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.