6.1Casos prácticos
Lo esencial en 30 segundos
- Ensamblar: analizar los datos → dibujar las ventanas → programar en WLangage → generar los informes → desplegar — la secuencia es lo que hace fiable una aplicación.
- Demostrar: una aplicación existe cuando los datos siguen siendo coherentes (transacciones, integridad), cuando funciona en casa del cliente y cuando se actualiza sin perder una sola línea.
- Elegir: Classic o Cliente/Servidor, mono-puesto o multi-puesto, ejecutable o actualización automática: decide el contexto de uso, no la moda.
Hilo Yacine — tres situaciones, un método
Yacine es desarrollador WinDev en una PYME de comercio de material eléctrico en Orán. Mantiene y hace evolucionar la aplicación interna que gestiona clientes, productos, pedidos, facturas y existencias. Repasa tres situaciones marcantes del trimestre — la construcción de la aplicación de la A a la Z, el paso de la base Classic al Cliente/Servidor multi-puesto y el despliegue en comerciales itinerantes. Los casos siguientes retoman su secuencia de los niveles 0 a 5: analizar, dibujar, programar, consultar, fiabilizar, desplegar.
Cada caso sigue el desarrollo Contexto → Etapas → Resultado: replíquelo en sus propias aplicaciones.
Por qué casos prácticos
Los niveles anteriores pusieron los ladrillos (análisis, ventanas, WLangage, HFSQL, consultas, informes, procedimientos, seguridad, despliegue); aquí se ensamblan de principio a fin. Es la secuencia de los buenos reflejos — un análisis limpio, campos vinculados, consultas acotadas, transacciones y una prueba de aceptación en una máquina virgen — lo que distingue una aplicación de gestión fiable de una demo que solo funciona en el puesto del desarrollador.
Rejugar de principio a fin
Un caso no se copia: se rejuega. Se retoma el orden del método, se adapta al contexto (número de puestos, volumen de datos, restricciones de la tienda) y se mantiene la misma exigencia de prueba en cada etapa.
De la pantalla al terreno
La verdadera prueba de una aplicación no es «se abre en mi equipo», sino «aguanta en el tiempo»: los datos siguen siendo coherentes, se respetan los derechos, existen las copias de seguridad y una actualización no rompe lo existente.
Caso 1 — Construir la aplicación de gestión del comercio de la A a la Z
Contexto: Yacine debe entregar a su PYME una aplicación que gestione clientes, productos, pedidos, facturas y existencias, con un seguimiento sencillo para el jefe y una introducción rápida en el mostrador.
Déroulé :
- Concebir el análisis: archivos, rúbricas, enlaces y claves, pensando en la integridad y en las evoluciones futuras (N0.4, N1.1).
- Dibujar las ventanas y los campos, cuidar la ergonomía y la nomenclatura (N1.2).
- Programar los tratamientos en WLangage: variables, condiciones, bucles, eventos (N1.3, N2.5).
- Vincular los campos a los datos y dominar los registros (HAjoute, HModifie, HEnDehors) (N1.4).
- Generar una primera versión con el RAD y luego producir los informes útiles (factura, existencias) (N1.5, N2.3).
- Escribir las consultas y elegir los modos correctos de recorrido y de tablas de archivo (N2.2, N2.4).
Resultado: Una aplicación coherente: análisis sólido, ventanas vinculadas, tratamiento limpio de los registros e informes generados — una base sana para las evoluciones futuras.
Caso 2 — Pasar la base de Classic a Cliente/Servidor
Contexto: La aplicación funciona primero en HFSQL Classic en un puesto. Con varios usuarios en el mostrador y en el almacén, las ralentizaciones y los riesgos de conflictos se hacen visibles.
Déroulé :
- Elegir el modo adecuado y preparar el paso a HFSQL Cliente/Servidor (N2.1, N4.1).
- Revisar las consultas: filtros del lado de la base, rúbricas indexadas, consultas acotadas (N2.2).
- Definir los derechos y los grupos de usuarios según los roles reales (N4.2).
- Enmarcar las escrituras con transacciones y gestionar los bloqueos en multi-usuario (N4.1).
- Probar la carga y la coherencia con varios puestos simultáneos (N4.5).
- Implantar las copias de seguridad y la restauración antes del cambio (N4.1).
Resultado: Una base compartida fiable: datos centralizados, respuestas rápidas, derechos respetados y escrituras coherentes — el multi-puesto se vuelve una ventaja, no un riesgo.
Caso 3 — Desplegar y mantener en comerciales itinerantes
Contexto: Los comerciales trabajan en la carretera y deben recibir las nuevas versiones sin informático en el lugar, sin perder sus datos ni bloquear su ruta.
Déroulé :
- Preparar el ejecutable y sus dependencias, con un instalador completo (N4.4).
- Implantar la instalación y la actualización automática (N4.4).
- Decidir qué queda local y qué viene del servidor, y gestionar la sincronización (N4.1).
- Proteger los accesos y los datos personales de los clientes (N4.2).
- Validar cada versión en una máquina virgen antes de difundirla (N4.5).
- Seguir las versiones y el código con el gestor de fuentes (N5.4).
Resultado: Un parque desplegado limpiamente: versiones controladas, actualizaciones sin pérdida de datos y comerciales autónomos — el mantenimiento se vuelve previsible.
Guion listo para decir — encuadrar una aplicación (30 s)
«La aplicación: [gestión del comercio / paso a Cliente/Servidor / despliegue]. Mi método: verificar el análisis, dibujar las ventanas, vincular los campos, programar los tratamientos, generar los informes y luego validar y desplegar.»
Para guardarlo y encuadrar un proyecto con su dirección o un cliente.
Guion listo para decir — explicar su método (30 s)
«Siempre parto del análisis, vinculo los campos en lugar de apañar en la pantalla, acoto mis consultas y pruebo en una máquina virgen antes de entregar — eso es lo que evita las malas sorpresas.»
Útil para explicar su método sin jerga inútil.
Modelo para copiar y pegar — método de construcción
1. Analizar: archivos + rúbricas + enlaces + claves
2. Dibujar: ventanas + campos + ergonomía
3. Programar: WLangage (eventos, procedimientos)
4. Vincular: campos <-> rúbricas, HAjoute/HModifie/HEnDehors
5. Presentar: consultas acotadas + informes
6. Fiabilizar: errores + derechos + pruebas
7. Desplegar: ejecutable + actualización + prueba en máquina virgenModelo para copiar y pegar — ficha de validación antes de la entrega
Versión: [x.y] Fecha: [..]
Análisis modificado: sí/no (migración probada sobre copia)
Datos: ¿copia de seguridad hecha? sí/no
Recorridos probados: conexión, introducción, modificación, supresión
Derechos verificados: perfil [mostrador / almacén / jefe]
Impresión: factura + informe de existencias OK
Instalación probada en máquina virgen: sí/no
Vuelta atrás prevista: sí/noMicroempresa / presupuesto ajustado
Quedarse en HFSQL Classic en uno o dos puestos, centrarse en el análisis y en los informes útiles, y no complicar más que si la necesidad es real.
PYME Orán
Adaptar a las realidades locales: cortes de electricidad, puestos heterogéneos, contenidos y etiquetas en francés, formación rápida de los usuarios en el mostrador.
Remoto / multisitio
Centralizar los datos en Cliente/Servidor, duplicar la trazabilidad y prever un procedimiento claro de actualización a distancia.
Intercultural
Explicitar los intitulados antes de transponer: un nombre de rúbrica o una etiqueta evidente para uno debe hablarle a cualquier recién llegado.
Reto 48 h — aplícalo mañana
Tome una aplicación real y rejuegue la secuencia: análisis verificado, ventanas vinculadas, 1 tratamiento programado, 1 informe generado y 1 prueba en máquina virgen.
- Sé encadenar análisis, ventanas, código, consultas, informes, fiabilización y despliegue en una aplicación real.
- Tengo un método rejugable (análisis primero, campos vinculados, consultas acotadas, prueba en máquina virgen).
- He hecho el reto de 48 h o he planificado su fecha.
Yacine entrega la aplicación del comercio. ¿Qué secuencia respeta la guía?