Documentos. Derivación

Formulario de derivación del Equipo Regional 

Tratando de responder a posibles necesidades prácticas, se me ha ocurrido que el documento actualmente vigente de solicitud de colaboración al Equipo Regional de Atención al ACNEAE podría ser un buen ejemplo de utilidad del uso de OOo Basic.

El documento lleva por título DEMANDA DE COLABORACIÓN AL EQUIPO REGIONAL DE ATENCIÓN AL ACNEAE, es accesible desde la web del Equipo y tiene una pretendida funcionalidad de facilitación de la comunicación entre el ER y el resto de los SEO del Principado de Asturias. 

Su formato (documento Word) es de un formulario teóricamente pensado para uso tanto manual (documento impreso y cumplimentado a posteriori) como (posiblemente como forma prioritaria) para ser cumplimentado mediante el propio programa MS-Office (Word). 

En su momento ya analicé la ambigüedad de este tipo de formatos y los errores de diseño en que se suelen incurrir. El documento del ER no es, en esto, una excepción, ya que se incurre en formulaciones mixtas que terminan complicando más que facilitando el uso del mismo. Ejemplo de ello, lo que muestra esta captura:

• Junto con un impecable uso de tablas para facilitar la estructuración del contenido, esta composición está correctamente diseñada para usar el documento en formato papel pero no para ser cumplimentado mediante el procesador de texto: las casillas de selección/verificación no son accesibles desde Word.
• Ejemplos de este tipo de errores no es que sean especialmente abundantes en el documento, pero por la escasa frecuencia de este tipo de formulaciones (tres ítem), ya no hay ocasión en la que se pueda cometer este error que no se produzca, lo que es coherente con la previsión de un uso manual del documento.
• No obstante, también hay ítem que parecen pensados para utilizar el procesador de texto, como los dos primeros de la segunda página, ya que no parece razonable pensar que el espacio reservado sea suficiente si los cubrimos a mano.

Veamos ahora un ejemplo de uso incoherente de tablas, que también los hay:

• Otra vez nos encontramos con un diseño aparentemente pensado para ser usado manualmente, ya que el uso mediante Word no se ve facilitado ni en el dimensionamiento de los espacios de respuesta ni en los desplazamientos.
• Por un lado se desperdicia espacio y por otro no se aprovechan las ventajas del uso de las tablas (desplazamiento mediante tabulador), lo que favorece que se desbarajuste el documento si se trabaja con el procesador de textos.

En resumen, este documento de derivación parece no haber sido repensado en términos de informatización de los procesos de comunicación entre Servicios, heredando formulaciones propias del uso manual que tuvo en su tiempo este tipo de materiales. Esto no facilita precisamente el logro de la finalidad que se pretende con él, ya que dificulta su manejo por parte de todos los profesionales que lo utilizan, incluyendo a los propios componentes del ER-ACNEAE.

Aunque no es el principal objetivo de esta entrada, como previo a éste, me considero obligado a ofrecer una opción que considero sí puede ser funcional para usar en soporte digital. Después crearé una alternativa pensada mediante OOo Basic.

El primer resultado de esta propuesta de modificación es este documento-base que, como se ve, lo que hace es redefinir la formulación original empleando sistemáticamente el formato tablas. De este modo, el documento, que se presenta dividido en tres partes (al igual que el original), se puede cumplimentar usando el procesador de texto sin más requisito que pasar de celda mediante el tabulador.

Dado que se pretende cumplimentar con el procesador de texto, los espacios reservados para las respuestas se ajustan al contenido sin ningún tipo de previsión al respecto, por lo que la apariencia del documento-base es una mera aproximación a lo que resulte de su uso en la práctica. No obstante, es posible que no se produzcan cambios significativo al respecto.

En este enlace te dejo copia al [documento-base] en formato .odt (LO-Writer). Recuerda que tienes que descargarlo y guardarlo en tu ordenador, pero también que tienes que tener instalado el [software Libre Office].

En buena lógica, el siguiente paso sería convertir el documento-base anterior en un formulario, lo que supone utilizar los controles propios de esta interfaz y su posterior conversión en un formulario .pdf (esta recomendable). Si alguien lo considera conveniente y lo solicita, no tengo ningún inconveniente en realizar una propuesta de este tipo, pero no es lo que entra dentro de mis planes en este momento, así que me ahorraré un trabajo que,  no obstante, considero puede ser de interés.

Lo que sí me voy a plantear es utilizar algunos de los recursos disponibles desde  la funcionalidad Grabar macro y/o OOo Basic para desarrollar una alternativa al uso del documento-base anterior. Para ello es conveniente analizar su naturaleza, ya que las alternativas disponibles son diversas y su idoneidad puede estar relacionada con el uso previsto para el documento en cuestión.

Partiré de que este documento va a ser utilizado en soporte informático (nada nuevo hasta ahora respecto al documento-base) y que posiblemente sea cumplimentado al menos por dos personas; OE y tutor/a (la firma de una tercera, no resulta especialmente relevante). (1)

Aunque las delimitaciones anteriores no condicionan en exceso ni cierran las opciones disponibles (un formulario sigue siendo una buena opción), en este caso voy a optar por utilizar las marcadores de texto como medio para facilitar la automatización de la escritura del documento y un sistema combinado de ventanas emergentes y/o cuadros de diálogo para recoger la información necesaria para cumplimentar el documento.

Esta alternativa es una concesión al aprendizaje de una estrategia concreta (la descrita), pero posiblemente sea una alternativa excesivamente costosas, por lo que no se debe considerar la idónea. Repito: un formulario podría ser suficiente en cuanto a prestaciones e incluso más funcional, al resultar menos costoso de construir. Los marcadores de texto y los cuadros de diálogo, por separado no constituyen novedad, pero sí la combinación de ambas técnicas, así como el código necesario para su funcionamiento.

Defiendo la necesidad de emplear marcadores por la escasa utilidad parece suponérseles o por mero desconocimiento, especialmente como recurso en documentos en los que es necesario cumplimentar información puntual a partir de un formato documental muy cerrado, similar en cuanto alternativa, a la utilidad de Combinar correspondencia, aunque ésta tiene la ventaja de contar con una base de datos como respaldo, lo que la hace útil para la generación masiva de documentos personalizados, pero no tanto para documentos como el presente, que no requiere producción masiva.

El hecho de que este documento pueda ser cumplimentado por varias personas hace que sea aun más atractivo el empleo de estrategias como la que propongo, sirviendo de paso como modelo para situaciones similares como la elaboración colaborativa de informes.

Partiendo de lo anterior, formularé en primer lugar la especificación de la supuesta demanda, para identificar el proceso a seguir según lo que podemos entender como aplicación (simplificada) de la lógica de diseño y desarrollo, incluyendo la de programación en sentido estricto. El output ha sido diseñado ya en la formulación del documento-base, por lo que los procesos anteriores hacen referencia al input y al procesamiento.

Especificación. Crear un soporte que permita el uso compartido pero diferenciado entre SEO y tutoría de un documento para la recogida de información de cara a solicitar la colaboración del ER para ACNEAE por parte de los SEO. La finalidad de esta solicitud es facilitar el uso de un instrumento que permita sistematizar el procedimiento de formulación de la citada demanda. A tal fin se ha elaborado un documento-modelo que se empleará como base para la elaboración del citado soporte (docap).

Fases del proceso

• Primera. Partiendo del documento-base (desarrollado a partir del documento-modelo original) introducir las marcas que sean necesarias para facilitar la automatizar la ubicación de la información. Comprobar el correcto funcionamiento de estas marcas.
• Segunda. Crear las interfaces necesarias, teniendo en cuenta el principio de simplicidad en el uso y la posible diferenciación entre al menos dos potenciales usuarios: OE y Tutor/a.
• Tercera. Generar el conjunto de rutinas, subrutinas y funciones que resulten necesarias para conectar el sistema de entrada (interfaces) con el procesamiento y elaboración de datos para generar la salida necesaria quede como resultado el correcto funcionamiento del docap.
• Cuarta. Comprobar el perfecto funcionamiento del conjunto y en diferentes condiciones de uso. En su caso, corregir los errores que se aprecien y abordar las mejoras que se consideren pertinentes.
• Quinta. Pilotar el empleo del docap en contextos reales de uso, recoger la información relevante sobre su funcionalidad e incorporar las mejoras que se aprecien necesarias.
• Sexta. Dar a conocer el docap como recurso para uso público mediante su inclusión en la página web del ER.

Esta formulación del proceso puede considerarse como teórica, por lo que me limitaré, por razones obvias, a desarrollarlo hasta la fase cuarta y en estos momentos me quedo con un primer desarrollo del docap que puede considerarse equivalente en funcionalidad y apariencia, a la que proporciona (en la práctica) el documento-base. 

Esto implica reconocer que podemos trabajar perfectamente con ese documento sin notar (aparentemente) ninguna diferencia respecto al docap, así que para quienes no estén interesados en ir un poco más allá de las formas y de las apariencias, y únicamente se preocupen por la funcionalidad, pueden quedarse perfecta y cómodamente con la citada formulación sin más preocupación.

Pero quienes sientan curiosidad e interés por profundizar en lo que aporta en realidad la formulación del documento como docap, diré que en realidad éste, aunque por ahora aun limitado, contiene un gran potencial de mejora  que, eso sí, hace falta explicar y evidenciar. De momento me limitaré a lo primero.

En efecto, utilizar un cuadro de diálogo como interfaz que concreta la fase de entrada (input) implica diferenciar esta fase de las subsiguientes (procesamiento y salida), lo que favorece que la fase output pueda desarrollarse de forma totalmente diferenciada en forma y contenido a lo que estamos acostumbrados. Esto se debe a que las formas de trabajo empleadas no diferencian input de output, resultando soluciones de compromiso entre ambos, posiblemente con predominio del input en cuanto a la forma y del output en cuanto al contenido. Un ejemplo de uso de la potencialidad que se deriva de esta diferenciación es su aplicación para la creación de informes de intervención a partir de cuestionarios, como por ejemplo, las entrevistas a familias o cuestionarios de observación

La segunda potencialidad que conlleva el algoritmo desarrollado tiene que ver con la potencial utilidad del uso de los marcadores de texto como referencias para la construcción de documentos. Y en principio se me ocurren dos líneas de desarrollo:

• La construcción de documentos en los que colaboran o participan varios profesionales de forma sucesiva (no simultánea) y con aportaciones diferenciadas y complementarias.
• Cumplimentar documentos personalizables basados en plantillas cuando no existe emisión masiva de documentos y el formato combinar correspondencia cuando no resulta pertinente.

Es posible ampliar el listado de potencialidades, incluyendo las resultantes de la combinación de ambas características, pero ya sería suficiente con desarrollar alguna de las citadas para comprobar que el esfuerzo de crear un docap basado en este algoritmo resulte "rentable". De ello me ocuparé en una próxima entrada.

De momento me contento con dejarte enlace a tres documentos en formato Writer que debes descargar:

• El [original del ER], para que lo tengas como referencia y por si te sirve de modelo y/o te es útil para el trabajo. Ten en cuenta que es el oficial del ER, al menos a la fecha de descarga (15/12/2022)
• El que llamé [documento-base], que no es otra cosa que la reformulación del anterior para ser utilizado mediante el procesador de texto. Su uso es tan simple que no requiere explicación alguna y no creo que utilizarlo suponga invalidar una posible demanda, así que lo puedes usar tranquilamente.
• Y el [formato docap] basado en el anterior aunque pero se cumplimenta mediante cuadros de diálogo (tres, uno por página) que se activan con botones de formulario (comandos asociados a script) visibles pero no imprimibles. Su funcionamiento se basa en el código asociado al que puedes acceder desde el IDE. Aunque el documento que te entrego no lo es, te propongo que crees una versión de trabajo de tipo plantilla y que trabajes desde este documento (desde las réplicas que se generan al hacer clic en la plantilla), de este modo no se alterarán los marcadores y no se corromperá el funcionamiento del algoritmo. 

NOTAS

(1) Lo que sí es relevante es que parezca preverse firma y sello manual. A falta de un recurso mejor aconsejo utilizar una firma digitalizada, así como también un sello de igual naturaleza. De este modo no es necesario el gasto de papel y puede ser enviado directamente por e-mail. No aprecio que exista motivo para que sea ineludible el tratamiento manual al que parece destinado este documento.

Modelos de programación.

Programación modular

Cuando un programa, una aplicación o como sea pertinente o preferible llamarlo, es de cierta complejidad, ésta se refleja en su extensión en número de líneas, pero y también, en su complejidad. Dentro de estos dos parámetros podemos incluir la repetición de una serie de líneas de código con funcionalidad específica que se pueden identificar como unidades de acción.

Cuando tomamos estas unidades de acción como objeto de análisis y trabajo, y las aislamos del desarrollo del script principal y los llamamos desde éste, pasamos de trabajar siguiendo un modelo lineal de programación a un modelo modular. Este modelo supone una simplificación de los procedimientos de trabajo y una economía de tiempo, y es posible porque estos segmentos de código pueden ser llamados desde el algoritmo principal tantas veces como sea necesario, ahorrando así su repetición.

El modelo modular no rompe la lógica del modelo lineal, simplemente hace más eficiente nuestro algoritmo, más sostenible y más robusto. Además, esos segmentos pueden ser reutilizados en otros programas o aplicaciones, lo que incrementa nuestra eficiencia a la hora de desarrollar proyectos.

En líneas generales, el comportamiento de estos módulos que llamaremos funciones, en sentido general, por cumplir una función específica, presentan estos comportamientos:

• En este esquema he representado el script principal y dos funciones que son empleadas por dicho script. La fecha verde representa el discurrir del algoritmo, que, como se puede ver, sigue un proceso lineal (de arriba abajo), tal y como representan esas flechas .
• La función Secundario A toma el control del flujo en el momento en que es llamada (en ese momento es A quien determina qué hace nuestro algoritmo), finaliza su cometido y devuelve (por decirlo de alguna manera) el control al script principal, que reanuda el control del desarrollo del algoritmo
• La función Secundario B es llamada (utilizada) por el script principal, se ejecuta y devuelve al script principal el resultado de su propio procesamiento, pero no toma el control del desarrollo del algoritmo, que sigue siendo responsabilidad del script principal.

Esta simplificación nos permite apreciar el modo en que funciona la relación entre el programa principal y sus auxiliares; también nos muestra que existen diferentes formas de concretarse el papel de estos auxiliares, aunque depende del lenguaje de programación que estemos empleando.

OOo Basic. Interfaces.

Interfaz. Notas introductorias.

Cierto es que hasta ahora hemos empleado el modo consola y que aun tendremos que emplearlo para trabajar tanto con OOo Basic como con Python, ya que resulta conveniente para seguir con el aprendizaje de ambos lenguajes, pero también lo es que para crear ejemplos de cierta complejidad y propuestas de trabajo que resulten útiles para la práctica, el modo consola resulta poco amigable y escasamente estético, ya que estamos acostumbrados a los modos gráficos, basados en ventanas y sistemas que facilitan la interacción entre el usuario o usuaria y el "programa". Así que me ha parecido que ya iba siendo hora de aprender a usar los modos gráficos (GUI) en la implementación de interfaces para empezar a construir propuestas de trabajo.

Empezaremos por algunas nociones básicas sobre lo que son las interfaces gráficas y seguiremos por la interface de propósito general de OOo Basic. La idea es crear un ejemplo de docap que hace uso de un cuadro de diálogo sencillo. Es una forma de empezar a familiarizarnos con la creación y uso de componentes hoy por hoy fundamentales en todo recurso digital.

El mundo de las interfaces gráficas es tan complejo que se está produciendo una división del trabajo dentro de los programadores en la que se diferencian aquellos o aquellas que orientan su trabajo a la generación de algoritmos (código oculto) y aquellas o aquellos que están especializado en generar las formas en las que estos programas se muestran e interactúan con los usuarios y usuarias.

Las interfaces de texto, como es la consola, ofrece formas de interacción muy simples, a veces poco amigables. Por eso, aunque son modos de implementar los programas muy eficaces, paulatinamente han sido sustituidas por interfaces gráficas. Una etapa intermedia es aquella en la que determinados programas funcionaban a base de comandos; como ejemplo el procesador de textos WordPerfect que aprendimos a manejar los que nos iniciamos en los programas informáticos cuando se empezaban a popularizar los ordenadores tipo Amstrad y similares. Los anteriores eran meras unidades centrales sin periféricos (había que añadirlos) como pantallas y teclados, que incorporaban sistemas básicos de almacenamiento (cintas de cassette, por ejemplo) trabajaban directamente en modo consola.

Las interfaces gráficas de usuario (GUI, como son llamadas en el mundillo de la programación) ofrecen ventanas, cuadros de diálogo, barras de herramientas, botones, listas desplegables y muchos otros elementos (objetos) con los que estamos tan acostumbrados a tratar que si un programa no cuenta con ellas, instintivamente lo consideramos "arcaico" y "complejo. Y eso que las interfaces de consola son tan eficientes (o más que las gráficas), además de más sencillas y más económicas de crear y de mantener. Y que ciertos lenguajes actuales siguen trabajando básicamente en ese modo (R es un ejemplo, aunque ya cuenta con un programa más "amigable": R-Studio)

De Shmuel Csaba Otto Traian, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=29272838

Este gráfico resume la complejidad que subyace al planteamiento de GUI potentes como aquellas con las que interactuamos a diario en nuestros dispositivos electrónicos. Afortunadamente no es este el nivel mínimo de complejidad al que tenemos que enfrentarnos para implementar una GUI en nuestros programas. 

Afortunadamente también para implementar las más simples no necesitamos nada especial. Sírvanos de ejemplo las ventanitas emergentes que hemos creado en OOo Basic (MsgBox, Print, InputBox). 

Hasta ahora en OOo Basic nos hemos limitado a utilizar las formas más elementales de interfaces gráficas, pero más bien llevados por la necesidad que deriva del tipo de lenguaje y las posibilidades que ofrece, que por un uso consciente y específico de las mismas. Esto implica que aun en su sencillez, aun tenemos pendientes descubrir algunos de sus secretos.

Y en cuanto a Python, aun nos falta para iniciarnos en la implementación de las formas más básicas de GUI, aunque trataré de acortar el camino pendiente de recorrer para que este proyecto personal de aprendizaje no se descompense demasiado en el ritmo de avance en cada uno de los lenguajes trabajados.

Por ello en este blog emplearemos una conceptualización simplificada del esquema anterior, que podemos representar de este modo,...

Basada en Shmuel Csaba Otto Traian

• La GUI sustituye en ella las posiciones/funciones básicas de entrada/salida (input-output), bien ambas, bien únicamente la entrada, como tendremos ocasión de ver en OOo Basic.
• Esa interface gráfica se conecta con el código de base (el que procesa los datos y genera resultados) mediante una capa intermedia de código específico que debemos conocer para que lo "dibujado en pantalla" sea algo más que una ventana más o menos amigable.
• El "programa" oculto devuelve a la interface los resultados de su procesamiento 
• y se una nueva interface gráfica nos muestra el resultado. 

En este último punto es donde OOo Basic presenta las características específicas que implica ser un lenguaje de script: esa devolución de información se presenta generalmente en una GUI que no es más que el servicio con el que estamos trabajando. Pero esto, que no tiene por qué ser necesariamente así, ya lo veremos cuando tratemos sobre las GUI en OOo Basic, que queda para una nueva entrada.

De momento me voy a adelantar de nuevo en OOo Basic (es una nueva demostración de la utilidad inmediata que tiene este lenguaje de script para los SEO y para los y las docentes en general)  y voy a tatar en esta entrada sobre uno de los recursos GUI menos empleados en LibreOffice y posiblemente también en otros lenguajes de similar propósito: los cuadros de diálogo.

OOo Basic permite trabajar con tres formatos de GUI: las ventanas emergentes, los formularios y los cuadros de diálogo. Aunque trataremos (de hecho ya lo hemos hecho, aunque indirectamente) sobre ventanas emergentes y formularios, considero conveniente empezar por el aprendizaje de los cuadros de diálogo por similitud con otros lenguajes de programación (como Python) y para facilitar la implementación sistemática de este tipo de GUIs (que son de propósito general en OOo Basic) en los ejemplos y los proyectos basados en OOo Basic que desarrollemos a partir de este momento.

OOo Basic. Estructuras.

Iteración. Concepto.

Del mismo modo que las estructuras condicionales vistas en las entradas anteriores nos permiten establecer itinerarios o bifurcaciones diferentes en un algoritmo en función del cumplimiento o no de una o varias condiciones, las estructuras denominadas normalmente bucles o ciclos, nos permiten establecer iteraciones de forma que se facilitan la estructuración del algoritmo, simplificando su elaboración y ejecución. Pero ¿qué es un bucle?, ¿qué significa iterar?. Vamos a tratar de estos conceptos en esta entra y en las siguientes.

La RAE define Iterar (del latín iterare) como sinónimo de repetir, derivando del verbo el sustantivo iteración (repetición) y el adjetivo iterativo/a. 

Como sinónimos de tenemos los términos verbos repetir o el reiterar, entendidos ambos como volver a desarrollar (realizar) una acción o pronunciar de nuevo lo que ya se había dicho.

Pero es respecto al adjetivo derivado iterativo/va donde la RAE aporta mas significados:

• Que se repite o que indica repetición (reiterativo acentúa el carácter repetitivo de lo subyacente)
• Y un significado específico en el ámbito de las matemáticas, entendido como procedimiento o método que llega al resultado mediante aproximaciones sucesivas, partiendo de una estimación inicial. Estos métodos matemáticos resultan útiles para resolver problemas con infinidad de variables

Existe otro concepto matemáticos relacionado con la iteración: la función iterada, que es aquélla que se compone de sí misma. Como función compuesta se logra a partir de la aplicación sucesiva de otras funciones, lo que implica que la iteración de una función constituye la creación de una función compuesta a partir de la repetición de la propia función.

Aunque este campo conceptual se muestra muy prometedor, especialmente  como conceptualización, aunque también como metodología de trabajo para abordar la resolución de problemas complejos, se encuentra relativamente alejado del uso que puede resultar de interés para nuestros objetivos concretos, y mucho más de mis capacidades de comprensión desde una perspectiva de funcionalidad. 

No obstante, intuyo la posibilidad de que un análisis más informado de ciertas formas de expresar la asignación de variables esté más próxima de lo que puede parecer al concepto de iteración de una función. Además, el  uso de la iteración para la creación y manipulación de sucesiones es mucho más funcional de lo que esta aproximación conceptual abstracta permite intuir, incluyendo su aplicación al trabajo con colecciones de datos. Aun así, y en todo caso, aun son meras intuiciones, por lo que es largo el camino que tendré que recorrer para poder expresarme con mayor propiedad y seguridad. En todo caso, estos conceptos parece ayudar más a la comprensión de productos y al tratamiento formal de los contenidos (las variables), que a las formas, formulaciones o estructuras que los hacen posible, cuestiones estas fundamentales desde la perspectiva de quien se inicia en la programación y en su lógica.

Por ello resulta de mayor utilidad inmediata y práctica para nuestros objetivos actuales la información que aportan los textos específicos sobre programación, ya que la RAE no contempla este campo específico (no al menos en la fuente consultada a la fecha 15/09/2022).

Esta fuente define las estructuras o sentencias iterativas como aquellas que permiten varias veces algunos segmentos del programa. Como se puede deducir, y de acuerdo con lo dije en la entrada anterior, iniciamos con ellas es aprendizaje de recursos de los lenguajes de programación orientados a facilitar el desarrollo del algoritmo y su funcionamiento, a la vez que a simplificar su formulación. 

No obstante, desde el punto de vista de la lógica de programación, estas estructuras iterativas, también denominadas más comúnmente bucles o ciclos, presentan cierta complejidad en su formulación y uso, por lo que será conveniente comprender correctamente su lógica de funcionamiento para que el uso que hagamos de ellas sea correcto y realmente nos faciliten el trabajo.

Distinguimos con los anteriores autores dos tipos básicos de bucles:

• Los denominados deterministas, que son aquellos en los que conocemos a priori el número de repeticiones.
• Y los indeterministas, que yo me atrevo a llamar también condicionados, que son aquellos en los que desconocemos el número de repeticiones y éstas están condicionadas al cumplimiento de una determinada condición.

Puesto que el tema es complejo y es necesario subdividirlo para abordarlo con mayor garantía de éxito, me planteo dar por finalizado esta entrada, anunciando continuidad temática para la próxima, en la que trabajaremos sobre los bucles deterministas.

Dejo a tu disposición, eso sí, algo de literatura respecto este tema. Salvo el documento de la Universidad de Málaga (ya citado, pero que reitero), el resto son enlaces a páginas informativas, básicas a nivel conceptual y clarificadoras. Al menos para mí lo han sido, cosa que agradezco a los autores y autoras.

Iteración. Significado.

Definiciones. Iteración.

Definiciones. Bucle.

Apuntes de Informática. Departamento de Lenguajes y Ciencias de la Computación. Universidad de Málaga.

OOo Basic. Estructuras.

Bifurcación condicional.

Vistos los principales tipos de datos (y variables) y de operadores, aunque cabe la opción de avanzar explicando las funciones con las que trabajar con los anteriores, dada la complejidad de ese contenido y su amplitud, he considerado más adecuado estudiar las estructuras fundamentales con las que nos podemos encontrar en un algoritmo.

Tres son las formas en que se desarrolla un algoritmo: sucesión lineal (que es la que deriva de lo que hasta ahora sabemos), bifurcación e iteración. Para el desarrollo de la primera es suficiente con el uso de variables y su tratamiento con operadores, pero para las otras dos se necesita contar con estructuras (instrucciones) específicas. Concretamente, para la bifurcación necesitamos estructuras condicionales, que son las que trataremos en este apartado de la sección en la que nos encontramos.

Una definición de bifurcación en programación es la ruptura condicionada del orden lineal del desarrollo del algoritmo; algo así, y en su forma más simple, como un punto en el que se presentan varias opciones de solución/desarrollo por las que hay que optar en función del cumplimiento o no de determinada condición. El cumplimiento o no de la condición (la cual puede ser simple o compleja) determina que se desarrollen unas opciones u otras. Una vez superado ese punto de decisión, el algoritmo puede seguir su curso lineal, hasta que se vuelva a presentar una nueva posibilidad de opción, o quedar todo el condicionado a la decisión previa, siendo esto secundario para lo que ahora nos ocupa.

La forma en la que en OOo Basic se trata la bifurcación es mediante diferentes estructuras condicionales, desde formulaciones (y representaciones) simple a otras más complejas, incluyendo dentro de las segundas el uso de condicionales dentro de condicionales (condicionales anidados). De todos ellos hablaremos en las entradas que se tratan dentro de esta sección. Ahora las presentaré en síntesis, para adelantar contenido y facilitar la comprensión del conjunto y de las partes.

La estructura condicional más simple (SI condicional) permite responder V/F a la validez del enunciado al que se refiere: Si vA = x es V (True), entonces conjunto de proposiones -> Fin del condicional; pero Si aV = x es F (False), entonces (directamente) Fin del condicional. Este razonamiento se expresa gráficamente mediante este flujograma:

Una segunda formulación del condicional incluye la alternativa para el caso en que la proposición valorada resulte ser falsa, la cual cumple la función de opción por defecto. 

Se desarrolla como sigue: SI vA = x es V Entonces Proposiciones A -> Fin del condicional; en caso contrario (ELSE) (vA = x es F), entonces Proposiciones alternativas por defecto B -> Fin del condicional. La representación mediante flujograma es la siguiente:

Aunque aparentemente hayamos considerado la existencia de una única proposición, lo que en el flujograma se denomina Bloque puede estar compuesto por un amplio conjunto de proposiciones, sin que esta complejidad afecte a la estructura condicional. Tampoco se ve afectada por el grado de complejidad que pueda presentar la condición, aunque aquí, por simplificar, la hayamos expresado de la forma más simple posible (aV = x).

Ahora bien, conforme vayamos analizando un número mayor de opciones condicionales, esa estructura se va haciendo más compleja, por lo que es necesario disponer de sintaxis condicionales adaptadas a esta complejidad. Esto es posible mediante el anidamiento de condicionales simples y/o mediante condicionales múltiples.

El anidamiento consiste en la inclusión de un condicional (o varios) dentro de otro condicional. Su forma más simple sería la que representamos en este flujograma que nos da idea, no obstante, de la complejidad que puede llegar a alcanzar una estructura de opcionalidad basada en condicionales anidados.

Los condicionales múltiples se basan en la posibilidad de que la condicional inicial pueda ser múltiple (no dicotómica), por lo que no es suficiente con las instrucciones If y Else. Para ello contamos con la instrucción ElseIf (Else If también es válido), que funciona como alternativa  a If inicial y también concreta (al igual que éste) una condición específica en oposición a Else, que funciona como opción por defecto; de hecho ElseIf requiere tanto la condición como la sintaxis condicional completa (ElseIf vA > x Then).

El siguiente flujograma representa una estructura condicional múltiple.

Ver en desarrolloweb.com

En algunos lenguajes (OOo Basic, por ejemplo), además de la opción If...ElseIf...Else, también existen otras estructuras específicas (Select Case/Switch case) que responden al flujograma anterior, pero otros lenguajes (Python, por ejemplo) no cuentan con estas instrucciones alternativas sin que se vea reducida la funcionalidad del algoritmo.

articunoblogjajairoxdlol.blogspot.com

OOo Basic. Datos y operadores

Operadores lógicos.

Para finalizar la descripción de los tipos (datos y variables) y los operadores, corresponde ahora presentar los tipos lógicos y los operadores relacionados. Pero antes es necesario retomar algunas cuestiones relativas a la lógica, especialmente a la lógica matemática y a la teoría de conjunto.

En este recorrido, lo primero que debemos retomar es el concepto de proposición que, como podremos ver, tiene diferentes significados.

Según la RAE, el término proposición puede ser entendido como sinónimo de oración, más concretamente como oración simple que se une a otras para formar oraciones compuestas; pero también se entiende por proposición el contenido de su enunciado, respecto al cual se puede emitir un juicio dicotómico en términos de verdad o falsedad. Desde esta perspectiva más centrada en la semántica que en la forma, una proposición es la relación semántica que se produce entre sus dos términos constituyentes (sujeto y predicado), de modo que posible emitir un juicio que los relaciona: bien se afirma o se niega el predicado respecto al sujeto, bien se incluye o excluye el sujeto del predicado.

La primera relación establece una opción dicotómica: V vs. F (toda proposición puede ser verdadera o falsa), que reduce el concepto proposición a determinadas formas expresivas: un enunciado desiderativo o imperativo no son proposiciones, ya que de ellos no se deriva posibilidad de afirmar o negar su enunciado.

Pero la segunda relación, o mejor dicho, la segunda forma de expresar la relación entre el sujeto y el predicado de una proposición, nos permite relacionar su análisis con la matemática, y más concretamente con la teoría de conjuntos (lógica matemática), tanto en términos de relación de pertenencia del elemento al conjunto, como en términos de relación de inclusión entre un conjunto y sus posibles subconjuntos (especialmente el conjunto varío y los unarios).

Además la teoría de conjuntos también permite expresar las relaciones que se producen entre dos o más conjuntos, sean éstas de igualdad o desigualdad. Los operadores relacionales vistos en la entrada anterior permiten establecer relaciones en esos términos entre dos variables (que asimilamos a expresiones que remiten a proposiciones), tanto en términos de igualdad vs. desigualdad (= vs. <>) como en las formas específicas en las que se expresa la desigualdad (esto es: como inecuación): < vs. > cuando no se incluye el extremo en el subconjunto que se define, y <= / >= cuando sí se incluye.

Es por ello por lo que estos operadores devuelven valores V vs. F como resultados de los juicios resultantes de su aplicación, según pudimos comprobar en la entrada anterior.

Desde esta misma perspectiva, podemos considerar los tipos lógicos como contenedores del resultado de las comparaciones establecidas mediante los operadores relacionales, lo que permite realizar procesos de análisis mucho más complejos.

También los operadores lógicos suponen un avance en esta línea, aunque su comprensión exige que nos adentremos un poco más en la teoría de conjuntos y en la lógica matemática.

Si podemos establecer un juicio dicotómico v vs. F respecto a la pertenencia de un elemento a un conjunto, o respecto a la inclusión de un subconjunto en un conjunto, también podemos realizar análisis en esos mismo términos (V-F) respecto a las relaciones que se establecen entre dos conjuntos diferenciados, esto es: que no cumplen criterios de inclusión o relación jerárquica. Esto es: conjuntos que mantienen entre ellos una relación que permite enjuiciar la existencia de elementos comunes (intersección), la suma o unión de ambos (unión) o una relación de complementariedad.

Obsérvese que la primera de estas relaciones, la inclusión, es expresión del concepto lógico y (AND), compartiendo ambas las mismas restricciones para cumplir criterios de verdad y similares signos:

• Un elemento pertenece a la intersección de dos (o más) conjuntos sí y sólo sí pertenece al primero y (también) al segundo.
• AND es V sí y sólo sí la proposición A es V y (también) la proposición B es V

Por su parte la relación Unión (de conjuntos) se asocia con el O lógico (y mantiene simbología similar) y permite juicios de verdad mucho más laxos:

• Un elemento pertenece a la unión de dos (o más) conjuntos, con tal de que pertenezca al menos a uno de ellos.
• OR es V con tal de que la proposición A sea V o lo sea la proposición B

Finalmente Not (No) permite negar la proposición (o la relación proposicional) afirmada previamente, de modo que si A->V, ¬A->F, y viceversa. ¬A puede considerarse, por tanto, complementario de A y cumple los mismos criterios que satisface el conjunto complementario (¬A) de A.

• Si un elemento pertenece al conjunto A, no pertenece a su complementario. Si pertenece al complementario (¬A), pertenece a A.
• Si la proposición A es V, entonces su contraria (No-A) es F y viceversa.

Además NOT también nos permite valorar (e invertir) el resultado de comparaciones: si (A AND B) es F implica que ¬(A AND B) es V.

Todos estos operadores se rigen (y permiten elaborar) tablas de verdad como las que puedes consultar en este documento.

OOo Basic. Datos y operadores.

Operadores relacionales.

Cuando necesitamos comparar el valor asignado a dos variables empleamos los operadores relacionales, los cuales devuelven Verdadero (V o 1) si el resultado de la comparación es positivo o Falso (F o 0) si ese resultado es negativo.

Los principales operadores relacionales son los siguientes:

• De igualdad (= o ==, según el lenguaje), que valora V/F en función de que el contenido de de las dos variables sea el mismo.
• De diferencia ( !=, <>), el opuesto del anterior.
• De superioridad: Mayor (>) o igual o mayor (>=), que compara dos variables y determina V/F en función de que la primera sea más grande o cuanto menos igual de grande (en el caso de >=) que la segunda.
• De inferioridad: Menor (<) o igual o menor (<=), que realiza la misma comparación que los anteriores, pero ahora en relación al juicio de inferioridad.

En PSeInt y también Python, los comparadores relacionales son los mismos, aunque algunos de ellos se representen mediante símbolos diferentes.

• El comparador de igualdad se representa con = en pseudocódigo (PSeInt), coincidiendo con el signo del operador de asignación. En Python se emplea el doble signo de igualdad (==) para evitar esa posible confusión.

• El opuesto al anterior, el comparador de diferencia se expresa de dos formas diferentes en PSeInt (<> o !=), aunque se puede convertir automáticamente al símbolo matemático de diferencia () según configuración.
• El segundo de estos símbolos (!=) es que que empleamos en Python.
• El resto de los operadores (< vs. > y <= vs. >=) son iguales en PSeInt y Python.
  

Por lo que parece, los operadores relacionales no presentan especial dificultad, pero es conveniente analizar su comportamiento cuando los empleamos en la comparación de los dos tipos de variable que conocemos hasta el momento: variables alfanuméricas (o de texto) y los distintos tipo de variables numéricas. 

• Sólo cuando dos variables (var1 y var2) son del mismo tipo (sea éste alfanumérico o numérico) y tienen asignado el mismo dato, existe coincidencia (V) entre los operadores de igualdad (=), superioridad (>=) o inferioridad (<=), dado que los tres devuelven V. Y es que en realidad se trata de la misma situación: var1 = var2.
• En caso de variables alfanuméricas, = es V sí y sólo sí ambas tienen asignado exactamente el mismo contenido. Un cambio, por mínimo que sea (vg. un espacio en blanco en Var1 ausente en Var2), aunque no cambie el significado del contenido (vg, el uso de mayúsculas) o sea admisible desde el punto de vista del significado (vg, en caso de que la presencia/ausencia de tilde no afecte al significado), da como resultado que la comparación = resulte F y la comparación <> resulte V.
• No es posible comparar entre variables de diferente tipo (vg, alfanuméricas con numéricas). En estos casos, Python resuelve la igualdad (==) como F y la diferencia (!=) como V.
• En las variables numéricas, aunque una variable sea de tipo diferente a otra (Entero vs Real) son posibles todas las comparaciones.

OOo Basic. Datos.

Datos numéricos.

Después de trabajar sobre las variables alfanuméricas, corresponde ahora hacerlo sobre las numéricas. En primer lugar hablaremos de los números y de la estructura de los conjuntos numéricos.

La representación de los números es tan antigua o más que la del lenguaje; de hecho, las primeras representaciones escritas lo son de registros cuantitativos, conteos y operaciones relacionadas con el manejo de cantidades: lo que primero movió al ser humano a escribir no fue tanto "contar" historias como contar cabezas de ganado o  cantidades de cereales.

Por su parte, la RAE define el número como la expresión de una cantidad con relación a su unidad. La palabra cantidad, refiere al número como concepto matemático que la expresa, aunque también como el signo con el que se expresa esa cantidad.

Los números se organizan en conjuntos (conjuntos numéricos) que están estructurados jerárquicamente de modo que unos conjuntos, los más específicos, forman parte de otros conjuntos más generales, lo que remite al concepto de inclusión de conjuntos.

Partiendo de los números naturales (N), el desarrollo del pensamiento matemático ha ido complejizando esta estructura de los conjuntos numéricos hasta llegar a la actual,  cuya representación recoge el siguiente esquema...

https://sites.google.com/site/portafoliofundamentosm/

... aunque es posible que la representación mediante un diagrama de Venn resultar, en mi opinión, más adecuada para expresar la relación existente entre los diferentes conjuntos...

https://cafecito.app/matemateando/

... y la relación que se establece entre ellos expresada mediante la expresión simbólica del concepto inclusión.

https://sites.google.com/site/portafoliofundamentosm/

Esta estructura de conjuntos y las relaciones de inclusión que se establecen entre sus componentes es fundamental para el buen conocimiento de los datos numéricos y de los tipos de variables a ellos asociados, según se contemplan en los diferentes lenguajes de programación.

La principal utilidad de los números es que nos permiten realizar diferente operaciones, unas consideradas básicas (suma, resta...), otras de mayor complejidad (potencia, radicación...), las cuales mantienen relaciones de complementariedad/oposición entre ellas, involucran dos cantidades o colecciones de cantidades y presentan una serie de propiedades. 

El conocimiento de estas operaciones y de sus propiedades es muy importante para el desarrollo de la lógica de programación, ya que se concretan como operadores (especialmente como operadores algebraicos) en los lenguajes de programación.

OOo Basic. Datos.

Lenguajes de programación. Variables como componentes básicos.

Todos los lenguajes de programación cuentan con estos componentes: datos, variables (y constantes) y operadores, aunque pueden diferir en la variedad de tipología y en la cantidad de elementos. Por ello es importante entender qué son y qué función cumplen. Empezaremos por algunas definiciones y por cómo se concretan en PSeInt en cuanto lenguaje, pero sobre todo por su carácter de pseudocódigo.

Existen varios significados para el término dato, así que empezaré por exponer cómo se define en el diccionario de la RAE.

Dice la RAE que... es una palabra que procede del latín datum, "lo que se da" y lo define como "Información sobre algo concreto que permite su conocimiento exacto o sirve para deducir las consecuencias derivadas de un hecho". También lo considera sinónimo de "fundamento" e incluso aporta una definición en el campo de la informática: "Información dispuesta de manera adecuada para su tratamiento por una computadora". Es significativo que la RAE aporte una definición específica dentro del ámbito de la informática, cosa que no sucede con otros términos también de uso frecuente en este campo.

Por mi parte planteo dos formas de entender un dato:

• Como el contenido con el que trabaja un algoritmo para resolver un problema. 
• Pero también como elemento de un conjunto (que puede ser unitario o estar formado por varios elementos), por lo que resulta ser elemento perteneciente al conjunto de las parte de un conjunto de un conjunto P(X).

La primera definición está necesariamente incompleta, por lo que la modificaré uy ampliaré más adelante. La segunda nos permite formalizar el análisis de un algoritmo y de los datos con los que éste trabaja, en términos de lógica matemática y teoría de conjuntos.

Los tipos básicos de datos son tres, aunque cada lenguaje de programación aporta subdivisiones que amplían este número, especialmente en cuanto a los tipos numéricos, como veremos en su momento:

• Numéricos
• Alfanuméricos
• Y lógicos

Los lenguajes de programación, por lo general, cuenta con los siguientes tipos de datos:

• Numéricos:
• Enteros
• Reales
• Alfanuméricos
• Carácter
• Cadena
• Lógicos

La distinción entre enteros y reales es importante, ya que permite diferenciar entre los números del conjunto Z del resto de los números del conjunto R. A parte de la relevancia lógico-matemática que esto implica, esta diferenciación también tiene que ver con la gestión de la memoria RAM, por los motivos que veremos en su momento.

Los datos alfanuméricos, son en realidad un único tipo de datos que podemos declarar indistintamente como Carácter o como Cadena.

Finalmente los datos lógicos, también llamados booleanos, son los que adoptan como resultado dos valores lógicos: Verdadero o Falso. A pesar de su sencillez aparente, estos datos son de gran importancia para el desarrollo de un algoritmo, ya que permite desplegar toda la potencia de la lógica matemática.

Frente a la claridad terminológica con que el diccionario de la RAE aborda el concepto de dato, el de variable resulta insatisfactorio al no contemplar el significado principal que tiene en el ámbito de la programación. De hecho puede acentuar la confusión que existe al respecto, ya que refuerza la idea de variabilidad y cambio. Incluso el concepto matemático de variable incide en este rasgo ("Magnitud que puede tener un valor cualquiera de los comprendidos en un conjunto"), que si bien es pertinente, no es sustancial para la lógica de programación.

Para comprender la lógica de programación en lo tocante a las variables, es necesario destacar que una variable es, en realidad, un nombre o indicador de un espacio de la memoria RAM, una especie de identificador del casillero dentro de ésta, que es el espacio en el que se almacenan los datos.

Esto me lleva a ampliar mi primera definición de dato que ya señalé como provisional e incompleta: desde esta perspectiva, un dato es un contenido almacenado o adscrito en un espacio concreto de la memoria RAM al que se accede mediante un identificador llamado variable. Los datos son los contenidos con los que opera un algoritmo para resolver un problema.

Desde esta perspectiva no existe una diferencia sustancial entre variable y constante, ya que en cuanto a ser identificador de un espacio de memoria, nada las diferencia; tampoco el hecho de contener datos, pero si de lo que se trata es de comprender la diferencia funcional entre ambas, su distinción sí es pertinente y el significado matemático de variable se ajusta perfectamente a esta distinción: mientras que una variable puede cambiar de contenido a lo largo de un algoritmo, una constante permanece invariable, siendo ésta su característica específica y diferencial.

No obstante, la importancia de la dimensión "física" que subyace a una  variable en cuanto a identificador de un espacio de memoria es fundamental para entender su relación con el contenido que almacena. Y es que entre dato y variable existe una determinación recíproca (o inter-determinación, si se me permite) que se expresa específicamente en el ámbito del análisis tipológico: todo cuanto antes dijimos sobre los tipos de datos es igualmente válido en cuanto a tipos de variable.

El trabajo que conlleva la correcta identificación de las variables de un programa y qué hacer con ellas es, en buena medida, uno de los trabajos principales del programador o programadora, siendo necesario realizar varias operaciones:

• Definir la o las variables
• Declararlas (o asignar tipo -> tipificarlas)
• Asignar los datos a las variables
• Y operar con ellas para obtener nuevos datos que, a su vez, se asignan a otras variables.

Algunos lenguajes de programación son más flexibles que otros en lo tocante a la definición y declaración de las variables, lo que personalmente no considero ninguna ventaja por los errores que esto puede producir, además de ocultar, hasta cierto punto, las restricciones recíprocas que son consustanciales con la inter-determinación antes señalada entre datos y variables. No obstante, todos los lenguajes guardan coherencia con este principio básico: no se pueden mezclar churras con merinas... salvo que estemos hablando de ovejas en general y la distinción de razas (tipos) sea irrelevante, algo que no suele ocurrir en programación y que, en ese caso, se encuentra sometido a otra lógica.

Cuando es prescriptivo definir o declarar una variable, es un proceso que se resuelve con una única expresión pero encubre, en realidad, tres procesos que están, eso sí, íntimamente relacionados:

• Declarar o denominar (dar nombre)  la variable
• Determinar o definir su tipología.
• Dimensionar y ajustar el espacio de memoria RAM denominada/identificada mediante el nombre de la variable.

Aunque lo común es denominar estos tres procesos con un único término, éste puede cambiar en función de en qué parte del proceso se ponga el acento: mientras que en PSeInt se hace sobre la definición tipológica (Definir var1 Como Tipo), en los lenguajes Basic se usa la expresión Dim (dimensión/dimensionar), que mantiene al uso inicial dentro de este lenguaje en referencia al establecimiento de las dimensiones de una matriz de datos (o array), que se traslada al manejo de variables. Pero otra denominación de este proceso es declarar, que será la que utilizaré en este blog.

Con independencia del interés de esta cuestión, que no es únicamente por lo que hemos visto, hay otras de mayor transcendencia práctica. Aunque por ahora no las abordaré todas, sí me interesa tratar una de ellas: es necesario saber si el lenguaje de programación por el que optamos exige o no declarar las variables y las constantes que se van a emplear, si da opción a hacerlo explícitamente (como es el caso de OOo Basic) o si permite o impone de alguna manera la "declaración implícita". Este último es el caso de Python: en este lenguaje no existe declaración específica, sino que se realiza implícitamente en el momento de realizar la asignación de datos a las variables.

Y al entrar en este tema, nos enfrentamos necesariamente con el concepto de operador, que podemos definir como el elemento del lenguaje de programación que permite relacionar variables y concretar qué hacer con su contenido. 

Ya hemos visto uno de los operadores de mayor frecuencia de uso: el operador de asignación. Más abajo vamos a volver sobre él, pero ahora quiero resaltar que el modo en que se expresan las instrucciones de asignación refleja la naturaleza de una variable: ser etiqueta identificadora de su contenido (el dato) que se almacena en un espacio de memoria. En este último sentido, la variable es el puntero que señala la ubicación del espacio de memoria.

Existen también distintos tipos de operadores, así como tipologías diferentes según autores. Algunas son más amplias y otras restringidas. En el primer caso (que es el que empleo) se habla de los siguientes tipos:

• De asignación
• De concatenación
• Algebraicos
• Relacionales
• Y lógicos.

Algunos operadores está restringidos a determinados tipos de variables, pero otros son de carácter universal (se usan con los diferentes tipos de variables). De momento vamos a recordar el de asignación, que pertenece al primer grupo. Y digo recordar porque ya te hablé de él. El resto serán explicados más adelante, en relación con la exposición sobre los tipos de datos/variables y sus características.

El operador de asignación se representa en OOo Basic como = y la expresión resultante se lee de derecha a izquierda: 

• NombreVariable <- DatoX se lee: el dato X está asignado a la variable NombreVariable, lo que permite al algoritmo utilizar el nombre de la variable (en lugar del valor asignado a ésta) en la formulación del resto de las instrucciones en que dicho dato sea empleado.
• No obstante, aunque <- es la representación universal, el signo más empleado en los lenguajes de programación es el signo =. 

Desafortunadamente dicho signo da lugar a confusión terminológica, ya que coincide con el signo "igual" de las operaciones matemáticas, cuando en realidad lo que estamos haciendo es únicamente una asignación, que viene a equivaler a una especie de "igualación" lógica, que no matemática. Por ejemplo, si a la variable Nombre asignamos el dato "Pedro" (Nombre = "Pedro"), lo que decimos es que Pedro es el dato que contiene (que tiene asignado) la variable Nombre (pudiendo tener asignado cualquier otro) y que podemos utilizar la referencia Nombre siempre que deseemos emplear su dato asociado. Este significado es igualmente válido cuando asignamos datos numéricos a variables numéricas.

La asignación también permite relacionar una variable con el resultado de una operación entre variables, que es la segunda fuente de datos de un algoritmo. En este caso, el dato asignado a dicha variable es el resultado de esa operación. Y la forma en que esta asignación se realiza es reveladora del significado real de dicha operación (asignación).

Por ejemplo, si asignamos a la variable ResultadoSuma el resultado de la suma de los datos x - y (ResultadoSuma = x + y), no lo hacemos mediante su expresión algebraica x+y=ResultadoSuma. Lo mismo sirve cuando empleamos los nombres de la variables en sustitución de los datos que éstas contienen (ResultadoSuma = SumandoX + SumandoY).