Evolución de las arquitecturas

de software
Grupo de Construcción de Software
Facultad de Ingeniería
Universidad de los Andes

Agenda
¾ Historia sobre la evolución de las tecnologías
y arquitecturas de software
… Necesidades empresariales
… Atributos de Calidad
… Del problema a la arquitectura
… Contenedores

Evolución de la Ingeniera de
Software
Desde una perspectiva Tecnológica:
Computación Distribuida

Terminal/Host/PC

Batch

Pocas Aplicaciones Aplicaciones Aplicaciones

de Negocio de Negocio Integradas de Clientes & Asociados

1950 1970 1990 2010

 Evolución arquitectónica
Modelo host
Modelo Cliente/Servidor dos niveles
1980 - Lógica Presentación
- Lógica aplicación
-Datos
- Lógica Presentación - Datos
- Lógica aplicación Terminal
Host
Cliente
Servidor

1990 1970 2005

Multicapas -> P2P
Modelo Cliente/Servidor modificado
Lógica
- Lógica aplicación WebServer Presentación
- Lógica -Datos
Presentación
Lógica aplicación
Cliente 1998 Terminal AppServer
(componentes)
Servidor
(Browser)
Datos

DBServer

Pregunta
… Qué elementos considera usted han generado
los cambios tecnológicos?

La 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: El punto crítico
… Aplicaciones automatizaban procesos individuales de
la compañía:
† contabilidad, inventarios, nóminas, 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
† Las mejoras en el hardware empeoraron el problema para
las aplicaciones existentes

Era Terminal/Host – Generadores

del cambio
… Innovaciones principios de los 70’s
† Sistemas transaccionales
† Bases de datos
† Terminales
† Acceso a disco más rápido
† Hardware para redes

… Requerimientos
† Integración de datos
† Independencia de datos

Acceso en línea a la información

de la empresa

• Muchas aplicaciones batch fueron reescritas

• Presupuesto para procesamiento de datos creció
enormemente en la mitad de los 70s
• IT ventaja competitiva
• Desarrolladores debieron aprender nuevas habilidades
de programación:
• administradores de BDs
• sistemas operacionales, servidores, redes,
• infraestructura de comunicación
Evolución arquitectónica: mainframe
(1970-1980) (Era Terminal/Host)
- Lógica Presentación
- Lógica aplicación
Generadores del cambio
- Datos
… Desarrollo de HW y de LAN
Terminal
Host

… Toda la aplicación es realizada en el host

… Consecuencias:
† El host es responsable
„ Manejo de datos
„ Control de concurrencia
„ Seguridad

† Tráfico en la red controlado

† Adición o modificación de un requerimiento funcional se refleja en un solo elemento

Era Terminal/Host: El punto crítico

… 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

Era de los Computadores

Personales
Impacto en la visión de los negocios y las
tecnologías de información
… Proliferación de aplicaciones de oficina

escritas por personas externas a IT (dBase,

Lotus 1,2,3 , WordStart, etc. )
… Cambio en la percepción de los usuarios con

respecto a las interfaces – incremento de

expectativas
 Distribución de la función de Tecnologías de Información dentro de las empresas
Nuevos retos para los departamentos de sistemas:
• Comienzos de los 90s: integración de la información, necesidades de
conectividad, mantenimiento, crecimiento y proliferación de las aplicaciones se
volvieron serios problemas

Modelo Cliente/Servidor dos niveles

(1980-1990) (Era de los Computadores Personales)
-Datos
- Lógica Presentación
- Lógica aplicación
Generadores del cambio:
Clientes • Desarrollo de HW, WAN e Internet
Servidor

… Entidades
† Cliente pesado: la mayor parte de la
aplicación del lado del cliente … Seguridad: quién accede los datos?
† Servidor ligero: repositorio de datos
… Manejo de datos … Adición o modificación de un requerimiento
† El servidor es el responsable funcional afecta los clientes
† El cliente conoce el modelo de datos y la
estructura de almacenamiento
… Vulnerabilidad del sistema
… Tráfico en la red importante
† El servidor es un punto de entrada al
… Control de concurrencia sistema
† El cliente es responsable … Ejemplo: CBBD
† Pérdida de información por
actualizaciones

Modelo Cliente/Servidor modificado

(1990-1998)
- Lógica aplicación
- Lógica
Presentación
- Datos Generadores del cambio:
• Desarrollo de tecnología de HW y
Clientes
Servidor
WEB

… Entidades
† Cliente ligero: se concentra en la
presentación … Seguridad: quién accede los datos?
† Servidor pesado:
„ la mayor parte de la aplicación del
lado del servidor … Adición o modificación de un requerimiento
„ repositorio de datos + lógica
funcional no afecta los clientes
(procedimientos almacenados en BD)
… Manejo de datos … Vulnerabilidad del sistema
† El servidor es el responsable y ofrece † El servidor es un punto de entrada al
“métodos” para su manejo sistema
… Tráfico en la red menor vs. c/s dos niveles
… Control de concurrencia … Ejemplo: SMBD
† Servidor es responsable
† Utilización de la funcionalidad SMBD
 Era de la Computación
distribuida
Aumento en las expectativas de los usuarios
comienzo de la computación distribuida
… Era Cliente/Servidor multicapas

… Proliferación de paquetes (frameworks -

COTS)
… Crecimiento del outsourcing

… Integración de aplicaciones

† Corba/ DCOM
… Atributos de calidad

Arquitectura multicapas (1998-2006)

(Era de la Computación distribuida)
Lógica
WebServer Presentación Generadores del cambio:
• Desarrollo de tecnología de redes
Lógica aplicación
(componentes)
(móvil)
Terminal AppServer
(Browser)
Datos

DBServer

… Seguridad: quién accede los datos?

… Entidades
† Servidor Web: lógica de presentación
† Servidor de aplicaciones: lógica de la … Adición o modificación de un requerimiento
aplicación funcional afecta solo a las partes
† Servidor de bases de datos: manejo de involucradas
datos
† Terminal: GUI … Vulnerabilidad del sistema
† Hay varios puntos de entrada
… Tráfico en la red relativo
… Control de concurrencia … Robustez
† Servidor de aplicaciones y de datos son † Distribución de la carga
responsables
† Una aplicación puede ser ejecutada solo
si todos los servidores están disponibles

Arquitectura P2P (2000-)

Lógica
Presentación

Lógica aplicación
(componentes)

Datos

… Entidades … Redefinición de conceptos de

† Peers: Clientes,Servidores ó C/S † Configuración del sistema: Catálogo
centralizado, Super peers, totalmente
† Heterogéneas distribuido
† Autónomas † Consultas sobre datos
† Configuración muy dinámica † Seguridad
† Gran escala † Manejo transaccional - concurrencia

… Manejo de datos
… Adición o modificación de un requerimiento
† Responsabilidad de todos: deseo de funcional puede afectar a todos los peers
compartir “información”
† Localización no predefinida de datos
… Vulnerabilidad del sistema
† Depende de la configuración
… Tráfico en la red relativo
Agenda
9 Historia sobre la evolución de las tecnologías
y arquitecturas de software
¾ Necesidades empresariales
… Atributos de Calidad
… Del problema a la arquitectura
… Contenedores

Pregunta
… Qué elementos considera usted han generado los cambios
tecnológicos?

… Cómo perciben las empresas los cambios tecnológicos?

† Qué decisiones deben tomar antes de realizar una aplicación?
† Cuanto les cuesta (tiempo, dinero) desarrollar una aplicación?
† Donde está la información que necesitan manipular en la
aplicación?
† Cómo afecta la nueva aplicación las soluciones existentes?
† Qué necesitan las empresas?

Percepción de las empresas

… Las decisiones con respecto a la infraestructura y a la solución
adecuada para la empresa son cada vez más difíciles

… El número de especialistas necesarios para proveer una solución

es incremental

… La tecnología evoluciona más rápido que su asimilación en las

empresas

… El mantenimiento de soluciones es cada vez más costoso

… Las soluciones no se adaptan a las verdaderas necesidades del

negocio
Realidad de las empresas
… Información
† Ausencia de información consolida
† Múltiples fuentes de datos

… Tecnología

† Múltiples especificaciones y plataformas para diseñar aplicaciones

corporativas (J2EE, .NET, CCM)

† Múltiples modelos de seguridad ( MULTIPLE SIGN ON)

† Soportar infraestructura legada (¿Si cambiamos la palabra soportar por

explotar? ¿Generar valor alrededor de los datos almacenados en estos
sistemas? )

… Desarrollo de software

† Tiempos de desarrollo cada vez más extensos (ciclos de desarrollo de

18 meses)

† Replicaciones innecesarias de datos (Como mantener coherentes las

réplicas?)

Necesidades de las empresas

… Portales, visión unificada e integrada de clientes y

proveedores

… Soportar las cadenas de valor y procesos

corporativos

… Modelo único de datos ( Piedra angular)

… Empresas de Tiempo Real (Infraestructura 100%

integrada, a nivel interno y externo)

… Flexibilidad y rápida adaptación a cambios del

entorno ( Negocio, Tecnología, etc)

Resultados obtenidos

… Qué tan exitosos son los proyectos de

software ( Desarrollo, Integración,
Infraestructura) ?

Estudios Relacionados
Chaos Report (Standish Group
Tiempo Alcance Report -1995)

Calidad 22%-31% de los proyectos son

cancelados antes de terminarlos

45% -52.7% de los proyectos

Recursos ( $$$, Gente) cuestan cerca del 189% del
presupuesto inicial

Usabilidad
Diagnóstico del problema

… Problemas técnicos
Resolver problemas que no existen
Requerimientos y especificaciones incompletas
Visión del problema centrada en tecnología
Nuevas tecnologías

… Problemas del cliente

Poco acompañamiento y compromiso del cliente
Cambios constantes de requerimientos y especificaciones
Expectativas irreales
Carencia de recursos
Objetivos de negocio poco claros

… Problemas en administración de los proyectos

Mala planeación
Mala gerencia de proyectos
Cronogramas de tiempos irreales

Agenda
9 Historia sobre la evolución de las tecnologías
y arquitecturas de software
9 Necesidades empresariales
¾ Atributos de Calidad
… Del problema a la arquitectura
… Contenedores

Atributos de calidad
… Atributo de calidad: característica de un componente o sistema

… Categorías
† Funcionalidad: aunque es el más importante no es el único

† Disponibilidad

† Usabilidad: ofrecer las operaciones para cancelar, deshacer, o reutilizar datos

previamente ingresados.

† Eficiencia-Desempeño
„ Cantidad de comunicación entre componentes
„ Funcionalidad ofrecida por cada componente
„ Localización de recursos compartidos

† Mantenibilidad
„ Determinada por la forma como se divide la funcionalidad
„ Un sistema es mantenible(modificable) si un cambio involucra el menor
número posible de elementos

† Portabilidad
„ Aislar dependencia del sistema
Atributos de calidad & Arquitectura
de Software
… Los atributos de calidad deben ser diseñados y
evaluados en la definición de una arquitectura

… La arquitectura por si sola no puede lograr

satisfacer los atributos de calidad, se deben
considerar los detalles (implementación)

… Los atributos de calidad

† No se logran de forma aislada
† Garantizar uno afecta otros (e.g., portabilidad y
eficiencia)

Clases de atributos de calidad

… Sistema: disponibilidad, mantenibilidad, desempeño, usabilidad

… Negocio
† time to market: tiempo para desarrollar vs. la oportunidad de
venderlo
† Costo/beneficio: construir una arquitectura flexible es más
costosa que una arquitectura rígida
† Tiempo de vida del producto
† Segmento objetivo

… Arquitectura
† integridad conceptual: visión que unifica el diseño del sistema
en todos sus niveles

Atributos de calidad
… Problemas
† Definición: el sistema es modificable con respecto a un conjunto
de cambios pero no modificable con respecto a otros.
† Sobre qué atributo específicamente se discute. Ejemplo: falla
del sistema concierne la disponibilidad, la seguridad,
usabilidad?
† Vocabulario cambia según el atributo. Ejemplo: desempeño –
evento, seguridad – ataque, disponibilidad - falla

… Solución
† Escenarios de atributos de calidad (2 primeros) –revisar
ejemplo pag. 84 escenario de desempeño
† Centrarse en lo que concierne el atributo y no en los términos
utilizados
 Escenario de desempeño

Artefacto
Estimulo Sistema Respuesta
Inicio de Transacciones
transacciones procesadas
Ambiente Medida Rta.
Bajo operaciones Promedio de latencia
normales dos segundos

Fuente
Usuario

Agenda
9 Historia sobre la evolución de las tecnologías
y arquitecturas de software
9 Necesidades empresariales
9 Atributos de Calidad
¾ Del problema a la arquitectura
… Contenedores

Del problema a la arquitectura

diseño construcción arranque
mundo
mundo
MM
programa

Requerimientos
funcionales

Requerimientos análisis implementación instalación ejecución

no funcionales

Lo que se quiere transformación

representar La representación

problema ciclo de vida solución

 Del problema a la arquitectura
… Desarrollo de software como una
transformación de elementos
… Arquitectura = forma o estructura
… Todo programa tiene una arquitectura
… Elementos estructuradores: mucho más que
sólo tecnología
… Mecanismos de composición
… Existen características inherentes a los
elementos que estructuran la solución

Propiedades deseables
… Localización: dado un elemento del problema, se
puede localizar su representación en el programa

mundo
mundo
MM
programa

Requerimientos
funcionales

Requerimientos
no funcionales

Propiedades deseables
… Aislamiento: un cambio en un elemento del
programa tiene una frontera de impacto
conocida
programa
 Propiedades deseables
… Flexibilidad: las decisiones arquitecturales se pueden
tomar tarde en el ciclo de vida
diseño construcción arranque
mundo
mundo
MM

programa
Requerimientos
funcionales

Requerimientos análisis implementación instalación ejecución

no funcionales

Arquitecturas Arquitecturas
rígidas flexibles

Propiedades deseables
… Reutilización: los elementos del programa son
fácilmente utilizables en otros programa

programa-1 programa-2

Propiedades deseables
… Evolución: la arquitectura del programa no se deteriora
debido a la evolución del problema

evolución
Propiedades deseables
… Enseñable: es clara la transformación de los elementos
del problema en elementos de la solución

diseño construcción arranque

mundo
mundo
MM
programa

Requerimientos
funcionales

Requerimientos análisis implementación instalación ejecución

no funcionales

Preguntas
1. ¿Cómo podemos ofrecer las propiedades
deseables de una arquitectura? De ideas
para cada una de estas propiedades:
Localización, Aislamiento, Flexibilidad,
Reutilización, Evolución.

Agenda
9 Historia sobre la evolución de las tecnologías
y arquitecturas de software
9 Necesidades empresariales
9 Atributos de Calidad
9 Del problema a la arquitectura
¾ Contenedores
Complejidad en Arquitectura de
Software
… Los enfoques actuales ó modelos
arquitectónicos de la industria enfrentan el
manejo de complejidad
† Evolución a arquitecturas multi-capas
† Necesidades de Negocio
† Avances en la tecnología

† Atributos de calidad

† Propiedades deseables

Vía contenedores ¿ Pero qué es

un contenedor?
Permiten que el desarrollador se concentre en
solucionar el problema de negocio

Los contenedores son la interfaz entre un

componente y la funcionalidad de bajo nivel
específica a una plataforma que soporta al
componente

Vía contenedores ¿ Pero qué es

un contenedor? (2)
Entorno de ejecución.

Ambiente donde se ejecutan componentes:

† Windows 2003
† Web (Jrun, Tomcat Jakarta, Servlet Exec)
† EJB (JBoss, WebSphere, iPlanet, Oracle IAS 9.i, Bea Weblogic, )
† Clientes (Aplicaciones stand alone, Applets, etc.)
† Conectores a sistemas legacy (Cobol, CICS, etc.), ERP, CRM

Maneja el ciclo de vida de un componente

† Create.
Cuantos problemas de memoria y
† Run desempeño tenemos hoy en día,
† Destroy. por no administrar
eficientemente los objetos???
 ¿ Qué es un contenedor ?
(cont...)

“The container is the car,

The component is the driver”
Bill Shannon. (J2EE Lead Architect)
JavaOne 1999.

“The container is the platform,

The Component is your application”
Mark Hapner. (J2EE Platform Architect)
JavaOne 1999.

Delegando requerimientos a los

contenedores
- Requerimientos funcionales
- Casos de Uso ¿Usted sólo costea /estima esto?
- Modelamiento del negocio

Aplicación =
Lógica + Lógica No
empresarial de gran
Funcional funcional
escala
- Integración (EAI, MOM, Connector)
- Acceso concurrente
- Transacciones distribuidas (ACID)
- Manejo de memoria
- Seguridad
¿Esto quién lo hace? - Alta disponibilidad
- Manejo de threads
- Pool de conexiones
- Escalabilidad

Entonces... Una aplicación

empresarial de gran escala es...
- Requerimientos funcionales
- Casos de Uso
- Modelamiento del negocio

Aplicación empresarial =
Lógica Lógica No
+
de gran escala Funcional funcional

- Integración (EAI, MOM, Connector)

- Acceso concurrente

J2EE - Transacciones distribuidas (ACID)

- Manejo de memoria

.NET
- Seguridad.
- Alta disponibilidad
- Manejo de threads.
- Pool de conexiones.
- Escalabilidad
 Vista arquitectónica de
despliegue
Componente

Clases Descriptor
Encapsula los
algoritos del
+ del componente
negocio (Archivo XML)

Contenedor

Manejo de Integracion
recursos Legacy Connector a
(pools) Systems CRM, ERP
Manejo de Manejo de Modulo de Modulo de
Transacciones Concurrencia Clustering load balancing

Vista arquitectónica de ejecución

Contenedor

Componente
Clases Descriptor
Encapsula los
algoritos del
+ del componente
negocio (Archivo XML)

Manejo de Integracion Connector a

recursos Legacy CRM, ERP
(pools) Systems
Manejo de Manejo de Modulo de Modulo de
Transacciones Concurrencia Clustering load balancing

Preguntas
… Qué papel juegan los contenedores y
modelos de componentes para garantizar
estas propiedades
… La presentación dice que un contenedor
maneja el ciclo de vida de un componente.
¿Qué quiere decir esto?
Abstracción arquitectónica del desarrollo
centrado en componentes (CBD)

Modelo Abstracto
Definición de los servicios implementados por el componente
Define las relaciones entre los componentes
Modelo de programación
Define la naturaleza del componente (Transitorio, Compartido,
Persistente)
Modelo de despliegue
Considera la distribución lógica del componente, parametrización
de los requerimientos no-funcionales.
Modelo de ejecución
Define los mecanismos y protocolos empleados por la plataforma
de ejecución de componentes para comunicarse con los
componentes. Ciclo de vida

Estructura multicapas de la
arquitectura
Presentación

Persistencia

Integración
Del negocio
Servicios

Datos y
Capa

Capa
Capa
Capa

Aplicación
Corporativa
Multi-capas

Manejo
Seguridad Clustering
Transaccional
Plataforma de
Componentes
Integración Replicacion Persistencia Distribuidos

Servidor de Aplicaciones

Preguntas
… La presentación habla de un modelo de programación que define la
naturaleza de un componente (Transitorio, Compartido, Persistente)
¿Qué impacto pueden tener estos aspectos sobre el ciclo de vida de un
componente?

… ¿Por qué deben estructurarse las aplicaciones alrededor de capas?

… ¿Las reglas del negocio no deben estar muy separadas de los datos o
viceversa? ¿Qué perdemos y ganamos con esta decisión?

… Qué trade-offs puede encontrar entre mantener la funcionalidad en el

cliente cerca al usuario (thick client) o descargar la mayoría de la
funcionalidad en el servidor (thin client).
Transparencia
Relevar al usuario (Desarrollador) de la necesidad de
preocuparse por aspectos técnicos
Todo aspecto de un sistema dado por su distribución es
escondido del usuario
Access transparency
Location transparency
Migration transparency
Replication transparency
Concurrent transparency
Failure transparency
Persistence transparency
Security transparency

Este material fue preparado por

… Nicolás López
… Pilar Villamil

Referencias
… Arias Jorge. Tutorial: Arquitectura de Software Bajo
Implementaciones .NET & J2EE. 2005

… Rubby Casallas, Jorge Villalobos. Tendencias en

Ingeniería de Software Grupo de Investigación en
Construcción de Software

… Bass Len, Clements Paul, Kazman Rick. Software

Architecture in Practice, second edition. Addison
Wesley. 2006.