En anteriores ocasiones hemos hablado en este blog de la importancia de la simulación en los entornos industriales y del estándar HLA (IEEE 1516), que permite integrar simulaciones distribuidas de manera que puedan cooperar en una federación y funcionar como una simulación única.
Hoy en día existen multitud de implementaciones del estándar IEEE1516. Las implementaciones del estándar HLA se suelen componer de un RTI (Run Time Infrastructure)y de sus interfaces de acceso, basados en unas librerías que dan soporte a uno o varios lenguajes de programación. Es inevitable pensar que la implementación elegida va a imponer los lenguajes de desarrollo de los simuladores e incluso, para algunos casos, las plataformas sobre las que pueden funcionar.
Cada organización, para desarrollar sus simuladores utiliza una RTI ya desarrollada o crea la suya propia. Aunque la mayoría de ellas siguen el estándar, IEEE1516 lo que debería asegurar que fueran interoperables, se trata de un estándar muy complejo que todavía no está del todo maduro y presenta algunas ambigüedades. Las diferentes interpretaciones en el desarrollo de las RTI existentes, han generado problemas de compatibilidad entre ellas. Es por ese motivo que grupos de trabajo de organizaciones como SISO han estudiado cómo hacer converger estas diferentes implementaciones para encontrar una verdadera interoperabilidad. Y aquí es donde están cobrando verdadera importancia los modelos de interoperabilidad o IRM (Interoperability Reference Model).
En la definición de estos modelos el sector industrial lleva ventaja, ya que ha propuesto el primer estándar acerca de cómo utlilizar el estándar (parece un trabalenguas, pero es así) . SISO CSPI PDG especifica con cuatro IRM cómo se debe utilizar HLA en los entornos de interoperabilidad típicos en simulación industrial.
Os dejo un enlace a la web de SISO para que podáis profundizar en estos temas:
http://www.sisostds.org/index.phpaa
3. El swimlane (canal) es un concepto adoptado por muchas metodologías de modelado de procesos y es utilizado como mecanismo para organizar actividades en categorías separadas visualmente, de
manera que ilustre diferentes capacidades funcionales o responsabilidades.
Dentro de BPMN se definen dos tipos principales de swimlane:
- Pool: Representa un participante (persona, departamento, área) que interviene en un proceso. Además actúa como un contenedor gráfico para fragmentar un conjunto de actividades y diferenciarlo de otros pools.
- Lane: Es una subpartición dentro de un pool y extiende la longitud del pool vertical u horizontalmente. Los lanes se usan para organizar y categorizar actividades.
4. Por último los artefactos diseñados dentro de BPMN permiten a los modeladores extender la notación básica hasta ahora explicada. La versión actual de la especificación de BPMN sólo tiene tres tipos de artefactos BPD predefinidos:
- Data Object: Su representación gráfica es un rectángulo con el ángulo superior derecho doblado. Representan los datos que son requeridos o producidos por las actividades. Están conectados a las actividades a través de asociaciones. Un Data Object es lo que normalmente se define como entrada o salida de un proceso.
- Group: Su representación gráfica es un rectángulo redondeado con linea discontinua. Se utiliza para agrupar actividades y clarificar el diseño del proceso, pero no afecta al flujo de secuencia.
- Annotation: Las anotaciones son mecanismos que permiten que el diseñador del proceso incorpore información adicional acerca de cualquier elemento que se encuentre formando parte de un BPD.
En BPMN se definen Business Process Diagrams (BPD). Un BPD está formado por un conjunto de elementos gráficos que facilitan el desarrollo de diagramas de flujos de procesos.
Estos elementos gráficos están categorizados de la siguiente manera:
- Objetos de flujo.
- Objetos conectores.
- Swimlanes.
- Artefactos.
1. Dentro de los objetos de flujo existen tres elementos que definen el comportamiento del proceso de negocio:
- Evento: Su representación gráfica es un círculo. Representa una determinada acción que se produce durante la ejecución del proceso de negocio. Los eventos suelen tener asociados causas (trigger) o impactos (resultados). Se definen tres tipos de eventos dependiendo de cuándo estos afectan al flujo de proceso: Start, Intermediate y End.
- Actividad: Una actividad es un término genérico que describe acciones que se ejecutan en una organización. Un ejemplo de actividad sería "Enviar hoja de gastos a administración". BPMN define tres tipos de actividades: Process y Sub-Process, de carácter no atómico, y Tasks, de carácter atómico. Los objetos Process (proceso) no están delimitados por ninguna figura geométrica, ya que un proceso no se representa con una figura específica, sino como un conjunto de objetos que normalmente se agrupan dentro de un Pool. Un Sub-Process (sub-proceso), se define como una actividad compuesta por una secuencia o flujo de otras actividades. Un sub-proceso forma parte de un proceso, pero éste a su vez puede ser contemplado como un proceso en sí. La representación gráfica asociada es un un rectángulo redondeado, pudiendo estar visible en el proceso principal (expandido) o pudiendo estar colapsado, en cuyo caso, se indica con un símbolo (+) que puede desplegarse. Y por último un objeto Task (tarea) se trata de una actividad atómica e indica las tareas específicas (a bajo nivel) que son realizadas de forma manual (por personas) o de forma automática (por sistemas) para ejecutar un determinado proceso. Surepresentación gráfica es también un rectángulo redondeado.
- Gateway: Su representación gráfica es un diamante o rombo, y se utiliza para controlar la divergencia o convergencia de la secuencia de flujo. Con este elemento se modelizan las decisiones y permite crear nuevos caminos de flujo del proceso.
2. Los objetos conectores son los encargados de unir diferentes objetos de flujo, es decir, relacionar distintos eventos y actividades, creando el esqueleto básico de la estructura de un proceso de negocio. Se describen tres objetos conectores que hacen esta función.
- Sequence Flow: Su representación gráfica es una linea sólida con una cabeza de flecha sólida y se usa para mostrar el orden (la secuencia) en el que las diferentes actividades se ejecutan en el proceso. Si es la secuencia por defecto, la línea sólida lo indica con una pequeña línea cruzada en diagonal sobre ella.
- Message Flow: Su representación gráfica es una línea discontinua con una punta de flecha hueca y se usa para mostrar el flujo de mensajes entre dos participantes del proceso separados (entidades de negocio o roles de negocio). Dentro de BPMN es el objeto conector que une dos Pools.
- Association: Su representación gráfica es una línea de puntos y se usa para asociar datos, texto, y otros artefactos con los objetos de flujo. Las asociaciones se usan para mostrar entradas y salidas de las actividades.
Redindustria os recomienda que visitéis el blog de la Consultora Logística LRM. Podéis acceder a él en la dirección http://www.lrmconsultorialogistica.es/blog.html.Este blog incluye artículos relacionados con el sector de la logística integral y la gestión de proyecto logísticos y podréis encontrar entradas relacionadas con Supply Chain Management, compras y aprovisionamiento, producción, almacén, transportes y distribución.
Una vez comprendida la finalidad de los patrones SOA en la entrada anterior, dedicaremos ésta a explicar brevemente las etapas que se deberían seguir para completar un proyecto SOA con éxito:- Escoger el modelo de referencia SOA. Se debe elegir un modelo, independiente de la tecnología, que defina los conceptos y el vocabulario básico para el proyecto. Determinadas organizaciones con experiencia en proyectos SOA definen modelos sencillos basados en su propio glosario de términos y conceptos, aunque existe un modelo de referencia estándar, OASIS (del que hablaremos en alguna entrada futura).
- Escoger el entorno de desarrollo. Principalmente, decidir entre .NET o un entorno Java.
- Proponer una arquitectura de referencia SOA. Esta arquitectura identifica los servicios necesarios en la organización, muestra como interactúan estos servicios con los usuarios de negocio, y su relación con los procesos de negocio y los sistemas de información. Depende de la infraestructura tecnológica escogida para el proyecto, pero es reutilizable de unos proyectos a otros.
- Identificar patrones SOA adecuados. Ya que su utilización facilita enormemente la siguiente etapa de esta metodología y permite aprovechar el conocimiento de otras organizaciones, empresas, etc, en experiencias previas.
- Implementar una instancia concreta de la arquitectura de referencia. Esta etapa ya es específica para cada proyecto, y supone desarrollar con la plataforma tecnológica escogida los servicios de la arquitectura de referencia propuesta. Tras completar estas etapas sólo faltaría desplegar los servicios, ejecutarlos y monitorizarlos. Y realizar una mejora continua de la arquitectura desplegada en función de los resultados obtenidos con esta monitorización.
De la misma manera que los patrones EAI han facilitado mucho en los últimos años la integración de sistemas mediante la utilización de middleware de tipo MOM, (ya hemos dedicado a ellos varias entradas), se han identificado patrones SOA que permiten la reutilización de conocimiento y la propuesta de mejores prácticas en la realización de proyectos SOA.
Estos patrones no están ligados a ninguna tecnología en concreto, ni tampoco a ningún sector de negocio específico. Al igual que los patrones EAI, simplemente intentan estandarizar las técnicas de diseño que ayudan a superar los obstáculos más frecuentes que aparecen durante la realización de un proyecto SOA.
Los 90 patrones SOA que se han documentado hasta el momento se pueden dividir en tres categorías
dependiendo del nivel de diseño en el que se centren: Arquitectura del Inventario de Servicios, Arquitectura de Composición de Servicios y Arquitectura de Servicio.
Y algo muy importante que se debe tener en cuenta es que la aplicación de estos patrones no es una cuestión todo-o-nada, sino que se puede utilizar un determinado patrón como referencia inicial aunque en algún momento determinado del diseño sea necesario tener las particularidades específicas del proyecto, que quizás no encajen del todo con el patrón estándar. Los propios patrones van evolucionando con el tiempo gracias a las contribuciones de desarrolladores e investigadores en el área.
Aquí tenéis un enlace interesante si queréis profundizar en el tema:
http://soapatterns.org/
