De los patrones de an á lisis y de integración a los componentes de negocio

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

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

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

4. 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”.

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

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

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

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

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

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

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

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

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

14. Arquitectura de componentes

15. 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 Cuentas Clientes ... Parámetros Seguridad Configuración

16. Plantilla de componentes de arquitectura

17. 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 negocioy que pueden ser reutilizados através de múltiples soluciones.

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

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

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

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

22. Referencias • Frankel S. David, Model Driven Architecture, Applying MDA to Enterprise computing, 2003, Wiley • D. Alur, J. Crupi, and D. Malks, Core J2EE Patterns: BestPractices and Design Strategies, Sun Microsystems Press, 2001. • D. Alur, J. Crupi, and D. Malks, Core J2EE Patterns: BestPractices 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 forModel-Driven Architectures, Addison-Wesley, 2002.

23. Preguntas