De los patrones de análisis y de integración a los componentes de negocio Alvaro Ernesto Carmona Ruiz Software Architect Heinsohn Software House S.A. acarmona@heinsohn.com.co

Agenda de la Conferencia Objetivos Acerca de los patrones de análisis e Integración Modelamiento de la arquitectura de Negocio Plantilla de arquitectura de aplicaciones empresariales De la arquitectura de Negocio a la arquitectura de Software De la arquitectura de software a los componentes de Negocio Caso de Estudio, Modelamento de la información histórica. Cómo estructurar el conocimiento de la organización alrededor de patrones de negocio. El analista funcional como el principal actor en la construcción de conocimiento del negocio del cliente. Otros ejemplos de componentes funcionales basados en patrones de análisis y negocio. Conclusiones.

Resumen Los patrones de Negocio, integración y análisis son hoy en día la mejor de las herramientas para asegurar el mantenimiento de una organización de software en un nicho de mercado, Estos patrones parten de un objetivo de negocio hasta una solución técnica que desde la perspectiva del software no son otra cosa que un análisis que le dice al arquitecto cómo se debe enfocar una solución tecnológica. Este conocimiento que a decir verdad es el más importante del mercado, es precisamente el que menos se registra y documenta. Los casos clásicos de análisis y diseño del día a día en la realidad colombiana, nunca los encontramos resueltos a pesar que muchos de nosotros día a día los volvemos a solucionar.

Objetivos Abonar el camino hacía un uso estándar de componentes funcionales en el común de las industrias colombianas. Reducir el tiempo y la calidad de desarrollo de proyectos de software con base en la integración recurrente de unidades funcionales completas. Evolucionar hacia el esquema de outsourcing de servicios de proceso, estructurados en la estandarización de la dupla “herramienta-proceso”.

El Arquitecto de un proyecto El negocio El framework Los datos La tecnología La visión del proyecto La integración Los componentes Los procesos Los costos

Patrones de Análisis Los patrones de análisis son un conjunto de clases y relaciones entre ellas, que tienen algún sentido en el contexto de una aplicación. Representan una estructura que puede ser válida para otras aplicaciones. En el contexto de las aplicaciones empresariales EPR, CRM, Nómina.. El patrón de análisis representa el conocimiento que le da el valor a la organización

Características de los Patrones de Análisis Ayudan a construir la experiencia colectiva de Ingeniería de Software. Son una abstracción de "problema – solución". Se ocupan de problemas recurrentes. Identifican y especifican abstracciones de niveles más altos que componentes o clases individuales. Proporcionan vocabulario y entendimiento común.

Estructurando Patrones de Análisis en la Organización Los analistas expertos de su área de desarrollo, podrían documentar los patrones que van encontrando e ir armando un catálogo. Un formato como el siguiente es de gran utilidad: 1. Nombre del patrón 2. Problema que resuelve 3. Modelo de la solución 4. Ejemplos de su uso El último punto es muy importante, ya que es donde realmente se puede verificar si un patrón es aplicable o no. Como el fin primordial de los patrones de análisis es transmitir experiencia, es esencial poner el catálogo al alcance de los desarrolladores. No olvidar el esfuerzo conjunto entre arquitectos y expertos de negocio.

Estrategía de definición de arquitectura En la estructura moderna de desarrollo, las aplicaciones de negocio deben ser ensambladas a partir del uso de componentes probados y que ofrecen soluciones estándar a los problemas recurrentes, integradas adecuadamente en un esquema de reutilización de lógica de negocio.

El valor de las especificaciones estándar Algunas organizaciones se dedican a promover el uso de especificaciones estándar de componentes, las cuales son utilizadas en su mayoría por las comunidades de software libre, aquí algunos ejemplos: www.oasis-open.org www.omg.org www.openapplications.org www.eTom.org

Algunas especificaciones estándar FASB: (Financial Accounting Standards Board) Establecer y promover estándares de contabilidad financiera http://www.fasb.org/ Promueve un framework de uso y de interfases entre componentes financieros. Party Management Facility specification : OMG, formal/01-02-68 www.omg.org OMG Manufacturing specifications Distributed Simulation Systems (DSS) specification, Product Data Management (PDM) Enablers specification.

PDM This specification is intended to provide standard interfaces to Product Data Management systems, or other systems providing similar services, from other manufacturing software systems, primarily those supporting various aspects of product and process engineering, and those supporting manufacturing planning. Document -- formal/02-11-11 (Distributed Simulation Systems, v2.0) Contact: Ms. Linda Heaton The document is available in the following formats: PDF(910861 bytes) alternatePostScript(4214274 bytes)

Open Applications Group www.openapplications.org Content Working Groups - Core Components - CRM XML - Internet Parts Order Joint Workgroup with AAIA - Inventory Visibility with AIAG - Location Services - Logistics XML - Material Replenishment with AIAG - Payment Harmonization - ICXML - STAR - VisionML - Web Services

Componentes de Negocio Qué es un componente Qué tipos de componentes existen Qué es un componente de negocio Características de un componente de negocio Cómo aportan los componentes de negocio el trabajo del diseño de la arquitectura de los sistemas empresariales

Qué es un componente?

Componentes de Negocio Qué es un componente Qué es un componente de negocio Características de un componente de negocio Cómo aportan los componentes de negocio el trabajo del diseño de la arquitectura de los sistemas empresariales

Componentes que surgen a partir de patrones de análisis Actor/Role Business Definitions Business Event/Result History Contract Core/representation Document Employment Geographic Location Organization and Party Product Data Management Thing Information Tittle/Item Type/object/value

Arquitectura de componentes

Componentes en el contexto de las aplicaciones de n-capas

Elementos del servidor de aplicaciones

Niveles de componentes Usuarios Procesos de Negocio, componentes funcionales Procesos de Negocio de Pensiones y Cesantias (WorkFlow) Integración en un Bus de Servicio Componentes Funcionales Componentes de Servicio del Sistema Intergrado de Pensiones y Ce santias Invocación de Servicios Componentes funcionales de infraestructura Servicios de Infraestructura del Negocio de Pensiones y Cesantia s Invocación de Servicios Servicios de Infraestructura Servicios de Soporte al Negocio ... Productos Clientes Cuentas Parámetros Seguridad Configuración ...

Plantilla de componentes de arquitectura

Bussiness Components Architecture Los componentes de negocio tienen dos características importántes: Encapsulación y Modularidad Comunicación vía interfases. Separación entre interfase e implementación. Soporta versionamiento, manejo de la configuración, desarrollo dinámico. Modularidad se refiere al proceso de descomponer un problema en un conjunto de pequeños problemas, los componentes de negocio son modulares en el sentido que implementan funciones relevantes del negocio y que pueden ser reutilizados através de múltiples soluciones.

Casos de Estudio Manejo de Información Histórica Componentes de doble control Manejo de Terceros El analista funcional como el principal actor en la construcción de conocimiento del negocio del cliente. Los patrones de análisis como herramienta para estructurar el conocimiento técnico y de negocio de una organización o de un nicho de mercado.

Integración de componentes vía SOA Presentación Procesos del Negocio - WorkFlow Bus de Servicio, Middleware Servicios del Sistema Componente Componente Componente Cada componente tiene capa de datos y de lógica de negocio Lógica Infraestructura de Componentes Datos

Enterprise Service Bus (IBM)

Lecciones aprendidas Las soluciones a los problemas clásicos ya existen. Hay que usarlas. El conocimiento que se tiene alrededor de cómo modelar las aplicaciones se encuentra más fácil en un analista de negocio que en arquitecto. El uso de modelos y estándares reducen la brecha de conocimiento para llegar a ser arquitecto.

Conclusiones Reutilización!!!!!... Pero de Negocio!!!!!. Integrar en una arquitectura de orientación a servicios. Primero lo primero, antes de integrar.. Hay que tener algo que valga la pena integrar. El uso de modelos y estándares reducen la brecha de conocimiento para llegar a ser arquitecto.

Referencias Frankel S. David, Model Driven Architecture, Applying MDA to Enterprise computing, 2003, Wiley D. Alur, J. Crupi, and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, Sun Microsystems Press, 2001. Natividad Martinez Madrid, Arquiecturas de componentes, Universidad Carlos III, Madrid, España, 2001 S. Mellor and M. Balcer, Executable UML: A Foundation for Model-Driven Architectures, Addison-Wesley, 2002.

Preguntas