Aunque esto va a deteriorar mi igamen reivindicativa y activista, hoy haré un poco de propaganda evangelizadora por que entiendo que es merecida y sería un ingrato si no lo hiciera.

Cuando estudiaba en la facultad de física de Valencia, imaginaba como seria llegar a ese punto donde todo lo que haces es nuevo, ese punto donde cada nueva teoría podría ser una herejía, un salto al vacío o un acierto. Pensaba que esa sensación tendría que ser única, llegar al filo de lo inexplorado, intentando caminar por su borde sin fracasar en el intento.

Lamentablemente para mi, la física es un toro demasiado grande y en mis lejanos años de facultad realmente solo llegué a conocer una o dos personas capaces de caminar por ese borde donde terminan las tesis de la ciencia conocida y solo hay conjeturas. Algún que otro ex decano que pasada la edad de jubilación seguía regalándonos clases por emérito, y otra de esas rarezas de la vieja escuela condenado e indultado por insumisión al ser objetor, en una época en la que no era un derecho fundamental y que formó a los nuevos delfines de IFIC (Instituto de Física Corpuscular), en el que inocentemente cada vez que accedíamos con nuestras tarjetas identificativas para realizar prácticas al extraño pequeño y cúbico edificio, nos parecia que íbamos a entrar en el centro mismo del cuartel general dela CIA.

Habia mucha gente dedicada al estudio si, pero talento, talento de verdad, solo lo logré ver en esos dos ancianos que eran los únicos capazes de llegar al borde mismo del abismo donde se agota la ciencia y quedan en soledad las personas. Yo pase en la facultad casi 10 años de mi vida y nunca logré ver en el horizonte ese abismo ni siquiera de lejos, por mucho que intentara participar.

Pero aunque mi travesía por la física nunca me llevó a ese límite, por casualidad si que lo hizo la programación, donde el camino no es tan arduo y cada nuevo proyecto parece que te lleve a un horizonte distinto. Por que en realidad cada nuevo trabajo ya te situa en ese mismo borde y eres tu quién decides si quieres volver atrás sobre la seguridad del camino que ya han recorrido otros para concluir tu trabajo o caminar hacia delante creando una nueva senda que quizás otros puedan llegar a recorrer.

¿Cuantas oportunidades tenemos en la vida de hacer eso? ¿cuantas veces has participado en un camino semejante? ¿cuantos lenguajes de programación conoces de los que puedas participar opinando sobre su desarrollo? ¿y cuantos lenguajes de programación conoces en los que tus proyectos puedan formar parte de esa comunidad de desarrollo que camina por el borde mismo del abismo?

Hoy por hoy, hay una pequeña comunidad de desarrolladores que caminan por ese borde, y dia a dia construyen con más o menos acierto el camino que muchos de nosotros recorremos, a veces por el camino equivocado, pero es solo por que son capacez de llegar hasta ese límite, y eso es un privilegio.

A mi las entrañas de Google me quedan muy lejos, pero lo que si logro ver en el horizonte al alcance de todos es Velneo. Life is soft, no me parece un mal lema, todo lo contrario y como escribió Noah Gordon en “El Medico”, este le dice a Ibn Sina (Avicena, principe de la medicina) – “he recorrido medio mundo, solo para tocar el borde de tu túnica”.

¿vendrás tu tambien a  life is soft 11 11 11?

P.D. Si ya se que hay que pagar los seminarios, pero el 11/11/11 la presentación es gratuita así que no hay escusa que luego tenemos toda la tarde para tomar sidras. Yo estaré allí que hay que pedirle autógrafos a Pepeto.

Por supuesto puedes ver los viajes interiores de otras personas, cuando lees un libro, vas al teatro, o ves una película. ¿Que estas haciendo, sino viajar con los ojos de otra persona? Y yo a menudo suelo ver otro viaje interior, el del vArquitecto con v7.

Son contadas las ocasiones en las que tenemos el tiempo y la tranquilidad de espíritu suficiente para desarrollar aislados y protegidos en nuestro propio mundo interior. En general, cada vez que nos enfrentamos a un desarrollo siempre necesitamos de una “puesta en escena inicial, es el comienzo del viaje”, esta puesta en escena nos sirve para inicializar nuestros pensamientos y focalizarlos sobre el problema que hay que desarrollar. Son minutos improductivos a nivel de código, pero cruciales para su desarrollo, antes hay que calentar motores y cuando paramos debemos dejar el motor en marcha para poder arrancar con rapidez y atacar el camino que se ha abierto bajo nuestros pies en ese preciso momento, porque si no lo haces entonces quizás no lo vuelvas a encontrar.

Seguro que el vArquitecto se emocionó, cuando ante sus pies se abrió un nuevo camino, siguió con la mirada el trayecto del mismo y seguramente hasta sintió vértigo al vislumbrar el nuevo paisaje al que conducía. Deshizo los pasos adelantados con la mirada, se situó de nuevo en el inicio del camino y comenzó a caminar por la nueva senda “empezó a manejar objetos”.

Pero para caminar debemos dar un paso después del otro, y una vez que el vArquitecto instanció el primero de sus objetos se paró y pensó – ahora debo lanzarle el primer mensaje, pero ¿que debe contener el mensaje? – y de nuevo se abrieron bajo sus pies una nueva colección de caminos (variables booleanas, numéricas, alfabéticas, arrays, fichas, listas, etc…). Y como en esta parada tenia el motor en marcha y todos somos esclavos de nuestro pasado, tomó rápidamente los caminos que ya conocía (variables booleanas, numéricas, alfabéticas) y los enlazó a su nuevo camino. No creo que desechara los otros, simplemente se dijo –primero recorreré los conocidos y más tarde ya regresaré a explorar los siguientes – y así fue, con estos nuevos caminos rellenó su mensaje y lo lanzó.

El mensaje viajó hasta el objeto, llegó correctamente, y casi sin pensar, el objeto al ver el contenido del mensaje lo procesó de oficio, era inherente a él. Expectante el vArquitecto no pudo contener un grito ahogado al contemplar de nuevo como se abrían bajo sus pies otra colección de caminos y le gritó al objeto – debes contestarme! Cualquier otra cosa sería de mala educación – y así fue, los caminos ya eran de ida y vuelta.

De nuevo parado con el motor en marcha, el vArquitecto se quedó mirando el horizonte y pensó -  ¿hacia donde dirigirme? ¿que más puede contener el mensaje? –  Miró fijamente una estructura de datos habitualmente poco utilizada en el país del que venia, los arrays unidimensionales – debería recorrer ese camino pero ¿por que no los n-dimensionales? – pero pronto abandonó ese pensamiento porque miró fugazmente a otro lado y sin pretenderlo centró su visión en sus particulares estrellas de las estructuras de datos, las fichas y las listas.

Musitando lo que pensaba dijo – estos caminos sin duda los debo recorrer – y como si de un cataclismo se tratara se volvieron a abrir bajo sus pies numerosas bifurcaciones,  haciéndole sentir vértigo en su estómago hasta que incluso llego a perder el equilibrio, por que en esta ocasión “todo era distinto”…

- ¿A que objetos debo enviar las fichas y las listas? – pensó, y a cada pensamiento le sucedía un nuevo terremoto bajo sus pies.

- ¿Cómo sabrá el objeto que estructura tiene la ficha o la lista que envíe? – hasta creía escuchar el ruido del cataclismo a su alrededor.

- Si el objeto no conoce previamente la estructura de la ficha o la lista ¿como las puede manejar? – el suelo empezaba a transformarse en arenas movedizas.

- ¿Se podrían manejar de forma genérica sin conocer su particular estructura? – necesitaba poner orden en su mundo, necesitaba volver a sus orígenes para organizarse.

- Por el momento ¿no seria más sencillo enviarlas solo a objetos contenedores de  listas o fichas y que tengan ya definida la misma tabla de la lista o ficha que enviamos en el mensaje con lo que el objeto ya conoce previamente su estructura?  

Y por aquí empezó,

Lazó en esa dirección su segundo mensaje a estos particulares objetos de configuración estática, y aunque funcionó correctamente, con lo que los movimientos sísmicos se estabilizaron, me gustaría pensar que no quedó satisfecho. Porque la primera vez que divisó la senda inicial sintiendo el vértigo en su estómago y recorrió el camino con la mirada vislumbrando el nuevo paisaje al que conducía, apuntaba al “paradigma de la programación orientada a objetos” y este nuevo camino lo alejaba del sueño.

- Seria fantástico añadir una lista “cualquiera” a un objeto y que este fuera capaz de procesarla, retornando la lista procesada – pensó soñando en su objetivo.

-¿Podríamos procesar una lista sin conocer previamente su estructura? ¿Tienen las listas atributos comunes que nos sirvan para procesarlas independientemente de su estructura? – volvió a replantearse – Joder si! – se dijo – como mínimo #ID y #NAME – y con un estruendo ensordecedor volvieron a abrirse bajo sus pies un abanico de nuevos caminos.

- Y ¿podría utilizar mis propios comandos de instrucción que ya poseo para manejar cualquier lista solo con esos atributos comunes? – decía mientras intentaba mantener el equilibrio – Joder! pues claro.

Y ahí bajo sus pies, en ese preciso día, en ese preciso momento, tuvo ante si el camino que le podía llevar al paisaje que vio adelantando su mirada por la primera senda de nuestra historia. Pero algo pasó, algo o alguien distrajo la atención del vArquitecto, y su viaje interior por ese día finalizó, acabó, se rompió, desapareciendo de su vista, en aquel preciso día, en aquel preciso instante “el camino que a todos nos hubiera gustado recorrer”.

to be continued …

Un paginador nos dividirá una LISTA de R registros en n páginas de k registros, es decir al aplicar el paginador trasformamos la LISTA de la forma:

en realidad solo hemos hecho una simple división, guardado los valores en R, k, r, c, n, y la LISTA ya está paginada, increíble pero cierto.

Ahora vamos con el paginador, necesitamos unos controles/procesos que nos muevan por el paginador, y un puntero que nos indique en que página nos encontramos:

y también necesitamos un proceso que nos devuelva los registros a mostrar en la página seleccionada (CARGAR_REG_PAGINA), que básicamente debe hacer,

(a modo de apunte el comando de instrucción que debemos manejar en v7 que nos permitirá reproducir el proceso seria, Cortar Lista)

Ahora para manejar el paginador solo necesitamos movernos por los punteros y cargar nuestra pagina, por lo que los procesos de navegación serian:

• Cargar la primera página P_1:

p = 1;

GARGAR_REG_PAG;

• Cargar la última página P_ULT:

p = n;

GARGAR_REG_PAG;

• Cargar página siguiente P_SIG:

 Si (p == n) entonces

            NADA_de_NADA

Si (p < n) entonces

p = p+1;

GARGAR_REG_PAG;

• Cargar página anterior P_ANT:

Si (p == 1) entonces

            NADA_de_NADA

Si (p > 1) entonces

p = p-1;

GARGAR_REG_PAG;

Y ya está, con esto ya tenemos “assolutamente tutti” lo que necesitamos saber de paginadores, el resto solo es cuestión de traducirlo a un lenguaje y presentar por patalla resultados.

Ahora que controlamos ya nuesto paginador, pensemos una situación real para aplicarlo

• Tenemos un servidor Apache con vModApache y un vServer con nuetra solución.
• Servimos con vModApache las páginas y los datos que gestiona el vServer.
• Tras interactuar con la web el vServer devuelve el resultado de una “busqueda o lista” que debemos presentar en HTML.
• El número de resultados puede ser lo suficientemente elevado para que necesitemos un paginador de n-paginas con k-registros.

Partiendo de esta base solo nos queda un pequeño paso, que es añadir el montaje de la tabla en HTML en el proceso CARGAR_REG_PAGINA  justo despues de nuestra instrucción “cargar registros de la lista”, y en v7 el montaje de la tabla HTML por ejemplo podria ser,

La variable RETORNO nos da el código HTML de la tabla con los registros de la página seleccionada. Y por último a gusto del consumidor en los porcesos P_1, P_ULT, P_SIG, y P_ANT, que cada uno monte la página como más le guste, solo hay que referenciar en la pagina los procesos que manejan el paginador adecuadamente, por ejemplo:

Esta sería una las clásicas formas de actuar,  en la que creamos un paginador y unos procesos de montaje de pagina cada vez que necesitamos hacer uso de diferentes listas, con lo que nuestro software cada vez se vuelve más “Frankenstein” a medida que aumento los modulos de consulta.

¿Se puede hacer de otra forma? Yo creo que si.

Pero como hoy me voy de vacaciones, y no vuelvo hasta dentro de 2 semanas ya lo intentaré entonces

Un saludo.

Independientemente de que al implementar la vClase lo hice con prisas y llame Foco_Inicio al Foco_Final y viceversa, podéis probar a manejar la vClase con las especificaciones de la imagen y crear burbujas.

Algunos dirán, “muy bonito muy bonito” pero ¿para qué sirve esto si yo hago aplicaciones serias de gestión empresarial?

Pues posiblemente al que se lo pregunte desde esa perspectiva no le sirva de nada, es difícil hacer cambiar a la gente, “casi imposible”, pero los que son capaces de mirar con otros ojos que no son los suyos, seguro que hace tiempo que ya han sacado provecho de ello, por que lo tiene y mucho.

No me repetiré demasiado diciendo que, en primer lugar es un ejercicio práctico de como utilizar la estrategia de vClases. Además ya indiqué que una de mis principales preocupaciones a la hora de programar era, que cada paso que diera, supusiera la consolidación de un nuevo peldaño sobre el que apoyarme para poder escalar otras cimas de forma sencilla sin necesidad de volver a repetir procesos, y a tal efecto orientar la programación de las partes susceptibles de ello a crear estos singulares “artefactos” que son las vClases.

Cada vClase que diseño pasa a formar parte de una librería similar a la del ejemplo del post anterior de fácil consulta y manejo (digo similar por que el diseño de la librería ya la he cambiado para que sea mucho más fácil su consulta y gestión) y de esta manera hacer crecer la base de “operaciones atómicas” sobre las que construir mi software.

“…con electrones, protones y neutrones construimos átomos, con átomos construimos moléculas, y con moléculas construimos elementos complejos, algunos hasta orgánicos capaces de albergar vida propia, y que son autenticas criaturas…”

Nosotros tenemos los elementos fundamentales en v7, con ellos podemos construir vClases (átomos) y con ellas construir vClases que llaman a vClases (moléculas), por ejemplo vClass Radial Gradient y con esas particulares moléculas construimos librerías de vClases, capaces de constituir autenticas criaturas con vida propia. Pero en fin, solo es un camino.

Y después de este rollo un ejemplo práctico con vClass Radial Gradient para los más pragmáticos, volvamos al ¿para que coñ… me sirve a mi esa vClase? Pues bien, probar a hacer la siguiente selección de controles:

Bonito efecto “perla” ¿a que si?, ahora usar vuestra imaginación y seleccionar mentalmente un widget llamado “QPushButton” lo conoceis ¿verdad? Y haciendo uso de vuestra inmensa capacidad de abstracción espacial, localizarme la propiedad “border-radius” y jugar con ella hasta conseguir que vuestro widwet sea redondo. Bien! Bien! ya veo que lo teneis! eso va muy bién! Ahora sacar la varita mágica y agitarla sobre la propiedad “background-color”, soplar y decir las palabras mágicas vClass_Radial_Gardient!!  Fantástico! acabais de conseguir un “hermoso boton redondo efecto perla” al estilo MAC para utilizar en esas aplicaciones de gestión empresarial tan “serias” que soleis hacer, BRAVO!

¿de verdad alguien se pregunta todavia para que sirve una vClase como esta?

No me lo creo

P.D. Estas vClases forman parte de una criatura mucho más potente vDeepCSS pero no depende solo de mi  hacerla  pública, cuando sea al momento  ya os la mostraré.

… un vObjeto es un ejemplar de una vClase en tiempo de ejecución …

… y vServer: “vatp://v7cloud5.velneo.com:6510” …

Voy a romper de nuevo mi esquema natural de posts, y es que esto de estar permanentemente en [MODO]: <storm brain training>, no se si es un “estado de gracia” o de “desgracia”, en realidad no es un estado, si no una “clase” y naturalmente “polimórfica”, por que joder! me acabo de cargar el software de los dos últimos meses!

Pero no os asusteis no he perdido nada, la anterior dirección del vServer contiene la primera vClase para que la veais en tiempo de ejecución, lo que ocurre es que me ha cambiado el prisma con el que veo v7 a la hora de abordar una aplicación, y claro está, estoy reescribiendo él código, orientando las partes susceptibles de ello, a crear un ecosistema de colaboración entre vClases a modo de mensajes que fluyen de unas a otras. Y ahora lo veo todo “flow” y no me puedo resistir a reescribirlo.

La primera consecuencia, es que no he aplicado CSS tal y como os prometí a la vClass_Main_ChooseColor, la he dejado como está. Asi que la vereis tal cual, “en ropa interior”, ya la vestiremos con otra vClase más adelante.

Y es que desde que lanzé los 2 últimos post, han sido muchas las vClases que a modo de tormenta de ideas, han llegado a mi pobre cabeza (además de un aluvión de e-mail’s). Algunas no me dejan dormir y estoy impaciente por implementarlas, pero todo tiene un orden natural en esta “estratégia de programación” y de momento me quedan por mostrar dos niveles más de implementación,

• vClases que llaman a vClases o ecosistemas de vClases formando un conjunto ligado o “libreria de vClases” que se llaman unas a otras  en un flow constante de comunicación interna, “yo no soy nada sin ti” ó “tu no eres nada sin mi” aunque siempre hay una Reina que pone el primer huevo .

• “vClases ligadas a datos”, vClases todavia en fase experimental, ya las veremos más adelante.

Por lo tanto, saltandome un paso previo os muestro en este vServer: “vatp://v7cloud5.velneo.com:6510” un primer ejemplo de “micro” libreria de vClases, que consta de 2 vClases con 5 subvClases.

No os digo que hacen cada una de ellas, mejor las veís en acción, pero ATENCIÓN para que todo funcione correctamente debeis alojar antes los archivos de recursos necesariós en las rutas especificadas, tal y como muestran las imagenes:)

Y aqui os dejo el enlace con el archivo vChip.rar que al descomprimir os creará los directorios necesarios con los archivos mencionados, pero revisar que sea todo correcto y quede así:

C:\vChip\vClases\vClass Main ChooseColor\cursor.gif

C:\vChip\vClases\vClass Main ChooseColor\Maiz_Saturacion.png

C:\vChip\vClases \vClass Gradient\inicio.png

C:\vChip\vClases \vClass Gradient\final.png

C:\vChip\vClases \vClass Gradient\pto rojo.png

Ahora si, una vez hecho esto ya sabeis:

vServer: “vatp://v7cloud5.velneo.com:6510”

A ELEGIR 5 entre usuarios:

usuario: demo1, demo2, …, demo5

password: demo1, demo2, …, demo5

si la haceis funcionar correctamente, ya me direis si os gusta …

Un saludo

P.D. El vServer solo estará disponible un par de dias, por que como imaginareis la libreria ya la he vuelto a modificar

Vamos a diseñar unos de esos singulares “artefactos” que respeten el formalismo de la programación orientada a objetos. Para ello he pensado en un artefacto que Velneo no lleva de serie y que a priori no parece que tenga mucha utilidad para una aplicación de gestión, un control ChooseColor, pero las cosas no siempre son lo que parecen.

Desde luego el ChooseColor es un artefacto que tiene toda la pinta de ser tratado como una clase, es un elemento completo, cerrado, con atributos y métodos propios y por lo tanto es un buen candidato a ser la primera vClase.

vClassChooseColor será un artefacto que podamos invocar de manera sencilla en cualquier parte de nuestra aplicación, capturando sus atributos y haciendo uso de sus métodos. Para ello implementaremos los cuatro mecanismos fundamentales ya mencionados, clases, métodos, objetos y mensajes, pero no nos quedaremos ahí eso solo es el comienzo.

A estas alturas todos conocemos los comandos de instrucción para el manejo de objetos que nos brinda Velneo, y que son la base para simular estos 4 mecanismos,

y de hecho los manejamos cotidianamente en nuestros desarrollos, pero generalmente lo hacemos como una abstracción funcional que incrustamos en una parte de nuestra aplicación respondiendo a la función o funciones a las que nuestra solución debe dar solución, y dejan de tener sentido o entidad propia una vez que las descontextualizamos de nuestra aplicación. Y esto es así por que por regla general nos limitamos a hacer uso de los comandos de instrucción para resolver nuestra necesidad más inmediata “la aplicación de nuestro cliente” y  “rápido que es para ayer”.

Si hacemos eso, por supuesto que nos dará resultado y probablemente salgamos como siempre del apuro, pero a la larga nuestro software se empobrecerá y nos costará reconocer qué partes de nuestro código son reutilizables y escalables.

Por el contrario, si cada vez que hacemos uso de los comandos de instrucción de objetos, lo hacemos bajo el prisma de la programación orientada a objetos, podremos construir software de mayor complejidad de una forma escalable, sencilla y 100% reutilizable. Pero no nos equivoquemos, hacer uso de estos comandos de instrucción, no es manejar clases, para manejar clases necesitamos mucho más que utilizar los comandos de instrucción.

Aunque sea una estupidez “empezaremos implementando mal una clase” para poder llegar a entender de forma más comprensible los requisitos que una vClase debe cumplir para respetar el formalismo de la programación orientada a objetos.

En el anterior post, ya os la presente y tenia esta pinta,

como vimos, en fase de diseño los dos mecanismos fundamentales que debemos articular son,

• El diseño formal de la clase, que en este ejemplo es el formulario vClass_ChooseColor.
• Y la definición del contrato programático API, que define la colección de atributos y métodos de la clase, que en nuestro caso será el formulario vClass_ChooseColor_API.

Veamos las primeras características de vClass_ChooseColor. Este en principio será un formulario cuyo conjunto de componentes representan un control que facilita la gestión del color a un usuario:

• El usuario podrá escoger el color que desee mediante métodos gráficos, bien sea desde una matriz de color Matiz-Saturación, o bien sobre una paleta de colores predeterminados. Además los métodos gráficos de la matriz Matiz-Saturación deben permitir posicionar un cursor sobre el píxel escogido, y los sliders de saturación y luminosidad deben dibujar en tiempo de ejecución el gradiente de color correspondiente al matiz seleccionado.
• Los colores se representarán bajo dos sistemas de coordenadas de color diferentes, el modelo RGB (Red, Green, Blue) y el modelo HSV (Matiz, Saturación, Luminosidad). Y por lo tanto deberemos crear controles para manejar los atributos de nuestra clase, R, G, B, H, S, V en los que podamos establecer directamente valores a los atributos, por ejemplo los RGB y la clase nos debe sincronizar automáticamente los métodos necesarios para devolver sus componentes HSV o viceversa.
• Por último para redondear el artefacto, le conferiremos un nuevo atributo a la clase, el atributo A, “la opacidad”, implementando los métodos gráficos necesarios para dibujar en el slider de opacidad el gradiente de opacidad sobre el color RGB o HSV seleccionado. Con lo que nuestro control sobre la gestión de cualquier color será completo.

Tengo que decir que no he cuidado en absoluto la estética del control ya que lo que me interesa es el motor no la carrocería y por supuesto a la clase le podemos pedir que haga algunas otras cosas que serian útiles para un control ChooseColor, pero de momento para nuestro objetivo fundamental es más que suficiente.

Además si este post no tratara sobre vClases, seguiría con un denso desarrollo de cómo conseguir que nuestro artefacto haga todas estas cosas, que no son pocas y desde luego no vienen de serie. Pero en principio de lo que aquí se trata, es de poder manejar este artilugio de una manera sencilla independientemente de su complejidad o de los mecanismos internos que utilice, que es donde reside la magia de las clases. Por lo tanto no vamos a ver como el artefacto hace todas estas cosas, si no que para aprender a diseñar y a utilizar una clase nos bastará con mostrar sus entrañas y saber que cometido tienen sus partes.

Este es el aspecto de nuestro formulario vClass_ChooseColor,

En cuanto a su utilización de forma intuitiva podéis adivinar como se maneja para controlar sus atributos. Por una parte tenemos una paleta de colores en la que podemos seleccionar un color clickando en el color deseado, por otra parte tenemos la matriz de color Matiz-Saturación en la que también podemos clickar para seleccionar cualquier color. Además de estos controles gráficos podemos acceder directamente a los modelos RGB y HSV con los sliders correspondientes o introducir valores directamente en los microscrolles. Y finalmente tenemos el control de la opacidad. También he mantenido dos testigos de color RGB y HSV para comprobar en tiempo de ejecución que la sincronización entre modelos de color es correcta y también hice un hueco para agregar colores personalizados a la paleta, pero no he tenido tiempo de implementarlo, me tendréis que perdonar.

En cuanto al diseño, para que esto funcione hemos necesitado las siguientes variables,

Unos cuantos eventos,

Y unas cuantas conexiones de eventos para que finalmente todo esto funcione,

ya veis estas son la tripas. Pero como os anticipaba antes, nos interesa manejar este artefacto como una unidad sencilla, independientemente de lo que lleve por dentro, por lo tanto para controlar el volante de este coche y poder conducirlo haremos uso del segundo mecanismo fundamental de la programación orientada a objetos en fase de diseño, el contrato programático ó API que no es ni mas ni menos que un hoja de instrucciones de nuestro juguete.

En la hoja de instrucciones API, diremos cuales son los atributos y métodos de esta clase, y obviamente la correspondencia ya la habréis establecido casi inmediatamente, atributos == variables, métodos == eventos. Y casi es así en este caso, y digo casi por que no todas las variables serán atributos de nuestra clase y no todos los eventos serán métodos de nuestra clase. Pero bueno veamos como montamos el API.

Dado que Velneo v7 no tiene herramientas internas de documentación de objetos, cosa que es bastante reprochable, para sortear este hecho he utilizado otro formulario en el que he incrustado una caja de texto. En la caja de texto haciendo uso del editor de fórmulas escribimos el contrato programático y como suele ser extenso podemos hacer uso de la vista previa del formulario en vDevelop para consultarlo con más facilidad. De modo que la API quedaría así,

Como veis en la API definimos que variables locales serán atributos de la clase y especificamos que rango de valores puede tomar el atributo, las unidades, si el atributo sirve para dar valores de entrada, salida o ambos y por último si el atributo hace cambiar el estado de la clase.

Por otra parte hemos indicado que eventos serán métodos de la clase, especificando cuales serán sus parámetros de entrada y salida.

Con esto a priori hemos terminado en primera instancia la fase de diseño, y ya podemos pasar a la fase de ejecución donde debemos articular los dos restantes principios fundamentales los objetos y los mensajes.

Y precisamente aquí, aunque aparentemente todo esta en su sitio y parece que vamos por buen camino, será donde pondremos de manifiesto de forma evidente que “hemos implementado mal la clase”.

Centrémonos pues en la fase de ejecución, un objeto será un ejemplar en tiempo de ejecución de una clase y un mensaje es un acto de invocación de un objeto en tiempo de ejecución. Veamos pues como invocamos un objeto y porque nuestro objeto todavía no puede tener la categoría de clase.

Para articular el mensaje, a modo de ejemplo estableceremos nuestro punto de partida en otro formulario, y en una parte del cual tendremos un control o campo al que le queremos establecer la propiedad color,

cuando hagamos doble click sobre el cuadrado background-color debe aparecer un objeto de nuestra clase vClass_ChooseColor, con el que seleccionaremos el color que deseemos y al aceptar su cuadro de dialogo devuelva los atributos de la clase a las variables locales de este nuevo formulario, R, G, B, A, H, S, V. Es más utilizaremos las variables RGBA para dar valores iniciales a nuestro objeto y de ese modo ya tengamos posicionado de inicio los controles en cierto color.

Pero veamos como articulamos el mensaje,

Esta claro que después de ejecutar este código habremos recogido en las variables locales R, G, B, A, H, S y V todos los atributos del color escogido y podremos construirlo y representarlo haciendo uso de ellos, pero ¿estamos utilizando una vClase? La respuesta es NO.

Como dijimos, lo que convertía a la programación orientada a objetos en el paradigma perfecto para realizar diseños basados en sistemas basados en abstracciones de datos (clases) era el uso de 6 características fundamentales, abstracción, encapsulación, herencia, polimorfismo, ligadura dinámica y genericidad. Y aunque dijimos que ni mucho menos todas estas características son soportadas por v7 (tan solo la abstracción) para conseguir que nuestro artefacto sea una clase, un ente autónomo, completo y cerrado debemos emular con los artificios que sean necesarios como mínimo, la encapsulación, el polimorfismo e incluso la ligadura dinámica.

Y atendiendo a nuestro primer diseño y mensaje nos daremos cuenta fácilmente,

Fijaros como al seleccionar una operación de paso de valores iniciales a la clase, por ejemplo el atributo R, en vDevelop tenemos acceso a todas la variables internas de la clase, variables que no son atributos de la misma y cuya modificación accidental suponen de facto una operación ilegal de la misma y nos provocarían errores de resolución tanto en los atributos de la clase como en sus métodos, ya que estas variables son las que utilizamos en el vChooseColor para hacer cálculos y operaciones auxiliares necesarias para dar funcionalidad al formulario pero no representan un atributo de la clase. Además el acceso se permite aunque declaremos las variables locales que no sean atributos, como privadas.

Para que una clase sea una clase, los atributos solo pueden ser modificados a través de sus métodos y de esta manera no se produzcan cambios de estado ilegales en la misma. Esto es lo que gestiona el encapsulamiento, protegiendo el núcleo de la clase y haciendo que su uso sea seguro. Por lo tanto algo deberemos variar en nuestro diseño para que esto se cumpla.

Otro aspecto a tener en cuenta también será el polimorfismo y  la ligadura dinámica.

El polimorfismo permitirá que podamos usar una clase bajo diferentes “formatos” ó “sub-diseños”, en nuestro caso el polimorfismo se podría aplicar a la clase para invocarla de formas distintas, por ejemplo:

1. tal y como la hemos presentado para retornar valores con la intervención del usuario haciendo uso del cuadro de dialogo.
2. exclusivamente como una función a la que le introducimos los atributos RGB y nos retorne los HSV sin presentación del cuadro de dialogo.
3. o también exclusivamente como una función a la que le introducimos los atributos HSV y nos devuelve las coordenadas RGB.

Por supuesto podríamos buscar otras combinaciones, pero para el ejemplo de hoy estos tres estados polimórficos serán más que suficientes.

Y dando tan solo un pequeño pasito más podemos emular la ligadura dinámica, que como dijimos es la capacidad que tienen algunos lenguajes de cambiar en tiempo de ejecución el objeto referenciado por otro objeto polimórficamente compatible. En nuestro caso podríamos seleccionar en tiempo de ejecución, desde nuestro formulario de origen, el modo de invocación bajo los tres estados polimórficos que hemos propuesto antes, con cuadro de dialogo, sin cuadro de dialogo RGB to HSV, o sin cuadro de dialogo HSV to RGB.

En cuanto al resto, la herencia, nonos resultará estrictamente necesaria para llegar al estado de vClase, y la genericidad sigue siendo una meta inalcanzada que nos permite seguir soñando.

Vamos a cambiar pues nuestro diseño actual para llegar al estado deseado de vClase (que la verdad dicho así, parece que vaya a ser el Nirvana). El nuevo diseño propuesto seria:

Como veis la complejidad de la clase a nivel estructural ya ha crecido, en la carpeta vClassChooseColor colocamos solamente la API y la nueva clase madre vClass_Main_ChooseColor que ya se ha transformado en un proceso (que es el objeto, perdón corrijo, la “abstracción funcional” más potente que tenemos en Velneo y no lo llamaré objeto porque recordar que hemos definido objeto como un ejemplar de una clase en tiempo de ejecución).

Como veis paralelamente a la API y a la vClase no debemos poner ningún elemento más, el resto de componentes que nos ayuden a definir la vClase y sus posibles subClases o estados polimórficos los colocaremos en una subcarpeta que he llamado “Core_Class”, adivinareis que en esta carpeta residen los elementos encapsulados de la vClase, elementos que nunca deberemos invocar para hacer uso de la vClase y motivo por el cual están situados fuera de ella. El único elemento que debe llamar a estas subClases alojadas en el Core Class es la propia vClass_Main_ChooseColor.

También habréis reconocido en la imagen los tres modos de invocación de la vClase propuestos que formaran las tres subclases hijas, representados por la ya conocida vClass_ChooseColor (formulario), y los procesos vClas_ChooseColor_RGB_TO HSV y vClas_ChooseColor_HSV_TO_RGB que nos devolverán los métodos de transformación de coordenadas de color sin la intervención del usuario en un cuadro de dialogo.

Como curiosidad os puedo enseñar el código para transformación de coordenadas  de las subClases RGB_TO_HSV,

y el código de la transformación de coordenadas HSV_TO_RGB

pero estos procesos los muestro solo a efecto de curiosidad por que a lo que debemos prestar especial atención es a la implementación de vClass_Main_ChooseColor, que hará posible emular el encapsulamiento, el polimorfismo y la ligadura dinámica.

Como podéis ver, la clase madre solo tiene como variables locales (atributos de la clase) las que verdaderamente escogimos en la API inicial (RGB – HSV – A), y ya no aparecen las variables auxiliares cuyo uso accidental podrían provocarían un mal funcionamiento de la clase, es decir un cambio de estado. De esta forma estas variables auxiliares y sus métodos quedarán encapsulados en el Core Class y cuando invoquemos la clase vClass_Main_ChooseColor no tendremos acceso a los datos encapsulados.

Entonces resulta obvio decir, que ahora solo podremos asignar valores a los atributos declarados en la API y que solo podremos modificarlos haciendo uso de los métodos de la clase, (vSubClass ChooseColor, vSubClass ChooseColor RGB to HSV, vSubClass ChooseColor HSV to RGB), ya que este proceso de asignación de valores iniciales o finales a los atributos no modifican el estado de la clase. Por lo tanto objetivo encapsulación conseguido.

Por otra parte tenemos un nuevo atributo MODO, esta variable local nos permitirá gestionar el polimorfismo de la vClase invocándola en modo cuadro de dialogo o procesos (dados nuestros ejemplos) y por supuesto a gusto del consumidor podríamos hacerlo directamente mediante código ó en tiempo de ejecución con lo que aparecería la ligadura dinámica.

Ya solo queda decir que el mensaje de invocación de las vSubclases dentro de la vClase representa un anidamiento de declaración de objetos, que tácitamente sigue el mismo formalismo, y como podemos observar para el MODO 1 seria,

para el MODO 2,

y para el MODO 3,

Y la API en esta ocasión quedará,

Con esto en principio volvemos a tener cerrada la fase de diseño de nuestra vClase. Volvamos ahora de nuevo a la fase de ejecución.

Partimos de nuevo desde nuestro formulario de origen,

¿Cómo articularíamos el mensaje de invocación ahora? Dado que el articulo ya es de por si un poquito largo, para no extendernos demasiado veremos la invocación en modo cuadro de dialogo, ya que el resto de modos ya os resultaran obvios. Entonces seguiremos diciendo que al hacer doble click sobre cuadrado background-color, invocaremos a nuestra vClase de la forma:

Y fijaros bien ahora en esto,

Como hemos dicho los atributos a los que tengo acceso desde el formulario de origen del mensaje con la vClase, solo son los declarados en la API, el resto esta encapsulado en el Core Class, a salvo de posibles invocaciones ilegales que dañarían la clase. Además también resulta obvio que la única manera de recoger cambios de estado en los atributos de la vClase es a través de los métodos declarados en la API.

Con lo cual esto ya empieza a funcionar correctamente, de forma sencilla y segura, pero ¿esta es una clase autónoma y cerrada? La respuesta es NO, aunque no es obvia y por lo que hemos visto hasta ahora es difícil de deducir.

Debemos pensar que una Clase debe ser un elemento autónomo que podamos no solo invocar de manera sencilla bajo el formalismo de la programación orientada a objetos, tal y como hemos visto hasta ahora. Si no que además debemos ser capaces de insertarla en nuestra solución de forma completa y cerrada, y para ello todos y cada uno de los elementos que la componen no deben presentar dependencias con otros elementos alojados fuera del Core Class. Si esto es así, siempre podremos cortar y pegar una vClase desde una solución a otra sin consecuencias o efectos secundarios que supongan un malfuncionamiento de la vClase y nuestro artefacto en este caso ya será un elemento 100 % portable y 100% reutilizable, con lo que ahora si, habremos cerrado la vClase y ya será un ente autónomo, ¡POR FIN!, POR FIN! YA ERA HORA!.

En consecuencia, para que vClass_Main_ChooseColor sea cerrada y autónoma, debo desvelar parcialmente algunos secretos que esta primera joya lleva alojados en su interior para representar los métodos gráficos.

El primero de los secretos para representar los métodos gráficos de forma autónoma será una constante con un carácter especial que me permita realizar las tareas que necesito directamente en el editor de formulas, de manera que la vClase quedaría de esta forma,

El segundo de los secretos, y “paquete adicional” que pueden llevar todas la vClases son las “carpetas de recursos” (o librerías) y que debemos alojar en el directorio donde tenemos instalado el vClient.

yo personalmente crearía una carpeta con donde alojar todos los recursos que necesitaran la vClases de mi solución, y dentro de esta carpeta otra subcarpeta con los recursos que vamos a utilizar, que son:

Os suenan los recursos, pues quizás otro día explique como funcionan pero hoy no por favor.

Ahora si, ahora ya hemos acabado, tras estos últimos ajustes la vClase ya es completa, autónoma, cerrada, de fácil invocación y 100% reutilizable. Y sobre todo y lo mas importante, responde a la estrategia de la programación orientada a objetos, que como veis dista mucho del mero hecho de manejar objetos, y centra toda su potencia en crear un ecosistema colaborativo de mensajes que fluyen entre clases que permite escalar en nuestro software de una manera espectacular, creando estructuras de datos complejas de fácil invocación.

A modo de apunte, recordaremos que en Velneo son bastantes los objetos que podemos manejar, formularios, casilleros, procesos, cestas, búsquedas, localizadores, rejillas, etc … y todas estas abstracciones funcionales las podemos convertir en vClases.

Pensemos por un momento, en las consecuencias de este paradigma, os imagináis por ejemplo ¿como seria la vClase_Agenda? UAh! Vaya control! Me encantaría tenerlo en todas mis aplicaciones de gestión e invocarla de forma sencilla pasándole los parámetros de la tabla que me interese en cada momento.

O por ejemplo, ¿debería Velneo dedicar el tiempo en crear la subindexación en los localizadores? O por el contrario creamos la vClase_Localizador_Indexado, con la potencia que me permitiría la personalización de mi localizador.

Yo ya tengo los primeros esbozos de estas clases, y no resultan complicados de implementar, como siempre solo nos falta tiempo.

Fijaros que con la orientación a vClases podríamos resolver de forma nativa, muchas de las mejoras que estamos pidiendo día a día a la plataforma. O incluso atacar estructuras complejas de las que actualmente no nos atrevemos, por considerarlas inabordables, como pueda ser el caso de un sistema integral de geoposicionamiento en Velneo, creando las clases necesarias para que el sistema funcione.

En fin esta es solo una primera aproximación del paradigma, y a esta alturas quizás lo que más os interese es ver en acción la primera vClass_Main_ChooseColor, y lo que toca es colgarla en un vServer con las instrucciones oportunas para que la veáis trabajando. Solo darme un par de días, para vestirla con un CSS adecuado y montar el tinglado con usuarios suficientes, por que no se vosotros pero yo necesito descansar.

“… no es solo una BD relacional …”

“… no es un lenguaje de programación genérica …”

“… lo que está claro es que se trata de un producto “abstracto”, y su desarrollo esta basado en abstracciones funcionales…”

“… por lo tanto parece un lenguaje estructurado…”

“… joder! y no paramos de ver objetos, ¿es un lenguaje orientado a objetos? no lo se …”

“… ¿y el código? no lo veo, solo hay objetos contenedores de comandos de instrucción …”

“… y vaya comportamiento! aquí hay errores de definición, una conexión de evento en realidad es un evento, un evento es un proceso,  un proceso es una pseudo-función, y una función ya no se lo que es …”

“… conecta de forma aceptable con otras tecnologías y funcionalmente integra el cloud computing …”

“…está claro que este modelo de desarrollo funciona y da buenos resultados pero no se, no lo acabo de asumir …”

Desorden, es la única conclusión clara que tenia. Seguía sin las ideas claras pero aun así podía desarrollar soluciones basadas en la DB y el resultado era aceptable. Tras este periodo de evaluación y aprendizaje (que no acaba nunca) impulsado y de la mano de un buen amigo (velneador hace 20 años) le tocó el turno al primer proyecto serio, ¿cliente? por supuesto una empresa, por lo tanto aplicación orientada a los datos.

Para las aplicaciones empresariales la mayoría de los desarrolladores casi de forma automática piensan en la consistencia de la BD, “… la solución debe ser robusta y estable, blindando los datos del cliente …” “ …esto en la BD lo haré así y asa, … ahora hago esto y luego lo otro que es muy rápido y rentable y los hago como churros …”  son gente generosa y piensan en como solucionar los problemas a los demás y encima trabajan rápido con lo cual todos contentos. En V7 no deja de ser distinto, e incluso esta tendencia es todavía mayor dada la filosofía de desarrollo basado en abstracciones funcionales. Todo es tan funcional y ahorra tantas tareas que lo adoptas sin más en un desarrollo compositivo casi de forma secuencial como generalmente hace cualquier RAD y la verdad es que funciona.

Desde la lejanía ha esto se le llama, programación estructurada, el paradigma de la programación estructurada centra la construcción de software en la creación de abstracciones funcionales organizadas de forma compositiva de acuerdo a una estructura jerárquica. La solución principal se descompone funcionalmente en subproblemas, que a su vez se descomponen en abstracciones funcionales más sencillas, hasta llegar a operaciones atómicas. El problema de esta aproximación es que asume, irrealisticamente, que la especificación del problema no cambia a lo largo del tiempo de desarrollo del proyecto, y además la reutilización de cada descomposición esta confinada al contexto funcional donde aparece implicado.

Pero volviendo a nuestro problema ya llevaba varias semanas con los primeros desarrollos imbuido y contagiado por  este modo de hacer, haciendo uso de todas las abstracciones funcionales que brinda Velneo, rápidas, compositivas, y ya iba siendo hora de cerrar alguna de las partes para sumarla al proyecto, y lo primero que pensé es, esto es serio y no puedo dejar en mal lugar a mi amigo, además mi situación personal no me permite estar a “full time” en el proyecto y cada proceso completado por mi debe servir a cualquier desarrollador del proyecto, y que aunque cambien las necesidades del problema se utilicen mis procesos, sin necesidad de repetirlos casuísticamente, por que de lo contrario en la practica yo no voy a ser útil.

En consecuencia cada cosa que termine debe ser un “artefacto” completo que sirva a mi propósito y que sea utilizado por los demás miembros del proyecto en lo sucesivo, para realizar la tarea para la que ha sido creado, de manera que se pueda crear un ecosistema de colaboración entre artefactos.

Flash! y de repente se me encendió la luz (que ya es raro) hice las primeras pruebas (no sin algún tropiezo) y joder! funcionaba la filosofía!, Velneo v7 empezó a tomar forma y a ser redondo para mi, todas las excentricidades de la herramienta parecían tener sentido y cada objeto de la herramienta (de forma consciente o inconsciente) encajó en un engranaje perfecto para mi propósito, y sobre todo para un formalismo que si que soy capaz de asumir sin péros, el paradigma de la programación orientada a objetos.

La construcción de software orientado a objetos es el método de desarrollo de software que basa la arquitectura de un sistema de software en artefactos deducidos de los tipos de objetos que este manipula, en lugar de basarse en la función o funciones a las cuales el sistema debe responder.

En absoluto digo que Velneo es un lenguaje de programación orientado a objetos, para eso aun le queda mucho camino, como veremos mas tarde, lo único que digo es que se puede programar nativamente en velneo bajo el formalismo de la programación orientada a objetos, con todo el beneficio que ello supone, por que v7 tiene las herramientas necesarias para respetar el formalismo, no las adecuadas, pero si las básicamente necesarias (y llama la atención que ninguna de las Open Apps que hay en el catalogo lo respeten. Por supuesto muchos desarrolladores utilizan fantásticamente las herramientas de Velneo que hacen posible un desarrollo basado en objetos, pero generalmente lo hacen desde la deriva de la programación estructurada).

El paradigma de la programación orientada a objetos se articula esencialmente a través de cuatro mecanismos fundamentales: Clases, métodos, objetos y mensajes. Los dos primeros tienen lugar en fase de diseño, mientras que los segundos corresponden a fase de ejecución.

Fase de diseño:

• Clases: Una clase es una especificación formal y computable que se utiliza para construir objetos de un mismo tipo en fase de ejecución. Internamente esta compuesta de una colección de atributos y una serie de operaciones.
• Métodos: La colección de métodos de una clase define las capacidades de la misma y conforma un contrato programático (API) para acceder o alterar los atributos de la misma. Los métodos generalmente ocultan su implementación al resto de clases y se perciben como artefactos de fácil invocación.

Fase de ejecución:

• Objetos: Un objeto es un ejemplar de una clase que reside en memoria durante cierto tiempo en la fase de ejecución. Esta formado por un estado definido a partir del valor que toma en cada momento cada atributo de la clase en ese ejemplar.
• Mensajes: Diremos que un mensaje es el acto de invocación de un objeto en tiempo de ejecución. Los algoritmos de la programación orientada a objetos representan la colaboración entre clases, en términos de mensajes que fluyen de unos a otros.

Estos cuatro mecanismos fundamentales pueden ser emulados en v7 perfectamente, teniendo Velneo las herramientas necesarias para ello.

Pero lo que convierte la programación orientada a objetos en el paradigma perfecto para realizar diseños basados en sistemas centrados en abstracciones de datos (clases) es el uso de 6 características fundamentales: abstracción, encapsulación, herencia, polimorfismo, ligadura dinámica y genericidad.

Para no extenderme no explicaremos que obviamente, v7 soporta excelentemente la abstracción. Pero por el contrario el resto de características fundamentales ya no las soporta.

La encapsulación, es el proceso por el cual la colección de métodos de una clase protege el acceso ilegal al estado de un objeto por parte de otros objetos. De esta forma los atributos de una clase no son directamente alterables sino solo a través de métodos de la clase. Esta característica no se puede soportar en v7 y veremos como si es posible alterar los atributos de una “vClase”.

La herencia es un mecanismo que permite organizar un conjunto de clases de acuerdo a una jerarquía, de manera que se pueden compartir datos y métodos entre clases. Tampoco es esta una característica que se pueda construir con los objetos que disponemos en v7.

La herencia permite que un objeto pueda tratarse como una instancia de la clase a la que pertenece y de cualquiera de las clases que son padre de esta, por eso un objeto puede tener diferentes tipos y lo llamamos polimórfico. Y lógicamente no es esta una propiedad que soporten los objetos velneo (sin embargo me llama la atención que el “arquitecto” de Velneo si que utiliza el polimorfismo en vDevelop, fijaros por ejemplo como cuando seleccionamos un control de un formulario en el editor, y nos fijamos en la pestaña de propiedades podemos cambiar el tipo de control, por ejemplo hacemos que de “edit” pase a ser un “dibujo”, esto es usar el polimorfismo).

La ligadura dinámica es la capacidad que tienen algunos lenguajes orientados a objetos de cambiar en tiempo de ejecución el objeto referenciado por otro objeto polimórficamente compatible. ¿Que creéis que hace el “alternador” en C++? pues hacer uso de la ligadura dinámica, sin embargo en v7 no tenemos posibilidad de emular semejante comportamiento.

Y ya mucho más abstracta seria hacer uso de la genericidad, que permite abstraerse de los tipos de objetos con los que trabaja internamente una clase por medio de la parametrización de los mismos y generalizar su manejo para cualquier clase, pero esto sería ya rizar el rizo.

En fin, no vamos a pedir que v7 sea un lenguaje orientado a objetos, por que podéis comprobar que sería mucho el camino que debería recorrer para que así fuera, y personalmente no creo que lo necesite ni es el objetivo de v7. Velneo centra su potencia en su BD y en las herramientas necesarias para la creación de aplicaciones empresariales y este foco no hay que cambiarlo.

Pero sin embargo ¿podemos crear vClases, haciendo uso de los formalismos fundamentales de la programación orientada a objetos, basando la arquitectura de determinadas partes de nuestro software en el manejo de vClases, en lugar de basarla en la creación de abstracciones funcionales organizadas de forma compositiva como solemos hacer en v7?

Si hacemos uso de esta estrategia obtenemos fundamentalmente dos beneficios, podemos crear “artefactos” “vClases” que realicen tareas complejas, que sean de fácil invocación y uso desde cualquier parte de la aplicación, siendo estos elementos cerrados que solo necesitamos programar una sola vez y utilizar siempre en cualquier nueva aplicación.

Y otra que no es tan funcional pero que es muy útil, dado que debemos establecer el contrato programático, la API de la vClase, documentando los atributos de la clase y su colección de métodos, nos obliga a escribir la documentación de desarrollo que todo software necesita, y que habitualmente dejamos para casi nunca, y por supuesto casi nuca se hace.

Pues vamos a recopilar, lo visto hasta ahora:

• Queremos crear “artefactos” que realicen tareas complejas, que sean de fácil invocación y uso desde cualquier parte de la aplicación.
• Deben ser elementos cerrados que solo necesitamos programar una sola vez y utilizar siempre en cualquier nueva aplicación.
• Para construir estos artefactos vamos a utilizar el formalismo de la programación orientada a objetos.
• Para utilizar el formalismo implementaremos los 4 mecanismos fundamentales de la programación orientada a objetos, Clases, métodos, objetos y mensajes, mecanismos que se pueden emular en v7.
• Por último debemos tener en cuenta que de las características abstracción, encapsulación, herencia, polimorfismo, ligadura dinámica y genericidad, solo podemos hacer uso de forma rigurosa de la abstracción y por contra debemos tomar las medidas necesarias en el uso de las vClases para respetar la encapsulación y no alterar el estado o los métodos de las vClases en el uso de las mismas. Para ello habrá que especificar rigurosamente en la API el uso los métodos y atributos de la vClase para que esta no resulte dañada.

Como veis casi es un memorando de mis preocupaciones a la hora de basar un desarrollo de software serio, de forma colaborativa, sencilla, potente, cerrada, ordenada, con artefactos completos en los que cada paso suma, y por supuesto 100% reutilizable.

¿Os atrevéis con una primera y sencilla vClase? Aquí os la presento. 

Pero mejor lo dejamos para el próximo bonus track. Je!Je!.

Parafraseando a Fray Luís de León “como íbamos diciendo …” hemos definido de forma teórica lo necesario para desarrollar tanto la BD como todo lo relacionado con el AEB43. Casi estamos preparados para empezar con v7,  y digo casi porque solo quedaría por definir las especificaciones de usuario, interfaz y usabilidad, es decir ¿como queremos que sea nuestra aplicación? ¿quien la debe usar y como la debe usar? etc…

Cuestiones estas que me parecen pseudo-filosóficas, por lo que dado que soy “novato” en la herramienta y esto es un blog de iniciados, quizás sean estas metas muy elevadas para nuestro pobre bagaje, y he decidido modificar el orden de los capítulos y dejar esto para cuando ya hallamos obtenido nuestra primera beta de vCriatura bajo la deriva de la herramienta Velneo. Es decir, veamos a lo que nos conduce dejarnos llevar, y sopesemos los resultados. Y una vez obtenidos los primeros resultados, definamos nuestras propias exigencias, interfaz, usabilidad especificaciones de usuario y comprobemos si ya nos sirven algunas de las partes generadas por Velneo.

Por lo tanto, manos a la obra y empecemos por la BD Velneo. ¿Puede Velneo representar la BD relacional que postulamos de forma teórica? uah!Ja!Ja! estarán pensando los ya evangelizados en la doctrina Velneo, y la verdad es que tienen razones para reírse de forma compasiva cuando observan desde las alturas a otras BD, por que pocas BD se adaptan con tanta elasticidad al modelo real, pero aún les restan algún camino por recorrer.

¿Como queda pues nuestra BD en Velneo? ¿Chula verdad?

Su editor de esquemas nos muestra que el grafo en el modelo de Velneo se adapta fielmente a lo deseado de forma teórica, y mediante fechas azules y rojas representa la naturaleza de las relaciones (o enlaces) entre tablas. En general diremos que las flechas azules representan relaciones de uno a uno (enlace singular) y las rojas de uno a n (enlace plural). Vamos a ver cada una de las tablas de la BD:

Especificación de la estructura de la tabla Bancos, tipo maestro con clave numérica:

Dado que estamos en un desarrollo pseudo-paso a paso, nos saltaremos el asistente para la creación de tablas y solo diremos que para la creación de nuevos campos pulsaremos:

 Así si que “cunde”! Y escogeremos los tipos de datos en función de las necesidades de cada campo según lo mostrado en la imagen anterior. Hasta aquí no necesitamos de campos enlazados,  pero por el contrario esta tabla tiene relaciones con otras, ¿como las estableceremos?. Para ello atendamos a las siguientes frases semánticas postuladas antes a nivel teórico:

“una Cta. de tesorería pertenecerá a un banco” (enlace singular) y “un banco podrá tener varias cuentas de tesorería” (enlace plural)

Sabemos que existe relación con la tabla “Cuentas Tesorería” pero en la tabla maestra “Bancos” ninguno de sus campos es de tipo enlazado a otras tablas, por lo tanto ¿donde debemos indexar y definir enlaces para relacionar ambas tablas?  La respuesta obvia es en la tabla submaestra “Cuentas de Tesorería”.

Creemos pues la tabla “Cuentas de Tesorería” con los campos básicos Id y Name, y vamos a establecer la relación con la tabla “Bancos” . Para crear un nuevo campo enlazado haremos uso del botón:

Y crearemos un campo enlazado a la tabla “Bancos” con lo que definimos el enlace singular. Por otra parte para crear un nuevo índice:

Haremos uso del botón indicado, y crearemos un nuevo índice banco, con el campo enlazado banco y de esta manera establecer el enlace plural. Al dar de alta el campo enlazado y el índice en la tabla Cuentas Tesorería se crean y definen los enlaces que buscamos y automáticamente aparecen las flechas azules y rojas que así lo indican en el editor de esquemas, además de aparecer el enlace plural en la tabla bancos :

de forma que la tabla “Cuentas Tesorería” queda así:

bueno aquí hay mas tomate, pero eso mejor lo vemos en el próximo post y asi no se hacen tan pesados y son mas fáciles de escribir.

Ya tenemos definida la estructura básica de la BD, por lo tanto vamos a centrarnos hoy en:

• La estructura y normas del cuaderno AEB43.
• Los algoritmos de importación de cuadernos AEB43 mediante ficheros ASCII.
• La consolidación de los cuadernos AEB43 en apuntes de tesorería.

El temario es aburrido, así que este post necesariamente será un poco pesadito de digerir, en primer lugar utilizaremos un documento oficial, de la Comisión de Organización Automación y Servicios (COAS) donde se recogen formalmente la serie de normas y procedimientos bancarios Nº 43 (aquí os dejo el enlace AEB43, que estará permanentemente en la página de descargas del blog). En el documento tenéis la información completa de la norma 43, ya que para el desarrollo de vCriatura  simplificaremos los posibles casos de AEB43, centrándonos en los aspectos básicos y generales de la norma.

Esta sería la primera imagen de un AEB43:

No intentéis validarla que no funcionaría, los datos no son coherentes pero la imagen nos sirve. En esa imagen tenemos todas las características que comentábamos en el post anterior, es decir:

• El AEB43 recoje el conjunto de movimientos de tesorería durante un periodo, especificando la fecha, el tipo de movimiento o servicio, y el saldo inicial y final del extracto.
• El AEB43 pertenece exclusivamente a una cuenta bancaria de tesorería.
• La cuenta bancaria de tesorería pertenece exclusivamente a una entidad bancaria.

La estructura de los datos la tenéis descrita en detalle en el documento del COAS C-43 anterior, pero como vamos a simplificar básicamente lo que nos dice es que la información del AEB43 se organiza de la siguiente forma:

Escogeremos la modalidad 2 (ver doc. COAS C-43 no la explico pero diré que es la más común), ademas ya que es posible que un AEB43 contenga extractos de más de una cuenta de tesorería, simplificaremos y lo vamos a reducir a una sola cuenta de tesorería por AEB43 (que también es el caso mas común). A partir de aquí tendremos siempre una estructura de registros que reproduce las características implementadas en la BD.

A groso modo como veis el AEB43 tiene un registro inicial de cabecera (que es obligatorio) y  donde los datos que contiene son:

(repetimos las especificaciones de los campos las teneis en el doc. COAS C-43)

Despues vienen los bloques de registros de movimientos, con el detalle de los movimientos del extracto y contendrá tantos bloques como movimientos contenga el extracto. Cada bloque de registros contiene obligatoriamente un registro principal de movimientos y opcionalmente podrá contener hasta 5 registros complementarios de concepto y un registro de complementario de equivalencia.

El detalle del registro principal de movimientos es el siguiente:

El detalle del registro complementario de concepto es el siguiente:

Y el detalle del registro complementario de equivalencia es el siguiente:

Por último para cerrar el fichero se presentarán obligatoriamente el registro final de cuenta y el registro de fin de fichero, cuyo contenido es:

Con esto ya hemos destripado con bastante detalle el AEB43, pero ¿que relación tiene con nuestra definición de BD? La relación es obvia y gráficamente más:

El cuerpo lo almacenaremos en la tabla Movimientos AEB43 y la cabecera y final del fichero en la tabla AEB43.

Ya que desgraciadamente no somos entidades financieras, solo nos tenemos que preocupar de leer correctamente el fichero ASCII y guardarlo en nuestra BD. Entonces ¿cual será el algoritmo de importación del fichero ASCII AEB43 a nuestra BD?

Como veis hemos construido un algoritmo sencillo sin anidamientos, que recorre secuencialmente dos veces el fichero, la primera para leer campos y guardar un registro en la tabla AEB43 (con los registros cabecera, final cuenta y fin fichero) y la segunda vez volvemos a recorrer secuencialmente todo el fichero para leer bloques de registros (ppal mov., compl. concepto y compl. equivalencia) y guardar en tabla Movimientos AEB43 tantos registros como bloques leamos. Resulta obvio decir que al grabar registros de Movimientos AEB43 indicamos también a que AEB43 corresponde el movimiento.

El último paso pues, seria dada una cuenta de tesorería localizar sus AEB43 correspondientes (hecho que ya teníamos resuelto con la relación R5 mencionada en el post anterior) y establecer la correspondencia entre los movimientos AEB43 y los apuntes de tesorería para consolidar el AEB43 en la tabla de apuntes de tesorería. Pero dado que nuestra intención es hacer una aplicación básica, haremos que sea el usuario a través de la interfaz de la aplicación el que gestione los AEB43 y autorice la consolidación de las colecciones de movimientos en apuntes de tesorería:

Esta claro que podríamos prescindir de la gestión del usuario para el traspaso de datos entre las tablas Movimientos AEB43 y Apuntes de tesorería, pero resultaría menos didáctica la aplicación y no es lo que pretendemos.

En fin tras este otro rollo, ya tenemos definido de forma teórica lo necesario para desarrollar tanto la BD como todo lo relacionado con el AEB43. Casi estamos preparados para empezar con v7,  y digo casi porque solo quedaría por definir las especificaciones de usuario, interfaz y usabilidad, es decir ¿como queremos que sea nuestra aplicación? ¿quien la debe usar y como la debe usar? ¿desde donde debería acceder el usuario? ¿bajo que medios o dispositivos? ¿como queremos que la aplicación resuelva las tareas? ¿con que herramientas? Etc…

Pero mejor lo dejamos para el próximo post, por que a mi esas me parecen cuestiones pseudo-filosóficas.

Como definimos en el análisis funcional vCriatura será un gestor de cuentas bancarias de Tesoreria normalizado, que debe cubrir  básicamente las siguientes areas:

• Titulares
• Bancos
• Cuentas bancarias
• Multi-titularidad de cuentas
• Extractos
• Apuntes de Tesoreria
• Gestor de cuadernos AEB43
• Importador de ficheros ASCII AEB43
• Consolidación cuaderno AEB43 en apuntes de tesoreria.

Solo con leer las funcionalidades pedidas, todos os habreis hecho una idea de los aspectos básicos que hay que cubrir, pero ¿pensaís en los mismos que yo?.

Seguramente cada uno de nosotros tengamos un concepto similar, pero distinto, así que inicialmente vamos a sobrevolar estos aspectos básicos, por lo que quizás no hagamos más que decir obviedades (del estilo – “esto es una manzana” ) pero aunque resulte un poco estúpido, será necesario para definir teóricamente la solución y poder compararla posteriormente con los resultados (si somos capaces de obtenerlos, claro esta).

Una cuenta bancaria es un contrato financiero con una entidad bancaria en virtud del cual se registran el balance (es decir el saldo) y los subsiguientes movimientos (apuntes) de dinero del cliente (o tiltular de la cuenta).

Podrán ser una o varias pesonas los titulares de una cuenta bancaria y los servicios que vayan asociados a una cuenta bancaria dependerán en gran medida de la entidad y de la finalidad de la cuenta, en nuestro caso particular hemos centrado el tema especificamente en cuentas bancarias de “tesoreria”.

Para las cuentas bancarias de tesoreria, los servicios más comunes suelen ser, por ejemplo:

• Ingresos y pagos en efectivo.
• Ingresos y pagos de cheques.
• Domiciliaciones de recibos.
• Emisión recepción de Transferencias.
• Pago de impuestos
• etc …

El conjunto de movimientos (apuntes) de una cuenta bancaria que refleja los sevicios asociados a la cuenta de tesoreria, será en consecuencia nuestro “extracto bancario”.

El primer concepto fundamental es el de “extracto bancario normalizado” que en realidad es la situación que pretendemos emular y gestionar con vCiratura. Cuando pensamos en un extracto bancario pensamos en una imagen mas o menos como esta:

En ella reflejamos todas las definiciones recogidas anteriormente:

• El extracto recoje el conjunto de movimientos de tesoreria durante un periodo, espefificando la fecha, el tipo de movimiento o servicio, y el saldo (balance) tras el movimiento.
• El extracto pertenece exclusivamente a una cuenta bancaria de tesoreria.
• La cuenta bancaria de tesoreria pertenece exclusivamente a una entidad bancaria.
• La cuenta bancaria de tesoreia podrá tener uno o varios titulares.

En consecuencia nuestra solución deberá reproducir y gestionar este conjunto de relaciones. ¿Cual será pues el modelo de datos? ¿Que estructura de tablas utilizaremos y como las relacionarenos para reproducir la situación?

Puntualizaré que estamos en el desarrollo teórico, y para nosotros de momento no existe Velneo. Teniendo en cuenta esto, la estructura de datos elegida, aplicable a cualquier BD relacional sería:

En primer lugar elegimos una tabla Bancos donde recogemos los datos de las entidades bancarias, una tabla Ctas.Tesoreria donde recogemos los datos generales de las cuentas de tesoreria, y estableceremos la relacion (R1) entre estas tablas indexando las cuentas de tesoreria por banco.

En segundo lugar, para resolver la Multi-titularidad de cuentas en la que una cuenta de tesoreria podrá tener varios titulares y un titular podrá tener varias cuentas de tesoreria, ademas de crear la tabla Titulares donde recogemos los datos de los titulares, creamos una tabla puente Titulares-Cuentas indexando la relacion entre ambas tablas doblemente, donde definiremos una relación (R2) para resolver que cuentas de tesoreria tiene un determinado titular, y otra relación (R3) para resolver que titulares tiene una determinada cuenta de tesoreria.

Y en tercer lugar, creamos una tabla  Apuntes donde recogeremos todos los movimientos de tesoreria, estableciendo la relación (R4) entre esta tabla y la tabla Ctas. Tesoreria indexando los apuntes de tesoreria por cuenta de tesoreria.

Hasta ahora, podríamos decir que hemos definido teóricamente la primera parte de la estructura básica de la BD, otra cuestión será ¿como utilizamos Velneo para implementar esta estructura? y sobre todo ¿que definiciones y objetos v7 utilizaremos para implementar las relaciones (R1, R2, R3, R4) definidas de forma teórica?

Las respuestas a estas perguntas las encontraremos en los capitulos dedicados a la implementación y no en la parte teórica, por lo que no nos vamos a adelantar ya que antes tenemos que realizar otras tareas previas.

• Debemos definir teóricamente la segunda parte de la estructura básica de la BD, es decir la definición y gestión del cuaderno 43 del Consejo Superior Bancario, dando por cerrada la definición básica de la DB.
• Debemos definir los procedimientos de importación de AEB43 mediante ficheros ASCII y definir la consolidación de los cuadernos AEB43 en apuntes de tesoreria.
• Y por último deberemos definir los requerimientos de usuario, interfaz y usabilidad.

Vamos pues a definir la 2ª parte de la BD, y para ello lo primero que tendremos que dejar claro es ¿que es un gestor de cuadernos AEB43? O mejor dicho ¿que es un AEB43?.

Pues bien, las entidades bancarias españolas a traves de sus respectivas asociaciones, Asociación Española de Banca (AEB), Confederación Española de Cajas de Ahorros (CECA) y Unión Nacional de Cooperativas de Credito (UNACC), crearon un marco comun, con una serie de procedimientos y normas de organización y comunicación de información bancaria de determinados servicios comunes a todas ellas, para la automatización de procesos entre los clientes y la banca.

Esta serie de procedimientos y normas vienen recogidos en lo que llamamos cuadernos bancarios, y cada uno de estos cuadernos estan asociados a diversos serviciós que prestan las entidades bancarias a sus clientes, por ejemplo:

• AEB19 (o cuaderno 19, C-19): Emision de recibos domicialidos.
• AEB58 (o cuaderno 58, C-58): Emisión de anticipos de crédito.
• AEB34 (o cuaderno 34, C-34): Emision de transferencias.
• AEB32 (o cuaderno 32, C-32): Emision de efectos comerciales.
• Etc …

La utilidad de estos cuadernos en la automatización de procedimientos bancarios con sus clientes es sencilla pero potente, y permite agilizar los procedimientos de comunicación entre ambos. Como todos sabemos que hay clientes bancarios que tienen la necesidad de emitir de una sola vez, por ejemplo 250 ó 1.000 transferencias, lo del número es lo de menos. Seria una tarea muy ardua si nos plantasemos en la ventanilla de un banco y le dijeramos al cajero – Buenos dias! Quisiera emirtir estas 3.000 transferencias. La cara del cajero seria un poema. Para evitar esta situación utilizariamos un cuaderno AEB34 (C-34) donde escribiriamos toda la imformación necesaria para la emisión de las 3.000 transferencias con las normas contempladas en el AEB34 para la correcta harmonización de los datos y le entregariamos al cajero el cuaderno AEB34, con lo que la cara del cajero se relajaría y respiraria de alivio uf! sobre todo al comprobar que el cuaderno 34 no es más que un fichero de texto plano ASCII donde toda la informacion esta normalizada para su lectura automatica por su ordenador.

Esta situación en la que utilizamos un cuaderno AEB para comunicar o solicitar servicios a una entidad bancaria, lógicamente puede ser bidireccional y puede ser la entidad bancaria la que nos comunique o preste servicios a traves de un cuaderno AEB.

A estas alturas muchos de vosotros sabreís o habeis imaginado que el cuaderno AEB43 es el cuaderno bancario con el que las entidades bancarias españolas pueden comunicar los extractos bancarios de una cuenta de tesoreria a sus clientes a traves de un fichero de texto plano ASCII con las normas y el formato contemplado en el AEB43.

Asi pues, partimos de una situación en la que nuestra entidad bancaria nos comunicará-emitirá a peticion nuestra cuadernos AEB43, que contendran el extracto bancario de un periodo concreto de una determinada cuenta de tesoreria de nuestra titularidad.

Es decir:

• El AEB43 recoje el conjunto de movimientos de tesoreria durante un periodo, espefificando la fecha, el tipo de movimiento o servicio, y el saldo inicial y final del extracto.
• El AEB43 pertenece exclusivamente a una cuenta bancaria de tesoreria.
• La cuenta bancaria de tesoreria pertenece exclusivamente a una entidad bancaria.

En consecuencia la estructura básica del modelo de datos que elegiremos será:

 En primer lugar, partiendo de nuestra anterior tabla Ctas.Tesoreria donde recogimos los datos generales de las cuentas de tesoreria, vamos a establecer la relacion (R5) entre esta y la nueva tabla AEB43 indexando los cuadernos AEB43 por cuenta de tesoreria. Ni que decir tiene que en la tabla AEB43 recogeremos todos los datos generales del cuaderno 43.

Y en segundo lugar, crearemos la tabla Movimientos AEB43 donde recogeremos todos los movimientos del cuaderno AEB43, y definiremos la relacion (R6) indexando los movimientos del cuaderno por cuaderno AEB43.

Con esto la estructura básica de la BD esta completa y pasaremos al siguiente punto teórico, que es mostrar la estructura y normas del cuanerdo AEB43, los algoritmos de importación de cuadernos AEB43 mediante ficheros ASCII, y definir por fin la consolidación de los cuadernos AEB43 en apuntes de tesoreria, lo que significaria que hemos conseguido un procedimiento por el cual no es necerario que un usuario de la aplicación vaya dando de alta los apuntes de tesoreria de una cuenta bancaria, uno a uno. Si no que utilizando los servicios bancarios, mediante la importación de un fichero ASCII, que no es otra cosa que un AEB43 podamos dar de alta esos registros de movimientos bancarios en nuestra BD de forma automatizada.

Esto lo dejaremos para el próximo capitulo … jeje