Al finalizar esta etapa usted deberá estar familiarizado con los siguientes conceptos:
Nociones de Modelado:
Elemento de Datos, Tipos de Datos, Conector, Ranura, Elemento de Vista de Datos, Referencia al Ancestro, Nombres Reservados, Prototipos
Técnicas de Modelado:
Recibir datos del usuario de la pantalla, guardar datos en una tabla de la base de datos.
Plantillas útiles:
Secuencia Numérica, Insertar
En esta etapa usted modelará algunas aplicaciones lógicas básicas - recibir la descripción de la solicitud ingresada por el usuario (mediante el formulario de la ventana emergente) y guardarla en una tabla de la base de datos.
El modelado de esta etapa puede ser ejecutado en el proyecto Tutorial 2-3 que usted importó al final de la etapa previa.
En la etapa previa hemos estudiado cómo modelar un formulario para una sencilla entrada de datos. Mencionamos que faltaba un tema crucial – guardar los datos ingresados por el usuario.
Ahora crearemos los modelos necesarios para guardar la descripción de la solicitud cuando el usuario presiona el botón Submit.
Como mencionamos anteriormente, el modelado en Tersus utiliza la técnica zoom-in en la cual la aplicación lógica se define "dentro" del elemento de vista que la invoca. En nuestro caso, la operación que guarda los detalles de la solicitud debe ser ejecutada cuando el botón es presionado, por lo tanto modelaremos esta operación dentro del botón Submit.
Haga doble clic en el botón Submit para agrandarlo, ya sea desde el editor de modelos o desde el Outline.
Ahora definiremos una estructura de datos para guardar los detalles de la solicitud:
Seleccione la plantilla Data Types/Database Record () y arrástrela hasta dentro del botón. Renómbrela como Requisition.
Una estructura es una colección de campos de datos (tanto "primitivos" como un número o fecha, como de otras estructuras de datos). Las estructuras de datos aparecen en el modelo como rectángulos verdes.
Puede haber notado que la plantilla Data Structure aparece cerca de la plantilla Database Record en la paleta. Ambas son prácticamente idénticas, excepto por el hecho de que la estructura Database Record es asociada automáticamente a una tabla compatible en la base de datos, y como querremos que los datos de la Solicitud se guarden en la base de datos, como veremos más adelante en esta etapa, basaremos ésta en una estructura Database Record.
El modelo del botón Submit debería lucir similar al siguiente:
A continuación debemos definir los campos contenidos en la estructura de datos. Para insertar elementos de datos dentro de la estructura simplemente debemos arrastrar los tipos de datos apropiados (Número, Texto, etc.).
Seleccione la plantilla Data Types/Number () y colóquelo dentro de la estructura de datos Requisition. Llámelo Id.
Seleccione la plantilla Data Types/Text () y colóquelo también dentro de la estructura de datos Requisition. Llámelo Description.
La estructura de datos Requisition debería lucir similar a la siguiente:
La estructura de datos Requisition contiene ahora 2 campos: Id, que será un identificador único automáticamente generado para cada solicitud, y Description, que es una descripción de la solicitud ingresado por el usuario.
Como explicamos anteriormente, Id debe ser un identificador único automáticamente generado. Debe ser único porque no queremos dos solicitudes con el mismo identificador.
Podemos lograr esto usando la plantilla Secuencia Numérica:
Seleccione la plantilla Database/Sequence Number () y colóquela dentro del botón Submit. Nómbrelo Requisition Id.
El modelo debería lucir similar al siguiente:
Sequence Number es un ejemplo de un proceso preconstruido (acción) que genera un nuevo identificador único. Un proceso es algo que debe ser ejecutado.Un proceso puede ser una acción preconstruida provista por la plataforma Tersus y accesible desde la paleta (Por Ej. un cálculo matemático básico), o un proceso más complejo modelado por el usuario (Usted mismo o alguien más).El modelado de procesos es la actividad principal para la creación de soluciones (una solución está formada por modelos de vista, modelos de datos y modelos de procesos).
Cuando un proceso (en nuestro caso la Secuencia Numérica) genera algún resultado (el identificador único), este resultado necesita "salir" del proceso para ser utilizado por otro proceso o llenar un campo de la estructura de datos. Una ranura de Salida es modelada como un triángulo gris () que aparece en el marco del modelo del proceso.
Hay dos tipos principales de Ranuras: Triggers que reciben la información cuando un proceso empieza (lo discutiremos luego), y Exits (Salidas) que exponen la información generada por el proceso durante su ejecución.
La plantilla Secuencia Numérica devuelve el identificador único que ha creado mediante la salida predefinida <Next>.
Por supuesto, todavía es necesario pasar ese identificador que ha sido creado desde la salida <Next> del proceso Secuencia Numérica al campo Id de la estructura de datos Requisition. Para esto necesitaremos usar un Flow (conector).
Seleccione la herramienta Conector (Flow) de la línea superior de la paleta, haga clic en la ranura de salida <Next> () del proceso Requisition Id para especificar el Origen, y luego en el campo Id dentro de Requisition para especificar el Destino. Una flecha debe de haber aparecido uniendo la ranura con el campo.
Mientras usamos la herramienta Flow, el puntero del ratón cambia para mostrarnos si la actual posición puede servir como Origen o Destino del conector.
El modelo Submit debería lucir ahora como el siguiente:
Un conector es modelado por una flecha entre dos elementos (Origen y Destino). Un Conector define la relación entre el origen y el destino en dos formas:
Orden de Ejecución: Cuándo deberá ser ejecutado cada proceso (y dependiendo de qué condiciones).
Flujo de Datos: Cuándo y cómo los elementos de dato son pasados.
Hemos guardado el identificador en la estructura de datos, necesitamos también guardar la descripción en la misma estructura – después de todo, esa es la información que realmente nos interesa. Para lograrlo debemos definir un nuevo tipo de elemento llamado Display Data Element (Vista de Elemento de Datos).
Una Vista de Elemento de Datos es una representación alternativa de un elemento de Vista (y sus sub-elementos) como una estructura de datos. Su principal propósito es permitirnos acceder al contenido de la pantalla para leerlo o escribir en él.
Por ejemplo, la jerarquía de la ventana emergente que hemos creado, contiene una etiqueta, un área de texto, un pie de página y dos botones (vea la captura de pantalla de la Vista - abajo a la izquierda). Ésta está representada por una estructura de datos de la ventana emergente, que contiene estructuras de datos para el área de texto, botones y etiquetas, el área de texto contiene a su vez, otra estructura de datos propia para el valor (value) (vea la captura de pantalla de la Vista de Elemento de Datos - abajo a la derecha).
El orden en que se muestran los elementos en la captura de pantalla de la Vista de Elementos de Datos (arriba a la derecha) puede diferir de la que usted ve en su modelo. El orden de aparición está definido por el orden en el cual los elementos fueron añadidos. Mientras los elementos aparezcan (no importa el orden) el comportamiento en tiempo de ejecución será consistente con el tutorial.
Queremos acceder al contenido del área de texto Description, para ello agregaremos al botón Submit una Vista de Elemento de Datos que hace referencia a la ventana emergente Enter New Requisition. Como Enter New Requisition es el “padre” del botón Submit, usamos la operación Add Ancestor Reference:
Haga clic derecho en el botón Submit, seleccione Add Ancestor Reference del menú, y seleccione Enter New Requisition.
Note que la estructura de datos que acaba de insertar tiene un marco azul (en oposición al marco negro de los otros elementos). El marco azul indica que esa estructura es una referencia a otro elemento (la ventana emergente Enter New Requisition), entonces en la medida que los datos cambien en una, se reflejarán automáticamente en la otra.
A continuación necesitará crear un conector desde el área de texto Description incluido en Enter New Requisition hasta el campo Description de la estructura de datos Requisition. El texto ingresado por el usuario está disponible a través del elemento de datos <Value> del área de texto Description dentro del elemento de datos Enter New Requisition:
Use la herramienta Conector () para unir Enter New Requisition/Description/<Value> a Requisition/Description.
La mayoría de los elementos contienen elementos de datos por defecto a través de los cuales pueden ser manipulados. Estos elementos de datos son identificados con un nombre descriptivo (como Value -Valor-) encerrados entre corchetes angulados (<...>).
El modelo Submit debería ahora lucir como el siguiente:
Vamos a resumir lo hecho hasta aquí:
El sub proceso Requisition Id genera un identificador que enviamos al campo Id de Requisition, y el contenido del área de texto Description (ingresado por el usuario) es enviado al campo Description de Requisition.
Ahora que hemos creado la estructura de Datos Requisition y ha sido cargada con la información relevante, debemos guardarla en la base de datos. Para lograrlo debemos usar otra plantilla de proceso, Insert:
Seleccionar la plantilla Database/Insert () y colocamos ésta cerca del modelo Requisition.
La plantilla Insert incluye una ranura trigger <Record> () a través del cual recibe la estructura de datos que debe ser guardada en la base de datos.
Las ranuras Trigger son usadas como punto de entrada a través de los cuales un proceso recibe la información de entrada cuando empieza a ejecutarse.
Para enviar la estructura de Datos Requisition al proceso Insert, crearemos un conector:
Seleccione la herramienta Conector (), luego haga clic en la estructura de Datos Requisition (en cualquier lugar fuera de los campos Id y Description) para definirla como el origen del conector, y luego en el trigger <Record> del modelo Insert para definirlo como el destino del conector.
El modelo Submit debería lucir como el siguiente:
El significado del último cambio debería estar claro - la estructura de datos Requisition es insertada como un nuevo registro de la base de datos, en la tabla de la base de datos con igual nombre: Requisition. Si esta no existe, será creada automáticamente por el servidor de aplicación.
Note que varios nombres de ranuras en las plantillas (como Sequence e Insert en la captura de pantalla anterior) usan una convención específica, cuando el nombre está encerrado entre corchetes angulares (‘<…>’). Estos son nombres reservados con los que cuenta cada funcionalidad de la plantilla. Si un nombre reservado es cambiado, la plantilla podría fallar o funcionar incorrectamente.
Una vez que la solicitud ha sido copiada a la base de datos, la ventana emergente debe cerrarse:
Seleccione la plantilla Display Actions/Close Window () y colóquela dentro del botón Submit.
El modelo Submit consta de 2 partes que ocurren en un orden inespecífico, uno es el proceso Close Window, y el otro es la cadena de procesos que guardarán la solicitud dentro de la base de datos.
Algunas veces es obligatorio especificar cual proceso ocurre primero, pues el orden de los procesos es una parte esencial dentro de la lógica de la aplicación. En otros casos el orden no importa, pero de todas maneras, es una buena práctica asegurarse que los procesos ocurren en un orden bien definido incluso si no es crítico.
Queremos asegurarnos que la ventana emergente Enter New Requisition se cierra sólo cuando la información ha sido guardada, por eso necesitamos definir un flujo que especifica que el proceso Close Window ocurre después del proceso Insert, y sólo si la inserción fue exitosa.
Para ello debemos agregar un trigger a Close Window. Podemos hacerlo ya sea agregando una nueva ranura trigger seleccionada de la paleta, o bien valiéndonos de la ventaja de que Close Window tiene “escondido” un trigger predefinido exactamente para ese propósito:
Haga doble clic en el elemento Close Window, abra el submenú Add Element (Agregar elemento), y seleccione el elemento Control.
El trigger “escondido”, está disponible debido a que la plantilla Close Window es implementada como un Prototipo.Los prototipos definen elementos sobre la marcha de un modelo dado, y qué partes de ellos son obligatorias. En el caso del elemento Close Window el trigger no se necesita cuando Close Window actúa como función (como ocurre en el botón Cancel de la ventana emergente), pero en la mayoría de los casos (como el que estamos tratando aquí) es necesario, y por lo tanto es provisto como un elemento opcional del prototipo Close Window.Esto debe tenerse en cuenta en otras plantillas que son utilizadas también como prototipos. Por ejemplo: el prototipo Insert incluye una salida “escondida”, <Duplicate>, útil en los casos en que el registro a ser insertado tenga una llave duplicada, en nuestro caso, si la estructura de Datos Requisition contiene un Id que ya existe en la base de datos. Pero esto nunca ocurrirá en nuestro modelo (puesto que nosotros generamos un Id único usando la plantilla Secuencia Numérica), la salida <Duplicate> puede permanecer “escondida”.Es importante aclarar que todos los elementos disponibles a través del sub menú Add Element tienen sólo el propósito de crear un 'atajo'. Cada elemento puede ser creado manualmente (en este caso específico, arrastrando un trigger de la paleta dentro de Close Window, y darle el nombre Control), y funcionará de igual forma.
Queremos cerrar la ventana solo después de que el registro fue insertado en la base de datos, es decir, cuando Insert termina con éxito y devuelve el resultado por medio de la salida <Inserted>:
Seleccione la herramienta Conector para unir la salida <Inserted> de Insert con el trigger Control de Close Window.
Debe haber notado que el trigger Insert/<Inserted> de la captura de pantalla anterior fue movido de su posición por defecto. Lo hicimos para lograr un modelo mas "claro" para el modelador, y no tiene ningún efecto en la funcionalidad.
Guarde su trabajo.
Para ver la aplicación en el navegador:
Haga Clic en el botón Launch the application de la barra de herramientas.
Intente ingresar solicitudes.
En este punto aún no podemos ver el contenido de la base de datos para verificar que las solicitudes fueron cargadas correctamente. Modelaremos esto mas tarde.
Si lo desea, usted podría utilizar una herramienta externa (generalmente provista por el vendedor de DBMS) para comprobar que la tabla Requisition fue creada en la base de datos y ver su contenidota.
Importe el proyecto de ejemplo Tutorial 3-4 y utilícelo como base para la siguiente etapa del tutorial.
Para recordar cómo importar un proyecto ejemplo, vaya a la sección Importando un Proyecto Ejemplo al final de la Etapa 2.
Este ejemplo contiene todas las funcionalidades modeladas hasta ahora.
El proyecto de ejemplo también incluye una funcionalidad adicional, como sigue:
Funcionalidad
Cómo modelarla
Ubicación
Agregar campos a la tabla Requisitions para uso a futuro
Agregue un campo Date (arrastre la plantilla Data Types/Date)
Agregue un campo Status (arrastre la plantilla Data Types/Text)
estructura de Datos Requisition
Seleccionar un valor por defecto (el día de hoy) para el campo Date de la solicitud
Arrastre la plantilla Dates/Today
Cree un conector de Today/<Today> hasta Requisition/Date
Botón Submit
Seleccionar un valor por defecto (New -nueva-) para el campo Status de la solicitud
Arrastre la plantilla Constants/Text llámelo New
Cree un conector de “New” a Requisition/Status
Hemos completado el modelado de la lógica que se lleva a cabo detrás del telón, recibir datos ingresados por el usuario y guardarlos en la base de datos.
Puede proceder a la Etapa 4, en la que implementaremos una tabla en pantalla para mostrar todas las solicitudes guardadas en la tabla Requisitions.
To use the full functionality of this web site, JavaScript needs to be turned on.
For best results, use the Firefox browser..
Copyright © 2003-2017 - Tersus Software Ltd., All rights reserved. Terms of Use License Graphic design by EmaraDesign