Cómo definir una buena arquitectura?arti...Aspectos para tener en cuenta al elaborar una arquitectura de software • Comprensibidad. –La arquitectura de software simplifica nuestra

Cómo definir una buena arquitectura?

Agenda

• Aspectos para tener en cuenta al elaborar una arquitectura de software

• Ejemplos

• Una propuesta metodológica

• Algunos patrones arquitectónicos

Aspectos para tener en cuenta al elaborar una arquitectura de software

• Comprensibidad. – La arquitectura de software simplifica nuestra capacidad para

comprender grandes sistemas de sofware,

• Reuso. – Descripciones arquitectónicas contribuyen al reuso en múltiples

niveles. • Actualmente se utilizan en librerías de componentes

• Construcción. – Una descripción arquitectónica ofrece un blueprint para

desarrollo indicando los principales componentes y dependencias entre ellos

• Evolución. – Las arquitecturas de software pueden exponerlas dimensiones

sobre las cuales se espera se desarrolle.

GARLAN, David. Software Architecture: a roadmap. Carnegie Mello University

• Análisis. – Las descripciones arquitectònicas ofrecen nuevas

oportunidades para el análisis incluyendo la validación de consistencia, cumplimiento de limitaciones impuestas por el estilo arquitectónico

• Administración. – La experencia ha mostrado que los proyectos exitosos

ven en el mejoramiento de una arquitectura de software la clave para el desarrollo de software a nivel industrial.

GARLAN, David. Software Architecture: a roadmap. Carnegie Mello University

Aspectos para tener en cuenta al elaborar una arquitectura de software

1. Desarrollar un modelo mental de la aplicaciòn a un nivel alto. – Como si fuera una aplicaciòn pequeña...

… “ejemplo aplicaciòn de finanzas personales funciona al recibir o pagar dinero, en cualquier orden, controlado mediante una interfaz de usuario”.

2. Desglosar en las componentes requeridas.

– Buscar una cohesiòn alta y un acoplamiento bajo.

– Ejemplo: aplicaciòn de finanzas personales se desglosaen activos, proveedorese interfaz

3. Repetir este proceso para los componentes.

METODOLOGÍA PARA INICIAR LA SELECCIÒN DE LA ARQUITECTURA BÁSICA

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Descomponer en módulos auto contenidos.

2. Comparar con una arquitectura estándar (ej., Clasificación de Garlan y Shaw’s). Mejorar la descomposición. – Los datos fluyen en batch entre estaciones que los procesan?

• Flujo de datos batch secuencial

– Estaciones de procesamiento esperan los datos y entonces ejecutan?

• Flujo de datos pipe-and-filter

– Los procesos se ejecutan en paralelo?

• Procesadores que se comunican en paralelo

– Un proceso provee las necesidades de procesamiento de los usuarios?

• cliente-servidor

Seleccionar una Arquitectura (1)


2. Comparar con una arquitectura estándar (ej., Clasificación de

Garlan y Shaw’s). Mejorar la descomposición (2).

– Un proceso únicamente reacciona a eventos que ocurren sobre él?

• Sistemas de eventos

– Cada ejecución es la interpretación de un script?

• interpretadores

– Es una aplicación centrada en un almacén de datos?

• repositorio

– Se agrupa en capas?

• En capas

Intente mínimo dos alternativas de arquitectura.



3. Evalué y seleccione una entre las alternativas identificadas.

4. Adicione las clases necesarias tomando como referencia el

análisis de requerimientos, que se ajusten a la arquitectura

seleccionada

– ej., flujo de datos: … controlar el flujo entre los elementos

– ej., sistemas de eventos: …controlar transiciones entre estados

5. Aplicar un framework existente y/o patrones de diseño.

– if a helpful one can be identified



6. Particionar las colecciones de clases en paquetes

– idealmente, 4-8 (paquetes anidados para aplicaciones muy grandes)

– Cada nombre de paquete debe tener significado en el lenguaje de la

aplicación (ej., “videos” está bien “grandes clases” no está bien)

7. Verificar alta cohesión en las partes; bajo acoplamiento entre las

partes, en otro caso ajustar la selección.

8. Considerar la introducción de un objeto/control Fachada para

controlar la interfaz de cada paquete



Metas de diseño

• Extensión – Facilitar la adición de nuevas características

• Cambio – Facilitar los cambios de requerimientos

• Sencillez – Hacerlo de fácil comprensión

– Hacerlo de fácil implementación

• Eficiencia – Lograr alta velocidad: ejecución y/o compilación

– Lograr un tamaño pequeño: tiempo en ejecutar y/o tamaño de código

Ejemplos

Una configuración física para un juego basado en Internet

Jugador m

Servidor de factiraciòn

de GameCorp

Jugador n

Clave:.

GUI

De encuentro

GUI

De encuentro

. . . .

Plataforma

De Hardware

Subsistema de

Software

Internet

Servidor

de encuentro

Maquina de

encuentro

Informador

de encuentro

Base de datos

de cuentas

Procesamiento


Diagrama de un sistema de frenos de seguridad

Procesador de

control del auto

Clave :

Controlasor ABS

Hardware Subsistema de

Software

Sensor de

velocidad

Alerta de unbral

de velocidad

Unidad moduladora

de presiòn hidràulica

Luz de

advertencia

Controlador

de presiòn


Cohesión y acoplamiento

1

2 3 4

5 6 Alta cohesiòn Bajo acoplamiento Puente

componente

componente


Cohesión y acoplamiento 1

2 3 4

5 6 Alta cohesiòn

Bajo acoplamiento

Alto acoplamiento

Puente

componente

componente

componente

Soporte De acero


UNA PROPUESTA METODOLÓGICA

Arquitecturas de Software

Preparación

• Análisis

– Casos de Uso

– Mundo del Problema

– Requerimientos No funcionales

• Arquitectura de software

Aproximación funcional

• Los requerimientos funcionales son la guía para construir el modelo – Qué elementos aparecen referenciados en los RF y como deben

interactuar entre ellos?

• Se corre riesgo de definir arquitectura guiada por el problema

• Se construye diagramas de clase y diagrama de secuencia a la vez

AL FINAL DEL ANALISIS (1)

Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes

AL FINAL DEL ANALISIS


AL FINAL DEL ANALISIS


Definir arquitectura

• Conjunto de cajas grises • Debe tener en cuenta RNF, MN y RF • Debe ser completa • Se definen sobre este borrador los principales

“protocolos”


Refinar Arquitectura

• Ciclo de medición y refinación

• Aunque sea abstracta se debe poder explicar


Elementos de la Arquitectura


Se llega al diseño detallado


Qué es la arquitectura?

• Define las estructuras de alto nivel del sistema, en términos de:

– Componentes de software

– Las propiedades visibles de estos componentes (comportamiento y características)

– Relaciones entre ellos (conectores, protocolos, restricciones,...)


Corrientes principales

• Arquitectura estructural – SEI – Carnegie Mellon – Garlan, Shaw, Clements

– Variantes con modelos de datos (Medvidovic), radicales, formales (Moriconi-SRI), etc

• Arquitectura como etapa de la ingeniería de software orientada a objetos – James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3…”), Craig Larman…

• Arquitectura basada en patrones – SEI – Redefinición de estilos como patrones POSA

– Microsoft Patterns & Practices

• Arquitectura procesual y metodologías – Kazman, Bass (SEI)

– Variantes de arquitectura basada en escenarios

Algunos patrones arquitectónicos

Estilos de arquitectura de software (Shaw & Garlan)

• Arquitecturas de flujo de datos

• Batch sequential

• Pipes and Filters

• Componentes independientes

• Procesos de comunicación paralela

• Sistemas Cliente-servidor

• Sistemas basados en eventos

• Maquinas virtuales

• Interpretadores

• Sistemas basados en reglas

• Arquitecturas de repositório

• Bases de datos

• Sistemas hipertexto

• Blackboards

• Arquitecturas de capas

Data Flow: Pipes and Filters

Couple Acquire To-XY Clip

Measure

Signal

Waveform Trace

Measurement

Dataflow pipe

filter Computation

Pipes and Filters

• Filtros – Transformar incrementalmente una cierta cantidad de datos de

entrada a la salida. • Transformaciones stream-a-stream

– Utilizar poco contexto local en el proceso corriente – No preservar ningún estado entre instanciaciones

• Pipe – Mover datos de la salida del filtro a la entrada del siguiente filtro – Pipes forman grafos de transmisión de datos

• Computación total – Correr pipes y filtros (no deterministicamente) hasta que no son

posibles más computaciones.

Repositorio orientado a los Datos (Blackboard)

Blackboard (shared

data)

ks1 ks2

ks3

ks4

ks5ks6

ks7

ks8

Acceso directo Computación

Memoria

El modelo Blackboard

• Fuentes de conocimiento

– El mundo y el conocimiento del dominio repartido en computaciones independientes

– Responder a los cambios en el blackboard

• Estructura de datos Blackboard

– Estado entero de la solución del problema

– Jerárquico, no homogéneo

– Solamente medios por los cuales las fuentes del conocimiento obran recíprocamente para conseguir la solución

• Control

– En el modelo, las fuentes de conocimiento son automáticas

Llamado-y-Retorno: Orientado a objetos

Llamado Proc

Gestor

obj es un manejador

op es una invocación

obj

obj

obj

obj

obj

obj

obj obj

op

op

op op

op

op op

op op

op

op

op

op op

op

op

Sistemas Llamada retorno

• Objetos

– Encapsular representaciones

– Proveer interfaces de acceso a servicios

• Conectores

– Llamado-retorno; servicio de invocación

• Razonamiento

– La corrección de un componente depende de la corrección de servicios que invoca .

Componentes débilmente acoplados: Invocación implícita

! !

! ! !

!

!

?

?

? ? ?

? ?

Invocación Implicita

Objeto o Proceso

Invocación-Implícita (Publicar-Suscribir)

• Componentes – Objetos, procesos – Tener un conjunto de métodos – Anunciar (publicar) eventos – via multicast – Suscribir a eventos por asociación de un procedimiento a un llamado

• Conector – Espacio del evento – Típicamente implementado como un despachador

• modelo Computacional – Cuando un evento es anunciado invoca procedimientos asociados (en

cualquier orden) – La corrección de un componente no debe depender de la corrección de los

componentes que suscriben a sus acontecimientos anunciados .

Cliente Servidor 3-Capas

Client-Server

Client-Server

Persistencia

Lógica de

negocio

Interfaz

Usuarios

Otros

• A menudo los estílos se usan en combinación

– Ejempo: Cada capa puede tener un estilo diferente internamente

– Ejemplo: un componente puede tener un subestuctura definida en un diferente estilo al que la rodea

• Muchos estilos se atan de cerca a los dominios específicos -- a menudo especializando un estilo más genérico

– Algunas veces llamados frameworks de integración de componentes

– Sistemas de N-capas

– Pila protocolo OSI

– Sistemas de instrumentación

• En muchos casos éstos se especializan a una familia de producto particular,

– Algunas veces llamados arquitectura de línea de producto

Estilo: CALL RETURN Subestilo: Sistema de capas

• Protocolos • Sistemas operativos • Front-end • Fachadas • proxies

Estilo: CALL RETURN Subestilo: Sistema de Objetos

• Componentes • Conectores • Distribuido o local

• Diseño por objetos • RMI • CORBA

SOAP • Object Oriented Middleware

Documents

Cómo definir una buena arquitectura?arti...Aspectos para tener en cuenta al elaborar una arquitectura de software • Comprensibidad. –La arquitectura de software simplifica nuestra