arquitecturas basadas en componentes · integración a través de las bases de datos fue...
TRANSCRIPT
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.