Patrones de Procesos de Gestión
Compartiendo Conocimiento para Aumentar la Productividad
Indíce del Capítulo
5.1-. Modelos de datos genéricos y su especialización
5.2-. Diseño e implementación computacional
5. DESARROLLO DE SOFTWARE DE APOYO
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:
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:
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.