Escuela Superior de Ingeniería. Máster Oficial en Ingeniería Fabricación. Trabajo de Aplicación

Transcripción

1 Escuela Superior de Ingeniería Máster Oficial en Ingeniería Fabricación Trabajo de Aplicación Estudio de viabilidad de una metodología dirigida por modelos para el desarrollo de los sistemas de información de una empresa de fabricación distribuida Planta A Planta B Comercial Almacén Producción Planta C Autor: Antonio García Domínguez Tutor: Mariano Marcos Bárcena

2 Índice general 1. Introducción Motivación Trabajos relacionados Objetivos Estructura del trabajo Conceptos previos Organizaciones virtuales: la empresa extendida Arquitecturas orientadas a servicios Ingeniería dirigida por modelos Selección de una metodología SOA Introducción Revisión de las metodologías existentes Antecedentes en el desarrollo basado en componentes Metodología IBM SOMA Metodología SOD-M Metodología base escogida: SOD-M Diagramas UML utilizados Modelos independientes de computación Modelos independientes de plataforma Modelos específicos de plataforma Extensiones propuestas sobre SOD-M para integración de pruebas Pruebas de sistema Pruebas de función e integración Integración de técnicas de pruebas Conclusiones Extensión con restricciones de rendimiento de SOD-M Introducción Estado inicial de las herramientas y tecnologías usadas en SOD-M Plataforma base de desarrollo: Eclipse Definición de metamodelos: EMF Creación de notaciones gráficas para modelos: GMF Estado inicial de las herramientas de SOD-M Tecnologías adoptadas para la extensión de SOD-M Problemas en la metodología de desarrollo habitual en EMF y GMF Paso a notación textual para definir metamodelos Ecore: Emfatic Unificación de lenguajes de manejo de modelos: Epsilon ii

3 Índice general Generación automática de los modelos de GMF: EuGENia Automatización del flujo de trabajo: Apache Ant Creación de las herramientas mejoradas para SOD-M Cambios en los metamodelos Validación de los metamodelos Algoritmos de estimación de restricciones de rendimiento Transformación de modelos de proceso de servicio a modelos de composición de servicio Conclusiones Caso práctico Introducción Descripción de los sistemas de información de la organización modelada Modelos de negocio Modelo de intercambios de valor Modelo de proceso de negocio Modelos de casos de uso Modelos de proceso de servicio Modelos de composición de servicio Selección de las acciones de servicio a implementar mediante servicios web Conclusiones Conclusiones y trabajos futuros 6.1 A. Instrucciones de instalación y uso A.1 A.1. Contenidos del DVD A.1 A.1.1. Directorio raíz A.1 A.1.2. Distribuciones Eclipse A.1 A.1.3. Código fuente A.2 A.1.4. Modelos A.3 A.2. Instalación y uso A.4 A.2.1. Instalación en Microsoft Windows XP A.4 A.2.2. Instalación en Ubuntu Linux A.4 A.2.3. Uso general A.5 iii

4 Índice de figuras 2.1. Propuesta MDA del OMG Esquema de los modelos utilizados en SOD-M Ejemplo de proceso de servicio «Atender pedido» extendido Ejemplo de composición de servicio «Atender pedido» extendida Ejemplo de un contrato visual basado en transformaciones de grafos para «Atender pedido» Diagrama de clases UML con el metamodelo común para los diagramas de actividad UML modificados Diagrama simplificado de clases UML para el metamodelo de procesos de servicio extendido Diagrama simplificado de clases UML para el metamodelo de composiciones de servicio extendido Descripción gráfica del cálculo de B = lca(d, F ) Grafo problemático para la segunda formulación con programación lineal Modelo de intercambios de valor en EBE Modelo de proceso de negocio de la parcela seleccionada de EBE Modelos de casos de uso para EBE Modelo de casos de uso extendido «Obtener tabaco empaquetado» Modelo de casos de uso extendido «Obtener tabaco pretratado» Modelo de casos de uso extendido «Obtener tabaco sin tratar» Modelo de proceso de servicio «Obtener tabaco empaquetado» Modelo de proceso de servicio «Obtener tabaco pretratado» Modelo de proceso de servicio «Obtener tabaco sin tratar» Modelo parcial de composición de servicio «Obtener tabaco sin tratar»: actividad de servicio «Seleccionar tipo de búsqueda» Modelo parcial de composición de servicio «Obtener tabaco sin tratar»: actividad de servicio «Buscar agricultor por variedad exacta» Modelo parcial de composición de servicio «Obtener tabaco sin tratar»: actividad de servicio «Buscar agricultor por variedad aproximada» Modelo parcial de composición de servicio «Obtener tabaco sin tratar»: actividad de servicio «Realizar control de calidad in situ» Modelo parcial de composición de servicio «Obtener tabaco sin tratar»: actividad de servicio «Realizar pedido» Modelo parcial de composición de servicio «Obtener tabaco sin tratar»: actividad de servicio «Obtener tabaco sin tratar» Modelo parcial de composición de servicio «Obtener tabaco sin tratar»: actividad de servicio «Realizar pago» iv

5 Índice de tablas 3.1. Tabla comparativa de las metodologías SOA bajo estudio Elementos de los diagramas UML de clases utilizados Elementos de los diagramas UML de casos de uso utilizados Elementos de los diagramas UML de actividad simplificados utilizados Elementos de los modelos de valor Elementos nuevos o cambiados en los modelos de casos de uso de SOD-M Elementos nuevos o cambiados en los modelos de casos de uso extendidos de SOD-M Correspondencias de los modelos de casos de uso extendido a los modelos de proceso de servicio Resumen de elementos en el metamodelo común Resumen de elementos en el metamodelo de proceso de servicio Resumen de elementos en el metamodelo de composición de servicio Common.evl: restricciones a cumplir por el metamodelo común y otros elementos compartidos a nivel de implementación ServiceProcess.evl: restricciones adicionales a cumplir por el metamodelo de procesos de servicio ServiceComposition.evl: restricciones adicionales a cumplir por el metamodelo de composiciones de servicio Definiciones de U A (e) para cada tipo de elemento de los metamodelos Correspondencias del metamodelo de proceso de servicio al metamodelo de composición de servicio Contenidos de los mensajes intercambiados en la composición de servicio «Obtener tabaco sin tratar» v

6 1 Introducción

7 1. Introducción 1.1. Motivación Hoy en día, las empresas se hallan bajo la necesidad de competir en un mercado en el que los ciclos de vida de los productos son cada vez más cortos y se exigen mayores niveles de flexibilidad y calidad a menor coste. Para ello, necesitan ser capaces de reorientar y mejorar continuamente sus procesos de negocio en función de la situación y de forma rentable. Sin embargo, las plataformas centralizadas normalmente usadas en las empresas de hoy en día no pueden cambiarse tan rápidamente como las situaciones lo requerirían, y finalmente son éstas las que definen las prácticas a seguir, más que la propia situación del mercado. Se necesita, por lo tanto, un enfoque distinto para estructurar los sistemas de información en la así llamada Siguiente Generación de Sistemas de Fabricación (SGSF). Actualmente, se admite a nivel conceptual la necesidad de distribuir las actividades a lo largo de varios sistemas de información especializados y de posteriormente integrarlas en lo que se conoce como una empresa extendida Marcos et al. [2005]. Entre los protomodelos de empresa distribuida más conocidos, se encuentran las organizaciones holónicas, llamadas así por constituirse de una serie de actores semiautónomos que se interrelacionan entre sí a varios niveles, conocidos como holones Tharumarajah et al. [1998]. Una vez establecido el marco conceptual sobre el que modelar a la organización, resulta evidente la necesidad de plasmarlo en un sistema de información. Afortunadamente, desde hace varios años, una forma de estructurar los sistemas de información que se ajusta bien a estas ideas ha ido recibiendo cada vez más atención: las Arquitecturas Orientadas a Servicios o «Service-Oriented Architectures» (SOA). La idea central detrás de ellas es organizar los sistemas de información no como sistemas integrados unidad a unidad de negocio o proyecto a proyecto, como se ha hecho comúnmente, sino como servicios individuales que pueden ser reutilizados a lo largo de la organización, o incluso por otras organizaciones con las que se tiene relación. Posteriormente, estos servicios individuales pueden ser integrados en servicios de nivel superior con su propio valor añadido, modelando procesos de negocio completos en vez de operaciones individuales. A nivel de implementación, estas arquitecturas suelen implementarse utilizando Servicios Web («Web Services» o WS), para así aprovechar las numerosas tecnologías, herramientas e infraestructuras ya implementadas para la World Wide Web y reducir las barreras tecnológicas. La información deja de concentrarse en «silos» de departamentos concretos y pasa a estar disponible a toda la organización en forma de servicios. Este enfoque y su implementación mediante WS ofrecen grandes ventajas a nivel tecnológico y de negocios, pero no dejan de tener sus propias dificultades. Implantar una SOA es complejo, ya que afecta a toda la organización, y necesita tanto una buena visión global como una correcta implementación. La máxima flexibilidad se conseguiría con muchos servicios muy específicos, pero implantar cada servicio tiene un coste adicional respecto a la simple implementación de la funcionalidad, por lo que en términos de coste de desarrollo a corto plazo, interesa tener pocos servicios. El óptimo global se halla en una granularidad media de los servicios, pero es difícil de localizar. A esto se le añade la dificultad inherente en el desarrollo de cualquier sistema distribuido de esta magnitud. Para hacer frente a este nivel de complejidad, han surgido metodologías orientadas a SOA como SOMA Ghosh et al. [2008], SOD-M de Castro [2007] o la propuesta por Stojanović Stojanović [2005]. Tratan de reducir el nivel de dificultad y asegurar resultados más controlables y repetibles en su implantación. Algunas de estas metodologías son revisiones de metodologías 1.1

8 1. Introducción de desarrollo tradicional de software orientado a objetos, y otras han sido creadas desde cero alrededor del concepto de «servicio» tal y como se entiende en SOA. En este trabajo se propone que estas nuevas metodologías son las que pueden dar los mejores resultados, ya que disponen de un nivel mayor de abstracción y reflejan de forma más directa los procesos de negocio a implementar. Otro problema, independientemente de la metodología utilizada, es el hecho de que el mayor grado de integración y la mayor visibilidad de los servicios de la organización implican también una mayor dependencia en su correcto funcionamiento, y un mayor grado de impacto en caso de fallo. Esto se acentúa en el caso de SOA, ya que la integración de servicios internos o externos a la organización es central a dicho enfoque. Este Trabajo Fin de Máster aplicará una metodología SOA a un caso práctico de una empresa de fabricación distribuida, por lo que habrá que definir una metodología que sea capaz de ayudar a controlar la complejidad en la gestión de una SOA y a reducir el riesgo de que en algún momento no funcione de la forma esperada Trabajos relacionados En el contexto de la ingeniería de fabricación, la implementación de sistemas complejos a partir de la interacción de una serie de agentes simples es una estrategia común a nivel de planta Marcos et al. [2005]. La variedad radica en la forma en que se organizan estas entidades. Algunos sistemas se estructuran de forma jerárquica, con mecanismos y sensores sin inteligencia propia que son manejados de forma remota con controladores de sección y de planta. Los controladores de planta realizan acciones de nivel superior utilizando la información que reciben de los controladores de sección. Otros sistemas más dinámicos integran agentes que interaccionan con su entorno, con los agentes en los alrededores y en algunos casos con supervisores, que más que enviar órdenes, proporcionan información y sugerencias. En muchos casos se combinan ambos enfoques, o se extienden utilizando técnicas de inteligencia artificial. Por otro lado, las SOA se han utilizado normalmente a nivel de empresa para comunicar las distintas plantas entre sí y con la cadena de proveedores, uniéndolas en una empresa extendida Browne et al. [1998]. Conceptualmente puede verse como una implementación de los sistemas de información de acuerdo con el modelo empresarial holónico Tharumarajah et al. [1998]. En particular, Hyfinity Hyfinity [2003] utilizó el enfoque de las SOA para implementar un sistema que integraba la cadena de concesionarios de Nissan con sus plantas de fabricación y sus proveedores: una venta se convertía en un pedido de producción que generaba los pedidos de material necesarios, de forma que se minimizara el tiempo entre la realización del pedido y su entrega. Otras organizaciones, como MESA, proponen usar las SOA en dos capas: una primera capa a nivel de la organización, y una segunda capa a nivel de planta IBM Corporation et al. [2008]. Esto se debe a los distintos requisitos de cada tipo de comunicación: pocas operaciones pero que implican mayor carga computacional y actúan a nivel de negocio, frente a muchas interacciones cortas con carga computacional mínima, que actúan a nivel de planta. Antes de seguir, es necesario aclarar exactamente qué se entiende por SOA. La acepción original, que es la que se utilizará en este Trabajo Fin de Máster, fue descrita por Erl en Erl [2008] y sugiere que no es más que una forma de ver los sistemas de información como una colección de servicios que apoyan al negocio integrándose entre sí. Actualmente, sin embargo, muchas empresas desarrolladoras de software abusan del término SOA para hacer referencia a 1.2

9 1. Introducción una pila determinada de tecnologías. Definir y mantener una SOA dentro de una organización no es nada trivial, por lo que han surgido diversas metodologías SOA con distintos alcances y objetivos. Engels propone una metodología que se limita a extraer del entorno los servicios que han de formar parte de la SOA Engels et al. [2008], mientras que la metodología sugerida por Stojanović define la funcionalidad esperada y cómo se implementará, pero no los datos que se manejarán Stojanović [2005]. La metodología SOD-M de Castro [2007], tras integrarse con MIDAS, permite describir la información que manejará el sistema además de su funcionalidad, pero no cubre todas las fases del ciclo de vida del software. Por otro lado, la metodología SOMA Ghosh et al. [2008] de IBM sí incluye todas las fases, pero tiene un importante coste de ejecución Objetivos Los objetivos de este Trabajo Fin de Máster (TFM de ahora en adelante) son los siguientes: Seleccionar una metodología SOA dirigida por modelos que permita obtener la funcionalidad esperada del sistema a partir de la descripción de su negocio. Dicha metodología debería ser lo suficientemente flexible como para ser utilizada en organizaciones de menor tamaño, con menos recursos para realizar un modelado extensivo. Además, la metodología debería asistir en la generación parcial del código necesario para su implementación y/o pruebas. Revisar el grado de integración de técnicas de pruebas sobre la funcionalidad del sistema y demás características (como su rendimiento) en la metodología seleccionada. En caso de que el nivel de integración no sea satisfactorio, se propondrán las extensiones necesarias para cubrir dicha carencia. Realizar una revisión del estado del arte sobre pruebas en el contexto de los Servicios Web y SOA, reuniendo una serie de técnicas integrables en un enfoque dirigido por modelos. Estas técnicas podrían recibir sus entradas a partir de los modelos, o presentar sus resultados en ellos. Evaluar el grado de madurez de las herramientas existentes para la metodología seleccionada, extendiéndolas o reemplazándolas en función de las conclusiones extraídas. Aplicar el conjunto final de herramientas sobre un caso práctico basado en una empresa real, comprobando la viabilidad de la aplicación práctica de la metodología extendida Estructura del trabajo En esta sección se listarán cada una de las partes en que se divide este trabajo, describiendo de forma general su contenido. Conceptos previos En este capítulo se describen las ideas básicas sobre las que se asienta esta propuesta, tanto desde el punto de vista de la ingeniería de fabricación como desde el de la ingeniería del software. Se introduce el concepto de «empresa extendida» Browne et al. [1998], se relacionan con los modelos empresariales en la literatura y se proponen las arquitecturas 1.3

10 Bibliografía orientadas a servicios («Service-Oriented Architectures» o SOA) Erl [2008] como una forma de implementar sus sistemas de información. Se presentan las metodologías dirigidas por modelos Object Management Group [2003] como una forma de diseñar las SOA que permite mantener bajo control su gran envergadura. Selección de una metodología SOA Tras haber definido los conceptos fundamentales, en esta parte del TFM se comparan algunas de las metodologías SOA existentes y se selecciona una de ellas, describiéndose en más detalle. Tras analizar sus carencias, se proponen una serie de extensiones dirigidas a modelar las características funcionales y no funcionales (rendimiento, p.ej.) de la SOA. Se expone un abanico de técnicas de prueba del software que pueden integrarse con estas especificaciones, de forma que se reduzca el riesgo de que el sistema no se comporte de la forma esperada en algún momento. Extensión con restricciones de rendimiento de SOD-M Antes de poder evaluar la metodología, es necesario desarrollar las herramientas que permitan aplicarla de forma automatizada. Este capítulo comienza evaluando las herramientas para la metodología SOD-M recibidas en marzo del 2009 de sus desarrolladores, el grupo Kybele de la Universidad Rey Juan Carlos, y describiendo las tecnologías utilizadas y las posibilidades de extensión. Se estimó que era necesario mejorar el flujo de trabajo del desarrollo de dichas herramientas, por lo que se integraron una serie de nuevas tecnologías dirigidas a aumentar su agilidad y robustez. El resto del capítulo se dedica a los aspectos de diseño e implementación de las nuevas herramientas, que reemplazan a algunas de las originales e incluyen las extensiones antes propuestas para modelar el rendimiento esperado del sistema. Caso práctico La metodología extendida e implementada es evaluada sobre un caso práctico inspirado en una importante empresa del sector tabaquero. Tras una descripción textual de sus sistemas de información, se describe el negocio en términos de intercambios de valor y del proceso seguido para que el consumidor final obtenga el tabaco empaquetado que desea. A partir de esta descripción de alto nivel se obtienen en última instancia modelos con las acciones a implementar en el sistema final, anotadas con el rendimiento esperado. De entre estos modelos, por limitaciones de espacio, se expande y detalla uno de ellos al nivel más concreto de la metodología SOD-M, seleccionando aquellas acciones que se ofrecerán o consumirán en forma de Servicios Web. Bibliografía J. Browne, I. Hunt, and J. Zhang. The Extended Enterprise (EE). In L. M. Camarinha-Matos, H. Afsarmanes, and V. Merik, editors, Intelligent Systems for Manufacturing: Multi-Agent Systems and Virtual Organizations, pages Kluwer Academic Publishers, Londres, , 1.3 María Valeria de Castro. Aproximación MDA para el desarrollo orientado a servicios de sistemas de información web: del modelo de negocio al modelo de composición de servicios web. PhD thesis, Universidad Rey Juan Carlos, March ,

11 Bibliografía Gregor Engels, Andreas Hess, Bernhard Humm, Oliver Juwig, Marc Lohmann, Jan-Peter Richter, Markus Voß, and Johannes Willkomm. A method for engineering a true Service- Oriented Architecture. In José Cordeiro and Joaquim Filipe, editors, Proceedings of the 10th International Conference on Enterprise Information Systems, pages , Barcelona, España, ISBN Thomas Erl. SOA: Principles of Service Design. Prentice Hall, Indiana, EEUU, ISBN , 1.4 S. Ghosh, A. Arsanjani, and A. Allam. SOMA: a method for developing service-oriented solutions. IBM Systems Journal, 47(3): , , 1.3 Hyfinity. Nissan Motor Manufacturing Case Study, URL Nissan_Motor_Manufacturing.html. Fecha de última comprobación: 2 de noviembre de IBM Corporation, MESA International, and Capgemini. SOA in Manufacturing Guidebook, May Mariano Marcos, Francisco Aguayo, Manuel Sánchez Carrilero, Lorenzo Sevilla, and J. R. Lama. Toward the next generation of manufacturing systems. Frabiho: a synthesis model for distributed manufacturing. In Proceedings of the First I*proms Virtual Conference, pages Elsevier, , 1.2 Object Management Group. MDA Guide version 1.0.1, June URL org/mda/. Fecha de última comprobación: 2 de noviembre de Z. Stojanović. A Method for Component-Based and Service-Oriented Software Systems Engineering. PhD thesis, Delft University of Technology, , 1.3 A. Tharumarajah, A.J. Wells, and L. Nemes. Comparison of emerging manufacturing concepts. In Proceedings of the 1998 IEEE International Conference on Systems, Man, and Cybernetics, pages , California, EEUU, ,

12 2 Conceptos previos

13 2. Conceptos previos En esta sección se revisarán algunos conceptos básicos sobre los que se apoya el resto de este trabajo. Tras un recorrido general sobre el tratamiento del problema, se introducirán las ideas centrales a la propuesta: las arquitecturas orientadas a servicios y las metodologías de desarrollo dirigido por modelos Organizaciones virtuales: la empresa extendida Ninguna empresa vive en un vacío: ha de relacionarse con el ecosistema formado por sus proveedores, diseñadores, fabricantes, subcontratistas, clientes y otras empresas competidoras. Para tener éxito, ha de añadir más valor a su producto final que los competidores, y esto se traduce, normalmente, en usar la información de forma que se pueda responder eficazmente a las demandas del mercado. Sin embargo, hoy en día las empresas se ven obligadas a interactuar más allá del ámbito geográfico local al que se encuentran habituadas. El uso de sistemas de información interconectados es por lo tanto un paso crucial, así como la estandarización de las prácticas de cada participante y la resolución de diversos problemas de logística. Una vez se ha completado dicha integración, la organización resultante se conoce con el nombre de empresa extendida Browne et al. [1998]. Existe una amplia variedad de modelos para representar la estructura de una empresa extendida. Muchos de ellos pueden englobarse en una de tres categorías Tharumarajah et al. [1998]: modelos biónicos, fractales u holónicos. Los modelos biónicos se hallan inspirados en sistemas biológicos. La empresa consiste en una serie de tejidos (correspondientes a procesos, productos o servicios), formados a su vez por células que realizan diversas operaciones y reciben y producen artefactos codificados de forma genética (partes y productos, por ejemplo). Manteniendo la analogía, una célula se autorregula mediante la secreción de enzimas (información interna de control), y puede influenciar o ser influenciada por las hormonas (información del entorno y otras unidades) que se hallen en el entorno. Ante situaciones urgentes, un sistema nervioso puede responder rápidamente. Por otro lado, los modelos fractales parten de las formas geométricas del mismo nombre. Se centran en la construcción de la empresa a partir de entidades similares entre sí a distintos ámbitos. Se construye un fractal sobre otro cuando el fractal de nivel inferior no puede acometer todas las tareas que deben ser realizadas. De forma inversa, las metas de la organización descienden desde el fractal principal que modela a la organización completa, y se van concretando nivel a nivel. Cada fractal tiene un cierto grado de autonomía y capacidad de reorganización. Finalmente, los modelos holónicos se inspiran en los estudios de los sistemas jerarquizados de Koestler, quien define el concepto de «holón» como una entidad que es a la vez un todo formado por agentes de nivel inferior, y una parte de varias holarquías (jerarquías de holones) de nivel superior. Dichos holones combinan cierta autonomía con un grado de dependencia en otros holones del mismo nivel o del nivel inmediatamente superior. Estos tres modelos poseen distintos enfoques, pero tienen en común la visión de la empresa como una red dinámica de agentes con cierta autonomía y capacidad de colaboración. A nivel de implementación de estos modelos, uno de los mayores problemas de las empresas extendidas es el establecimiento de los canales de comunicación necesarios. Los sistemas de información suelen diseñarse e implementarse con planes a corto plazo específicos de cada unidad de cada organización, y en otras ocasiones existen aplicaciones cruciales que se diseñaron en una etapa anterior a la Web y resulta demasiado costoso reemplazar. Todo esto resulta en dificultades a la hora de establecer colaboraciones puntuales con empresas separadas geográficamente y 2.1

14 2. Conceptos previos aprovechar los nuevos procesos y otras ventajas que ofrecen Arquitecturas orientadas a servicios Normalmente, los sistemas de información utilizados por las empresas suelen dividirse en una serie de capas implementadas a lo largo de varias máquinas: una base de datos recoge toda la información, que es manipulada por una capa con la lógica de cada área de negocio y finalmente visualizada y manipulada por el usuario mediante una capa de presentación. Esta arquitectura ha sido utilizada con éxito para definir un número considerable de sistemas de gran envergadura de hoy en día. Encajan de forma natural con las empresas centralizadas, jerarquizadas y estables. Sin embargo, no están exentos de problemas. Estos sistemas suelen estar desarrollados para satisfacer las necesidades de partes individuales de la organización a corto plazo. No tienen en cuenta la necesidad de cambiar las prácticas de negocio a medio o largo plazo: la lógica de negocio suele hallarse unida al diseño y la implementación. Tampoco se suelen diseñar con vistas a colaborar en el futuro con otras compañías originalmente no previstas. Con el tiempo, las empresas o bien han de rodear al sistema para poder innovar, o pierden la capacidad de reaccionar ante nuevas situaciones. Por estas razones, un nuevo enfoque basado en arquitecturas orientadas a servicios («Service Oriented Architectures» o SOA) ha recibido un gran nivel de atención en los últimos años. Más que un conjunto de tecnologías, es una forma distinta de organizar los sistemas de información de una empresa Erl [2008]. Éstos dejan de ser estructuras rígidas y centralizadas para convertirse en una serie de servicios reutilizables y recombinables independientemente para definir nuevos procesos de negocio y/o refinar los existentes. Las ideas subyacentes son muy similares a las de los modelos holónicos o basados en agentes: un servicio de nivel inferior puede formar parte de servicios de nivel superior o procesos de negocio, posiblemente colaborando con otros servicios, y con un cierto nivel de autonomía. Una SOA sería una herramienta ideal para apoyar las operaciones de una empresa de fabricación distribuida. Las tecnologías más utilizadas hoy en día para implementar SOA son las de los servicios web. Aprovechan muchas de las herramientas existentes y se basan en estándares abiertos para reducir las barreras tecnológicas. Un fallo común a la hora de adoptar SOA es pensar que basta con adquirir y utilizar la última versión de la plataforma SOA escogida. Sólo se consiguen sus verdaderos beneficios una vez se hayan comprendido sus conceptos fundamentales, se haya definido un catálogo de servicios base de alto rendimiento y fiabilidad y exista una visión global de los servicios y procesos definidos desde los niveles más altos de la organización. Este proceso no es sencillo, por lo que surge la necesidad de definir metodologías que guíen su ejecución, al igual que cuando se desarrolla cualquier otro tipo de software. En una sección posterior se hará una comparativa de algunas de ellas Ingeniería dirigida por modelos En la actualidad, un problema al desarrollar software es el hecho de que existe un vínculo muy débil entre los modelos de alto nivel (es decir, más cercanos a la forma de pensar de los humanos) que se crean de los sistemas y el código que los implementan. En la práctica, lo 2.2

15 2. Conceptos previos Computation Independent Models Platform Independent Models Platform Specific Models Figura 2.1. Propuesta MDA del OMG que ocurre es que los lenguajes de modelado se usan solamente como vías de comunicación entre desarrolladores, y los modelos son de usar y tirar, ya que rápidamente quedan obsoletos al cambiar el código o los requisitos del sistema. Esto se traduce en una serie de problemas en varias actividades usuales, como por ejemplo comprobar si se han implementado los requisitos pedidos por el cliente, optimizar un diseño ante nuevas situaciones, aprovechar las últimas tecnologías existentes o verificar si el sistema cumple determinadas condiciones. Una nueva perspectiva en el desarrollo de software conocida como ingeniería dirigida por modelos («Model Driven Engineering» o MDE) y defendida por el Object Management Group (OMG) bajo el nombre de arquitectura dirigida por modelos («Model Driven Architecture» o MDA) Object Management Group [2003a] trata de dar la vuelta a esta situación. Propone implementar el sistema a partir de una serie de modelos cada vez más detallados entre los cuales se puedan hacer correspondencias a distintos niveles de automatización. Así, volvería a elevarse el nivel de abstracción al que se implementan los sistemas, como se consiguió con los lenguajes de alto nivel frente al código ensamblador, o con el código ensamblador frente al código máquina. En particular, la propuesta del OMG (véase la figura 2.1) define tres tipos de modelos para cualquier sistema. Los modelos independientes de computación («computation-independent models» o CIM) describen el negocio sin preocuparse de cómo se implementará el sistema. Los modelos independientes de la plataforma («platform-independent models» o PIM) dicen cómo cumplir los requisitos de negocio con el sistema, pero sin entrar en detalles de cómo se implementará en una plataforma software y hardware determinada. Por último, los modelos específicos de la plataforma («platform-specific models» o PSM) completan el resto de los detalles, para así simplificar la traducción final a código. OMG ha definido el metamodelo de nivel 2 Meta-Object Facility (MOF) Object Management Group [2003b] para especificar los metamodelos de nivel 1 CIM, PIM y PSM, y la especificación Query/View/Transformation (QVT) Object Management Group [2008] para describir transformaciones automatizadas entre ellos. A nivel práctico, dada la complejidad de MOF, se tiende a utilizar versiones simplificadas de dicha especificación, como la usada en la comunidad de desarrolladores Eclipse: Ecore Eclipse Foundation [2009b]. De forma parecida, en lugar de QVT, suelen usarse alternativas más limitadas pero maduras, como el ATLAS Transformation Language (ATL) Eclipse Foundation [2009a], un lenguaje similar a QVT. 2.3

16 Bibliografía Bibliografía J. Browne, I. Hunt, and J. Zhang. The Extended Enterprise (EE). In L. M. Camarinha-Matos, H. Afsarmanes, and V. Merik, editors, Intelligent Systems for Manufacturing: Multi-Agent Systems and Virtual Organizations, pages Kluwer Academic Publishers, Londres, Eclipse Foundation. ATLAS Transformation Language (ATL), 2009a. URL eclipse.org/m2m/atl/. Fecha de última comprobación: 2 de noviembre de Eclipse Foundation. Eclipse Modeling Framework, 2009b. URL modeling/emf/. Fecha de última comprobación: 2 de noviembre de Thomas Erl. SOA: Principles of Service Design. Prentice Hall, Indiana, EEUU, ISBN Object Management Group. MDA Guide version 1.0.1, June 2003a. URL org/mda/. Fecha de última comprobación: 2 de noviembre de Object Management Group. Meta-Object Facility (MOF) 2.0, June 2003b. URL http: // Fecha de última comprobación: 2 de noviembre de Object Management Group. Query/View/Transformation (QVT) 1.0, April URL Fecha de última comprobación: 2 de noviembre de A. Tharumarajah, A.J. Wells, and L. Nemes. Comparison of emerging manufacturing concepts. In Proceedings of the 1998 IEEE International Conference on Systems, Man, and Cybernetics, pages , California, EEUU,

17 3 Selección de una metodología SOA

18 3. Selección de una metodología SOA 3.1. Introducción Implementar una SOA es una labor compleja, ya que afecta a toda la organización. Sin una metodología apropiada, puede ser inabarcable incluso para empresas de fabricación de menor tamaño. Por ello, han surgido una serie de metodologías SOA dirigidas a controlar la complejidad de las tareas asociadas. Estas metodologías varían en gran medida entre sí, por lo que es necesario compararlas siguiendo criterios de completitud, capacidad de automatización y coste de ejecución, entre otros. Este capítulo se estructura de la siguiente forma: tras comparar algunas de las metodologías existentes, se selecciona una y se describe en mayor detalle. A continuación, se proponen una serie de extensiones para modelar los aspectos funcionales y no funcionales del comportamiento esperado del sistema Revisión de las metodologías existentes En esta sección se realizará una revisión de algunas de las metodologías disponibles para desarrollar sistemas de información basados en arquitecturas orientadas a servicios. La tabla 3.1 resume los resultados. Se descartan aquellas especificaciones y metodologías que sólo cubren pasos específicos del proceso de construcción del software, como Business Process Modeling Notation (BPMN) Object Management Group [2009a]. Esta especificación se ocupa únicamente de modelar los procesos de negocio, sin entrar en cómo se implementarán. De la misma forma, la metodología presentada por Engels Engels et al. [2008] sólo establece la lista de servicios a crear y operaciones a definir en cada uno a alto nivel, sin llegar a implementarlos. Su objetivo es establecer un «sistema ideal» que vaya consiguiéndose con el tiempo a medida que el existente en la organización va siendo renovado. Para ello, utiliza una serie de modelos intermedios con correspondencias manuales sobre varias fuentes de información, utilizando un abanico de fuentes de información. Esta metodología podría asistir a cualquiera de las opciones de esta sección Antecedentes en el desarrollo basado en componentes Ya se ha mencionado anteriormente que SOA no es una revolución, sino una evolución de las lecciones aprendidas en el campo de la Ingeniería del Software. Pueden establecerse varios paralelismos entre SOA y el paso conceptual inmediatamente anterior: desarrollo basado en componentes («component based development» o CBD). Existe una gran variedad de definiciones del concepto de «componente», pero en general puede decirse que un componente se trata de una «caja negra» con entidad propia de la que se sabe qué servicio provee, pero no cómo lo hace, y que puede ensamblarse con otros componentes. En muchos aspectos, la idea es similar a la de un servicio. La principal diferencia entre SOA y CBD es cómo se explota esa funcionalidad: con CBD, el componente pasa a formar parte inseparable del programa, mientras que con SOA sigue siendo un ente independiente, con el que se interacciona mediante mensajes. Además, un servicio de SOA ha de implementar una funcionalidad a nivel de negocio, mientras que un componente no tiene por qué, pudiendo ser algo más sencillo. 3.1

19 3. Selección de una metodología SOA Aprovechando estas similitudes, Stojanović Stojanović [2005] define una metodología originalmente dirigida a CBD, que posteriormente extiende al caso de SOA. Existen otras metodologías basadas en componentes más conocidas, como Kobra Atkinson et al. [2008] o Catalysis D Souza and Wills [1998], pero no tratan explícitamente el caso de SOA. Stojanović describe los conceptos a describir en cada modelo, pero no la notación exacta a utilizar: en su lugar, deja que el usuario elija de entre varias posibilidades. El proceso seguido por esta metodología puede resumirse de la siguiente forma: 1. Se modelan los procesos de negocio, el entorno y sus participantes en unos modelos del dominio del negocio («Business Domain Models» o BDM). 2. Se identifican los casos de uso a nivel de negocio que debería implementar el sistema, y se agrupan en un modelo de componentes del negocio («Business Component Model» o BCM). Un componente del negocio reúne casos de uso que manejan los mismos elementos del universo de discurso, cambian en unísono, emplean los mismos sistemas ya existentes o forman parte de una misma transacción. 3. Identifica las aplicaciones a utilizar para implementar cada uno de los componentes del negocio seleccionados, produciendo los modelos de componentes de aplicación («Application Component Models» o ACM). 4. Concreta los ACM anteriores pasando de productos software de alto nivel a las partes que los forman: bibliotecas desarrolladas externamente o internamente, lógica del negocio, etc. En este paso se crean los modelos de componentes de implementación («Implementation Component Models» o ICM). Los pasos son similares a la propuesta MDA del OMG: se modela el negocio, se crea un modelo del sistema de forma independiente de su implementación basado en agrupaciones de servicios y se consigue finalmente un modelo cercano a la implementación. La metodología no impone una notación particular, pero en su caso de estudio utiliza UML. Sin embargo, el paso de un modelo a otro es completamente manual, y no se establecen formalmente las correspondencias entre ellos Metodología IBM SOMA La metodología SOMA (Service Oriented Modeling and Architecture), desarrollada por IBM, define un enfoque integrado sobre el proceso de desarrollo SOA que cubre desde su concepción hasta su monitorización y mantenimiento Ghosh et al. [2008]. Consiste en un ciclo iterativo de refinamiento dividido en varias fases. En primer lugar, se define un modelo del negocio y una serie de plantillas para los distintos tipos de soluciones de integración posibles. A continuación se identifican los servicios que formarán parte de la arquitectura, combinando varias fuentes: las metas de la empresa, un modelo conceptual del entorno, y los sistemas informáticos ya implantados. Posteriormente se estructurarán, racionalizarán y especificarán todos los servicios especificados en una arquitectura coherente. Puede que se haya identificado un gran número de servicios, por lo que se seleccionará el subconjunto que reporte el mayor retorno en inversión y se pospondrá el resto. Finalmente, se implementarán, depurarán e implantarán los servicios, tras los cuales se someterán a monitorización. 3.2

20 3. Selección de una metodología SOA Tabla 3.1. Tabla comparativa de las metodologías SOA bajo estudio Metodología Alcance Basado en Notaciones Automatización Coste Stojanović SOMA SOD-M Análisis y diseño funcional Ciclo de vida completo Análisis y diseño funcional (ampliable si se integra con MIDAS) Componentes, para posteriormente convertir a servicios Clases esterotipadas UML, para posteriormente convertir a servicios Servicios, para posteriormente convertir a artefactos ejecutables A elegir, UML (ligero) Ninguna Medio Perfiles UML (completo) Diagramas de valor, perfiles UML (ligero) Generación código y de documentos Generación interfaces y modelos Alto Medio 3.3

21 3. Selección de una metodología SOA Sus mayores aportaciones se hallan en los aspectos de ingeniería de requisitos, en que combinan tres distintas técnicas de obtención de servicios para conseguir un catálogo más completo: El modelado meta-servicio («Goal-Service Modeling» o GSM) obtiene servicios estudiando las metas a nivel de negocio de la organización, y viendo cómo el sistema puede impulsar dichas metas y sus métricas asociadas. La descomposición del dominio consiste en tomar los distintos conceptos que se manejan en el universo de discurso del negocio y listar las distintas funcionalidades que puede ofrecer el sistema en relación con ellos. Por ejemplo, si se tiene el concepto de un pedido, el sistema podría crearlos, consultarlos, modificarlos, crear una factura para ellos, etc. El análisis de los recursos existentes consiste en tomar los sistemas que ya estén implantados y ver cómo se podría reutilizar parte de su funcionalidad en otros puntos de la organización. Muchos de estos sistemas ya existentes son demasiado críticos como para ser reemplazados de un día para otro. Los servicios obtenidos mediante estos métodos se estructuran en una jerarquía, sobre la que se aplica una prueba de paso («litmus test» en el original) personalizable para ver si realmente merece la pena incurrir en el coste adicional que supone exponerlo como servicio web. La metodología se halla implementada como una serie de extensiones al Proceso Unificado de Rational («Rational Unified Process» o RUP)), utiliza el estándar Lenguaje Unificado de Modelado («Unified Modeling Language» o UML) Object Management Group [2009b] con algunas extensiones para modelado. Aunque se ha validado a través de múltiples proyectos y se apoya sobre un proceso conocido, SOMA es una metodología compleja en la que se elaboran un gran número de documentos intermedios y se utilizan numerosas herramientas. Por ello, esta metodología puede no ser la mejor opción para empresas pequeñas y medianas de fabricación, con menos recursos para realizar este tipo de modelado extensivo. Una metodología más ligera sería más efectiva en estos casos Metodología SOD-M La metodología Service Oriented Development Method (SOD-M) de Castro [2007]; Vara Mesa et al. [2008], desarrollada por el grupo Kybele de la Universidad Rey Juan Carlos, es también dirigida por modelos y centrada en servicios. Cubre los tres puntos de vista del enfoque MDA del OMG con perspectivas sobre el negocio (nivel CIM) y sobre el sistema (niveles PIM y PSM). Puede verse un esquema de las relaciones entre los distintos modelos en la figura 3.1. La perspectiva del negocio incluye un modelo de la organización y su entorno especificado sobre los intercambios de valor entre las distintas partes de la organización Gordijn and Akkermans [2003], y un modelo de los procesos de negocio seguidos, utilizando diagramas UML de actividad. Estos diagramas son parecidos a los conocidos diagramas de flujo. La definición de la perspectiva del sistema (nivel PIM), por otro lado, comienza por establecer modelos de casos de uso del sistema de información, que después se integran y estructuran en modelos de procesos de servicio del sistema. Estos modelos se integran y estructuran en una serie de modelos de casos de uso extendidos, que después se concretarán a modelos de procesos de servicio del sistema. 3.4

22 3. Selección de una metodología SOA Figura 3.1. Esquema de los modelos utilizados en SOD-M Los modelos de procesos de servicio detallan las actividades necesarias para su realización y las relaciones con los demás procesos. Posteriormente, esas actividades se reparten entre los participantes en modelos de composición de servicio. Estos dos últimos tipos de modelos también usan diagramas de actividad de UML. Finalmente, en el nivel PSM de la perspectiva del sistema se decide en el modelo de composición de servicio extendido qué actividades de los modelos de composición de servicio extendido serán servicios web, y se definen sus interfaces. Esta metodología resulta ser más ligera que en el caso de SOMA, y algunas de las correspondencias entre los distintos modelos llegan a estar automatizadas parcialmente Vara Mesa et al. [2008], a diferencia de otros métodos, como el de Stojanović Stojanović [2005]. Utiliza notaciones más sencillas, facilitando la comunicación entre clientes y desarrolladores. Esta metodología es una buena candidata sobre la que basarse para definir una metodología completa para el desarrollo de sistemas de información orientados a servicios para empresas de fabricación distribuida. Pueden representarse de forma comprensible para las partes implicadas las prácticas actuales de negocio de la organización, y a partir de ellas descender hasta obtener un esqueleto de la SOA. Es cierto que, a diferencia de SOMA, no incluye todos los pasos del proceso de desarrollo, y en particular no integra actividades de realización de pruebas sobre el software. Sin embargo, estas carencias pueden cubrirse extendiendo SOD-M en lo estrictamente necesario, e integrándolo en metodologías de nivel superior, como es el caso de MIDAS Metodología base escogida: SOD-M En la anterior sección se seleccionó la metodología SOD-M, debido a que era capaz de modelar la SOA partiendo de la situación actual de la organización, al mismo tiempo que era suficientemente ligera como para aplicarse en organizaciones de menor tamaño. 3.5

23 3. Selección de una metodología SOA En esta sección se describirán en más detalle los pasos seguidos por dicha metodología, describiendo en paralelo los conceptos subyacentes y las notaciones utilizadas. Inspirándose en la propuesta MDA del OMG Object Management Group [2003], la metodología parte de unos modelos de alto nivel del negocio, y va bajando el nivel de abstracción hasta obtener unos modelos cercanos a la implementación final. Los modelos utilizados se encuentran en la figura Diagramas UML utilizados SOD-M define sus modelos basándose en el Lenguaje Unificado de Modelado («Unified Modeling Language» o UML) definido por el Object Management Group Object Management Group [2009b]. En particular, utiliza tres tipos de diagramas UML: diagramas de clases, diagramas de casos de uso y diagramas de actividad. En esta sección se expondrán los elementos de UML que SOD-M emplea de cada diagrama. SOD-M no considera todos los elementos definidos por UML, ya que se trata de una especificación considerablemente compleja. Estos diagramas UML son extendidos utilizando perfiles, que añaden nuevos estereotipos con los que pueden marcarse los nodos y enlaces de los diagramas para reflejar aspectos semánticos. Estas extensiones se describirán en apartados posteriores. Diagramas de clases Los diagramas de clases permiten representar los distintos elementos que se procesarán en el sistema, de acuerdo con el paradigma de la programación orientada a objetos. Una «clase» es un concepto abstracto que representa a toda una categoría de «objetos» que la instancian. Por ejemplo, el concepto abstracto Coche como «vehículo autopropulsado de cuatro ruedas» es una clase, y «ése coche» es un objeto de dicha clase. Los objetos de una clase tienen asociados ciertos campos con información acerca de ellos (conocidos como «atributos»), y pueden incorporar ciertos comportamientos (conocidos como «métodos»). Los atributos y métodos se definen a nivel de clase. Se dice que la clase A es subclase de una clase B cuando todos los objetos de A son también objetos de B. Es decir, los objetos de A son un tipo de los objetos de B. Volviendo al ejemplo anterior, Turismo sería una subclase de Coche, ya que todo Turismo es un Coche. Esta relación puede expresarse de otras formas: B es superclase de A, A hereda de B, B es padre de A, o A es hija de B. La ventaja de establecer estas relaciones es que las subclases heredan todos los atributos y métodos de sus superclases: por ejemplo, si Coche tuviera el atributo cilindrada, entonces Turismo también lo tendría. Existen varias formas de especificar las relaciones de herencia en UML, pero en estos diagramas consideraremos únicamente el tipo más común: herencia completa y disjunta. Es decir, no existen más subclases que las que indiquemos explícitamente, y un objeto sólo puede pertenecer a una subclase a la vez. Es decir, si sólo definimos las subclases Turismo y Monovolumen, entonces todo Coche será de uno y sólo uno de esos tipos. Así, no tendremos Deportivos. Puede que los objetos de una clase se relacionen con los objetos de otra clase. Un Coche tendrá una Persona que será su dueño (cardinalidad 1 en este extremo), y una Persona podrá ser dueño de ninguno o varios coches (cardinalidad cero o más). Cada clase juega un rol en dicha relación: aquí, Coche es una posesión, mientras que Persona es el dueño. 3.6