2011Integración de Aplicaciones Desarrollo Basado en Componentes.
-
Upload
cruzita-amparan -
Category
Documents
-
view
2 -
download
0
Transcript of 2011Integración de Aplicaciones Desarrollo Basado en Componentes.
2011 Integración de Aplicaciones
Desarrollo Basado en Componentes
Características Aplicaciones empresariales
• Los sistemas están altamente acoplados con la organización, procesos y modelo de negocios de la compañía
– Dependencias entre departamentos– Relaciones con partners externos
• Alto número de requerimientos– En muchos casos, requerimientos en conflicto y no bien
definidos …
• Los procesos de negocio cambian constantemente– Deben reflejarse rápidamente en la estructura de IT
• Los sistemas no funcionan aisladamente– Alto nivel de dependencias entre múltiples sistemas
• Evolución de sistemas con alto nivel de heterogeneidad y redundancias
Aplicaciones empresariales: Situación Actual
• Los sistemas no son flexibles • Imponen limitaciones para la adaptación de la
organización a nuevos contextos• Los sistemas tienen ineficiencias
• Los desarrollos son más costosos que los resultados obtenidos
Razones de la dificultad de adaptación
• Técnicas • Dificultad de modificación del código• Decisiones de diseño que afectan la
adaptación futura• Organizacionales
• El equipo del proyecto pasa a otros proyectos• Mantenimiento desarrollado por trabajadores
con menos experiencia• Superada la fase de “euforia” del nuevo
sistema, el apoyo del management suele caer
• Restricciones de presupuesto para efectuar los cambios en forma adecuada
2010 Ing. de Sistemas II
Aplicaciones empresariales
• Requerimientos deseables– Simplicidad
– Comprensible para técnicos y no técnicos
– Flexibilidad– Adaptabilidad a cambios en el contexto
– Mantenibilidad– Cambios locales no deben impactar globalmente
– Reusabilidad– Reducir costos y minimizar redundancias
– Bajo acoplamiento entre funcionalidad y tecnología– Evitar dependencias de tecnologías específicas– Permitir evolución tecnológica, con menor impacto en
negocio
Rol de la Ingeniería de Software
• Aplicación de principios y métodos ingenieriles para la producción de software en escala industrial
• Producto:– “Cost-effective”– Confiable– Calidad
• Proceso:– Sistemático– Controlado– Eficiente
• Incluye:• Desarrollo• Operación• Mantenimiento
Por qué es una ingeniería?
• Los ingenieros se desempeñan tomando una serie de decisiones, evaluando opciones cuidadosamente y seleccionando en cada punto de decisión una alternativa que es apropiada para la tarea en desarrollo y en el contexto actual.
• Los ingenieros enfatizan el uso de un proceso disciplinado cuando crean un diseño
• Los ingenieros aplican herramientas sistemáticamente en el proceso; la elección y uso de la herramienta adecuada es clave.
• Los ingenieros reusan diseños y artefactos.• Las disciplinas ingenieriles avanzan por medio
del desarrollo y validación de nuevos principios, estandares y ‘best practices’
Objetivos Ing. de Software
• Producir productos de software de calidad
• Proceso de desarrollo eficiente• Posibilitar la evolución de los
sistemas, en una forma eficiente• Permitir la integración de distintos
tipos de sistemas • Independencia de la tecnología
Requerimientos no funcionales
• Performance• Mantenibilidad• Extensibilidad• Flexibilidad• Reusabilidad• Confiabilidad• Seguridad
Evolución de los Paradigmas
1970 1980 201020001990
Pascal, Ada, COBOL, RPGMetodologías estructuradas
C++, Eiffel, OOA/D
CORBA 2.0, DCOM, UML
CORBA 3.0, EJB, DNA,Componentes de negocio
Programación estructuradaProgramación estructurada
Orientación a ObjetosOrientación a Objetos
Objetos DistribuidosObjetos Distribuidos
Desarrollo basado en Desarrollo basado en componentescomponentes
2 capas vs. 3 capas
• Aplicaciones 2 capas:• Cliente / Servidor• Ej. terminales remotas conectadas a
mainframes centrales (‘thin-client’)• Generalmente aplicaciones ‘data-
intensive’
• Aplicaciones 3 capas:• Introduce una capa adicional para el
manejo de la lógica de negocio• Mas adecuadas para aplicaciones con
mayor procesamiento / lógica• Permite una evolución a N capas
Aplics. 2 capas vs. 3 capas
• Las arquitecturas de 2 capas son típicas de:
• Ambientes con pocos clientes• Ambientes homogéneos
• Las arquitecturas de 3 capas se requieren para:
• Tener escalabilidad con miles de clientes• Acceso a fuentes de datos heterogéneas• Mantenibilidad (la actualización de la
lógica está encapsulada)
Servidores de Aplicación
• Capa central donde se ejecuta la lógica de la aplicación
• Mantenida independientemente de los clientes y de las bases de datos
• “Un conjunto estandarizado de frameworks y servidores sobre los cuales construir aplicaciones empresariales”
Servidores de Aplicación
• Algunos servicios provistos:– Concurrencia– Coordinación de transacciones– Seguridad– Administración de recursos (ej. BDs)– Distribución entre distintos servidores– Comunicación entre distintas partes del
sistema distribuido– ‘Naming’
• Estos servicios son configurables
Servidores de aplicación
• La lógica de negocios de una aplicación debe ser escrita y ‘deployada’ dentro de un servidor de aplicaciones
• El servidor de aplicaciones provee un conjunto de servicios, disponibles para la aplicación, y define las interfaces para accederlos
• Provee también capacidades para deployar una aplicación
• Sugiere un modelo de programación para instalar el software
– “Modelo de componentes”
Modelos de componentes
• Un modelo de componentes describe como diseñar y construir aplicaciones.
• Las aplicaciones consisten de un conjunto de componentes, que interactúan entre sí.
• El servidor de aplicaciones debe soportar este modelo de componentes– Ejemplos:
• COM• EJB
Objetivos del desarrollo basado en componentes
• Lograr los mismos niveles de ‘plug-and-play’ , disponibles en otras industrias
• Circuitos integrados --> componentes de software
• Placa --> frameworks de aplicación, contenedores
Qué es un componente?
• Tiene una interfaz bien definida• Se inserta en un contenedor específico• Una pieza de software que:
– Es accedida sólo via interfaces– Es construida para su customización, composición y
colaboración con otros componentes– Tiene un tamaño adecuado para su reuso,
reemplazo y mantenimiento– Su tamaño también permite su distribución,
deployment y soporte– Es entregado dentro de un paquete ‘self-contained’
• Puede ser desarrollado, distribuido e instalado independientemente
Componentes vs.Objetos
• Un componente puede verse como:• Una forma de agrupar implementaciones de
objetos en una sola entidad• Una entidad que puede ser ensamblada
dentro de un sistema más grande
• Un componente debe insertarse dentro de un modelo de componentes (contenedor)
• El componente debe seguir las reglas establecidas por el modelo de componentes
• El componente puede usar el conjunto de servicios establecido por el modelo
Porqué desarrollo basado en componentes?
• Mejor manejo de la complejidad• Reduce tiempo de entrega• Incrementa productividad• Permite el desarrollo paralelo y
distribuido• Reduce costos de mantenimiento• Permite usar el “mejor de su clase”
Referencias
• “Large-Scale, Component-Based Development”, Alan Brown, Prentice-Hall, 2000.
• “Software Architecture in Practice”, L. Bass, P. Clements, R. Kazman, Addison-Wesley, 2003
• “Software Architecture: perspectives on an emerging discipline”, M. Shaw, D. Garlan, Addison-Wesley, 1996.