ENTRADA Y SALIDA

En esta sección, se darán a conocer algunos los mecanismos básicos para interactuar con un sistema. Como ejemplo de una aplicación visual, los procesadores de texto presentan al usuario una hoja en blanco, los sistemas de hojas de cálculo interactúan mediante libros, hojas y celdas. Así mismo dichas aplicaciones cuentan con formas para que el usuario modifique tipos de fuente, cambie configuraciones, guarde, asigne nombres a archivos, etc. Toda la información que el usuario necesite ingresar al sistema, lo hará a través de botones, cajas donde ingresará texto, cuadros combinados para seleccionar opciones, botones radio o cajas de selección. A su vez, el sistema proporciona mensajes y emite resultados ya sea en ventanas de mensajes hechas ex profeso, en etiquetas, en cuadros de impresión, en las etiquetas de los botones, etc. Las posibilidades de ingreso y emisión de resultados son variadas.

El problema básicamente se puede resumir de manera simplista en hacer que la aplicación tome información del usuario, haga un procesamiento de la misma e imprima de manera visible algún resultado. A los datos que el usuario proporcione, se le llamarán datos de entrada y a la acción que el programa ejecute para mostrar sus resultados se le dará el nombre de datos de salida. Tradicionalmente a esto en computación se le conoce como proceso de entrada/salida (I/O, input/output). El siguiente diagrama de flujo muestra de manera esquemática cómo se representan diferentes técnicas de entrada y salida:

Tarjeta I/O Genérico

Proceso

Impresora

Teclado

INICIO

FIN

Archivo de Pantalla

Archivo dedatos

Fig. 1.- Diagrama de entrada-proceso-salida

Se tiene que tomar con cautela lo que se representa en un diagrama de flujo con respecto a la entrada y salida de información, sobre todo para aplicaciones visuales. En la figura se muestra que la entrada de datos puede ser a través de tarjetas perforadas, teclado o archivo en disco, sin embargo esto es un esquema muy simplificado, ambiguo y no se debe tomar de manera literal. Para ilustrar lo anterior tómense los siguientes ejemplos:

1) En la actualidad, ya no existen entradas de tipo tarjeta perforadas, sin embargo el código de barras se podría considerar como el sucesor de dicho sistema. Mas bien, el símbolo correspondiente se ha utilizado por tradición para representar entrada del usuario.

2) El acceso por teclado puede estar dirigido a una caja de texto, un cuadro combinado, un botón de radio, etc.

3) La entrada de datos por archivo puede referirse a archivo de texto ASCII sencillo, ANSI, con un tipo propio, una celda en una hoja de cálculo, una tabla en una base de datos, etc.

4) Para la salida en pantalla, no se especifica en cuál formulario, caja de texto, etiqueta, campo de impresión, etc., se realizará dicha salida.

5) Como en el caso de la entrada vía archivo, la salida a archivo que se muestra en la figura tampoco especifica el tipo del referido archivo.

6) Aunque se puede enviar directamente a una impresora, por tradición la salida impresa se podría utiliza para representar la salida del sistema a pantalla a algún objeto en particular.

Representación Algorítmica de Entrada/Salida

Los libros de texto muestran que existen dos símbolos comunes para ingresar datos a un programa y estos son:

(a)

Tarjeta

(b)

I/O Genérico

Fig. 2.- Entrada de información

El uso de uno u otro símbolo depende de las preferencias de los autores de los textos y del nivel tecnológico que se maneje en las obras. Sin embargo, en este trabajo se utilizara la figura 2(a) como la básica para representar entrada manual del usuario. Cuando la entrada de información sea de alguna manera diferente, se representará de manera acorde. Así mismo, se dejará a criterio del programador especificar de qué objeto se tomará la información respectiva.

De manera similar, para la salida de información se utilizan generalmente alguna de las siguientes representaciones:

(a)

Impresora

(b)

I/O Genérico

Fig. 3.- Salida de información

La figura 3(a) se ha tomado en muchos libros de texto como la básica para representar salida de información. Así mismo, esta convención está sujeta a las preferencias del programador o a las necesidades de la aplicación a desarrollar.

Tanto para entrada y salida, la implementación de la entrada/salida se tiene que especificar cuando se diseña el formulario. Finalmente se tiene que recordar que no todas las aplicaciones necesitan de emitir o leer información del usuario. Existirán aplicaciones que no impriman información de resultados. Así mismo existirán aplicaciones que no requieran de leer datos del usuario.

Objetos y Entrada/Salida

La interacción entre el usuario y el sistema se hace a través del formulario. Sobre este se colocan diversos objetos que sirven para capturar datos del usuario, imprimir resultados, servir de componentes

explicativos o ejecutar una acción. Existen una gran variedad de componentes en cualquier sistema de desarrollo. Aunque cualquiera de esos objetos puede servir de elementos tanto de entrada como de salida, se este trabajo se revisarán los siguientes:

Caja de edición (Edit). Son elementos en los que el usuario ingresa texto de manera directa. El valor que se ingrese se guarda en la propiedad “Text” del objeto. El tipo del contenido es siempre una cadena de caracteres o texto. Si se desea que el texto sea interpretado como número, se tiene que ejecutar una rutina de conversión acorde a lo que se necesite.

Cuadro combinado (ComboBox). Este control consta de una caja de edición, con una lista de opciones añadidas. Se deja al programador la elaboración de dicha lista de opciones. Estas opciones se programan en la propiedad “Ítems” del control. El valor que se ingrese se guarda en la propiedad “Text” del objeto. Cuando el usuario selecciona uno de los elementos a elegir, dicho texto se despliega en el contenido de la caja y se guarda en la propiedad “Text”. Aunque se pueden seleccionar algún elemento de la lista, el usuario tiene la posibilidad de ingresar texto de manera directa. Si se desea que el texto sea interpretado como número, se tiene que ejecutar una rutina de conversión acorde a lo que se necesite.

Cuadro de lista (ListBox). Un cuadro de lista presenta una lista de posibilidades a elegir al usuario. Se deja al programador la elaboración de dicha lista de opciones. Estas opciones se programan en la propiedad “Ítems” del control. Una vez seleccionado, el control guarda el índice de la selección, comenzando desde cero, para la primera posibilidad, hasta la n-ésima posibilidad que el programador halla elaborado en dicho control. El valor que se guarda en la propiedad “ItemIndex” del objeto y es de tipo entero.

Cuadro de Selección (CheckBox) y Botón de Radio (RadioButton). Son aquellos objetos que el usuario puede seleccionar. Estos objetos pueden estar en uno de los siguientes estados, mas no en ambos: Seleccionado (verdadero) o no seleccionado (falso). El estado de dichos objetos se encuentra guardado en la propiedad “Checked”.

Grupo de Botones de Radio (RadioGroup). Presenta al usuario la posibilidad de seleccionar una de entre una lista de varias posibilidades, utilizando botones de radio. Se deja al programador la elaboración de dicha lista de posibilidades. Dicha lista se encuentra guardada en la propiedad “Items” de este objeto. Una vez seleccionado, el control guarda el índice de la selección, comenzando desde cero, para la primera posibilidad, hasta la n-ésima posibilidad que el programador halla elaborado en dicho control. El valor que se guarda en la propiedad “ItemIndex” del objeto y es de tipo entero. La propiedad más importante de este control es que la selección de una opción es mutuamente excluyente. En otras palabras, si se selecciona alguna opción, las demás se deseleccionan.

Cuadro de Etiqueta (Label). Estrictamente hablando, no es un objeto que el usuario utilice como entrada, ya que este no puede modificar el contenido de una etiqueta en un formulario. Sin embargo, se puede utilizar para que el sistema imprima un mensaje en el formulario. El texto de una etiqueta se encuentra guardado en la propiedad “Caption” de la misma. Si se requiere que se muestre o se lea información numérica, dicha información tiene que ser convertida de manera acorde al tipo que se maneje.

Cuadro Memorando (Memo). Estrictamente hablando, un cuadro memorando es un control multilínea, que se comporta de manera similar a un editor de texto muy simple. Una aplicación puede utilizar un control memorando para enviar un listado de resultados, de manera similar a como se podría enviar a una impresora los resultados de un proceso. También puede ser utilizado para que el usuario ingrese información que requiera un posterior proceso. El texto de un cuadro memorando se encuentra guardado en la propiedad “Lines” del mismo. La información que se despliega en un objeto memorando es siempre de tipo texto, por lo que si se desea enviar información numérica, esta se debe convertir de manera acorde al tipo que se maneje.

El objeto Botón (Button) puede servir tanto para mostrar mensajes cortos, como para ejecutar acciones. En un botón, la etiqueta que este muestra se encuentra contenida dentro de la propiedad “Caption”. La propiedad “Caption” de un botón funciona de manera similar a la de un objeto de tipo etiqueta. Esta propiedad es de tipo texto, por lo que si se quiere enviar información numérica, esta se debe de convertir de manera acorde. Además de lo referido anteriormente, el hecho de realizar un clic doble sobre un botón cuando se está trabajando en la IDE del sistema produce que se muestre el código fuente de las acciones que ejecutará cuando la aplicación se ejecute.

EJEMPLO

Tómese por ejemplo la siguiente aplicación:

Se pretende crear una aplicación que lea dos números que el usuario ingresará en sendas cajas de edición, sume sus valores y que dicho valor se envíe a una etiqueta. Pártase del formulario siguiente:

Fig. 4.- Aplicación de ejemplo

Nota Se han agregado mas textos explicativos en el formulario con el fin de hacerlo lo más legible posible.

El diagrama de flujo de una aplicación de este tipo es como en la figura 5:

A,B

INICIO

C= A + B

C

FIN

Fig. 5.- Lectura, Suma e Impresión de Resultados

El siguiente código sería una posible alternativa para ejecutar el proceso anteriormente explicado en el diagrama:

procedure TForm1.Button1Click(Sender: TObject);var

A, B, C: real;begin

A:= Edit1;B:= Edit2;C:= A + B;Label4 := C;

end;

Cuando se manda a compilación la aplicación, se producen los siguientes mensajes de error:

1. [Error] Unit1.pas(39): Incompatible types: 'Real' and 'TEdit'2. [Error] Unit1.pas(40): Incompatible types: 'Real' and 'TEdit'3. [Error] Unit1.pas(42): Incompatible types: 'TLabel' and 'Real'4. [Fatal Error] Projec1.dpr(5): Could not compile used unit 'Unit1.pas'

En el caso del error 1, la línea 39 de la unidad Unit1 (la que está asociada con el formulario de trabajo) maneja tipos incompatibles Real y Caja de Edición (TEdit). Lo mismo se puede decir con el error 2 en la línea 40. El error 3 establece que la línea 42 de la misma unidad tiene un error de tipos incompatibles al asignar un valor real a una variable de tipo Etiqueta (TLabel). El error 4 presenta un mensaje diciendo que la aplicación no puede seguir compilándose debido a errores en el código.

En el caso de los errores 1 y 2, lo que sucede es que en realidad se está asignando un objeto Caja de Edición (Edit1, Edit2) a una variable real. En esencia si se quiere asignar una caja de edición como valor para una variable, la variable tendría que ser del mismo tipo, o sea caja de edición. Sin embargo el valor que se quiere utilizar para la variable real no está en TODO el objeto caja de edición, sino en una de sus propiedades. Cuando se mencionó con anterioridad a algunos de los objetos que se pueden utilizar en un formulario, se estableció que la propiedad que el usuario tiene acceso, para el caso de este objeto de caja de edición es la propiedad Text. Para el caso de este ejemplo, se podría suponer que si se substituye la llamada apropiada a la propiedad Text de una caja de edición, se podría eliminar este error. En este caso el código de las líneas con los errores 1 y 2 podría ser de la siguiente manera:

A:= Edit1.Text;B:= Edit2.Text;

Para el caso del error 3 el problema que el compilador detectó fue que no es posible asignarle un valor real a la variable etiqueta, la cual es de tipo “TLabel”. Para este caso, si se pretende enviar dicho valor a la etiqueta 4 (Label4), se tendrá que enviar a la propiedad correspondiente. Para ello, el referido valor se tendrá que enviar a la propiedad “Caption” de la etiqueta. El código correspondiente para resolver el error 3 podría ser el siguiente:

Label4.Text := C;

Una vez hechos estos cambios y cuando se piensa que ya se han resueltos todos los errores, si se manda a compilar a la aplicación, se produce los siguientes mensajes de error:

5. [Error] Unit1.pas(39): Incompatible types: 'Real' and 'TCaption'6. [Error] Unit1.pas(40): Incompatible types: 'Real' and 'TCaption'7. [Error] Unit1.pas(42): Incompatible types: 'Srtring' and 'Real'8. [Fatal Error] Projec1.dpr(5): Could not compile used unit 'Unit1.pas'

Aunque se han llamado a las propiedades que corresponden a cada objeto, ahora el problema es mas bien de conversión de tipos entre las propiedades y las variables que recibirán los valores. Antes se estableció que las propiedades Text y Caption de los objetos que se colocan en un formulario son de tipo texto, o cadena de caracteres. Si se requiere leer o enviar información numérica a estas propiedades, se tendrían que hacer las conversiones correspondientes.

Para el caso de los errores 5 y 6 el código que soluciona de manera definitiva tanto el problema de la lectura de la propiedad correspondiente de la caja de edición, como la conversión de tipo de texto a real, será el siguiente:

A:= strtofloat(Edit1.Text);B:= strtofloat(Edit2.Text);

Para el caso del error 7, el envío del valor a la propiedad correspondiente, junto con la conversión adecuada será el siguiente:

Label4.Text := floattostr(C);

Al mandar a compilación el programa, ya no se emiten mensajes de error. Más lo anterior no significa que no se produzcan errores en otras partes del funcionamiento de la aplicación.

FUNCIONES DE CONVERSIÓN

Se ha mencionado que algunos de los controles que se han visto hasta ahora manejan información de tipo texto. Por ejemplo, si un usuario ingresa un texto dentro de una caja de edición, el texto sigue siendo texto. Si el usuario ingresa un número, el número se considerará como texto. Si se requiere que una variable de la aplicación, declarada como de alguno de los tipos numéricos disponibles, lea su valor de una caja de texto, esto producirá un error. Esto es extensivo para el caso que se quiera enviar información a un control. Si se envía un valor numérico a un control de etiqueta sin antes haberlo transformado, se producirá un error de conversión de tipos.

En el ejemplo anterior, las funciones de conversión strtofloat y floattostr tienen como objetivo el convertir un valor de texto a real de punto flotante y viceversa. Existen diversas funciones de conversión para cada tipo de datos posibles. De entre estas funciones de conversión se pueden mencionar las siguientes:

De texto a algún tipo:

StrToInt Convierte un valor de tipo cadena de caracteres (texto) en un número enteroStrToFloat Convierte un valor de texto a real de punto flotante (Real, Flota, Extended, etc.,) StrToInt64 Convierte un valor de tipo cadena de caracteres (texto) en un número entero de

64 bitsStrToBool Convierte un valor de texto a un valor de tipo valor de verdad verdadero/falso

(T/F Boleano)StrToBoolDef Lo mismo que la anterior pero con criterios que pueden traducir el valor de

verdad de los tradicionales T/F o si es posible a sus correspondientes representaciones numéricas (0/1).

De algún otro tipo a texto:

IntToStr Convierte un valor entero a textoFloatToStr Convierte de real de punto flotante a textoFloatToStrF Lo mismo que la anterior, pero estableciendo parámetros como separación de

comas para millares, redondeo de decimales, número de caracteres máximo para representación con formato.

FloatToText Convierte un real de punto flotante en su representación decimal, utilizando un formato especificado, precisión y número de dígitos.

FloatToTextFmt Lo mismo que la anterior, pero se especifica una cadena de caracteres que se utilizará como plantilla para representar el resultado

BoolToStr Convierte un valor de tipo T/F en textoVarToStr Convierte un valor de una variable de tipo variante (con algún valor

entero/real/fecha/.etc.) en texto

Existen muchas otras funciones de conversión además de las ya mencionadas. Entre ellas se encuentran por ejemplo HexToBin, TryStrToBool, CompToDouble, etc., cuyo fin son de convertir un valor de un tipo a otro. En algunos casos se deberá utilizar un proceso conocido como “Type Casting” en la literatura. Esto no debe de abrumar al lector, puesto que dependiendo de las necesidades de una aplicación, se deberán consultar con el sistema de ayuda para mayor información acerca de estas funciones. Sin embargo, una manera de recordar cómo es una función de conversión de tipos es la siguiente:

TipoOriginalToTipoDestino()

Como una regla genérica, si se pretende leer información numérica de una propiedad dada de un objeto, en el que el usuario ingresa información en un formulario, la función de conversión correspondiente debe de comenzar con “StrTo". En contrapartida, si se quiere mandar el valor de una variable de algún tipo numérico a la propiedad de tipo texto de algún objeto, la función de conversión deberá finalizar con “ToStr”.

ASPECTOS SOBRE LA INTERACCIÓN CON EL USUARIO DE UNA APLICACIÓN

Haciendo referencia a la figura 4, se mencionó que se habían agregado más de una etiqueta de las que necesita el algoritmo, solo con el fin de mantener entendible lo que se solicitaba del usuario. Sin embargo, se dejaron abierta la posibilidad de mostrar de manera más explícita al usuario qué posibles valores se pueden ingresar en las cajas de edición. Tómese el siguiente formulario como ejemplo:

Fig. 6.- Formulario con valores por defecto.

En el caso anterior, el usuario puede observar claramente el tipo de dato que las cajas de edición esperan. Aunque no se puede modificar el valor de la etiqueta donde se mostrará el resultado, se puede inferir que algo (en este caso un número) se mostrará en dicho objeto.

Es una buena costumbre el agregar valores por defecto en aquellos objetos en los que se espera que el usuario ingrese un valor, así como mostrar en el formulario etiquetas con el mero fin de mostrar lo que se espera que el usuario manipule o provea. Una manera más sofisticada de explicar las acciones de una aplicación es proveyéndola de un archivo de ayuda.

VENTANAS DE MENSAJES

Otra manera que una aplicación puede recurrir para interactuar con el usuario es mediante cuadros de mensajes. Un cuadro de mensaje es un formulario que el sistema emite y que a diferencia de los formularios que el programador diseña y produce, estos son creados en tiempo de ejecución y obedecen a ciertas directivas propias del sistema operativo. Los tipos de cuadros de mensajes que existen pueden ser creados con las siguientes funciones/procedimientos:

ShowMessage ShowMessagePos MessageDlg MessageDlgPos MessageBox

ShowMessage es el más sencillo de todos ellos. El cuadro aparece por defecto en el centro, el título del mismo es el nombre de la aplicación, el texto lo indicamos nosotros, y tiene solo un botón. Para probarlo, en una aplicación nueva póngase un botón, hágase doble clic en él para que aparezca el editor de código en el evento doble clic, y dentro de él escríbase la siguiente instrucción:

ShowMessage ('Mensaje del programa');

ShowMessagePos necesita que se le indique el texto, y además las coordenadas, primero el ancho y luego el largo. Añádase un nuevo botón al proyecto y en su evento OnClick agréguese la siguiente línea:

ShowMessagePos ('Cuadro con Coordenadas', Screen.Width div 3,Screen.Height div 3);

Pruébese el programa y observe que el cuadro sale aproximadamente en el centro. Obsérvense que las coordenadas (Screen.Width div 3, Screen.Height div 3) dividen el ancho y el alto de la pantalla en tres porciones enteras, las cuales localizan la esquina superior derecha de la ventana de mensaje aproximadamente a un tercio del ancho y alto. Esto ofrece la apariencia de que el cuadro se encuentra centrado. Pruébese sustituyendo dichas coordenadas por otros valores.

MessageDlg y MessageDlgPos son similares a ShowMessage y ShowMessagePos, pero estos además de enviar un mensaje en pantalla al usuario, cuentan con la capacidad de recibir una respuesta por parte del mismo.

MessageDlg, como en el caso de la instrucción ShowMessage, el primer dato que reciben es el texto que se desea mostrar, luego el tipo de cuadro que se mostrará según una lista predefinida por Windows, el tercero son los botones que se van a mostrar, y para terminar el cuarto es índice que esta relacionado con la ayuda de la aplicación que se crea si es que se coloca un botón de ayuda en el cuadro.

La variante de MessageDlg es MessageDlgPos, que es igual pero tiene un par de datos más, que es, al igual que ShowMessagePos, las coordenadas donde se situará el cuadro cuando se muestre. Su formato es:

MessageDlg ('texto', tipo de cuadro, botones, índice de ayuda);

MessageDlgPos ('texto', tipo de cuadro, botones, índice de ayuda, coordenada X, coordenada Y);

Los tipos de cuadro que existen están indicados en la lista que a continuación se muestra. Téngase en cuenta que según el tipo de cuadro Windows pinta un icono en el cuadro de mensaje, por ejemplo un cuadro de información mostrará un icono de exclamación.

mtInformation mtWarning mtError mtConfirmation mtCustom

Los tipos de botones que se pueden poner son los siguientes:

mbYes mbNo mbOk mbCancel mbAbort mbRetry mbIgnore mbAll mbHelp

Cuando se ponen los tipos de botones que se desean, se deben poner entre corchetes ([ ]), y seguidos de una coma. Otra opción es poner un serie de botones predefinidos, pero si se hace de esta manera, no se deben poner los corchetes. Los tipos de botones predefinidos son:

mbYesNoCancel

mbAbortRetryIgnore mbOkCancel

Es la función de mensaje más compleja para interacción con el usuario que una aplicación puede ofrecer, puesto que puede proporcionar un título que el programador introduce, así como establecer estilos para la ventana, establecer un botón por defecto y un método de escape, manejadores del sistema operativo, etc. Delphi ofrece diversas opciones de sintaxis de la misma con el fin de facilitar la programación de esta instrucción en particular. Pero para lograr lo anterior, se deberá incluir la librería QDialogs en la sección uses de la unidad. Una de las sintaxis que se pueden usar para esta función es como sigue:

MessageBox(Título, // Título de la ventanaTexto, // Texto del mensajeEstilo, // Si se requiere desplegar un título, utilícese mtCustom Botones, // BotonesContexto, // Contexto de AyudaX, // Posición horizontal de la ventana en la pantallaY, // Posición vertical de la ventana en la pantallaDefecto // Botón seleccionado por defectoBitmap // Imagen bmp a mandar junto con el mensaje

);

EJEMPLO

Se tiene el ejemplo anterior, pero ahora se han añadido mensajes del sistema de la siguiente manera:

procedure TForm1.Button1Click(Sender: TObject);var

A, B, C: real;begin

A:= strtofloat(Edit1.text);ShowMessage('Variable A ingresó con éxito');B:= strtofloat(Edit2.text);ShowMessagePos('Variable B ingresó con éxito',100,100);C:= A + B;MessageDlg('C = A +B , Calculado', mtInformation, [mbOK], 0);Label4.Caption := floattostr(C);MessageDlg( 'Mensaje del sistema', 'Listo!!', mtCustom,

[mbOk], 0, mbOk, nil);end;

En este caso se puede observar cómo se comportan las diferentes cajas de mensajes. Cabe recalcar que para el caso de la instrucción:

MessageDlg( 'Mensaje del sistema', 'Listo!!', mtCustom,[mbOk], 0, mbOk, nil);

... se añadió la librería QDialogs en la sección uses de la unidad.

VENTANAS DE ACCESO DE INFORMACIÓN (CAJAS DE INGRESO)

En algunos casos, será necesario que el usuario proporcione información que no necesariamente será proporcionada por alguno de los objetos en un formulario. Esto conlleva a tener una aplicación más

interactiva. Para ello, Delphi provee la función InputBox, la cual se refieren a la manipulación de ventanas en las que el usuario ingresa información para ser usada en la aplicación. La sintaxis más sencilla de la función anterior es:

InputBox (TítuloDeLaVentana, Pregunta, ValorPorDefecto);

A diferencia de los mensajes, las cajas de ingreso necesariamente tienen que asignar el valor que el usuario ingrese, a una variable. En el caso de la función anterior, el valor que el usuario proporciona se considera de tipo texto (ya sea texto, número, valor de verdad, etc.). Tómese como ejemplo la siguiente aplicación: Supóngase que se desea crear una aplicación que le pida al usuario un dato y que imprima el valor de este dato en una caja de mensaje. Sin poner mucha atención en el formulario de trabajo, el botón de ejecución correspondiente contendrá el siguiente código fuente:

procedure TForm1.Button1Click(Sender: TObject);var

entrada: string;begin

entrada:= InputBox('Sistema...','Ingrese el valor', '');Showmessage(entrada);

end;

Al ejecutar el código anterior, se producen los siguientes mensajes:

Caja de ingreso: Mensaje:

Tanto los objetos como las cajas de mensajes y las cajas de ingreso son algunas de la posibilidades que se tienen a la mano para crear aplicaciones que interactúen con el usuario. Sin embargo, no son las únicas. Queda a juicio del lector el explorar diferentes maneras de crear aplicaciones utilizando los conceptos aquí expuestos.