Tutorial POO con Ruby (I)

glpunzi | 15 Octubre, Miércoles, 2008 | 8:57 pm

Este tutorial está escrito por Fernando Arroba (a.k.a. Notxor)

INTRODUCCION

Esto es un tutorial sobre programación orientada a objetos. Su objetivo es que como me sugirió G.L. aprendamos a pensar en modo objetos. Hasta ahora, y por lo que me ha contado el amigo G.L., está acostumbrado a pensar en modo Delphi (tan pernicioso como el modo BASIC). Éste modo consiste en considerar que el fichero del formulario también es la clase del modelo; o dicho de otro modo, meten en el mismo saco el modelo, la vista y el controlador… Al final, una mala política de diseño que se traduce en sistemas que al crecer se hacen imposibles de gobernar.

Vamos a hacer un ejemplo, desde el principio. Partimos de la más absoluta ignorancia sobre el tema elegido. Ésto no es cierto del todo, siempre tenemos una idea aproximada de en qué consiste una tarea o el trabajo del vecino, pero debemos huir de estas ideas (llamémoslas prejuicios) para hacer un análisis correcto de lo que quiere el cliente o de en qué consiste la tarea que estamos analizando.

En un mensaje de nuestras conversaciones sobre lo humano y lo divino, G.L. me decía lo siguiente:

Uno de los problemas que yo veo es que los libros no reflejan casos reales. Me explico. Está muy bien que me digas que si en el shell de Ruby pongo 2+2 me devuelve 4, pero eso lo convierte en una calculadora costosa en memoria.

Por ejemplo, si quieres, ponemos un “background” (o se podrían ir haciendo varios) y se le dan forma. Por ejemplo, el caso que actualmente quería hacer para llevar un poco de control sobre las tareas que hacemos en nuestra empresa, y que quería hacerlo de tal manera que eso mismo pudiésemos venderlo, aunque es borrador de la idea, y muchas cosas pueden ser confusas o sin sentido, allá vá.

Caso 1:
“Nuestro cliente (que dispone de distintas empresas o delegaciones de distintos servicios), requiere de una aplicación donde poder registrar todas las incidencias de sus clientes en las distintas empresas. Estas incidencias, deben ser asignadas a un técnico, el cual recibirá un correo con los detalles de ésta.

Algunos técnicos trabajarán en incidencias de distintas empresas, y otros, en cambio, pertenecerán sólo a una empresa para la que trabajarán.

El técnico, deberá rellenar una hoja de trabajo asociada a esa incidencia, así como definir el estado de ésta (completada, en curso), si pertenece a un mantenimiento, y asignarle material y/u horas de trabajo así como si ese material u horas de trabajo han sido o no cobradas. De ésta hoja de trabajo, se podrá formalizar una factura que
será entregada al cliente.

El gerente, solicitará al personal de administración correspondiente, los siguientes informes.
- Informes Incidencias realizadas dentro de un rango de fechas (completadas, en curso, facturadas etc..).
- Informes de productividad de técnicos.

and so on.
“

PRIMERA APROXIMACION
No es mucha información, pero retomamos lo que tenemos hasta ahora y vamos planteando una posible solución. Esta solución es parcial (muy parcial, debido a la escasa información) pero ya nos permite el poder presentar a nuestro cliente un primer esquema sobre el que poder trabajar.

Lo primero que haremos será descubrir posibles clases que se dan en el ámbito de trabajo del que estamos hablando. Para ello, lo que suelo hacer es tomar esas pocas frases e ir subrayando los sustantivos.

Nuestro cliente (que dispone de distintas empresas o delegaciones de distintos servicios), requiere de una aplicación donde poder registrar todas las incidencias de sus clientes en las distintas empresas. Estas incidencias, deben ser asignadas a un técnico, el cual recibirá un correo con los detalles de ésta.

Algunos técnicos trabajarán en incidencias de distintas empresas, y otros, en cambio, pertenecerán sólo a una empresa para la que trabajarán.

El técnico, deberá rellenar una hoja de trabajo asociada a esa incidencia, así como definir el estado de ésta (completada, en curso), si pertenece a un mantenimiento, y asignarle material y/u horas de trabajo así como si ese material u horas de trabajo han sido o no cobradas. De ésta hoja de trabajo, se podrá formalizar una factura que será entregada al cliente.

El gerente, solicitará al personal de administración correspondiente, los siguientes informes.
- Informes Incidencias realizadas dentro de un rango de fechas (completadas, en curso, facturadas etc..).
- Informes de productividad de técnicos.

En esta primera aproximación se ven los siguientes adjetivos… candidatos a formar nuestras clases:

Empresa: aparece 4 veces.
Cliente: aparece 3 veces.
Hoja de trabajo: aparece 3 veces.
Incidencia: aparece 3 veces.
Informe: aparece 3 veces.
Técnico: aparece 3 veces.
Aplicación: aparece 1 vez.
Correo: aparece 1 vez.
Delegación: aparece 1 vez.
Estado: aparece 1 vez.
Factura: aparece 1 vez.
Gerente: aparece 1 vez.
Hora de trabajo: aparece 1 vez.
Material: aparece 1 vez.
Personal Admón.: aparece 1 vez.
Servicio: aparece 1 vez.

¿Cómo se relacionan estas clases?
Lo primero que observamos es que podemos agregar conceptualmente esos sustantivos (candidatos a convertirse en clases) en distintos grupos. Por ejemplo, nos encontramos varios actores del sistema, como son los clientes, los técnicos, los administrativos, el gerente, todos ellos sustantivos que se refieren a personas que o bien interactuan con el sistema o bien deben realizar algún tipo de acción. En este apartado habrá que clarificar qué acciones llevan a cabo cada uno de esos actores. Por ejemplo, el cliente puede perdir un servicio de mantenimiento de forma telefónica, o rellenando un formulario web, o enviando un e-mail, o de cualquier otro modo. Por tanto, o el sistema es lo suficientemente flexible para admitir todos los modos o debemos indicar a los clientes cuál es el modo correcto de iniciar una incidencia. También debemos aclarar, y estos son sólo ejemplos, si el técnico debe rellenar algún tipo de documento en papel, o mediante la aplicación, o por sms, o por e-mail, o si se le pasa esa información o documento a algún administrativo que es el que lo hace. O por ejemplo, el gerente pide informes a la aplicación, o a los administrativos, o a los técnicos…

Por otro lado, también nos encontramos otro grupo de clases que podríamos llamar de documentación, como es la hoja de trabajo, los informes, la factura, el correo. Debemos aclarar quién genera la hoja de trabajo o la factura, de qué partes están compuestas, cómo se remiten, a quién se remiten, cómo se guardan…

El último grupo de clases es los que pueden ser, bien sinónimos de algún otro y que podrían entrar perfectamente en otro grupo, como es el servicio e incidencia, delegación y empresa, o bien forman parte de otra clase como es el estado. De este grupo hay que averiguar si efectivamente debemos tratar estos adjetivos como sinónimos o bien hay algún matiz con el suficiente peso para tratarlos por separado.

No hace falta decir que es una conversación con nuestro cliente el método más sencillo de averiguar todos estos datos. A dicha reunión conviene aportar cierta documentación que consistirá básicamente en devolverle al cliente información elaborada sobre la que él nos ha dado. Podemos aportar, por ejemplo el siguiente diagrama:

Click para ampliar

A aquellas personas que lean esto y tengan conocimientos previos de UML les resultará un gráfico demasiado simple. Es cierto, es muy simple, tanto que hasta nuestro cliente lo entendería (que es de lo que se trata). Habría que realizar un gráfico para cada relación que observemos en el texto. En el gráfico anterior propongo las dos más evidentes, pero hay más. Sin embargo, en la siguiente reunión me interesa hablar sobre todo de la estructura de administración de la empresa cliente y del proceso que sigue una incidencia desde que se informa hasta que se soluciona. Otros posibles temas para reuniones posteriores serían, por ejemplo, los presupuestos y facturaciones que deberá hacer el sistema.

En este punto, cabe aclarar que una de las fuentes de error más comunes es la semántica. En determinados ámbitos, las palabras tienen significados que no tienen porqué coincidir con lo que entendemos el resto de las personas y puede darse la situación de que empleando la misma palabra el analista y el cliente se estén refiriendo a conceptos totalmente distintos. Es recomendable que nos adecuemos al lenguaje que utiliza nuestro cliente y nos aseguremos que hemos comprendido correctamente el concepto tras él.