|
EL PROBLEMA
Si usted es desarrollador, sabrá, que
crear soluciones de software profesional para cubrir las necesidades de
empresas o administraciones públicas es una labor muy compleja ya
que las peticiones y exigencias de los clientes son cada vez mayores, para
resolver problemas ilimitados cada vez más complejos y totalmente
especializados. A esto se suma que las herramientas de desarrollo tienen
limitaciones que dificultan (si no impiden) muchas veces responder a dichos
retos en plazos de tiempo y con costes asumibles. Realmente, crear o
diseñar software de aplicación, es una labor de
ingeniería y por tanto los jefes de
desarrollo han de tener una amplia formación y conocer las
herramientas que puedan resolver los problemas que se les plantean.
Lo que si debe tener claro, es que para disponer
de un sistema que le permita realizar esto con competitividad y en el plazo
de tiempo más corto, es imprescindible que como punto de partida
opte por una solución parecida o al menos con prestaciones parecidas
a la que aquí le estamos describiendo ya que de otra forma,
necesitaría invertir decenas de miles de horas de trabajo y tener
una formación en innumerables disciplinas para empezar desde un
punto de partida parecido y ser competitivo en el mundo del software.
Entendemos que optar por un sistema de
desarrollo óptimo es también sumamente complejo debido a la
multitud de parámetros y factores que es necesario evaluar para
decidirse. En ésta web intentamos por todos los medios darle a
conocer todos los parámetros y características de nuestros
sistemas para ayudarle a tomar sus decisiones.
MODELOS
CLÁSICOS DE DISEÑO
A partir de las herramientas de desarrollo
tradicionales (informática relacional utilizando tablas
bidimensionales), es posible crear
soluciones sencillas y proceder a su mantenimiento de forma más o
menos racional. Pero cuando se afrontan problemas de complejidad media o
alta, éste modelo falla y no cubre en absoluto las expectativas o
deseos de los clientes finales a los que van dirigidas. En otras palabras,
dichas herramientas no son lo suficientemente potentes para desarrollos con
más exigencias (que por otra parte son los que se producen en
el mundo real). No quiere decir ésto que con dichas herramientas no
sea posible resolver los retos planteados, lo que intentamos explicar es
que con ellas el resolver dichos problemas requiere un nivel de complejidad
en el desarrollo y en los recursos necesarios para llevarlo a cabo que son
totalmente desorbitados y que hay otras posibilidades mucho más
racionales, mucho menos costosas y más potentes para resolverlos.
¿Qué supone una modificación o reforma de una
aplicación, cuando están en liza miles de tablas relacionadas
del anterior tipo?
Lo
normal, es que los técnicos de desarrollo se asusten y no tengan mas
remedio que hacer cargar a sus clientes con costosos desarrollos en dinero
y tiempo y muchas veces dicho cliente sufrirá las consecuencias de
sus adecuaciones con grandes problemas y mal funcionamiento en sus sistemas
debido a la complejidad de desarrollar dichas acciones con el modelo
clásico establecido.
¿Qué repercusión tiene todo esto para la
empresa de desarrollo?
Lo
normal es que se cree una gran dependencia con los técnicos, hasta
tal punto que el abandono de la empresa por alguno de ellos, implicados en
dichos desarrollos, provoque una gran crisis (incluso de viabilidad) en
dicha empresa.
Lo más grave, es
que prácticamente todos los productos de software de
aplicación más conocidos a nivel mundial han sido
diseñados a partir de dichas herramientas e incluso los mas caros y
aparentemente más profesionales del mercado tienen enormes
deficiencias derivadas de que han sido construidos utilizando dicha
filosofía como dogma de fé. Hay soluciones de tipo ERP con
precios prohibitivos y con nucleo central con más de 20,000 tablas
relacionadas parametrizables. Al margen de la cantidad de recursos que
requiere para su implantación y parametrización (que
usualmente son disparatados para las prestaciones ofertadas ya sean de
hardware, consultoría o software), ¿Quien se atreve a
realizar una personalización o adecuación a un cliente final
con tal engendro?. Evidentemente dichos sistemas deben ser carísimos,
ya que por mal filosofía de diseño no tienen más
remedio.
NUEVAS ALTERNATIVAS PARA EL DESARROLLO
¿Existe algo más allá del modelo tradicional
de tablas relacionadas bidimensionales?
Por
supuesto que existe y gsBase es un ejemplo de ello. gsBase
incluye un modelo relacional mucho mas avanzado. En nuestra
organización y en nuestro afán de investigación,
siempre hemos sido inconformistas con las normas clásicas de
diseño preestablecidas y cada día nuestros sistemas dan
fé de que llevábamos plena razón. La prueba de ello
son las reacciones de nuestros clientes: lo normal es que inicialmente se
muestren incrédulos y de forma posterior eufóricos y
totalmente fieles a gsBase. Aún valoran más nuestros
productos, aquellos cuyos sistemas antiguos provenían de
suministradores que utilizan métodos clásicos de
diseño, los que a pesar de tener una publicidad como los productos
más punteros de mercado, han constituido un severo fracaso para
cubrir sus expectativas y exigencias.
Por
favor, lea detenidamente todo lo explicado en características
técnicas gsBase y evalúe nuestros
productos, poco a poco comprenderá que llevamos plena razón: gsBase
incluye una nueva filosofía de desarrollo y es mucho mas puntera, productiva
y racional que los productos ofertados por nuestra competencia.
Estamos
hablando de soluciones de hasta miles de usuarios concurrentes trabajando
de forma simultánea y por tanto válidas para pequeña,
mediana o gran empresa u organismos públicos.
VENTAJAS MODELO gsBase: Ejemplo Práctico
Este
ejemplo muestra los recursos necesarios para diseñar y mantener un
simple archivo de facturas con el modelo tradicional y el nuevo modelo
gsBase, como se puede observar, los recursos necesarios para el modelo
clásico son 8 veces más que los necesarios con el modelo
gsBase, ya que en el clásico es necesario definir 8 tablas
(equivalentes a 8 archivos de longitud fija) y en gsBase con un sólo
archivo de longitud variable, es posible resolver el problema. Con una gran
desventaja del modelo clásico: no hay más remedio que
relacionar las tablas con el número de factura y en todas ellas, por
cada una de sus líneas, repetirlo. ¿Qué implicaciones
tiene esta forma de trabajo si el cliente final se empeña en tener
almacenados en algún orden los artículos o albaranes de su
factura o en cualquiera de sus tablas?. Por tanto, los recursos necesarios
aproximados pueden ser en casos extremos hasta diez veces superiores a los
que utiliza gsBase.
Ha
de entenderse, que no solo se trata de recursos hardware y de
diseño, esta mayor complejidad influye drásticamente en:
tiempos de diseño y mantenimiento, complejidad y costes en futuras
modificaciones o ampliaciones de la aplicación, rapidez y eficiencia
de las bases de datos, tamaño de las copias de seguridad, tiempos
necesarios para instalar a los clientes finales, tiempos para arrancar
desde situaciones catastróficas de hardware, etc,. Quedan
justificadas por completo todas las afirmaciones categóricas que
hacemos en el apartado ¿Sabia
que ….?.
|
Modelo clásico:
Uso de tablas bidimensionales relacionadas
|
Modelo avanzado gsBase:
Uso de longitud variable
|
|
|
|
|
Conclusión:
El modelo gsBase es, en este caso,
como mínimo 8 veces más efectivo que el modelo clásico
|
|
VENTANAS DINAMICAS gsBase:
Nuevas ideas para diseño de Software de
aplicación
Modularidad
El sistema gsBase incluye novedosas ideas para diseñar
aplicaciones o soluciones software de aplicación para Empresas o
Administraciones Públicas.
Una de las ideas más originales y productivas consiste en
la forma de concebir el diseño de aplicaciones, son 4 los
elementos a definir por cada aplicación:
1.
Diccionarios de Archivos de Datos
de Aplicación
2.
Ventanas Dinámicas de
Aplicación
3.
Informes y Plantillas de Informes
para presentar resultados.
4.
Documentación de Ayuda para
la aplicación
Una vez diseñados los archivos de datos, construir una
aplicación consiste simplemente en ir creando ventanas para que el
usuario pueda interactuar con las bases de datos gsBase que se relacionan
con dicha aplicación.
Las ventanas mediante las que los usuarios interactúan se
denominan Ventanas Dinámicas. Una ventana dinámica a
su vez se puede subdividir en tres secciones:
1.
Diseño y Geometría
(estructura jerarquizada de contenedores y controles)
2.
Zona de Programación de
Respuestas de Cliente
3.
Zona de Programación de
Respuestas de Servidor
Gráficamente:
(a) El usuario interactúa con los controles
de la ventana y el sistema gsBase hace una petición local, dicha
petición será procesada por la sección de
Programación de Respuestas de Cliente (Acciones de Cliente). Las
acciones de cliente pueden ser de tipo estándar (no es necesario
programarlas, en cuyo caso se procesan de forma directa), o bien pueden
ser particulares para esta ventana en cuyo caso se procesa el
código o zona de programa definido en diseño para tal
acción o evento en el cliente (Zona de Programación de
Acciones de Cliente en respuesta a peticiones de usuario).
(b) Puede ser que la programación de cliente
sea autosuficiente para generar la respuesta y no es necesario realizar
petición al servidor gsBase. En tal caso se procede a actualizar
la ventana con la petición realizada y termina el proceso
Petición -> Acción.
(c) Usualmente las peticiones de cliente son
redirigidas al servidor gsBase y procesadas por éste. Lo mismo que
en cliente, dichas acciones pueden ser de tipo estándar o bien
programadas de forma particular para la presente ventana en la
Sección de Programación de Respuestas de Servidor.
(d) Por último, el servidor envía los
datos o resultado al software de cliente que a su vez enviará a
los controles de usuario las modificaciones o mensajes pertinentes como
ocurría en (b).
Esta estructura tan sencilla es sumamente eficaz
y productiva.
Y lo más importante: garantiza la
programación modular de aplicaciones. En consecuencia:
1.
Es posible que los desarrolladores
trabajen de forma cooperativa en los proyectos sin problema alguno.
2.
El concepto de programación
modular (o de reutilización de diseños ya hechos)
está garantizado fácilmente.
3.
Es posible modificar aplicaciones
en caliente y sin necesidad de parar el trabajo de los usuarios finales
de la aplicación, lo cual es lógico, ya que dicha
modificación consiste en interactuar sobre partes de la
aplicación muy definidas. Lo mismo que ocurre al modificar un
sitio Web, el cambio en una página HTML se puede hacer sin problema,
lo único que ocurre es que los usuarios que la están
utilizando verán los cambios realizados al entrar de nuevo en
dicha página.
Esta forma de trabajo, confiere a gsBase una
potencia excepcional en desarrollo de aplicaciones. Téngase presente,
que la longitud variable, permite que todas las ventanas dinámicas
de una aplicación estén incluidas en un simple archivo, lo
mismo ocurre con diccionarios de datos e informes o plantillas.
¡ Las aplicaciones gsBase
mas complejas, pensadas para dar servicio a miles de usuarios no ocupan
nunca mas de 2,5 Mb !
|
|
