Arquitecturas Basadas en Componentes - Universidad Icesi · EN COMPONENTES Ingeniería de Software...

ARQUITECTURAS BASADAS

EN COMPONENTES

Ingeniería de Software II

Evolución de las Arquitecturas

Desde una perspectiva tecnológica (física)

Desde una perspectiva de software

Evolución de las Arquitecturas

Desde una perspectiva tecnológica (física)

Desde una perspectiva de software

Era Batch

Recolección manual de

datos de procesos de

negocio

Oficina de procesamiento

de datos Propósito: aumentar la productividad

explotando el poder de cálculo de los

computadores para reducir el tiempo de

procesamiento.

Era Batch

Aplicaciones automatizaban procesos individuales

de la compañía:

Contabilidad, inventarios, nomina, compras, etc.

Duplicación de información, inconsistencias

A medida que la compañía crecía:

Aplicaciones complejas, interdependientes, difíciles de

extender y mantener

Era Terminal

Innovaciones de principios de los 70’s:

Sistemas transaccionales

Bases de datos

Terminales

Hardware para redes

Era Terminal

Integración a través de las bases de datos fue

rudimentaria

El modelaje de los datos de la organización no se

logró:

Aplicaciones en diferentes partes de la organización

tienen distintas arquitecturas y visiones de los datos

Dolores de cabeza con el mantenimiento de las

aplicaciones viejas y la integración con las nuevas

Incremento en las expectativas de los clientes

Los Computadores Personales

Impacto en la visión de los negocios y las

tecnologías de información

Proliferación de aplicaciones de oficina

Cambio en la percepción de los usuarios con respecto a

las interfaces – incremento de expectativas

Computación Distribuida

Era Cliente/Servidor

Crecimiento del outsourcing

Nuevos Requerimientos

Escalabilidad

Disponibilidad

Seguridad

Alto desempeño

Grandes volúmenes de datos y de transacciones

Crecimiento exponencial de aplicaciones

Integración de procesos de negocio

Evolución de las Arquitecturas

Desde una perspectiva tecnológica (física)

Desde una perspectiva de software

Propiedades Deseables

Localización: dado un elemento del problema, se

puede localizar su representación en el programa.

Propiedades Deseables

Aislamiento: un cambio en un elemento del

programa tiene una frontera de impacto conocida.

Propiedades Deseables

Flexibilidad: las decisiones arquitecturales se

pueden tomar tarde en el ciclo de vida.

Propiedades Deseables

Reutilización: los elementos del programa son

fácilmente utilizables en otros programas.

Propiedades Deseables

Evolución: la arquitectura del programa no se

deteriora debido a la evolución del problema.

Propiedades Deseables

Enseñable: es clara la transformación de los

elementos del problema en elementos de la

solución.

Elementos Estructuradores

Funciones

Objetos

Componentes

Contenedores

Servicios

Funciones

Análisis y diseño estructurado

Programa = estructuras de datos + algoritmos

Funciones

Muy difundida y con curva de aprendizaje baja

Ideal para cierto tipo de problemas

No tiene en cuenta todos los elementos del

problema

Arquitectura rígida, que se degrada rápidamente

Objetos

Análisis y diseño por objetos

La estructura del mundo guia la arquitectura del

programa + encapsulamiento

No tiene en cuenta los elementos no funcionales

Pensada para resolver los problemas de hace 20

años

Objetos

Sigue siendo la base de gran parte de los

desarrollos de software de hoy en día

Arquitectura rígida

Componentes

Surgen de la necesidad de hacer más flexible la

arquitectura de los objetos

Objetivo inicial: resolver el problema de la

distribución de objetos

Objetivo actual: independizar la descripción

funcional de un elemento del mundo, de su

implementación

Componentes

Un componente agrupa uno o varios elementos del

mundo, y los aísla, haciendo explicita una interfaz

para ofrecer sus servicios

Se gana en flexibilidad

La facilidad de evolución es muy dependiente del

diseño de las interfaces

Componentes

Se sigue ignorando los dominios no funcionales

No hay metodologías claras de apoyo

Contenedores

Primer intento por tener en cuenta los dominios no

funcionales

Aprovecha la flexibilidad introducida por los

componentes, para adicionar el «comportamiento»

no funcional

Servicios

La diferencia con los componentes es sutil, puesto

que se basa en la misma idea de introducir

interfaces para desacoplar

Un excelente medio de integración de aplicaciones

Conclusiones

Todo programa tiene una arquitectura

La selección del elemento estructurador define

muchas propiedades de la arquitectura resultante

No existe una solución ideal. Todo depende del tipo

de problema.