Alvaro Ernesto Carmona Ruiz Software Architect

Presentación del tema: "Alvaro Ernesto Carmona Ruiz Software Architect"— Transcripción de la presentación:

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

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:

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

12 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/ (Distributed Simulation Systems, v2.0) Contact: Ms. Linda Heaton The document is available in the following formats: PDF( bytes) alternatePostScript( bytes)

13 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

14 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

15 Qué es un componente?

16 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

17 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

18 Arquitectura de componentes

19 Componentes en el contexto de las aplicaciones de n-capas

20 Elementos del servidor de aplicaciones

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

22 Plantilla de componentes de arquitectura

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

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

25 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

26 Enterprise Service Bus (IBM)

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

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

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

30 Preguntas