Documento de trabajo # 677

Solucin al condicionante de arquitectura Extensibilidad

Bogot, mayo 1 , !"1"

#istoria de re$isin
%ersin 1.0 1.1 1.2 1.) 1.$ &ec'a 15/5/2010 17/5/2010 01/0%/2010 1$/0*/2010 $/0#/2010 (utor lvaro Lpez Hermes Puentes Vladimir Lpez lvaro Lpez lvaro Lpez Descri)cin Versin inicial Adicin utilizacin !"0#$ "evisin en &eneral ' se a&re& la seccin de (El
motor de reglas dentro del sistema de gestin documental Orfeo.

!e incorporaron notas de !!P+ !e incorporaron notas de !!P+

*(B+( DE ,-.*E./D1.1 Extensibilidad................................................................................................................................................4 1.1.1 Extensibilidad de la estructura................................................................................................................4 1.1.2 Extensibilidad del comportamiento.........................................................................................................4 1.1.3 Solucin al condicionante de extensibilidad de la estructura..................................................................7 1.1.4 Solucin al condicionante de extensibilidad del comportamiento..........................................................9 1.1.5 El Estndar JSR 94.................................................................................................................................9 1.1.! "Rools como motor de re#las de ne#ocio............................................................................................1 1.1.7 $otas adicionales...................................................................................................................................11 1.1.% El motor de re#las dentro del sistema de #estin documental &r'eo....................................................12

Extensibilidad

101

Extensibilidad

Extensibilidad se define como la capacidad del sistema de modificar la estructura de los objetos existentes y adicionar acciones o reglas de comportamiento sin tener que realizar modificaciones al cdigo fuente de la aplicacin. Formalmente el condicionante se expresa de la siguiente forma 10101 Extensibilidad de la estructura
,om)onente Arte,acto de so,t-are /uente de est0mulo .st0mulo Am2iente de tra2a3o "espuesta .ntidades de ne&ocio 1n&eniero especializado 1n&eniero desea modi,icar la estructura de al&unos de los componentes del sistema. +esarrollo4 Prue2as4 Produccin .l in&eniero puede modi,icar ciertas caracter0sticas de la estructura de los componentes sin a,ectar el ,uncionamiento normal del sistema. 11 .l sistema permite al in&eniero modi,icar las caracter0sticas de la estructura de 6r,eo en ,orma 7&il4 modi,icando a su vez los casos de uso correspondientes4 utilizando los tiempos de respuesta esta2lecidos para el mantenimiento del sistema. .l cdi&o resultante 8ace uso de la veri,icacin de tipos 9ue provee el compilador. .l cdi&o resultante 8ace uso de la proteccin de tipos 9ue provee el mane3ador de 2ase de datos. .l desempe:o del sistema resultante de la e;tensin es compara2le con a9uel antes de la e;tensin. .l mantenimiento del sistema resultante cumple con el condicionante de 5anteni2ilidad. De1inicin

5edicin de la respuesta

11 11 11 11

1010!

Extensibilidad del com)ortamiento

,om)onente Arte,acto de so,t-are /uente de est0mulo .st0mulo Am2iente de tra2a3o "espuesta .ntidades de ne&ocio 1n&eniero especializado

De1inicin

1n&eniero desea modi,icar cierto comportamiento selecto de al&unos de los componentes del sistema. +esarrollo4 Prue2as4 Produccin .l in&eniero puede modi,icar ciertas caracter0sticas del comportamiento de 6r,eo sin tener 9ue modi,icar directamente el cdi&o ,uente. 1. .l sistema permite al in&eniero modi,icar el comportamiento de 6r,eo en ,orma 7&il4 sin tener 9ue modi,icar directamente el cdi&o ,uente. .l cdi&o resultante 8ace uso de la veri,icacin de tipos 9ue provee el compilador. .l cdi&o resultante 8ace uso de la proteccin de tipos 9ue provee el mane3ador de 2ase de datos. .l desempe:o del sistema resultante de la e;tensin es compara2le con a9uel antes de la e;tensin. .l mantenimiento del sistema resultante cumple con el condicionante de 5anteni2ilidad.

5edicin de la respuesta

2. 3. 4. 5.

Puesto que la extensibilidad est considerada en funcin del negocio, para acomodar la variedad de reglas de negocio de una nueva instalaci n, o un cambio en el funcionamiento de una existente, las entidades consideradas extensibles parten del modelo de clases del dominio de la aplicaci n. No se consideran extensibles aquellas clases introducidas por el ingeniero durante su proceso de dise o y optimizacin, pero que son desconocidas por un usuario final. Tampoco se considera la creaci n de nuevas clases por medio del mecanismo de extensibilidad. La extensibilidad es una funcin de ingeniera. No se pretende que un usuario sin capacidad de programacin implemente conceptos de extensibilidad, dado que tiene que trabajar con tipos de datos, persistencia, presentaci n, y expresin de reglas que pueden tener conceptos como decisiones, iteraciones o secuencia. Para aquellas clases afectadas del modelo de dominio de la aplicaci n, el sistema debe guardar la versin de la estructura hasta la fecha de modificaci n, debe introducir una nueva versin que contiene los nuevos atributos, habilitar la persistencia de la nueva versin de la entidad, actualizar su visualizacin, si es aplicable, y permitir utilizar la nueva versin la siguiente vez que se compile el sistema.

Un usuario normal no se da cuenta de la operacin de la extensibilidad. Desde su punto de vista, si consulta una versin antigua de la entidad afectada, el sistema le presenta la estructura correcta a la fecha de la versi n con las reglas de negocio como eran en esa poca, sin tener que proveer ningn tipo de informacin adicional ( e.g. cdigo de versin). Si utiliza una nueva versin tiene un comportamiento similar, sin que el usuario se percate de que existen mltiples versiones para la misma entidad. El sistema debe manejar la estructura cambiante de la base de datos en forma transparente. Existen conceptualmente tres tipos de campos en una entidad de negocio La llave de persistencia La llave de negocio Los dems campos

La llave de persistencia es la llave primaria de la tabla correspondiente a la entidad en la base de datos. Esta es normalmente un nmero secuencial y no se considera extensible. La llave de negocio es el identificador nico de la entidad dentro del dominio del negocio. Por ejemplo, para un documento puede ser su radicado, para una serie puede ser su cdigo, para una persona puede ser su cdula de ciudadana, etc. La llave de negocio no se considera extensible. Los dems atributos que definen una entidad se consideran extensibles. Un conjunto selecto de las entidades relacionadas en el modelo de dominio son candidatas a ser extensibles. El hecho de que una entidad del dominio pueda extender su estructura no quiere decir que se deba abusar de esta posibilidad, sobre todo cuando se espera que el sistema Orfeo pueda ser utilizado por mltiples entidades. La tentacin de colocar en cada entidad de negocio todos los atributos que se considera que se puedan necesitar para la implantacin del sistema en SuperServicios y en otras entidades tiene varios efectos negativos:

Por una parte, es inevitable que todos los atributos se reflejen en las interfaces de usuario definidas, pues de otra forma no sera posible diligenciarlos. Esto complicar enormemente el diseo y construccin de la interfaz de usuario. Por otra parte, ninguna entidad puede diligenciar la totalidad de campos concebidos para hacer al sistema tan genrico. Por ltimo, si se disea la totalidad del sistema con base en un registro de metadatos, su esfuerzo y tiempo de desarrollo ser an incompatibles con el presupuesto asignado y las restricciones de tiempo impuestas contractualmente. Adems, se perderan las verificaciones de tipo realizadas por el compilador, y las restricciones de integridad referencial realizadas por el motor de base de datos, y las restricciones y l gica intrnseca de cada atributo tendra que ser programadas por un mecanismo tal como JSR094.

El sistema resultante de una adaptacin con base en metadatos tendra una enorme complejidad de mantenimiento, un pobre desempeo, y una fragilidad natural. Por lo dems, al observar el resultado logrado no sera para nada superior a una adaptacin del cdigo fuente para incluir los atributos deseados, incluir la l gica de negocio asociada, y representar los atributos en la base de datos. Por esta razn, se recomienda de la forma ms insistente que no se pretenda generalizar la utilizacin del sistema Orfeo con base en la definicin de mltiples atributos, sino que se generalice con base en la adaptaci n del comportamiento. La extensin de las clases y los atributos del sistema se debe realizar modificando el cdigo fuente de la aplicacin, y no con base en un registro de metadatos. Para facilitar la extensin de atributos del sistema, la arquitectura provee una clara segmentacin de responsabilidades, concentrada en el componente de entidades de negocio del modelo, y en el diseo de la vista. Se ha procurado en lo posible, que los controladores ( del modelo Vista-Controlador-Modelo) deban ser modificados en forma mnima con un cambio en los atributos del sistema, tal como se describe en la siguiente seccin. 10102 Solucin al condicionante de extensibilidad de la estructura La adaptacin de la estructura requiere que el sistema haya sido desde un comienzo diseado para ser adaptado, transformando el problema a un problema de administracin. El mecanismo opera de la siguiente forma:

1. Toda entidad del modelo de negocios a ser extendida (su EJB) implementa una interfaz que contiene un solo mtodo esValido(), que determina si la entidad es consistente. 2. Cuando se desea realizar una extensin, se crea una nueva entidad correspondiente en su EJB, y se adicionan, modifican o suprimen los campos requeridos, y se actualiza el mtodo esValido() correspondiente a la entidad a extender. 3. Se actualiza la definicin de la base de datos, y se reformatea su contenido utilizando los utilitarios disponibles en el Framework Seam. 4. Se implementa una fbrica de entidades, que entrega el objeto de la entidad correcto, dependiendo de la fecha de vigencia de la entidad, o de su n mero de versin. La fachada del modelo ( modelo MVC) solo se modifica si el cambio en la estructura cambia las reglas de negocio de algunos casos de uso. 5. Los controladores ( controlador MVC) de los casos de uso afectados por el cambio de estructura deben ajustarse para apoyar la modificaci n correspondiente en la vista (vista MVC). 6. El diseo de vista debe ajustarse para reflejar los cambios realizados a la(s) entidades afectadas. Esto aplica tanto para los controladores GUI, como para los controladores de web services, como para los controladores de migraci n. Ntese que para tener agilidad en la modificacin de la estructura de la aplicacin es necesario conocer cules son las entidades del modelo de dominio que son ms susceptibles de ser actualizadas, pues para estas entidades se requiere implantar todo el mecanismo de interfaces, fbricas, y versiones que permita modificar la estructura sin problema. An si en un principio no se conocen cules entidades del modelo de dominio son las ms susceptibles de ser modificadas, si fuese necesario modificar la estructura puede implantarse el mecanismo descrito para implantar una solucin gil al problema. En resumen, la extensibilidad de la estructura debe afrontarse como un problema de mantenimiento del software, en donde los programas fuente siempre se ver n afectados. La estructura a utilizar para realizar la extensin se ilustra en el siguiente diagrama

10103 Solucin al condicionante de extensibilidad del com)ortamiento La extensibilidad del comportamiento establece que se pueda actualizar ciertos comportamientos selectos del sistema a voluntad de un usuario con capacidad de programacin. Esta capacidad de extensin debe ser provista por el mecanismo del estndar JSR094, y en Orfeo ser implantada por medio del software DRools. 1010 El Estndar 4S5"630

En la actualidad las aplicaciones tienen que lidiar con cambios dinmicos en sus reglas de negocio. Una solucin para esto es trabajar con un motor de reglas de negocio, que bsicamente es un conjunto de herramientas que permite hacer an lisis del negocio y a los desarrolladores construir una lgica basada en los datos de la organizacin. El motor de reglas de negocio aplica las reglas y acciones segn como las defina el usuario final sin afectar la forma como se ejecuta la aplicaci n. Las aplicaciones son desarrolladas para lidiar con las reglas, y estas son diseadas por separado. Lo importante de construir un motor de reglas basado en JSR094 es que si el motor de reglas seleccionado deja de ser soportado es fcil reemplazarlo por otro sin tener que reescribir el cdigo de la aplicacin. JSR094 define dos paquetes principales:

El API para Administracin de reglas de negocio: Provee clases que son usadas para cargar las reglas y las acciones asociadas como conjuntos de ejecuci n. El API de Ejecucin del Cliente: Provee clases que son usadas por el cliente para ejecutar las reglas y obtener sus resultados.

10106 D5ools como motor de reglas de negocio0 La implementacin de cdigo abierto del estndar JSR094 en Java es el motor de reglas de negocio DRools. Este motor de reglas de negocio suministra tres tipos de semntica para definir las reglas de negocio, Python, Groovy y Java. DRools define las reglas de negocio en un archivo en formato XML con extensi n *.drl, el cual tiene la siguiente estructura:

<rule-set name="Nombre_conjunto_reglas" xmlns="http://drools.org/rules" xmlns:java="http://drools.org/semantics/java"> <rule name="Nombre_regla"> <parameter identifier="parametro_entrada_regla"> <java:class>co.gov.ss.orfeo.modulo.TipoParametroEntrada</java:class> </parameter> <java:condition> parametro_entrada_regla.getValorAnalizar1().equals("ok"); </java:condition> <java:condition> parametro_entrada_regla.getValorAnalizar2() > 10 </java:condition> <java:consequence> parametro_entrada_regla.setAccionEstado(true); </java:consequence> </rule> </rule-set> DRools evala el conjunto de reglas definidas dentro del archivo XML, las cuales est n expresadas como sentencias if-then. Dentro del elemento rule-set se define el nombre y la semntica que ser utilizada para construir las reglas de negocio, por cada elemento rule, se definen los parmetros de entrada (<parameter>), las condiciones de ejecuci n

de la regla (<java:condition>) y la accin a realizar en caso de que las condiciones sean vlidas (<java:consequence>). El siguiente ejemplo presenta la ejecucin que hace el cliente de las reglas de negocio mediante el API de DRools. El objeto ruleBase se construye a partir de la definici n de las reglas en el archivo XML, por medio de este se crea nuevo objeto de tipo WorkingMemory que es el encargado de hacer el llamado a las reglas y obtener su resultado.

WorkingMemory workingMemory = ruleBase.newWorkingMemory(); TipoParametroEntrada parametro_entrada_regla = new TipoParametroEntrada ( ok !"" ); workingMemory.assert#$%e&t(parametro_entrada_regla); workingMemory.'ire(ll)ules(); *ystem.err.println(parametro_entrada_regla.get(&&ionEstado());

Orfeo har uso de DRools para implantar las reglas de negocio que tengan mayor probabilidad de ser modificadas durante el proceso de adaptacin. No todas las reglas de negocio son susceptibles de ser actualizadas por medio del mecanismo de JSR094. Debe identificarse el subconjunto de las reglas que es ms susceptible de ser modificada de acuerdo con la implantaci n, y para este subconjunto utilizar el mecanismo de extensibilidad. 10107 .otas adicionales La extensin del sistema por medio del mecanismo de JSR094 debe considerarse como un esquema excepcional. Si este mtodo se utiliza en forma generalizada dificultar el mantenimiento del sistema. La localizacin natural de los archivos fuente de extensin es con la funcionalidad que afectan. Por esto se propone que las reglas que se implementen con este mecanismo se localicen en los mismos paquetes en donde se encuentra el c digo original afectado por la extensin.

Los archivos fuente de las extensiones a realizar son archivos textuales y por tanto pueden ser procesados con el mismo IDE que se utilice para realizar el mantenimiento de la aplicacin. Un mecanismo antiguo y alternativo al motor JSR094 es el de utilizar plugins para realizar la extensin. Este mecanismo requiere que la interfaz que realiza el comportamiento sea conocida. De esta forma, se pueden construir m ltiples clases que implementan la interfaz, y al momento de instalaci n del sistema se escoge con cul clase trabajar. La clase escogida es identificada por el mecanismo de configuraci n del sistema, y se carga en momento de ejecucin utilizando el mecanismo de Class.forName. Otra alternativa es la implementacin de plugins para funciones an no definidas de Orfeo, en la forma en que los programas integrados de desarrollo (tales como Eclipse) pueden incorporar plugins. Puesto que estos casos implementaran funcionalidades an no contempladas en los casos de uso definido, se deben tomar las siguientes acciones: Implementar un mecanismo para cargar la clase bootstrap del plugin. Se debe implementar un mecanismo para generar las tablas de persistencia requeridas. Se debe implementar un mecanismo para acceder a la vista existente e incorporar la funcionalidad del plugin en los mens. Se supone que el plugin implementa su propio mecanismo de controlador y de modelo y por tanto no es necesario implantar ninguna funcionalidad adicional.

10107 El motor de reglas dentro del sistema de gestin documental -r1eo0

Para implantar la extensibilidad del comportamiento utilizando JSR094 se debe conocer Los casos de uso afectados por la extensibilidad La regla DRools a aplicar

El siguiente diagrama ilustra la relacin entre el Orfeo existente y sus extensiones por medio de JSR094.

El diagrama ilustra claramente que JSR094 es un mecanismo til para realizar actualizaciones menores al comportamiento del sistema. En una ejecucin tpica el Controlador no se da cuenta de la existencia del JSR094 sino que llama al modelo solicitando la ejecucin de un caso de uso. El modelo a su vez determina si en la ejecucin del caso de uso se cumplen las condiciones para ejecutar una regla JSR094, en cuyo caso obtiene y aplica la regla correspondiente. La ejecuci n del caso de uso procede hasta su completitud.