Dada la claridad de los requerimientos expresados en el cap�tulo anterior, partimos como una buena base para el dise�o y construcci�n del software de apoyo al proceso. Esta base se da en varios niveles y provee varios enfoques alternativos para el desarrollo.

El primer enfoque, que es el obvio, consiste en tomar los requerimientos espec�ficos de un caso particular y con ellos elaborar un dise�o ad hoc sobre una tecnolog�a seleccionada, por ejemplo, bases de datos relacionales.

El segundo enfoque toma los requerimientos y los implementa tomando un paquete de aplicaci�n –si es que hay alguno para el dominio en cuesti�n– que tenga la suficiente flexibilidad de adaptaci�n. Esta adaptaci�n es por medio de par�metros y de programaci�n de una parte del software. Una variaci�n de este enfoque, para empresas que no puedan pagar el alto costo de este tipo de software, consiste en comprar paquetes m�s r�gidos, pero m�s baratos, y hacer redise�o a la inversa, adaptando los procesos al paquete.

Por �ltimo, tenemos un enfoque que est� m�s de acuerdo al esp�ritu de la idea de patr�n. Este consiste en reconocer que un patr�n general, como Macro1 o patrones de dominio o subdominio, como Macro1c y Macro1chi tienen suficiente definici�n como para dise�ar software general que, por especializaci�n, puede adaptarse a una aplicaci�n espec�fica de tales patrones.

Como este �ltimo es el enfoque que m�s partido le saca a la idea de patr�n, lo describimos en alg�n detalle a continuaci�n.

5.1-. Modelos de datos gen�ricos y su especializaci�n

De la misma manera en que se pueden construir patrones para procesos, es posible derivar, a partir de �stos, modelos gen�ricos de datos, vale decir, modelos v�lidos para un dominio o subdominio. Estos modelos se pueden especializar de manera similar a los patrones.

El punto de partida para la derivaci�n de patrones son los requerimientos explicitados en la Secci�n 4.4. En efecto, dijimos que los flujos de informaci�n de estado que se generan en Mantenci�n de estado de un modelo contienen los atributos acerca de los cuales deben mantenerse datos. Estos atributos pueden organizarse en forma muy natural asoci�ndolos a diferentes entidades. Estas son representaciones por medio de datos de personas o cosas que existen en la vida real y son realmente conjuntos, ya que modelan un cierto n�mero de instancias u ocurrencias de �stas. Por ejemplo, en todos los patrones presentados existen conjuntos de clientes representados por diferentes atributos: Rut, nombre o raz�n social, estado cliente, ubicaci�n, etc. Una instancia particular de cliente queda representada por datos o valores espec�ficos para los atributos: 10.455.899, Juan P�rez, etc.

O sea, derivando entidades y atributos asociados, a partir de los requerimientos expresados en los flujos de estado, podemos definir sin ambig�edad los datos que deben tenerse en Mantenci�n de estado y su estructura.

Como ejemplo de la idea anterior, consideremos el modelo Macro1. Partiendo del diccionario del Anexo 1 y centr�ndose en los flujos originados en Mantenci�n de estado, es relativamente f�cil llegar a las siguientes entidades:

Cliente = "rut cliente" + nombre o raz�n social + ubicaci�n + estado cliente + estado requerimiento producto o servicio generado + ‘rut contacto’ + cargo + tel�fono + fax + direcci�n electr�nica

Producto o servicio generado = "c�digo producto o servicio generado" + nombre producto o servicio generado + disponibilidad producto o servicio generado + an�lisis requerimientos producto o servicio generado + requerimiento producto o servicio generado + plan e instrucciones producci�n y entrega

Producto o servicio insumido = "c�digo producto o servicio insumido" + descripci�n producto o servicio insumido + disponibilidad producto o servicio insumido + requerimiento proyectado producto o servicio insumido

Proveedor = "rut proveedor" + nombre o raz�n social + ubicaci�n + estado proveedor + estado requerimiento a proveedor + ‘rut contacto’ + nombre contacto + cargo + tel�fono + fax + direcci�n electr�nica

Unidad productiva= "c�digo unidad productiva" + descripci�n unidad productiva + proyecci�n disponibilidad unidad + estado unidad

Estas entidades son complejas –en el sentido de incluir grupos repetitivos –atributos que contienen atributos– y a otras entidades dentro s�– y, de acuerdo a pr�cticas habituales de modelamiento de datos [5], deben someterse a una simplificaci�n para llegar a una forma can�nica. Esta forma tiene una relaci�n estrecha con las tecnolog�as –particularmente de Sistemas Administradores de Bases de Datos Relacionales (SABDR)– que permiten implementar las entidades en registros computacionales.

Ilustramos, a continuaci�n, dos ideas fundamentales de simplificaci�n: generalizaci�n/especializaci�n y agregaci�n. La generalizaci�n/especializaci�n permite definir nuevas entidades que comparten atributos comunes a otras entidades. La nueva entidad se llama una generalizaci�n de las existentes, que son especializaciones. Este mecanismo puede tambi�n utilizarse a la inversa.

Por ejemplo, las entidades Cliente y Proveedor, definidas previamente, comparten varios atributos. Esto permite su generalizaci�n definiendo:

Persona natural o jur�dica = "rut" + nombre o raz�n social + ubicaci�n + ‘rut contacto’ + cargo + tel�fono + fax + direcci�n electr�nica

Cliente = estado cliente + estado requerimiento producto o servicio generado

Proveedor = estado proveedor + estado requerimiento a proveedor.

De la misma se pueden generalizar Producto o servicio generado y Producto o servicio insumido.

Producto o servicio = "c�digo producto o servicio" + descripcion producto o servicio

Producto o servicio generado = disponibilidad producto o servicio generado + an�lisis requerimiento producto o servicio generado + requerimiento proyectado producto o servicio generado + plan e instrucciones producci�n y entrega

Producto o servicio insumido = disponibilidad producto o servicio insumido + requerimiento proyectado producto o servicio insumido

En la generalizaci�n/especializaci�n est� impl�cito que las entidades especializadas comparten los atributos de las entidades generalizadas.

La agregaci�n –que tambi�n puede interpretarse como "compuesto de" – identifica entidades que participan en otra entidad y atributos que en s� est�n compuestos por otros atributos. Por ejemplo, contacto es una instancia diferente de la persona natural o jur�dica que la contiene. Por lo tanto debe originar una entidad, que en este caso es del mismo tipo, lo cual lleva a una recursividad que modelaremos como relaci�n m�s adelante. Por otro lado, ubicaci�n, estado cliente, estado requerimiento y varios otros son atributos que deben caracterizarse en m�s detalle, tambi�n con atributos. Esto lleva a definirlos como entidades que, por agregaci�n, definen a otras entidades.

Adem�s de las entidades, existen relaciones entre ellas que pueden ser de diversos tipos.

En primer lugar, las relaciones entre entidades generalizadas y sus especializaciones se definen como una relaci�n ISA ("es una" en ingl�s) y la de una entidad que incluye a varios otras como agregaci�n se define como A.

En segundo lugar, existen referencias de una entidad a otra; por ejemplo, el atributo estado requerimiento producto o servicio generado de Cliente hace referencia a ciertos productos o servicios contenidos en la entidad correspondiente.

Por �ltimo hay relaciones arbitrarias, por ejemplo, un Producto o servicio insumido se usa en un Producto o servicio generado.

Las relaciones tienen una cardinalidad, en cuanto que una instancia de una entidad puede estar relacionada con una o varias de otra y viceversa. Por ello se definen, entre otras, relaciones 1:1, 1:n y m:n.

Por ejemplo, la relaci�n ISA es 1:1, la relaci�n agregaci�n 1:n y las de referencia y las arbitrarias pueden tener tambi�n cardinalidad arbitraria; as� la relaci�n usa mencionada anteriormente es claramente m:n.

Las entidades y sus relaciones se representan por medio un modelo Entidad/Relaci�n (E/R), en el cual las entidades son rect�ngulos y las relaciones se representan por medio de conectores y rombos insertos en ellos que indican el tipo de relaci�n. Tambi�n se indica la cardinalidad por medio de letras asociadas a los conectores^*.

Todas las ideas anteriores permiten representar en forma integral un modelo E/R para Macro1, el cual se entrega en la Figura 5.1. Como ya hemos dicho, este modelo, que llamaremos E/RMacro1, es gen�rico, en el sentido que aplica a cualquier dominio que se modele a partir de Macro1 y, a partir de �l, se pueden derivar modelos E/R para patrones m�s espec�ficos de dominio.

La especializaci�n de E/RMacro1 a un dominio se realiza por medio de seleccionar las entidades relevantes en el dominio y, para las elegidas, detallar, por medio de atributos adicionales, las entidades parcialmente definidas o no definidas. Por ejemplo, si tomamos el dominio de cr�dito, representado por Macro1c, algunas especializaciones de E/R Macro1 son las siguientes:

1. Se elimina Proveedor, sus especializaciones y relaciones asociadas, ya que no se considera relevante.
2. Se elimina Persona natural o jur�dica, por ser irrelevante la generizaci�n.
3. Ubicaci�n pasa a ser una entidad atributo de Cliente.
4. Se detalla, por ejemplo:

Estado requerimiento = estado cr�dito = "no cr�dito" + monto cr�dito + plazo cr�dito + condiciones + fecha solicitud + antecedentes financieros + antecedentes garant�as + otros antecedentes + estatus + otra informaci�n.

Los detalles anteriores pueden implicar un cambio en la estructura del modelo, por inclusi�n de nuevas entidades –por agregaci�n, por ejemplo– y relaciones. As�, en el caso de cr�dito, el atributo antecedentes garant�as obviamente originar� una nueva entidad por agregaci�n.

Como alternativa a un modelo E/R se puede desarrollar, a partir de los mismos antecedentes, un modelo orientado a objetos[5], que presenta algunas ventajas con respecto a la especializaci�n, particularmente en lo que respecta a implementaci�n. Bosquejamos tal alternativa a continuaci�n.

La orientaci�n a objetos parte de las mismas entidades presentadas anteriormente. Sin embargo, las organiza de manera diferente. Esto se debe a que el concepto de clase de objetos es m�s general que el de entidad. En efecto, una clase de objetos representa una entidad o estructura de entidades, caracterizada por medio de sus atributos y los m�todos –tambi�n llamados operaciones– que son los procesos computacionales que podemos asociarle naturalmente, porque se alimentan de los datos de ella.

As�, por ejemplo, para Macro1 podemos definir las clases de objetos Persona natural y jur�dica y Cliente, incluyendo esta �ltima las entidades Cliente, Estado cliente y Estado requerimiento de la Figura 5.1. Adem�s, de acuerdo a los requerimientos establecidos para Macro1, se incluyen los siguientes tipo de m�todos:

1. Actualizar datos
2. Emitir informaci�n

Las clases definidas se representan por medio de rect�ngulos divididos en secciones: una para el nombre, otra para los atributos y una tercera para los m�todos. As�, para Macro1, las clases Persona natural o jur�dica y Cliente se representan como se muestra en las Figuras 5.2 y 5.3, donde hemos simplificado la primera clase, resumiendo los atributos de contacto –rut contacto, cargo, etc– en otros atributos, para evitar la complejidad de la recursividad asociada a ellos.

Notamos que, en orientaci�n a objetos, las relaciones entre una clase y sus especializaciones se manejan por medio del mecanismo de herencia. Concretamente, esto implica que una clase especializada puede hacer uso de todos los atributos y m�todos de una clase de la cual hereda. Este poderoso concepto –que implementan los lenguajes y bases de datos orientadas a objetos [5]– permite especializar modelos gen�ricos de clases de objetos, como el ejemplificado, a dominios m�s espec�ficos. Esto se realiza, esencialmente, por medio de la definici�n de clases que son una especializaci�n de las m�s generales, agregando atributos y m�todos.

Por ejemplo, para especializar Cliente de Macro1 a Cliente para Macro1c, debemos agregar los atributos que precisan estado requerimiento y los nuevos m�todos necesarios, lo cual se muestra en la Figura 5.4.

Apreciamos que la herencia provee una manera muy natural para ir especializando gradualmente las clases de un dominio a subdominios m�s detallados, conservando y reusando el trabajo previo de definici�n y, como lo veremos m�s adelante, de programaci�n.

Las clases de objetos tienen otras relaciones entre ellas, m�s all� de la herencia, las cuales tienen que ver con las mismas relaciones identificadas en modelamiento de datos E/R y otras que se originan en la manera en que las clases interact�an. Las primeras tienen que ver con que una instancia de una entidad referencia una o varias instancias de otra. Por ejemplo, en la Figura 5.1, la entidad Estado requerimiento referencia a Producto o servicio generado, en el sentido de que ciertos antecedentes de los productos o servicios contenidos en Estado requerimiento se encuentran en Producto o servicio generado. En el caso de la especializaci�n de ERMacro1 a cr�dito, esto podr�a consistir en que asociado a un no cr�dito hay un tipo de cr�dito y que los datos que caracterizan tal tipo –descripci�n, monto m�ximo, nivel de aprobaci�n, etc– se encuentran en Producto o servicio generado. Esto implica que para que la salida que genera Emitir informaci�n cr�dito contenga los datos del tipo de cr�dito, debemos utilizar ambas entidades.

En orientaci�n a objetos lo reci�n descrito se�ala que una clase que contenga una entidad que referencie a otra, que a su vez est� contenida en otra clase, debe necesariamente pedir la colaboraci�n de �sta. Esto genera la necesidad de nuevos m�todos de servicio por medio de los cuales una clase pide los servicios de otra y �sta responde, lo cual tambi�n se denomina contrato.

La presentaci�n gr�fica de lo anterior para el ejemplo de cr�dito se muestra en la Figura 5.5. N�tese que el diagrama representa "flujo" entre clases y que hemos resumido los atributos y m�todos anteriormente detallados para las clases.

Detr�s de lo reci�n presentado est� otra de las ideas fundamentales de orientaci�n a objetos, cual es la de encapsulamiento. Esta implica que s�lo los m�todos de una clase pueden acceder a los datos de la clase.

La manera en que las clases interact�an depende de c�mo se satisfacen los requerimientos a partir de los datos en las clases. Por ejemplo, para satisfacer el requerimiento de Macro1 de emitir An�lisis de requerimiento hay que ejecutar un procesamiento que implica conocer el Estado requerimiento. Naturalmente, el procesamiento (m�todo) anterior debe estar asociado a una clase Unidad productiva –que contiene la entidad Proyecci�n disponibilidad unidad– y, como vimos, el Estado requerimiento est� en la clase Cliente. Por lo tanto, estas clases deben colaborar, solicitando la primera los datos de Estado requerimientos a la segunda.

5.2-. Dise�o e implementaci�n computacional

En este punto consideramos s�lo dos tecnolog�as de implementaci�n: bases de datos relacionales y orientaci�n a objetos. Esto debido a que creemos que son las apropiadas para implementar los modelos del punto anterior.

La implementaci�n por medio de un SABDR es bastante directa a partir de los modelos E/R de la secci�n anterior. En efecto, basta con transformar los modelos E/R a tablas relacionales normalizadas, para lo cual existen reglas bien definidas [12] que permiten la implementaci�n de los datos. Esto es facilitado por la existencia de herramientas de software de apoyo –CASE y de otro tipo [6]– que permiten dibujar y documentar los modelos de datos con apoyo computacional, realizar la normalizaci�n y generar el c�digo (programa) que permite crear y actualizar las tablas relacionales.

Lo que falta por dise�ar e implementar son los procesos computacionales que, a partir de las tablas, satisfacen los requerimientos. Para ellos tambi�n pueden utilizarse herramientas a las cuales se les especifican tales procesos, incluyendo, posiblemente, algunos algoritmos que automatizan parcialmente actividades del proceso del negocio –lo cual puede implicar alg�n grado de programaci�n computacional–, las cuales son capaces de generar el c�digo que satisface los requerimientos.

Por lo tanto, usando adecuadamente las herramientas de apoyo, uno podr�a tener la especificaci�n y dise�o de una base de datos relacional y de los procesos que satisfacen los requerimientos a nivel de Macro1 y dominios o subdominios de especializaci�n, en forma coordinada y reusando todo el trabajo realizado en un nivel previo de especializaci�n.

Las herramientas apoyar�an tambi�n la generaci�n del c�digo que permite la implementaci�n del apoyo computacional para el nivel de especializaci�n a un caso particular.

Alternativamente a lo reci�n propuesto, se puede realizar una implementaci�n computacional usando la orientaci�n a objetos. En este caso, lo que estar�a definido ser�an las clases a nivel de Macro1, un dominio o un subdominio, las cuales contienen los datos y los m�todos. Estas clases y sus relaciones tambi�n pueden especificarse a base de un esquema formal apoyado en herramientas de software, que permiten la generaci�n autom�tica de c�digo [9].

Por lo tanto, la especificaci�n, dise�o e implementaci�n del apoyo computacional a un proceso de negocio para un caso particular, podr�a hacerse a partir del trabajo previo realizado para la especializaci�n de m�s bajo nivel disponible.