Objetos y reglas de negocios en la integracin y automatizacin de procesos de produccin continua

Isabel M. Besembel Universidad de Los Andes. GIDyC. Departamento de Computacin. Mrida. Venezuela. 5101. ibc@ing.ula.ve and Edgar Chacn Universidad de Los Andes. LaSDAI. Departamento de Computacin. Mrida. Venezuela. 5101. echacon@ing.ula.ve

ABSTRACT
Actually, the need of software integration used in all of the different enterprise levels is notably. The industry of continuous process (refineries, oil production, gas production, etc.) has some properties not considered in the manufacturing process integration models already proposed. It exists a real need for the automation of a Continuous Production Complex (CPC), to improve performance and to give straightforward responses to market requirements. Our modelling approach of considering CPC as a composition of elements, where each element may also be a composite, is our main work line in the Industrial Automation area. In this work, we propose an object class model that supports horizontal and vertical integration of the automation of CPCs, as generic production units. The heart of our model is an Application class which supports all of the software applications of a production unit. This class is related to two main classes named Business Objects and Business Rules, which both support all of the needed information to permit the integration of the aforementioned applications by using CORBA technology. Keywords: Automation, Business Objects, Business Rules, Systems Integration, Object-Oriented Systems.

RESUMEN
Actualmente es notable la necesidad de la integracin del software empleado en los mltiples niveles de una empresa para poder manejar sus procesos operacionales automatizados. La industria de procesos continuos (refineras, produccin de petrleo, de gas, de aguas tratadas, etc.) tiene caractersticas no consideradas en los modelos de integracin de procesos de manufactura. Hay una necesidad real para la automatizacin de los complejos de produccin continua (CPC) que mejore su ejecucin y poder as dar respuestas rpidas y adecuadas a los requerimientos del mercado. El enfoque de modelado donde los CPC se describen como una composicin de elementos, que a su vez son vistos como partes compuestas de componentes, es la columna principal de nuestro trabajo en el rea de Automatizacin Industrial. Enmarcado en esto, se presenta un modelo de clases de objetos que soportan una integracin horizontal y vertical en la automatizacin de los CPCs, vistos como unidades de produccin genricas. El corazn del modelo es la clase Aplicacin que soporta las aplicaciones de software de la unidad de produccin, que est relacionada con dos clases importantes denominadas Objetos de negocios y Reglas de negocios, que soportan toda la informacin necesaria para realizar la integracin de dichas aplicaciones utilizando CORBA. Palabras claves: Automatizacin Integrada, Objetos de negocios, Reglas de negocios, Complejos de Produccin Continua, Integracin de Sistemas, Sistemas Orientados a Objetos.

1.

INTRODUCCIN

La evolucin de los sistemas de produccin continua se ha centrado en mantener el proceso operativo, funcionando de modo seguro y no en la optimizacin del mismo (basada en sus relaciones con los otros elementos de un complejo productivo), ni en su integracin con los sistemas de gestin [3]. Hay una necesidad real para la automatizacin de los CPCs que mejore su ejecucin y poder as dar respuestas rpidas y adecuadas a los requerimientos del mercado. El modelado de los CPCs como una composicin de componentes, donde a su vez, cada componente es vista como una composicin de componentes anidadas, es a nuestro parecer, la manera ms simple y segura de desarrollar sistemas de automatizacin integrada [4]. Existen diferentes enfoques para integrar sistemas, entre ellos estn: el propuesto por OMG (Object Management Group) [15, 16, 17], el modelo GRAI [5], los modelos de la Universidad de Purdue (PERA) [18], PROSA [2], CIMOSA [11], etc. El modelo de clases de objetos presentado soporta una integracin horizontal y vertical en la automatizacin de los CPCs, vistos como unidades de produccin genricas que: poseen entradas, usan recursos, generan desperdicios, envan y reciben informacin y generan productos acordes con una misin, una capacidad de produccin, unas condiciones de infraestructura y una constante evaluacin de la evolucin de los procesos presentes en las mismas. Se resalta en este modelo, las posibles configuraciones de los recursos utilizados en el proceso de produccin de los productos en cuestin. Como resultado, este modelo de base de datos orientado por objetos se basa en las unidades de produccin genricas, en adelante UP, que tiene como centro el uso de una gran cantidad de aplicaciones de software para soportar los diferentes procesos presentes en dichas unidades, catalogadas como aplicaciones de: manejo de recursos, financieras y de toma de decisiones. El resto de este artculo est organizado como sigue: la seccin 2 presenta un resumen del rea de automatizacin integrada de procesos de produccin continua, la seccin 3 se dedica a presentar los principales conceptos sobre objetos y reglas de negocios, la seccin 4 muestra el modelo de clases de objetos basado en las unidades de produccin genricas y por ltimo, la seccin 5 incluye la discusin del alcance del modelo y las conclusiones de este trabajo. 2. AUTOMATIZACIN INTEGRAL DE PROCESOS DE PRODUCCIN CONTINUA

Actualmente es notable la necesidad de la integracin del software empleado en los mltiples niveles de una empresa para poder manejar los procesos operacionales, que incluyen tareas tales como: monitoreo de procesos, control regulatorio, ajuste de datos, optimizacin de unidades de produccin y plantas, diagnstico de fallas en procesos, control supervisorio, planificacin y plan de trabajo. Como antecedentes en la realizacin de integracin de sistemas surgen en el mercado diferentes metodologas como: CIMOSA de CIMOSA Association [11], GRAI-GREY de la Universidad de Burdeos [5] y el mo delo PERA de la Universidad de Purdue [18]. El modelo GRAI-GREY analiza y describe la estructura de toma de decisiones de un sistema productivo de manufactura y realiza una propuesta de integracin. El ms completo es CIMOSA, ya que describe la tecnologa disponible en cada nivel del modelo CIM (Computer Integrated Manufacturing) y las aplicaciones posibles [23]. Finalmente, PERA realiza una mezcla de los dos anteriores. En CIM cada UP est controlada localmente mediante la tecnologa adecuada y existe una centralizacin de la informacin de produccin, que permite gerenciar la produccin entre las unidades de arranque de procesos, basndose en el conocimiento que se tiene de las tareas cumplidas en cada UP. Esta operacin automtica se refleja en una reduccin de costos de operacin, de los tiempos y tamaos de los sistemas de almacenamiento y en un incremento de los niveles de produccin. Existen en el mercado paquetes computacionales como: SAP [20], MRP II (Manufacturing Resource Planning) [8] y PRM (Production Resource Manager) [19], que son capaces de fijar los parmetros ptimos de un proceso modelado de antemano. Para ello, los datos de entrada son extrados desde los equipos de control central como: SCADA (Supervisory Control And Data Adquisition) o D (Distributed Control System) y almacenados en una base de datos (BD) en CS tiempo real. Estos paquetes no son aprovechados cabalmente, ya que los datos de entrada asociados a los valores econmicos de los productos no estn disponibles en la planta, debido a la falta de integracin entre el ambiente de gestin y de produccin. La industria de procesos continuos, tales como: refineras, produccin de petrleo, de gas, de aguas tratadas, etc., tienen caractersticas no consideradas en los modelos anteriormente mencionados y por ello, no es posible su utilizacin. El modelo de referencia para lograr la automatizacin integral de procesos se denomina Modelo Referencial de Automatizacin Integral (MRAI) propuesto por J. Montilva et. al. en [12], el cual propone un mtodo para la elaboracin de planes estratgicos de automatizacin integral que permitan definir la estructura global integrada de informacin, gestin, comunicacin y control que requiere una empresa de produccin continua. MRAI tiene como base conceptual la arquitectura de referencia mostrada en la figura 1, que describe los elementos tecnolgicos y de gestin esenciales para alcanzar un alto nivel de integracin y automatizacin.

Estas cinco arquitecturas de la figura 1 descansan sobre el proceso productivo propiamente dicho, que se denomina proceso fsico. Su carcter piramidal se asocia a la estructura jerrquica de los procesos de toma de decisiones, la cual divide estos procesos en seis reas: en el nivel ms alto, llamado Estrategia la estructura operacional encargada de dar soluciones a los problemas de coordinacin de planificacin, presentados en casos como: consideraciones de plantas separadas geogrficamente en forma dispersa, en donde deben ser tomados en cuenta factores como costos y demoras en tiempo, asociadas con el transporte de intermediarios y productos entre las plantas y los consumidores finales; la distribucin geogrfica de los inventarios, y las especificaciones de capacidad y las capacidades individuales de los sitios de cada planta para poder asegurar una buena cantidad de suministros y tipos de productos. En el segundo y tercer nivel de la pirmide, denominados Planificacin y Plan de Trabajo, se encuentra la estructura operacional que tiene que ver con el plan de trabajo y la optimizacin de las funciones. Aqu las funciones se encargan de la optimizacin de las operaciones de planta, en los casos continuos y en los de asignaciones y planificacin de los recursos de la planta tomando en cuenta, a su vez, los casos en los que se requiere compartir los recursos de manufactura entre diferentes productos. Incluidos en este nivel deben manejarse los inventarios durante los procesos, planificacin de mantenimientos, y los anlisis de calidad y soporte de seguridad. El cuarto nivel est enfocado en el Monitoreo y diagnstico de los segmentos de los procesos entre los puntos de recoleccin de inventario durante los procesos, coordinacin de los encendidos y paradas de planta, y el manejo de los trastornos y las emergencias. Al nivel de Control regulatorio le concierne los reajustes locales, coordinacin entre las unidades y monitoreos de produccin y las operaciones de comparacin. En el nivel inferior, las funciones principales corresponden al control regulatorio y las unidades de monitoreo. Todo lo que se encuentra en este nivel debe trabajar a un tiempo real del proceso, en donde se realizarn los procesos de Adquisicin de datos y la informacin debe ser soportada de acuerdo a las necesidades del mismo proceso y de las variables que se estn tomando del proceso [12]. El modelo de este proceso captura los procesos bsicos de transformacin o produccin continua de productos, que convierten materia prima o productos semielaborados en productos semifinales o finales, respectivamente.

Estrategia Planificacin Plan de trabajo Monitoreo y diagnstico Control regulatorio Adquisicin de datos

Figura 1. Modelo Referencial de Automatizacin Integral (MRAI). Los procesos de toma de decisiones de la empresa, requeridos para realizar la gerencia del negocio a diferentes niveles jerrquicos, se modelan en la arquitectura central de la pirmide, denominada Arquitectura de Gestin. Las tecnologas que se emplean para transformar materia en productos se representan en la Arquitectura de Tecnologas de Produccin. Esta arquitectura est estrechamente ligada al proceso fsico, pues las actividades o funciones del proceso fsico son realizadas con el auxilio de estas tecnologas. La separacin entre el proceso fsico y sus tecnologas permite alcanzar un mayor grado de independencia tecnologa-proceso, la cual es fundamental en empresas cambiantes o en evolucin. Los elementos de datos, informacin y control, empleados por las dos arquitecturas ya mencionadas, se modelan a travs de las arquitecturas de objetos, de aplicaciones y de tecnologas de informacin y comunicaciones. La Arquitectura de Objetos representa los tipos de entidades del negocio que de una u otra forma participan en sus diferentes procesos. Los materiales, los productos, los proveedores, los clientes, los empleados, los equipos representan, entre otros, tipos de entidades que comnmente forman parte de un negocio de produccin continua. Esta arquitectura define las bases de datos y data warehouses requeridas por la empresa para soportar sus diferentes aplicaciones de software. La Arquitectura de Aplicaciones describe todas y cada una de las aplicaciones de software que integran el negocio y que son vitales para apoyar la ejecucin tanto del proceso fsico, como de los procesos de decisiones. La informacin requerida para llevar a cabo estos procesos la proporciona los componentes de esta arquitectura, la cual est estructurada en varios niveles de complejidad. El nivel ms alto de la arquitectura contempla cada uno los sistemas de informacin que posee el negocio y las relaciones que existen entre ellos. A un nivel intermedio se identifican las herramientas de

planificacin de recursos. En el nivel ms bajo se definen los paquetes de aplicaciones de propsito especfico, empleados para satisfacer necesidades muy particulares o concretas del negocio, tanto del proceso fsico (p.ej., controladores, analizadores y herramientas virtuales) como de los procesos de toma de decisiones (p.ej., procesadores de texto, paquetes grficos y hojas de clculo). La integracin entre estas aplicaciones, que normalmente son heterogneas, es tambin un aspecto muy importante que esta arquitectura toma en consideracin y es la que se desarrolla a lo largo del modelado y diseo del presente trabajo. Finalmente, la pirmide MRAI incluye, bajo la forma de arquitectura, todas las tecnologas de informacin y comunicacin sobre las que se implementan las arquitecturas de aplicaciones y objetos. Las redes de computadores, los equipos de computacin y el software de operacin y desarrollo son los componentes fundamentales de esta ltima arquitectura. Este modelo de referencia es diferente de otros modelos propuestos hasta ahora en la inclusin directa de los mecanismos de la toma de decisiones en los CPCs. Para soportar tal inclusin se hace necesario que dichos mecanismos sean modelados e implantados con algn elemento de modelado, en este caso los elementos que se usan son los objetos y las reglas de negocios, las cuales se describen a continuacin. 3. OBJETOS Y REGLAS DE NEGOCIOS

El enfoque de modelado de MRAI propone la utilizacin de una tecnologa emergente denominada Arquitectura de Objetos de negocios, que se basa en los conceptos de objetos y reglas de negocios. Un objeto de negocios es una abstraccin computacional que representa una entidad del mundo real. El uso de las cadenas de valor es la base para desarrollar modelos de las diferentes reglas de negocios que son especficas a la empresa. Una representacin grfica de las cadenas de valor puede verse en la figura 2.
Proceso 1 Proceso 2

...

Proceso i

...

Proceso N

Proceso i.1

...

Proceso i.j

...

Proceso i.m

Figura 2. Cadena de valor. Una cadena de valor expresa la secuencia de valor agregado a un producto a lo largo del proceso de produccin de dicho producto en un CPC. Objetos de Negocios Un objeto de negocios (ON) o business object es una representacin mental de elementos comnmente utilizados en un dominio particular del negocio y cubre elementos de diferentes tipos, tales como: Elementos f'sicos: Un producto, una planta, un empleado. Elementos de comunicacin: Orden de pago, facturas, una orden de produccin. Elementos de informacin: Capacidad de produccin, inventario. Muchas veces algunos ON poseen caractersticas que a su vez son propiedades de otro ON, como puede ocurrir en el caso de las tareas que debe cumplir un gerente y las labores que deben realizarse en una unidad de produccin. Los objetos de negocios estn en tres niveles diferentes: La capa del ON comn, que contiene objetos de negocios que son comunes a todas las empresas. La capa de los ON de la especificacin del ambiente, que contiene los ON agrupados por ambientes. La capa de especificaciones de las aplicaciones de l s ON, que contiene los ON que son especficos a la o aplicacin en desarrollo. Un ON, desde el punto de vista de computacin, es una coleccin de objetos de software, que representa las estructuras (atributos, relaciones, reglas) y el comportamiento de conceptos o cosas del mundo real que se manejan en un dominio particular de los negocios. Ellos difieren de otros objetos, tales como: ventanas, mens, barras de desplazamiento o fechas, en que stos son comunes o familiares para los usuarios en el dominio de los negocios. Segn la OMG [13, 15, 16, 17], la infraestructura requerida para apoyar objetos de negocios y desarrollar aplicaciones reutilizando los ON consiste de varias capas. Cada capa proporciona servicios a su capa superior inmediata. La capa ms baja es la capa de CORBA, proporcionando los servicios del inter-operabilidad requeridos para la comunicacin de varios objetos de negocios distribuidos [22]. La prxima capa es la de facilidades de objetos de negocios, tambin llamada mquina virtual del ON, que apoya la realizacin a tiempo de ejecucin de los objetos de negocios.

Un ON se transforma en cada fase del desarrollo, comenzando con el concepto del ON en el negocio y finalizando con un objeto de software. En cada fase del proceso de desarrollo, se agregan nuevas clases para apoyar al ON cuando evoluciona de un concepto a un objeto del software. En esta evolucin se incluyen: Clases del negocio, que se agregan durante el anlisis para capturar la semntica del concepto, ejemplo: las clases Persona, Compaa y Direccin que son complemento de la clase Cliente, en tanto que todo cliente del negocio es una persona o una compaa y ambos tienen direcciones. Clases utilitarias, agregadas durante la fase de diseo para tratar con los detalles de implementacin, por ejemplo: la clase de interfaz de usuario y objetos persistentes. Clases tcnicas, anexadas durante la implementacin para convertir el diseo en el cdigo ejecutable, escrito en un lenguaje de programacin orientado por objetos, como pueden ser las clases: Cadena, Fecha, Lista, Conjunto, etc. [13]. Todo lo anterior sirve para conformar un componente reutilizable, que es la aplicacin y el mecanismo de entrega de un ON. Para entregar un componente reutilizable y distribuido en tiempo de ejecucin, se necesitan los mecanismos siguientes: una clase de componentes de distribucin o el componente reutilizable un objeto reutilizable las facilidades de objeto de negocios. En ejecucin, el componente reutilizable es usado por las facilidades del objeto de negocios para crear tantos objetos reutilizables como sean requeridos por las aplicaciones. Los componentes reutilizables son objetos cuya estructura y comportamiento es descrito por su correspondiente componente reutilizable. Las facilidades del ON es la infraestructura tecnolgica que hace posible la utilizacin plug and play de los componentes reutilizables y hace posible tambin, la existencia de los objetos reutilizables. Los objetos de negocios se acceden como objetos especializados CORBA y sern accesibles en red a travs de un corredor de demanda de objetos o por sus siglas en ingls ORB (object request broker). Un determinado ON puede existir conceptualmente independiente del ambiente CORBA, los objetos de negocios pueden existir inicialmente en una base de datos del sistema y pueden ser activados en un ambiente CORBA. Por lo tanto, un ON se puede considerar que existe incluso si nunca ha estado instanciado como un objeto de CORBA. Dicha abstraccin hace que los objetos de negocios puedan ser instanciados en un ambiente computacional distribuido. Una referencia de objetos CORBA, identifica singularmente un ON activo dentro del ambiente de los objetos distribuidos para propsitos de comunicacin de demandas a travs de un ORB. La seccin que sigue describe caractersticas particulares de un ON en un ambiente computacional distribuido CORBA. Caractersticas de un Objeto de Negocios bajo CORBA Segn OMG en [15], un ON en CORBA es: Identificable Un ON tiene una nica identidad o clave que lo asocia c la entidad real que l representa en el dominio de los on negocios. Por ejemplo, los objetos de negocios pueden representar rdenes, clientes, departamentos, productos, fbricas, procedimientos o proyectos. Un objeto de negocios y la entidad que representa, tienen existencia e identidad nicas. Ellos pueden ser movidos y la operacin del movimiento mantiene la identidad nica del mismo. Ellos pueden tambin ser copiados, pero la copia debe tener una nueva identidad. Las implementaciones especficas pueden utilizar rplicas de los objetos de negocios (es decir, dos o ms objetos de CORBA para un mismo ON) con el fin de mejorar el rendimiento, pero ello es transparente para el que realiza el desarrollo del ON y para otros objetos de negocios, asegurando que solo hay uno definido. Transaccional En general, los objetos de negocios son accedidos en un contexto transaccional, ya que ellos son compartidos en un ambiente multiusuario distribuido donde debe existir un control de concurrencia basado en la seriabilidad transaccional, para mantener la integridad del modelo que ellos representan. Estas capacidades deben ser construidas dentro de los objetos de negocios, de modo que la persona que lo desarrolla solo se vea en la necesidad definir el principio y el final de las transacciones. Persistente La mayora de los objetos de negocios sern persistentes. La persistencia es necesaria para mantener el estado de los objetos cuando el sistema se cierra o falla. No se requiere la persistencia de todos los objetos de negocios, sino que, hablando en general, si tienen estado y representan la informacin actual sobre el negocio, sern persistentes. La

persistencia, junto con los mecanismos de actualizacin basados en transacciones, proporcionan la posibilidad de recuperacin, conocida como recuperabilidad del sistema. Las operaciones relacionadas con la persistencia pueden no ser visibles en las interfaces del ON. Descrito con Atributos Los objetos de negocios pueden tener atributos, que son los elementos o propiedades relevantes del objeto real que estn asociadas a los datos que proveen informacin acerca del ON. Los valores de los atributos no tienen identidad desde la perspectiva del negocio. Estos elementos sin identidad nica se llaman tipos dependientes porque su significado y persistencia dependen del ON en el cual ellos son valores de sus atributos. Los valores de los atributos sern accedidos con los mtodos get y set (mtodos que leen y escriben el valor, respectivamente), los cuales tendrn formas definidas. Estos mtodos estn relacionados con la funcionalidad propia del ON y los cambios de los valores de los atributos de un ON slo se pueden realizar con el uso de los mismos. La mayora de los atributos son atmicos, esto es, slo pueden almacenar un valor que ser pasado cuando ste sea solicitado o fijado. De vez en cuando, un atributo contendr una gran cantidad de valores que seran ineficaces de pasar como una secuencia o arreglo muy grande, stos atributos no son atmicos sino multivaluados donde los miembros pueden ser extrados individualmente o en secuencias de tamao limitado con un iterador. Especificado con Estados Un ON puede poseer diferentes estados definidos, mientras los estados y las transiciones de estados pueden ser parte de la especificacin del ON, las interfaces de los atributos de estado no poseen diferencia al compararlas con las de otros atributos, excepto por la particularidad de que los atributos de estado poseen como requerimiento valores enumerados. Asociable con otros ON Generalmente, un ON tendr relaciones con otros objetos de negocios, representando as las asociaciones de sus colegas del mundo real. Estas relaciones pueden ser uno a uno o uno a muchos, y a su vez pueden ser bidireccionales o en un solo sentido. Invocado con Operaciones El comportamiento de un ON se expresa mediante las operaciones asociadas al mismo, las cuales estn especificadas en su interfaz y que se desarrollan en un contexto transaccional. Notificado a travs de Eventos Los eventos asociados a un ON pueden ser de tres tipos: eventos internos que indican sus cambios de estado, eventos implcitos que ocurren cuando sus atributos o relaciones cambian o cuando sus operaciones son invocadas, y eventos programados que son generados pos la lgica del negocio. Todos ellos son notificados al ON mediante el pase de mensajes a travs de CORBA. Reglas de Negocios Toda aplicacin trata de reflejar parte del funcionamiento del mundo real, para automatizar tareas que de otro modo seran llevadas a cabo de modo ineficiente, o bien no podran realizarse. Para ello, es necesario que cada aplicacin, en principio, refleje las restricciones que existen en el negocio dado, de modo que nunca sea posible llevar a cabo acciones no vlidas. A las reglas que debe seguir la aplicacin para garantizar lo anterior, se las llama reglas de negocios (RN) o business rules. Una RN es una sentencia que indica como se hace el negocio, es una gua con restricciones de los estados y procesos de una organizacin [10]. Ejemplos de tales reglas son: no permitir crear facturas pertenecientes a clientes inexistentes, controlar que el saldo negativo de un cliente nunca sobrepase cierta cantidad, etc. En realidad, la informacin puede ser manipulada por muchos programas distintos, as una empresa puede tener un departamento de contabilidad que controle todo lo relacionado con compras, cobros, etc., y otro departamento tcnico, que est interesado en relacionar diversos parmetros de produccin con los costos. La visin que ambos departamentos tendrn de la informacin y sus necesidades ser distinta, pero en cualquier caso siempre se debern respetar las reglas de negocios. El hecho de que la informacin sea manipulada por diversos programas hace ms difcil garantizar que todos respetan las reglas, especialmente s las aplicaciones corren en diversas mquinas, bajo distintos sistemas i operativos y estn desarrolladas con distintos lenguajes y herramientas. Las RN tienen una estrecha relacin con las reglas definidas en Bases de Datos Activas [24], las cuales utilizan sus reglas para responder ante eventos que sucedan en el mundo real y que deben ser reflejados en la base de datos (BD). La estructura de dichas reglas es evento precondicin accin (EPA) [7], donde un evento es un suceso instantneo de inters para el negocio y asociado a un punto en el tiempo, una precondicin es aquella condicin que debe ser verificada antes de realizar la accin; y la accin define aquello que debe hacerse despus de verificar la precondicin.

Actualmente los Sistema de Gestin de Bases de Datos Relacionales (SGBDR) soportan reglas con disparadores o triggers, que son procedimientos que se ejecutan implcitamente cuando se invoca en la aplicacin una instruccin de insercin, eliminacin o actualizacin de datos en la BD (insert, delete, update del SQL). Estos disparadores incluyen instrucciones SQL que se ejecutan como una transaccin y que pueden invocar a su vez a otros procedimientos almacenados en la BD. Dependiendo del SGBDR, solo pueden ser definidos a nivel de las tablas o de las vistas modificables de la BD. Como ejemplo se incluye a continuacin un disparador en el SGBDR Oracle [24]: create trigger at after update or insert on Salario // Definicin del disparador sobre la tabla Salario declare tipo char(8); // que s e activar despus de una operacin de horas number; // actualizacin o insercin de tuplas o filas. begin if updating then tipo:=update; end if; if deleting then tipo:=`delete`; end if; if inserting then tipo:=`insert`; end if; horas := trunc((SYSDATE trunc(SYSDATE)*24); update tabEstado set contFila = contFila + estado.cont where tipoU = tipo and horaU = horas; if SQL%ROWCOUNT = 0 then insert into tabEstado values (tipo, estado.cont, horas); end if; exception when dup_val_on_index then update tabEstado set contFila = contFila + estado.cont where tipoU = tipo and horaU = horas; end; Ellos pueden definirse para efectuar su accin antes, despus de o en vez de la operacin que lo dispar. Tipos de Reglas de Negocios La clasificacin presentada a continuacin se basa en la realizada por P. Solivares en [21]. Reglas del Modelo de Datos El primer grupo de reglas de negocios engloba todas aquellas reglas que se encargan de controlar que la informacin bsica almacenada para cada atributo o propiedad de una entidad u objeto sea vlida: no hay precios de artculos negativos, el sexo de una persona solo puede ser masculino o femenino, una fecha siempre debe ser una fecha vlida, etc. Reglas de Relacin Otro grupo importante de reglas incluye todas aquellas reglas que controlan las relaciones entre los datos. Estas reglas especifican, por ejemplo, que todo pedido debe ser realizado por un cliente, y que el mismo debe atendido. Adems, una vez que un cliente haya hecho algn pedido, se deber garantizar que no es posible eliminarlo, a menos que previamente se eliminen todos sus pedidos. Reglas de Derivacin Es frecuente que a partir de cierta informacin se pueda derivar otra, este conjunto de reglas especifican y controlan la obtencin de informacin que se puede calcular a partir de la ya existente. Por ejemplo, el total de un pedido se puede calcular a partir de las distintas lneas que lo componen, mientras que el total de cada lnea se puede calcular a partir del nmero de unidades vendidas y el precio por unidad. Reglas de Restriccin Otro grupo de reglas de negocios es el compuesto por las reglas de restriccin, que restringen los datos que el sistema puede contener. Ntese que este grupo de reglas se solapa en cierto modo con las reglas del modelo de datos, dado que aquellas tambin impiden la introduccin de datos errneos, como se vio anteriormente. La diferencia estriba en que las reglas de restriccin restringen el valor de los atributos o propiedades de una entidad ms all de las restricciones bsicas que sobre las mismas existen: por ejemplo, para un saldo existe una regla bsica (regla del modelo de datos) que indica que ste debe ser un nmero (no por obvia es menos regla!). Adicionalmente puede haber una regla que indique que el

saldo nunca puede ser menor que cierta cantidad tope establecida para cierto tipo de clientes. Esta sera lo que aqu se denomina una regla de restriccin, y la diferencia fundamental se manifiesta en el hecho de que este tipo de reglas requiere para su verificacin del acceso a otros fragmentos de informacin, algo que no sucede con las reglas del modelo de datos. Reglas de Flujo Este grupo de reglas de negocios incluye aquellas reglas que determinan y limitan cmo fluye la informacin a travs de un sistema. Por ejemplo, un cliente puede hacer una peticin de anlisis a un laboratorio, que anota un encargado, hecho esto, se genera una orden para uno o ms analistas, estos realizan las mediciones correspondientes y devuelven las partes con la informacin pertinente, a partir de la cual se genera un informe de anlisis, que ser un anlisis vlido slo cuando sea firmado por los responsables de garantizar su correccin. Estas reglas indican qu camino recorre la informacin y obligan a que se sigan solo los caminos vlidos. Reglas de Decisin Hay otro grupo de reglas de negocios, que son las encargadas de representar las reglas para la toma de decisiones, las cuales determinan cuando, donde y quin debe realizar una tarea especifica. Las RN tambin pueden ser clasificadas segn su origen, como RN externas y RN internas, o segn su alcance, como RN intra unidades de negocios o RN inter unidades de negocios. Otra clasificacin relevante es la presentada por H. Herbst et. al. en [6], donde el parmetro de clasificacin es la complejidad de las componentes de la regla EPA, as se tiene que: Evento Simple La regla EPA tiene asociado un evento que puede ser: Relacionado con los Datos Cuando el disparo de la regla depende del estado o contenido de algn dato de la BD. Temporal Cuando el disparo de la regla depende de un da-hora especfico. Definidos por el Usuario Son aquellos eventos que no estn relacionados con los datos o con la fecha y son invocados explcitamente por alguna aplicacin o usuario. Evento Complejo Es una combinacin de eventos simples o complejos con propiedades adicionales y ellos pueden ser: Seleccin Tiene una combinacin de eventos simples relacionados con operadores lgicos, como por ejemplo: Si el producto X ha sido ordenado y la orden del producto ha sido recibida por el cliente. Secuencia Es la conjuncin de eventos que deben ocurrir en una determinada secuencia. Intervalos Temporales Ocurren entre dos eventos especficos, como por ejemplo: el cliente llama entre el envo de la oferta y 30 das despus del envo de la oferta. Peridicos Son aquellos que ocurren en intervalos fijos de tiempo, como por ejemplo: cada quince das o cada cinco rdenes de compra. Retardo Son aquellos que ocurren luego de un determinado periodo de tiempo en relacin a otro evento, por ejemplo: diez das despus de la aceptacin de la orden de compra.

Precondiciones Simples La precondicin puede ser: Comparacin del Valor de un Atributo con una Constante Por ejemplo: el estado de la orden sea 2. Comparacin entre Dos Valores de Atributos de Dos Objetos Por ejemplo: el total de la orden sea menor o igual al lmite de crdito del cliente. Uso de Operadores de Conjunto Por ejemplo: que exista un cliente asociado a la orden. Precondiciones Complejas Combinacin de varias condiciones con operadores lgicos. Acciones Dependientes de los Datos Estas fcilmente se desarrollan con las instrucciones de consulta, insercin, eliminacin o actualizacin del SGBD. Acciones de Envo de Mensajes Los problemas que se tienen a la hora de la implementacin son: (1) El nmero de disparadores por tabla es delimitado y variable (2) Ninguno puede manejar eventos sobre consultas y eventos temporales (3) Ninguno puede manejar todas las posibles RN Ejemplos de estas RN son: a. Revisar cada mes si existe una orden con fecha de hace ms de cinco aos atrs entonces elimine el pedido del cliente b. Sobre la eliminacin de un pedido de un cliente, si existe una orden asociada al cliente, entonces se niega la eliminacin y se enva el mensaje eliminacin no realizada por existir una orden asociada al cliente c. Sobre la eliminacin de un pedido de un cliente, si existe una orden asociada al cliente, entonces elimine todas las rdenes asociadas al cliente y elimine al cliente. d. Una RN de nivel superior sobre la insercin de una orden de compra en el sistema de compras, si se insert, entonces enviar la orden al sistema de pedidos. 4. MODELO DE CLASES DE OBJETOS

La representacin utilizada para mostrar el modelo est basada en el Lenguaje Unificado para el Modelado de Objetos, denominado UML [14], por sus siglas en ingls de Unified Modelling Language, propuesto por I. Jacobson, G. Booch y J. Rumbaugh en 1997 de la compaa Rational Software [9] que est asociada a OMG. UML soporta los principales conceptos de la Orientacin por Objetos permitiendo su extensin segn diversos mecanismos, en particular los utilizados en el modelo son los siguientes: Clases: Es el resultado de la agrupacin de un conjunto de objetos con estructura y comportamiento similar, esto es iguales atributos, relaciones, operaciones y semntica. En UML se representan con un rectngulo identificado con el nombre de la clase. Relaciones: Son las asociaciones que existen entre las clases, las cuales pueden ser de 5 tipos en UML, a saber: Generalizaciones (flechas), Asociaciones (lneas), Agregaciones (lnea con un rombo vaco), Composiciones (lnea con un rombo relleno) y Dependencias (flecha discontinua). Normalmente, ellas se identifican con un nombre y contienen en ambos lados los roles y cardinalidad de las relaciones entre los conjuntos de objetos agrupados por las clases. Interfaz: Clase que contiene la interfaz de una clase, representada en UML con un crculo vaco o con la representacin de una clase. Estereotipos: Palabras que agregan un significado semntico al diagrama y en UML se pueden asociar a las clases o relaciones y en particular, a cualquier elemento de modelado. Se representan encerrndolos entre los smbolos << >>. La figura 3 presenta el modelo inicial de una UP genrica, representada por la clase Unidad de Produccin, que est compuesta de otras UP indicado con la relacin usa, cuya composicin se puede configurar de diferentes formas, la

clase asociacin Configuracin de la UP representa est capacidad. Cada UP tiene su propia configuracin de los recursos que maneja, expresado a travs de la relacin utiliza que contiene la clase asociacin Configuracin con la clase Recurso. Las clases Empresa y Complejo de Produccin son subclases de la UP, ya que ellas se consideran UP tambin. De igual manera, las clases Personal, Materia prima, Servicio y Equipo, representan los tipos de recursos manejados por toda UP.
<<Associacin>> Configuracin <<Associacin>> Configuracin de la UP usa 1..* Unidad de Produccin utiliza * Recurso

Empresa

Complejo de Produccin

Personal

Materia Prima

Servicio

Equipo

Figura 3. Diagrama de clases inicial de una UP. El diagrama de clases inicial se extiende para indicar en ms detalle los objetos y relaciones presentes en una UP. La figura 4 muestra este diagrama de clases extendido, donde se considera una UP como un agregado de productos, capacidades de la UP y misiones de la UP, todos ellos agrupados en las clases Producto, Misin de la UP y Capacidad de la UP. Las relaciones entre estas clases representan el hecho que una UP produce productos, para alcanzar una misin de la UP, basndose en un conjunto de capacidades de produccin de la UP. Para los productos se pueden utilizar diferentes mtodos de produccin agrupados en la clase Mtodo de produccin, la cual est asociada con la clase Producto por la relacin de agregacin denominada producido con. La misin de una UP se evala para conocer que tan cerca est la UP de la misma, lo cual se mantiene en la clase Avance de la misin. Por otro lado se tiene una relacin de dependencia entre la capacidad de la UP y sus recursos. Los mtodos de produccin pueden ser variados segn una accin de control especfica, seleccionada de acuerdo a los estados posibles de la UP. Las clases Accin de control y Estado de la UP soportan el manejo de esta informacin. Finalmente, la clase Proceso contiene toda la informacin relevante sobre el mismo, el cual puede ser medido (sensar y observar) para obtener el estado del mismo, que es colocado en la clase Estado del proceso. Las otras clases han sido descritas en el prrafo anterior.
produce Unidad de produccin 1..1

1..* 1..* Producto alcanza 1..* Misin de la UP 1..* evaluacin producido con 1..* Mtodo de produccin 1..1 1..* sigue 1..1 Proceso 1..1 * medicin * utiliza 1..* Recurso * Estado del proceso control * Accin de control * 1..* * compone Estado de la UP tiene obtiene Capacidad de la UP

Avance de la misin

forma

<<Associacin>> Configuracin Personal Materia prima Servicio

1..* Equipo

Figura 4. Diagrama de clases extendido. Finalmente, se presenta el diagrama de clases para la integracin de la figura 5, donde cada UP tiene asociado un conjunto de aplicaciones de software heterogneas que apoyan su funcionamiento y que trabajan de manera independiente, donde la comunicacin entre ellas se realiza en forma manual o por i tercambio de archivos o de n dispositivos, lo que no garantiza consistencia y compatibilidad. El punto central de esta figura es la clase Aplicacin que se especializa en cuatro subclases, a saber: De toma de decisiones, Financiera, Manejo de recursos e Integradora. Esta ltima en particular es la ms importante, ya que ella soporta toda la informacin necesaria para la integracin de las aplicaciones presentes en una UP a travs de CORBA.

10

En especfico, la clase Objeto de negocios permite mantener en forma persistente aquellos ON que se generan y utilizan en las reglas de negocios, que estn soportadas en la clase Reglas de negocios. En este diagrama, las reglas de negocios son disparadas o accionadas por la aplicacin integradora que es una aplicacin muy especial capaz de soportar toda la lgica del negocio [1].
Reglas del negocio Objeto del negocio genera transmite * soporte tecnolgico 1..* Unidad de produccin * anida Financiera maneja 1..* Tecnologa * usa <<Associacin>> Configuracin 1..* utiliza * Recurso De toma de decisiones soporta 1..* Aplicacin 1..* Manejo de recursos 1..* Integradora 1..* dispara

Personal

Materia prima

Servicio

Equipo

Figura 5. Diagrama de clases para la integracin. 5. CONCLUSIONES

La integracin de las aplicaciones de control y gestin de produccin se ha convertido en una necesidad ineludible en la mayora de las empresas de produccin. Debido principalmente a la automatizacin del intercambio de informacin entre las computadoras, se ha tornado necesario dotar a estas con un marco o ambiente, que no solo les permitan intercambiar datos e informacin, sino tambin les permitan de una manera aproximada, comprender los contenidos intercambiados, tomar decisiones y finalmente formar una red cooperativa de entidades inteligentes. Con este trabajo se ha podido mostrar la necesidad y factibilidad de la realizacin de un sistema integrado de aplicaciones de una UP, el cual ha sido modelado con tcnicas orientadas por objetos, lo que ha permitido plasmar de una forma adecuada y concisa la semntica presente entre los objetos que conforman una UP. Tambin se ha mostrado que la visin de UP genrica es vlida y til en el proceso de conocer y modelar los CPC. Los modelos presentados bajo el ttulo de diagramas de clases han sido llevados a la prctica a travs de un prototipo de experimentacin, que ha mostrado la validez y viabilidad de nuestro enfoque. El desarrollo de sistemas de informacin de negocios es un proceso complejo que envuelve no solamente aplicaciones de informacin modernas y tecnologas de telecomunicaciones, adems es importante un buen conocimiento de las aplicaciones del dominio de dicha organizacin. Como nuestra prxima lnea de accin a seguir se tiene los sistemas basados en agentes, que como su nombre lo sugiere, estn compuestos por un conjunto de agentes individuales, los cuales constituyen entidades que interactan y realizan tareas en forma cooperativa. Dicha capacidad de interaccin entre agentes, se torna una de las cuestiones ms fascinantes y atractivas dentro de este nuevo marco. AGRADECIMIENTO Este trabajo ha sido realizado dentro del marco del proyecto CONICITN G-97000824. Venezuela. REFERENCIAS 1. 2. 3. 4. Agentes, software conversando y razonando?. http://www.informador.com.mx/ informa/25in08a.htm. Septiembre 2000. H. Brusel, J. Wyns, P. Valckenaers, L. Bongaerts y P. Peeters. Reference architecture for holonic manufacturing systems: PROSA. Computer in Industry. Vol. 37. 1998. pp. 255-274. E. Chacn. Automatizacin Integral de Sistemas de Produccin Continuos: Tecnologas de Integracin y Automatizacin. Reporte tcnico de la Universidad de Los Andes. Mrida. Venezuela. Diciembre, 1998. E. Chacn, I. Besembel, F. Narciso, J. Montilva y E. Colina. An Integration Architecture for the Automation of Continuous Production Complexes. ISA Transactions. Elsevier. (aceptado para su publicacin). 2000.

11

5. 6.

7. 8.

9. 10.

11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.

G. Doumeingts, B. Vallespir, M. Zanettin y D. Chen. Cim grai integrated methodology, a methodology for designing cim systems. Reporte tcnico de la Universidad de Bordeaux, Francia. Mayo. 1992. H. Herbst, G. Kolmayer, T. Myrach y M. Schlesinger. The specification of business rules: a comparison of selected methodologies. Methods and associated tools for the information systems life cycle. Actas de IFIP WG8.1. A. A. Verrijn-Stuart y T. W. Olle (Eds.). Elsevier. 1994. pp. 29-46. L. Hsu y R. Obe. Business rules and object orientation. http://www.paragoncorporation.com/papers/SACM-96-2820.htm. 1996. International Product Data Management Users Group. Integrating/Interfacing PDM (Product Data Management) with MRP II (Manufacturing Resource Planning). http://www.pdmic.com/IPDMUG/ wpipdmug.html - model. 1996. I. Jacobson, G. Booch y J. Rumbaugh. Specification of the UML. Rational Software. http://www.rational.com/uml/ G. Kolmayer, H. Herbst y M. Schlesinger. Enforcing business rules by the applications trigger concepts. Methods and associated tools for the information systems life cycle. Actas de IFIP WG8.1. A. A. Verrijn-Stuart y T. W. Olle (Eds.). Elsevier. 1994. pp. 29-46. K. Kosanke, F. Vernadat y M. Zelm. CIMOSA: Enterprise engineering and integration. Computer in Industry. Vol. 40. Elsevier Science. 1999. pp. 83-97. J. Montilva, E. Chacn y E. Colina. METAS: Un mtodo para la automatizacin integrada en sistemas de produccin continua. . Actas de las IV Jornadas Panamericanas de Automatizacin. Caracas. Mayo 2000. J. Montilva. Software Design Methods. Unit 5: Business Objects. University of South Florida. http://www.csee.edu/~montilva/cis4930/cis4930.html. Abril 2000. A. Muller. Modelado de Objetos con UML. Eyrolles y Ediciones Gestin 2000, S. A., 1997. OMG Business Object Domain Task Force. Business Object Concepts. OMG Document: bom/99-01-01. http://www.omg.org/ OMG Business Object Domain Task Force. Business Object Architecture Interoperability Specification. OMG Document: bom/97-10-04 OMG Business Object Domain Task Force. Business Object Definition for C4I. Abril 1999. PERA. Pera reference model for cim. ISA publication. http://www.pera.net PRM. Production Resource Manager. IBM. Last Update april 1996. http://www.research.ibm.com/ pdtr/prm.html SAP. P. A. Solivares. Desarrollo Cliente/Servidor: Ubicacin de las reglas de negocio. Revista Profesional para Programadores (RPP). 1997. J. Sutherland. The Emergence of a Business Object Component Arquitecture. OOPSLA Workshops on Business Object Component Design and Implementation. http://www.jeffsutherland.org/. Agosto 1999. T. J. Williams. A Reference Model For Computer Integrated Manufacturing (CIM). International Purdue Works. C. Zaniolo, S. Ceri, C. Faloutsos, R. Snodgrass, V. Subrahmanian y R. Zicari. Advanced database systems. Morgan Kaufmann Pub. 1997.

12