Diseñando una Aplicación Web

Diseñando una Aplicación Web
(con Cruge e EYui)

Modelando con Cruge e EYui

En este tema quiero mostrar cómo integrar dos piezas importantes de Software para crear una aplicación web eficiente, tanto conceptualmente como a nivel de modelado UML.

En primer lugar usaré UML como lenguaje de modelado ya que te servirá para familiarizarte. Las cajas negras de punta cuadrada (por ejemplo "Empresa") son "Clases", no las confundas con las "Tablas" aunque muchas de ellas o quiza todas se almacenen luego en archivos (se llaman Relaciones..no "tablas") de un motor de datos. Una "tabla" es simplemente una forma de almacenar (o persistir) una Clase (sea en mysql, en un archivo de texto, etc).

Primera Etapa - Concepto Simple

REGLA DE NEGOCIO MINIMA:

Queremos que una empresa tenga departamentos, puestos y empleados. La regla aqui es que un empleado labore en varias empresas dentro del mismo sistema, además queremos usar Cruge como sistema de gestión de usuarios.

Como he repetido en varias oportunidades, no vamos a alterar a Cruge para insertar un modelo de negocios por mas que insistas en que: "hay que ponerle un idempresa a CrugeUser".

Relacion: Empresa-Empleado-CrugeUser

CrugeUser representa a una persona...las personas no son de una empresa, son libres, son seres libres, ahora...que "tengan una relacion" con una "empresa" eso es otra cosa, por tanto sería necesario crear una nueva "Relacion" (una nueva clase) para asociar a una persona (CrugeUser) con una Empresa, esa relacion se es representada por la clase "Empleado" que tiene dos atributos clave: idempleado e iduser. Esta clase puede ser almacenada en una relacion en mysql llamada "Empleado" con los campos igual a los atributos de la clase.

La relacion Empresa-Empleado-CrugeUser resuelve el problema de que un usuario de cruge labore en empresas. (sin necesidad en lo absoluto de crear un issue para insertarle el idempresa a crugeuser).

Relaciones: Departamento y Puesto

Una "Empresa" esta dividida en Departamentos y ofrece Puestos de trabajo. Ya lo adiviné: le vas insertar un IDEMPRESA a Departamento y Puesto...otra vez: NO!!, no se le agrega un IDEMPRESA al puesto o departamento

¿ Por qué no se debe insertar un IDEMPRESA a un Departamento o Puesto. ?

Principalmente la razon es que un sistema podría tener una lista global de departamentos o puestos, los cuales un administrador de sistemas agrega a una empresa.

Siempre hay un puesto de "ingeniero de sistemas" o "administrador" o "analista" (como ejemplos de puestos), no vamos a anotar los 30 puestos de una empresa a cada empresa que hagamos en el sistema, será mejor seleccionar los puestos y agregarselos a una empresa en particular, si un puesto es especifico para una empresa se agrega a la lista mayor y se asocia de vuelta quedando disponible para otras empresas del mismo sistema, mismo caso con los departamentos.

EYuiRelation como componente para manejar las asociaciones de Departamento, Puesto y demás.

Aqui es donde entra EYui, con su componente EYuiRelation. El cual permitiría asociar puestos, departamentos y demás a una empresa, de forma abstracta, EYuiRelation presenta un widget para manejar la asociación, te evita hacer el mismo codigo una y otra vez. Así quedaría el manejo de relaciones de Departamento, Puestos con EYuiRelation.

Segunda Etapa - Clases de Asociación

En el siguiente grafico verás dos clases nuevas: PuestoEmpresa y DeptoEmpresa. Estas son las "clases de asociacion". Una Clase de Asociación es aquella que permite que una clase X se asocie con una Y, siendo la clase de asociación otra nueva llamada XY, de ahi el nombre PuestoEmpresa....y no otro invento raro.

La clase de asociación se grafica con una "linea punteada" que apunta a la relación entre X y Y, es decir, la rayita que va desde Empresa a Departamento (o a Puesto). Esa "rayita punteada" indica que es necesaria una clase llamada "PuestoEmpresa" la cual guardará la asociación, dejando INTACTA a Puesto y a Empresa.

Lo mismo sucedió con la clase EMPLEADO, esta no es sino una "clase de asociación" entre Empresa y CrugeUser, pero no quise graficarla de otra forma para evitar confusiones de inicio. Podríamos perfectamente graficar a Emplado-Empresa-CrugeUser de esta forma:

En esta imagen (arriba de este texto) ves cómo se convierte el gráfico (el primero de esta wiki) en un modelo mas refinado a nivel de UML, diciendote que Empleado es una Clase de Asociación entre Empresa y CrugeUser.

Aqui además ves que CrugeUser tiene atributos propios de una persona, Cedula, Nombre, Apellido, y otros...aqui no van campos de negocio...!! solo van campos de persona. (ahora me entiendes la razón de existir de un CrugeField, espero que si. ?)

En la clase de asociación "Empleado" van atributos propios de la relacion entre Juan Perez y "Empresa XYZ"...por ejemplo, el numero de contrato, la fecha de su relacion laboral etc....estos datos NO VAN EN Cruge !!...van en tu modelo.

Los dos asteriscos *------* que van de CrugeUser a Empresa dicen que: "Un usuario puede estar asociado a varias empresas a la vez, y una empresa puede tener varios usuarios". (En matemática básica de conjuntos tiene un nombre específico, que ahora no recuerdo, pero es algo de 5to grado de escuela básica, la cual aun recuerdo a mi papa enseñandome eso de chico, pero soy malo recordando nombres, recuerdo mejor hechos y dibujos.)

Reconociendo los PIVOTES y el concepto de PIVOTE

Quisiera introducir la idea del PIVOTE (Es un concepto transmitido por mi Papa, quien no conocía UML pero si fue un gran modelador de software complejo).

Un PIVOTE es aquella pieza de software alrededor de la cual todo ronda. En este sistema no es CrugeUser..el negocio no esta orientado hacia un usuario, sino a la relacion de este con una empresa, por tanto tenemos dos pivotes: Empresa y Empleado.

¿ Por qué hago referencia a pivotes ? , porque hay que reconocerlos a la hora de profundizar en el diseño, para orientar el diseño hacia estos elementos. Como ejemplo de esto, lee la tercera etapa en este mismo documento, a continuación.

Tercera Etapa - Insertando un widget para manejar relaciones

Aqui entra al juego un paquete llamado EYui, el cual fabriqué hace un tiempo para darle a Yii una capa de modelado de negocio mas alta que lo provisto por defecto (lo cual no es tarea de yii..sino de un componente como EYui).

Queremos que un widget nos maneje las relaciones como Departamento y Puesto, las cuales son mas simples y vulgares en comparación con Empleado, que si bien son lo mismo conceptualmente, no es igual a nivel de negocio porque el Empleado es una pieza PIVOTE, tal cual como lo es la EMPRESA. (lee sobre PIVOTE en el tema anterior).

EYuiRelation puedes hallarlo en este repositorio de bitbucket, es parte del paquete EYui.

EYuiRelation usa la inyección de dependencia para pedirle a tu modelo que lo alimente con datos en una forma mínima de fácil comprensión. Mucha gente se intimida con EYui, pero lo cierto es que es simple, lo duro esta oculto...(denle gracias a la Encapsulación).

Lo que se hará será decirle a EYuiRelacion quien es el maestro (la empresa, la parte X de la relacion XY), decirle además dónde estan las opciones seleccionables (la Y de una relacion XY. por ejemplo, la lista general de departamentos o puestos disponibles), y finalmente decirle dónde guardar la relacion (la XY, el departamento asociado a una empresa, o mejor dicho DeptoEmpleado, siguiendo el ejemplo).

Fíjate en las interfaces. Estan simbolizadas por una linea azul que sale (por ejemplo) de Puesto y termina en una pelotica azul. Eso significa que: Puesto REALIZA la interfaz EYuiRelationIOptions, la cual alimenta al widget con las OPCIONES disponibles para seleccionar. Cuando digo "REALIZA" no es un invento mio, es un concepto UML "Realization", lo cual significa que algo lleva a cabo la tarea, debido a que las interfaces son ABSTRACTAS, aqui la realización dice:

 "Yo, el Puesto, voy a darle vida a esta interfaz para que tal cosa me consuma".

Lo que hace PUESTO es Realizar la interfaz EYuiRelationOptions, proveyendole al Widget EYuiRelation los datos necesarios para presentar el DropDownList del cual el usuario va a seleccionar un Puesto para agregarselo a una empresa. Mismo caso con el Departamento.

EYuiRelation también le exige a PuestoEmpresa que le provea de una interfaz llamada "EYuiRelationIRelation", la cual le pide a la clase PuestoEmpresa que provea un mecanismo para "almacenar" (olvidate de mysql, sacatelo de la cabeza) a aquella OPCION tomada de EYuiRelationIOptions (el puesto seleccionado).

Finalmente, EYuiRelation le pide a Empresa una interfaz para poderla reconocer como un objeto al cual asociar. Solo le pide su PRIMARYKEY, para aclarate la idea, pero lo hace bajo una interfaz, es muy simple tecnicamente.

Con todo eso, EYuiRelation ahora puede: Listar los puestos, asociar a un puesto seleccionado a una empresa y guardar eso en una "tabla" llamada "PuestoEmpresa".

Christian Salazar H.
tema escrito para Yii Framework en Español.