2011Integración de Aplicaciones Desarrollo Basado en Componentes.

Presentación del tema: "2011Integración de Aplicaciones Desarrollo Basado en Componentes."— Transcripción de la presentación:

1 2011Integración de Aplicaciones Desarrollo Basado en Componentes

2 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

3 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

4 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

5 2010Ing. 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

6 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

7 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

8 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

9 Requerimientos no funcionales Performance Mantenibilidad Extensibilidad Flexibilidad Reusabilidad Confiabilidad Seguridad

10 Evolución de los Paradigmas 19701980201020001990 Pascal, Ada, COBOL, RPG Metodologías estructuradas C++, Eiffel, OOA/D CORBA 2.0, DCOM, UML CORBA 3.0, EJB, DNA, Componentes de negocio Programación estructurada Orientación a Objetos Objetos Distribuidos Desarrollo basado en componentes

11 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

12 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)

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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.