FlexAB Guia Tecnologica

FLLEEXXAB - TG
GUUÍÍAA TEECCNNO
OLLÓ
ÓGGIIC
CAA
ÍÍnnddiiccee
I N T R O D U C C I O N ............................................................................................................3
O B J E T O S .......................................................................................................................4
C L A S E S .........................................................................................................................5
O B J E T O S F L E X A B .........................................................................................................7
R E L A C I O N E S E N T R E O B J E T O S ......................................................................................8
E S T R U C T U R A D E F L E X A B .............................................................................................9
A P L I C A C I O N E S C O N F L E X A B ......................................................................................10
C R E A C I Ó N D E A P L I C A C I O N E S C O N F L E X A B ..............................................................11
U N I V E R S O S E N F L E X A B .............................................................................................12
U N I V E R S O S ................................................................................................................... 12
S I S T E M A S ..................................................................................................................... 12
E S P A C I O S ..................................................................................................................... 13
G R U P O S D E U S U A R I O S .................................................................................................. 13
A P L I C A C I O N E S .............................................................................................................. 13
C L A S E S E N F L E X A B ....................................................................................................... 14
T I P O S D E C L A S E S E N F L E X A B ....................................................................................... 14
R E L A C I Ó N E N F L E X A B ...............................................................................................16
T I P O S D E R E L A C I O N E S E N F L E X A B ............................................................................... 16
M O D E L O D E C L A S E R E A L ............................................................................................19
T I P O S D E A T R I B U T O S E N F L E X A B ................................................................................. 19
E S T A D O S E N F L E X A B .................................................................................................... 21
G R U P O S E N F L E X A B ...................................................................................................... 21
T I P O S E N F L E X A B ......................................................................................................... 22
T I P O S D E I D E N T I F I C A D O R E S E N F L E X A B ....................................................................... 24
D E F I N I C I Ó N D E M É T O D O S E N F L E X A B .......................................................................... 24
C L A S E R E A L ( V I S T A S ) .................................................................................................27
F O R M U L A R I O S D E U N A C L A S E R E A L ............................................................................... 27
R E P O R T E S D E U N A C L A S E R E A L ..................................................................................... 28
C L A S E R E A L ( M I S C E L Á N E A ) .......................................................................................29
R E G L A S D E S E G U R I D A D ................................................................................................. 29
C O N F I G U R A C I Ó N D E A Y U D A .......................................................................................... 30
F I L T R O S .....................................................................................................................30
E V E N T O S D E F L E X A B .................................................................................................31
E V E N T O S D E U S U A R I O .................................................................................................. 32
R E F E R E N C I A D E L O S G R A F I C O S .................................................................................32
FlexAB–TG: Guía Tecnológica 2

v22 – 1_(DOC)TEG.pdf
IInnttrroodduucccciióónn
FlexAB es una herramienta para la creación de aplicaciones informáticas (informatización de
procesos) sin programación y Orientada a Objetos.
La Orientación a Objetos es un paradigma, es decir, es un modelo para aclarar algo o para

explicarlo. La Orientación a Objetos está basada en los tres métodos de organización que
utilizamos desde la infancia:
• entre un objeto y sus atributos (celular > marca, color, modelo);

• entre un objeto y sus componentes donde incluso otros objetos pueden formar parte de
otros objetos (inclusión) (automóvil > motor, parabrisas, llantas);
• entre un objeto y su relación con otros objetos (automóvil > vehículos automotores;
una bicicleta no entraría en esta relación).
La metodología de orientación a objetos consiste en:
• Saber el espacio del problema

• Realizar una abstracción
• Crear los objetos
• Instanciarlos (esto es, traerlos a la vida)
• Dejarlos vivir (ellos ya saben lo que tienen que hacer)
En una aplicación típica no orientada a objetos, usted tiene dos cosas: Código y Datos.
En una aplicación típica orientada a objetos usted tiene una cosa, y solo una cosa: OBJETOS.
FlexAB nos permite crear objetos y manejarlos de una manera sencilla, sin necesidad de
preocuparnos en como se almacenan los datos.
Debido a que todas las Aplicaciones que se desarrollen con FlexAB se realizan sobre la misma
base o plataforma, y con la misma estructura de datos TODOS los objetos que se creen pueden
ser utilizados en cualquier Aplicación.
Esta es la capacidad de FlexAB escalabilidad e integración. Puedo crear aplicaciones

independientes y luego hacer que interactúen de manera sencilla. Es más, todas las aplicaciones
que se desarrollen con FlexAB forman una familia de aplicaciones que pueden ser utilizadas de
manera de potenciar los desarrollos propios, y lograr soluciones completas con menos esfuerzo
de desarrollo.
Esta guía esta dirigida al Usuario como al Configurador de aplicaciones de FlexAB,

para introducirlos en los conceptos en las que se basa esta herramienta.

v22 - 1_(DOC)TEG.pdf
OBJETOS
Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor. Digamos que
para leer esta guía lo hacemos a través del monitor y una computadora, ambos son objetos, al
igual que nuestro teléfono celular, un árbol o un automóvil.
Analicemos un poco más a un objeto del mundo real, como la computadora. No necesitamos ser
expertos en hardware para saber que una computadora está compuesta internamente por
varios componentes: la placa madre, el procesador, un disco duro, una placa de video, y otras
partes más. El trabajo en conjunto de todos estos componentes hace operar a una
computadora.
Internamente, cada uno de estos componentes puede ser sumamente complicado y puede ser
fabricado por diversas compañías con diversos métodos de diseño. Pero nosotros no
necesitamos saber cómo trabajan cada uno de estos componentes, como saber que hace cada
chips de la placa madre, o cómo funciona internamente el procesador. Cada componente es una
unidad autónoma, y todo lo que necesitamos saber de adentro es cómo interactúan entre sí los
componentes, saber por ejemplo si el procesador y las memorias son compatibles con la placa
madre, o conocer donde se coloca la placa de video. Cuando conocemos como interaccionan los
componentes entre sí, podremos armar fácilmente una computadora.
Un sistema en FlexAB está construido en base a diferentes componentes (Objetos), cada uno
tiene un rol específico y todos los componentes pueden comunicarse entre ellos de formas
predefinidas.
Todo objeto del mundo real tiene 2 componentes: características y comportamientos. Por
ejemplo, los automóviles tienen características (marca, modelo, color, velocidad máxima) y
comportamiento (frenar, acelerar, retroceder, llenar combustible, cambiar llantas).
Los Objetos de FlexAB, al igual que los objetos del mundo real, también tienen características
y comportamientos. Son entidades complejas provistas de datos (propiedades, atributos) y
comportamiento (funcionalidad, programas, métodos). Corresponden a los objetos reales del
mundo que nos rodea.
Cada objeto es una estructura compleja en cuyo interior hay atributos y métodos, todos ellos
relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta
propiedad (encapsulamiento), es una de las características fundamentales en la Orientación a
Objetos.
Las peticiones de información a un objeto, deben realizarse a través de mensajes dirigidos a él,
con la orden de realizar la operación pertinente. La respuesta a estas órdenes será la
información requerida, siempre que el objeto considere que quien envía el mensaje está
autorizado para obtenerla.
El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto
determinado pueda ser transportado a otro punto de la organización, o incluso a otra
organización totalmente diferente que precise de él. Si el objeto ha sido bien construido, sus
métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la
Orientación a Objetos sea muy apta para la reutilización de aplicaciones.
Los objetos FlexAB son la representación de cualquier objeto de la vida real (toda entidad
única que se la pueda identificar con un nombre y que posea atributos o propiedades que lo
definan) dentro del sistema de desarrollo de aplicaciones. En función de la vida real, si es un
objeto en la vida real seguramente será un objeto FlexAB, ahora puede haber objetos que
no existen en la vida real que también son objetos FlexAB.

CLASES
En el mundo real, normalmente tenemos muchos objetos del mismo tipo. Por ejemplo, nuestro
teléfono celular es sólo uno de los miles que hay en el mundo. Si hablamos en términos de la
orientación a objetos, podemos decir que nuestro objeto celular es una instancia de una
clase conocida como "celular". Los celulares tienen características (marca, modelo, sistema
operativo, pantalla, teclado, etc.) y comportamientos (hacer y recibir llamadas, enviar mensajes
multimedia, transmisión de datos, etc.). Un mensaje en un objeto es la acción de efectuar una
llamada a un método. Por ejemplo, cuando le decimos a un objeto celular que haga una llamada
estamos pasándole el mensaje “hacer llamada”, el cual se ejecuta a través de un evento. El
evento es una acción determinada que genera la ejecución de un método en un objeto, en el
caso del celular un evento sería apretar el botón send en la pantalla para enviar un mensaje.
Cuando se fabrican los celulares, los fabricantes aprovechan el hecho de que los celulares
comparten esas características comunes y construyen modelos o plantillas comunes, para que a
partir de esas se puedan crear muchos equipos celulares del mismo modelo. A ese modelo o
plantilla lo llamamos CLASE, y a los equipos que sacamos a partir de ella la llamamos
OBJETOS (instancia de una clase).
La clase es un modelo o prototipo que define las variables y métodos comunes a todos los
objetos de cierta clase. También se puede decir que una clase es una plantilla genérica para un
conjunto de objetos de similares características.
Por otro lado, una instancia de una clase es otra forma de llamar a un objeto. En realidad
no existe diferencia entre un objeto y una instancia. Sólo que el objeto es un término más
general, pero los objetos y las instancias son ambas representación de una clase. Es decir, una
instancia es un objeto de una clase en particular.
Las clases de objetos de FlexAB tienen las mismas características de los objetos del
paradigma de sistemas orientados a objetos, más algunas características particulares para la
relación entre ellos.
Se puede pensar en una CLASE como en un molde para un objeto. A partir de la clase, se
pueden crear o instanciar objetos con propiedades especificas.
Además, dentro de una misma Clase los objetos pueden estar agrupados según alguna
característica. Como sabemos los celulares poseen una marca, por lo tanto un grupo posible
podría ser: marca A, marca B, marca C. A este agrupamiento lo llamamos GRUPOS de una
Clase. El identificador de objeto puede depender del grupo al que pertenezca el objeto. Uno de
los objetivos fundamentales del Grupo es poder generar identificadores con mayor flexibilidad.
Otro concepto a tener en cuenta, son los ESTADOS, cada clase se define en un árbol de
valores (estados) en los que puede estar cada uno de los Objetos de la Clase. Mediante los
estados se definen y se administran los distintos estados por los que puede pasar un Objeto.
Por ejemplo, la clase Celular puede pasar por estado operativo, estado reparación, estado
desuso.
Por otro lado, podemos definir una clase Batería. Las baterías tienen características (tensión,
tamaño, tipo de batería, etc.) y comportamientos (cargar batería). Como sabemos, para que un
celular funcione es necesario el uso de una batería, por lo tanto la clase Batería tiene que estar
representada dentro de la clase celular para una definición completa de Celular, ya que la
misma lo constituye. Por lo tanto, la clase batería la debemos incluir en la clase Celular para
agrupar lógicamente las dos clases relacionadas físicamente. Entre la clase Celular y la clase
Batería existe una relación de inclusión. Los objetos de la clase Celular tienen acceso, a los
atributos y comportamientos de la clase Batería sin necesidad de redefinirlos.
Por otro lado, la clase Batería es una clase independiente la cual tiene características y
comportamientos, a parte de ser una clase incluida de celular, puede tener una relación

estructural con otros objetos. Por ejemplo, “A es hijo de B”, “A pertenece a B”, “A lo
encuentro en B”.
Como todos sabemos, todo celular tiene un dueño, en este caso tenemos una relación
estructural con la clase Dueño. Por lo tanto, CELULAR pertenece a DUEÑO.
Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto
relacionarse con aquellos que forman parte de la misma organización. Dentro de la
organización, podemos tener otras relaciones estructurales como: CAJA contiene a CELULAR
Las relaciones estructurales se definen dentro de la Aplicación, siendo aplicación un

concepto abstracto que nos interesa para ordenar la información en un determinado lugar.
Estas relaciones son esenciales para la existencia misma de la aplicación porque la construyen.
Por ejemplo, podemos crear un sistema de inventarios para una empresa que fabrica
celulares, la empresa decide ordenar los inventarios por año, por lo tanto requiere una
aplicación inventario 2005, inventario 2006, cada aplicación con la misma estructura, pero con
la información correspondiente a cada una.
Sistema de Inventarios
Inventario 2005
Inventario 2006
Como sabemos, los objetos siempre tienen relación con otros objetos, por lo que pueden tener
distintas relaciones estructurales de acuerdo al ámbito (espacio) en el que se encuentren.
Podemos definir dos ámbitos para Clase Celular (ESPACIOS):
1- Espacio EN USO:
CELULAR DUEÑO
Tiene un
2- Espacio EN REPARACION:
CELULAR TECNICO
Reparado por

OBJETOS FLEXAB
Los objetos FlexAB son la representación de cualquier objeto de la vida real dentro del
sistema de desarrollo de aplicaciones. ¿Cómo defino un objeto FlexAB?
En función de la vida real, si es un objeto en la vida real seguramente será un objeto

FlexAB, ahora puede haber objetos que no existen en la vida real que también son objetos
FlexAB.
Por ejemplo una cuenta corriente puede ser definida como un objeto FlexAB, cuando en la
realidad no existe. Lo importante es que los objetos que se definan tengan sus
atributos y su relación con los demás. Esta relación puede ser estructural, es decir en el
universo de objetos de quien es “hijo”, o relacional, es decir, como depende ese objeto, o
alguno de sus atributos del resto del universo.
Un tema importante es que los objetos pueden depender estructuralmente de mas de

un padre, es decir que al mismo objeto lo podemos visualizar en mas de un lugar, pero el
objeto siempre es el mismo: por ejemplo el objeto factura podrá estar como hijo del
objeto cuenta corriente, y además como hijo del objeto proveedor.
Además se debe definir para cada objeto sus reglas de validación y métodos,
relacionados con los eventos del objeto (al editarlo, al crearlo, al borrarlo). También es
necesario definir como es la vida de cada objeto, es decir una vez que se crea que sucede
con él: cambia, crece. Se define el flujo de vida del objeto, especificando cuales serán los
estados en los que cada objeto se puede encontrar, y cuales son los eventos que lo llevan de
una transición a otra.

RELACIONES ENTRE OBJETOS
Todo lo que se define en el espacio de las definiciones, tiene su contraparte en el espacio de las
Instancias como entidades independiente, y autónomas que comparten características comunes.
Las entidades que tienen características comunes se las define en este espacio en términos de
Clases. Por ejemplo la Clase Personas, podrá tener las instancias de las entidades u Objetos
Juan, Pedro, y Manuel.
Dado un proceso de la vida real que se desea informatizar se define el Sistema de información
dentro del espacio que estamos describiendo. El Sistema esta determinado por las diferentes
Clase de Objetos existentes, y la conformación de cada una de estas Clases, en términos de
Atributos, Métodos, Eventos, Mensajes, y Relaciones. Se pueden definir distintos
Sistemas de manera de dividir la complejidad de la vida real en diferentes partes que puedan
ser tratadas debido a sus características como semi autónomas. Es decir que tiene una gran
parte de las definiciones propias y comparten solo algunas partes con otros Sistemas. Todos
los Sistemas residen en el Universo, donde son válidas todas las definiciones de Clases, de
esta manera una Clase puede instanciar Objetos en más de un Sistema.
Las Clases dentro del Sistema que se esta modelizando son válidas dentro del Universo. Este
es el espacio donde residen todas los Sistemas. Debido a que las Clases son Universales,
compartir información entre Aplicaciones dentro del modelo es una de sus características
directas por definición.
Los Objetos como sus relaciones se definen o clasifican en el Espacio de las Definiciones, y se
crean, existen, o se instancian en las Aplicaciones.
Objetos
Relacionados o
Vinculados a las

ESTRUCTURA DE FLEXAB
Toda la tecnología de FlexAB reside en una Base de Datos Relacional-Orientada a Objetos.

¿Cómo es esto? Es una base de datos que tiene la robustez, y la tecnología asentada como son
las bases de datos relacionales; con una estructura interna y funciones COM para su acceso que
hace que para los usuarios se comporte como una base de datos orientada a objetos, es decir
que almacena objetos: datos y lógica de cada uno de ellos.
Aparte de este manejo de objetos, que se basa en una Base de Datos Relacional Orientada a
Objetos más las funciones COM de acceso a los objetos (OrDBC), la suite de FlexAB entrega
una Interface Estándar de manera de crear aplicaciones lo más rápido posible. Esta interface
puede o no ser utilizada por el configurador, en función de cómo quiera resolver la interacción
con el usuario. Entendemos que el 90% de las aplicaciones se pueden resolver con esta
interface, lo que hace que los tiempos y costos de desarrollo se vean reducidos.
Un punto importante relacionado con lo descrito en el punto anterior, es que debido a que el
FrontEnd de la aplicación puede ser cualquiera, NO EXISTE LOGICA en los FrontEnd. Toda la
lógica del sistema reside en los objetos, por lo tanto no importa como o quien programa el
ingreso de los datos o la interacción con el usuario, eso no afectara la forma en que guarda u
obtiene la información.
¿Qué hace por su estructura?
• Garantiza el acceso y seguridad de la información (datos y archivos) integrada en una

misma manera de trabajo.
• Trabaja con diferentes interfaces estandarizadas.
• Herramientas para trabajo en grupo de objetos (LOCK-UNLOCK por eventos y a
pedido).
• Lógica de negocio centralizada, asociada a las CLASES y no a la interfaz utilizada.
• Trabaja con objetos fuera del sistema (PACKING OFFLINE).
• Permite múltiples alternativas de entrada de datos (formulario de objeto, importar-
exportar, packing, otras aplicaciones a medida, etc.) pasando por los mismos controles
configurados.

APLICACIONES CON FLEXAB
Por último, una vez que se crean objetos, y se los hace interrelacionar dentro de una aplicación
es muy fácil usarlos en cualquier otra aplicación de la familia FlexAB. La escalabilidad es directa,
es decir si se necesita la información de un objeto en otra aplicación que se ha creado con
FlexAB simplemente vínculo ese objeto a la nueva aplicación, en el caso que necesito la
información y no solo la definición del objeto, permite exportar o importar la información en la
nueva aplicación. No pierdo el trabajo de definición del objeto, de su flujo de vida (que
seguramente adaptaré a la nueva aplicación), y de sus atributos.
Vincular
Si tengo una aplicación ya en uso y encuentro que necesito agregar una nueva información a un
objeto, simplemente lo edito y le agrego el nuevo atributo. No tengo que tocar código, rehacer
pantallas, verificar que no dañe la estructura de datos. Todo es directo y simple. Agrego lo que
necesito en cualquier momento.
Es mas, si lo que necesito es agregarle información a mi aplicación, defino el nuevo objeto, sus
atributos, funciones, eventos, flujo de vida, y lo agrego a mi definición de la aplicación FlexAB.
Listo. No tengo que hacer nada más. La nueva funcionalidad ya esta integrada al sistema y
andando. No hay necesidad de reescribir código, definir tablas, vincular registros. Nada! Esto es
flexibilidad y escalabilidad de FlexAB.
La siguiente figura muestra como funciona la familia de aplicaciones FlexAB y como es posible
compartir objetos (información) entre ellas y entre distintos universos. Se muestran cuatro
aplicaciones distintas, todas usando tecnología FlexAB, y como es posible compartir un mismo
objeto que fue creado en la aplicación EGP como objeto vinculado en la aplicación RCM y como
una copia del mismo objeto en la aplicación PIM.

CREACIÓN DE APLICACIONES CON FLEXAB
En la actualidad debido a la competitividad del mercado se necesitan herramientas de desarrollo

rápidas, confiando los datos a tecnologías robustas y probadas. Ese es el objetivo de FlexAB.
La idea central de creación de aplicaciones con FlexAB es orientar todo, no solo la

programación y sus rutinas, a objetos. Se definen cuales son los objetos relacionados con los
procesos que necesitamos informatizar, y como interactúan estos objetos con su entorno (otros
objetos).
FlexAB nos permite crear objetos y manejarlos de una manera sencilla, sin necesidad
de preocuparnos en como se almacenan los datos (en que tablas, y con que registros). El
creador de la aplicación solo se preocupa sobre qué tienen que hacer los objetos, y cómo se
deben relacionar entre sí.
Otro punto importante es que no existe programación. No es necesaria la generación de

código para el manejo de objetos.
La pregunta sería: ¿Si no hay código como genero los procesos que de los datos extraen
información?.
La respuesta es, cada objeto tiene la capacidad de definir como interactúan su
propios datos, y como interactúa él con los demás objetos. Esta funcionalidad se traduce
en consultas FQL (SQL + XQL), es decir consultas SQL orientadas al manejo de
información de objetos.
Toda la lógica de la aplicación se hace por medio de FQLs. Además se pueden definir
operaciones que toman datos de los resultados del FQL y lo operan según se le indique en la
configuración de las clases. También de manera similar se cargan las validaciones de integridad
de cada objeto.
Por otro lado, parte de la configuración permite el manejo de mensajes y la ejecución de

programas externos los cuales pueden interactuar con objetos FlexAB mediante la utilización de
las funciones COM.

UNIVERSOS EN FLEXAB
Universo
tiene 1..n <DBName, LoginType, tiene 1..n
FSServerName>
tiene 1 n
Sistema Espacio Grupo de

Usuarios
especifica 1..1 define 1..1

permisos
define 0..n
tiene 1..n
Aplicación 1..n
FQL
es definida
0..n por
Clase
Clase Real Clase Virtual
UNIVERSOS EN FLEXAB
Un universo es una configuración de trabajo en donde se especifica un Fileserver (para el

manejo de los archivos asociados a sus objetos), un Servidor de bases de datos, y el nombre de
dos bases de datos existentes en dicho servidor. Una de estas bases de datos es la que
almacenará los objetos de las aplicaciones y la otra almacenará información de auditoria sobre
dichos objetos.
Dentro de un determinado universo es posible configurar sistemas, espacios, aplicaciones y
grupos de usuarios.
SISTEMAS
Un sistema es un conjunto de clases y relaciones organizadas en espacios. La separación en

distintos sistemas permite dividir la complejidad del dominio en partes que puedan ser tratadas
con cierta autonomía. Esto quiere decir que un sistema tiene un conjunto de definiciones
propias y comparte solo algunas con otros sistemas.

Un sistema se define mediante los siguientes atributos:
• IdSystem: Identificador interno del sistema. Ej: SAD (Sistema de Administración de
Documentos).
• Description: Nombre descriptivo del sistema.
• Support Mail: Cuenta de correo electrónico del soporte del sistema.
• Grupos: Grupos a los que pertenece el usuario.
ESPACIOS
Un espacio es un conjunto de definiciones de clases y de relaciones entre éstas. Las relaciones

entre clases son relativas al espacio, es decir que las definiciones de clases pueden especificar
relaciones con otras clases de manera diferente en distintos espacios.
GRUPOS DE USUARIOS
FlexAB permite definir usuarios y grupos de usuarios para restringir los permisos de operación
sobre los objetos desde cualquier interfaz de usuario. Un Grupo de usuario está definido por los
atributos:
• IdUserGroup: Identificador del universo
• Description: Nombre descriptivo del universo.
Las operaciones permitidas para el grupo se configuran de manera independiente en cada
aplicación (ver siguiente apartado).
Un usuario se define por los atributos:
• IdUser: Nombre de usuario para el inicio de sesión.
• Username: Nombre descriptivo del usuario.
• PassWord: clave de acceso para el inicio de sesión
• Login Try: Cantidad de intentos disponibles antes de iniciar sesión.
• State: Habilitado o no habilitado
• User Language: Idioma configurado para utilizar desde la Interface de usuario.
• Email: Cuenta de correo electrónico donde reportar los mensajes de error
• SMTP Server: Servidor SMTP a usar en el envío de los reportes de error.
APLICACIONES
Una aplicación es una instancia de un sistema, es decir que agrupa un conjunto de objetos que
son instancias de clases que pertenecen a dicho sistema. La definición de aplicaciones permite
especificar los permisos de los grupos de usuario para acceder a los objetos (en termino de los
espacios del universo).
Una aplicación se define mediante:
• IdApplication: Identificador numérico interno de la aplicación.
• Description: Nombre descriptivo de la aplicación.
• idSystem: Identificador del sistema sobre el cual se define la aplicación.
• preFixDoc: Prefijo que se incorporará en el nombre de cada documento de la aplicación.
• State: Estado en el que se encuentra la aplicación: Enabled (Habilitado) o Disabled
(Deshabilitado).
• Configuraciones de acceso:

1. UserGroup: Nombre del grupo de usuarios.
2. AccessType: Tipo de acceso permitido al grupo de usuarios. Es un
subconjunto del siguiente conjunto de valores
Deny Negado. Sin acceso

New Permite crear nuevos
Read Solo lectura
Change Solo cambios, no nuevos
Delete Eliminar objetos
Del Link Eliminar vínculos de objetos
Copy Copiar objetos.
Cut Cortar objetos
Link Vincular objetos
Print Permiso de impresión
Version Revisionar objetos
Version Edit Editar revisiones de objetos
User Events Ejecutar eventos de usuario
Pack Empaquetar objetos
Pack Up Subir paquetes
Import Importar objetos
Trails Herramienta de caminos
Fullcontrol Acceso con control total
3. IdSpace: Identificación del espacio al que se le concede acceso al grupo de

usuarios.
CLASES EN FLEXAB
Una clase encapsula las abstracciones de datos y métodos que se requieren para describir el
contenido y comportamiento de alguna entidad del mundo real. La clase es un modelo o
prototipo que define los atributos y métodos comunes a todos los objetos de cierta clase.
TIPOS DE CLASES EN FLEXAB
C
Clases Reales
Son clases que permiten generar una instancia de un objeto real. La relación estructural
entre clases reales puede verse en el árbol estructural.
Configuraciones generales (Solapa Class)

• Nombre: Nombre único (universal) de la clase
• IdClass: Prefijo para identificar los objetos de la clase (ver definición de Tipos)
• Descripción: Texto descriptivo de la clase
• ClassType: Real
• FormType: Permite elegir la organización de los atributos en el form (layers | table)
• FormFather: Permite elegir si la información del padre se muestra o no en el
Header del form (ver definición de Vistas).
Propiedades Comunes (Solapa Common)

Independientemente de la definición de sus atributos particulares, todo objeto FlexAB
tiene cuatro propiedades predefinidas (ver Vistas de una Clase Real, Formulario):

• IdObject: es un identificador único dentro de la aplicación. Se genera de acuerdo a
los tipos definidos en su clase (ver definición de tipos).
• IdState: es el estado actual del objeto, un estado entre los estados definidos en la
clase (ver definición de estados).
• IdGroup: es uno de los grupos definidos para la clase (ver definición de grupos)
• Tag: (ver definición de tipos).
C
Clases Virtuales
Estas clases se definen como vistas sobre las clases reales. La estructura de objeto que
define una Clase Virtual se compone de información proveniente de objetos de otras
clases. Por este motivo, estas clases no pueden ser instanciadas ni sus objetos pueden
verse en el árbol estructural.
Las clases virtuales se definen a nivel del universo (es decir, valen para todos los
sistemas), y no a nivel de cada sistema-espacio como en el caso de las clases reales.

RELACIONES EN FLEXAB
Relación
Atributo
Espacio
Relation
vale en 1..1
Relación Relación Relación
Definida por 1..1
vale en 1..1 Estructural Inclusión Funcional
relationType={object, link,..} relationType={1-1, 1-N} {1-1}
Sistema clase componente 1..1 relación componente 0..n
(1)
Relación Padre 1..n Clase destino 1..n
Clase Padre 1..n Clase

Relación Funcional 0..n
TIPOS DE RELACIONES EN FLEXAB
Relación
R de Inclusión
La relación de inclusión es aquella que verifica que sus componentes no pueden existir
fuera del objeto compuesto. Su principal característica es que cualquier objeto
componente está completamente encapsulado. En consecuencia, si se tiene una relación
de inclusión, los objetos componentes sólo podrán ser accedidos a través del objeto
compuesto.
La relación de inclusión es una relación entre dos Clases Reales: una clase contenedora
y una clase componente, teniendo la clase contenedora una relación estructural.
El tipo de relación puede ser: 1-1 (uno a uno) o 1-N (uno a muchos), especifica cuántos
objetos componentes pueden relacionarse con un único objeto contenedor. Un objeto
contenedor hace que se trate de forma atómica o encapsulada a las los objetos
componentes. Además, una clase real puede tener relaciones de inclusión con más de una
clase (ver gráfico de Relaciones).
Creación de un objeto componente

La existencia de un objeto componente en un único objeto contenedor se asegura
mediante el mecanismo de creación, la única forma de establecer la relación entre ellos
es: mediante la operación de creación de objetos componente que provee la interfaz por
defecto (form de edición) del objeto contenedor.
La creación de un objeto con un valor de tag que ya existiera en otro objeto de la clase
genera un error.
Eliminación de contenedores y componentes

Mediante una relación funcional, un objeto de cualquier clase puede conocer a un objeto
incluido en otro (objeto componente). Sin embargo no se permite navegar esta relación
funcional (no se puede modificar el objeto conocido por el atributo relation mediante el
form correspondiente).
Si un objeto incluido es referenciado por otro a partir de una relación funcional, no puede
ser eliminado desde el objeto contenedor.
Cuando se elimina el objeto contenedor, todos los objetos incluidos se eliminan también.
Relación
R Estructural
Es la relación entre clases reales dentro de un sistema. Una clase real puede participar
en más de una Relación estructural, es decir que puede tener uno ó más padres
estructurales.
En la relación estructural se distinguen dos roles: una clase padre y una clase hijo,
donde los objetos relacionados tienen comportamiento independiente el uno del otro
(diferencia con respecto a la relación).
Las relaciones estructurales se sub-clasifican en:

• Object: La relación Object es la relación de un objeto con su padre estructural, es
decir, con el objeto a partir del cual fue creado. Un objeto puede tener un solo
padre en sentido de este tipo de relación.
• Link: Es una relación de conocimiento entre dos objetos. A diferencia de la
relación Object, el conocimiento no implica creación. Un objeto puede estar
referenciado por múltiples objetos (múltiples padres en sentido estructural de tipo
Link).
• Import-Link: Análogo al anterior, permitiendo que los objetos referenciados
pertenezcan a otra aplicación.
Restricciones de creación/eliminación
• Si se crea una relación estructural entre dos clases, luego se instancia la relación
(creando un nodo hijo) y finalmente se elimina la relación (desde la SCI), la
relación entre instancias sigue existiendo.
• Al instanciar una relación estructural no se puede utilizar un hijo existente, solo se
puede relacionar con un objeto nuevo (creado a partir del form correspondiente).
• Una relación estructural de tipo object sólo puede eliminarse cuando no existen
relaciones de tipo link a ese objeto. Esta restricción tampoco permite borrar
ancestros del objeto referenciado mediante relación Link.
• Cuando se borra un objeto padre se eliminan los objetos hijos en cascada.
• No es posible eliminar un objeto que esté referenciado funcionalmente desde otro
objeto.
Las relaciones funcionales se implementan mediante la definición de atributos relation.

Estas son relaciones N a 1 entre el objeto que hace referencia a otro y el objeto
referenciado.
Las relaciones funcionales pueden ser:
• Absolutas: En este caso será una relación con cualquier objeto del universo. Es
decir, es posible relacionar con otro objeto de cualquier aplicación del universo.
Esto se indica con idApplication = 0.
• Relativas: Se deberá especificar el valor de la aplicación a la que pertenece el
objeto. En este caso se asocian solo con objetos de la aplicación especificada
(idApplication <> 0).
El SQL asociado a un atributo relation debe respetar las siguientes reglas:

• La denominación del SQL debe tener la forma:
attREL<nombreClase><nombreAtt>
• El esquema resultante debe contener:
(IdInternal, IdApplication, IdObject, <campo> as Value)
• El nombre de sql debe ser de la forma:
attREL<nombreClase><nombreAtributo>.
Las relaciones funcionales no permiten recursión: El código SQL asociado a un atributo
relation de una clase A no puede hacer referencia (directamente o mediante una
secuencia de queries) a si misma.
Por ejemplo: si se define la clase virtual B con sql:
[select IDINTERNAL,IDAPPLICATION,IDOBJECT from classA]
Entonces no es posible agregar en A un atributo de tipo relation con SQL:
[select IDINTERNAL,IDAPPLICATION,IDOBJECT from classB]
La existencia de una relación funcional con un objeto (objeto referenciado) impide que
éste pueda ser borrado.
(1) La cardinalidad del conector clase destino es 1..n dado que el FQL puede retornar
un conjunto heterogéneo de tuplas de la forma (IdInternal, IdApplication, IdObject,
<campo> as Value), o sea, dichas tuplas pueden pertenecer a distintas clases. Notar
que la cardinalidad de este conector es a nivel de Clases y no de Objetos. La relación
funcional tiene cardinalidad (a nivel de Objetos) 1..1.

MODELO DE CLASE REAL
puede pasar a 0..n
define 0..n
tiene regla 0..n Estado
define de 1..n
Atributo
Filtro define 0..n
Estado Grupo Clase Real depende de
(regla)
Atributo Atributo Atributo Atributo

tiene filtro 1..1 define 0..n
Tipo Virtual Relación Visual Real
Filtro FQL
es definido por es definido por
Tipo
tiene 0..n
Filtro tiene filtro 1..1
Método es disparado por
Evento
gotoNo calcula
Método método invocado 1..1
gotoYes
puede cargar
Validación Programa Excel / Word Operación
Macro Mensaje
/ Project
especifica 0..n
aplica 1..n
Expresión a comparar es definido por asigna valor 0..n Parámetro

Función
COM
es definido por
FQL es definido por
TIPOS DE ATRIBUTOS EN FLEXAB
Los atributos son las características o propiedades de las clases de objetos, es la información de
interés que las describen. Todo objeto puede tener cierto número de propiedades, cada una de
las cuales tendrá, a su vez, uno o varios valores.
En Orientación a Objetos, las propiedades corresponden a las clásicas "variables" de la
programación estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con
los métodos y las relaciones (punteros a otros objetos).
Las propiedades de un objeto pueden tener un valor único o pueden contener un conjunto de
valores más o menos estructurados.
Real
R
Se define este tipo de atributo cuando estamos dando de alta un atributo simple, que
puede llevar cualquier tipo de dato:
• · Boolean
• · integer
• · long

• · autonumber
• · single
• · double
• · char
• · text
• · date
• · time
• · datetime
• · timestamp
• · numtext
Relation
R
Se define este tipo de atributo cuando el mismo necesita traer un dato de un atributo que
se encuentra en otro objeto (ver relaciones funcionales).
Virtual
V
Este tipo de atributo cambia de valor dependiendo de la información de otras Clases en el
Universo, es la forma en que los Objetos se nutren de lo que pasa en el Universo, de la
información que brindan las demás Clases. Todos los objetos pueden acceder a la
información de los demás objetos, solo deben suscribir a la información de las Clases que
le interesa. Este tipo de atributo tiene asociado una lista de clases, cualquier objeto que
modifique alguna de las clases de esta lista, va a generar la actualización del valor del
atributo virtual. Queda guardado en la base de datos, pero es el resultado de un cálculo.
Sea la clase A, con un atributo virtual v asociado a los cambios en la clase B (B está
listado en "Virtual: idCLASSVirtual").
• El fql asociado a v debe tener al menos un campo de nombre value y un
campo de nombre idInternal. La consulta a definir debe asociar un
resultado de un cálculo (campo value) a cada valor de idInternal de la clase A,
para que internamente FlexAB actualice cada objeto de A mediante el
correspondiente idInternal.
• El DataType del atributo v debe ser un tipo compatible con el valor devuelto en
el campo value de la consulta fql
• La actualización del v se lleva a cabo en el evento Save de los objetos de clase
A, solo si previamente hubo un cambio en algún objeto de B. En ese momento,
v toma el valor definido por el campo value de la consulta FQL.
Si el código sql es:
SELECT nue.idInternal,res.value
FROM CLASSNUEVA NUE,
(SELECT count(idInternal) AS VALUE
FROM CLASSLIBRO) as res
Entonces el código de actualización es:

UPDATE attNUEVA SET atVirtual=NUEVO.VALUE

FROM attNUEVA, (SELECT nue.idInternal,res.value
FROM CLASSNUEVA NUE,
(SELECT count(idInternal) AS VALUE
FROM CLASSLIBRO) as res
)AS NUEVO
WHERE attNUEVA.idInternal=NUEVO.IDINTERNAL
AND attNUEVA.idInternal=118470100000004
Visual
V
Se define este tipo de atributo cuando es necesario que el usuario de la aplicación,
observe alguna información de otras clases, por ejemplo la descripción del campo y no el
id del mismo, es decir no lo guarda en la base de datos, solo muestra esa información al
usuario.
Para la definición de un atributo Visual es necesario:
• · Definir un método de tipo operation asociado a un evento cualquiera y que
cargue algún valor en el atributo visual.
• · Los valores calculados no se guardan en la BD
ESTADOS EN FLEXAB
FlexAB permite definir un conjunto de estados por los que puede pasar un objeto durante su
ciclo de vida. Dicho conjunto de estados y la relación entre ellos conforman un grafo que se
define en la solapa State de la ventana de edición de la clase.
Cuando se crea el objeto, su estado siempre es INITIAL.
- Definición del grafo de Estados: El grafo de estados tiene una estructura visual de
árbol, por lo que deben repetirse los nodos para representar un ciclo de grafo. En esta
estructura de árbol no se especifica cuando ni como se realizan las transiciones.
Para cada estado es posible definir un conjunto de reglas (ver filtro de estado) y un
conjunto de métodos que se ejecuten en respuesta a un determinado evento solo cuando
el objeto se encuentre en un dicho estado.
- Filtro de Estado (Regla): Indica las condiciones que deben cumplirse para llegar a un
determinado estado.
GRUPOS EN FLEXAB
La configuración de grupos para una clase permite representar subconjuntos de los elementos
de la clase. La pertenencia de un objeto a un grupo es estática y se establece en el momento de
la creación del objeto.
La definición de un grupo requiere:
• idGroup: Nombre unívoco para el grupo
• preFixId: Prefijo que se utilizará como parte del idObject del objeto.
• postFixId: Postfijo que se utilizará como parte del idObject del objeto.
Si se definen grupos en la clase, el IdObject se forma como sigue:
<idClass><preFixId><type><postFixId>
Donde <type> depende de las reglas de tipo definidas para el grupo del objeto (ver Tipos)

Además se cuenta con los campos initialRangeNum y finalRangeNum que permiten definir
un rango de valores cuyo objetivo es limitar los valores posibles para el Tag del objeto. Es decir
que el valor de tag t debe ser tal que:
t є [initialRangeNum,finalRangeNum]
De esta manera, se establece un límite en la cantidad máxima de objetos a crear para ese
grupo.
TIPOS EN FLEXAB
Todo objeto debe poseer un identificador único. Una regla de definición de tipo de una
clase especifica el formato del identificador único de los objetos de la clase (denominado
idObject). La regla a aplicar puede variar para una misma clase de objetos según el Grupo al
que pertenezca un objeto. Las reglas se definen a partir de propiedades que se usan como
filtros para generar la clave del objeto. El idObject puede incluir información del objeto con el
que posee relación estructural o puede ser auto construido.
Para la definición de un tipo (regla) se tienen los siguientes campos

• AutoKey: Esta propiedad permite auto generar la clave del objeto, en caso de no
seleccionarla, se usa el TAG.
• En caso de seleccionar Autokey=no, la clave IdObject quedará formada:
(NNN)<tag>.
• En caso de seleccionar Autokey=autokey, se autogenera la clave IdObject, por lo

tanto quedará formada: (NNN)<autokey>.
• FatherKey: La activación de esta opción permite utilizar propiedades del objeto padre
en la clave del objeto hijo.
• FatherIdAttribute: En caso de activar la opción fatherKey, la propiedad
fatherIdAttribute permite seleccionar el atributo del padre que desea utilizar. Estos
atributos puede ser: el TAG, idObject, idInternal.
• FatherAhead: Esta opción indica la posición de la información del padre (definida
mediante fatherIdAttribute) con respecto a la información del hijo. Si está activada,
entonces la información del padre se coloca adelante.
• FatherDelimitChar: Esta propiedad permite seleccionar el carácter delimitador entre
la fatherIdAttribute y TAG del objeto, entre un conjunto predefinido de caracteres.
• FatherLevel: Esta propiedad indica que ancestro utilizar en término de la cantidad de
niveles hacia la raíz de la jerarquía.
Entonces la clave IdObject se formará de la siguiente manera según las opciones
seleccionadas:
<idCla><tag>[<char><fatherInfo>]
Donde <idCla> está definido en la solapa Class, <char> es lo definido en el campo
FatherDelimitChar, y <fatherInfo> es lo que define el campo FatherIdAttribute. Con la
notación [xx] se indica que xx es opcional, dependiendo del valor de la opción FatherKey.
Adicionalmente, el IdObject puede tener información relativa al grupo del objeto (ver Grupo)
Ejemplos de Uso
Ejemplo 1:
Sean las clases
• [Nueva] (Sin definición de types y con idCLA = (Nue))
• [Hija] (Sin definición de types y con idCLA = [Hi])

1. Se crea un objeto de clase Nueva, con tag aaa entonces el IdObject es: (Nue)aaa.
2. Se crea un objeto de clase Hija, con tag 111 entonces el IdObject es: [Hi]111.
Ejemplo 2:
Sean las clases
• [Hija] (Con idCLA = [Hi] y con type: Autokey=NO)
3. Se crea un objeto de clase Hija, con tag 222 entonces el IdObject es: [Hi]222.
Ejemplo 3:
Sean las clases
• [Hija] (Con idCLA = [Hi] y con type: Autokey=NO, FatherKey=yes,
FatherIdAttribute=Key)
4. Se crea un objeto de clase Hija, con tag 333 entonces el IdObject es: [HI]333aaa.
Ejemplo 4:
Sean las clases
• [Hija] (Con idCLA = [Hi] y con type: Autokey=NO, FatherKey=yes, FatherIdAttribute=idObject)
5. Se crea un objeto de clase Hija, con tag 444 entonces el IdObject es: [HI]333444.
Ejemplo 5:
Sean las clases
• [Hija] (Con idCLA = [Hi] y con type: Autokey=NO, FatherKey=yes, FatherIdAttribute=tag,
FatherAhead=yes)
6. Se crea un objeto de clase Hija, con tag 555 entonces el IdObject es: [HI]aaa555.
Ejemplo 6:
Sean las clases
• [Hija] (Con idCLA = [Hi] y con type: Autokey=NO, FatherKey=yes, FatherIdAttribute=tag,
FatherAhead=yes, FatherDelimiterChar=_)
7. Se crea un objeto de clase Hija, con tag 666 entonces el IdObject es: [HI]aaa_666.
Ejemplo 7:
Sean las clases
• [Hija] (Con idCLA = [Hi] y con type: Autokey=NUMUNIC)
8. Se crea un objeto de clase Hija, con tag 000 entonces el IdObject es: [HI]779.

TIPOS DE IDENTIFICADORES EN FLEXAB
IDINTERNAL Identificador universal, es el identificador único del objeto en el

universo.
IDOBJECT Identificador del objeto, se genera de acuerdo a los tipos definidos para
la clase, es un identificador único dentro de la aplicación.
TAG Es el único identificador que el usuario define.
- Filtro de Tipo: Dado que es posible especificar más de una definición de tipo por clase,
es necesario desambiguar en que caso utilizar cada definición. Para esto se utilizan los
filtros de tipo que deben ser disjuntos.
DEFINICIÓN DE MÉTODOS EN FLEXAB
M
Método Operación
Una operación en un método que permite manipular el estado interno (atributos) de un

objeto. Proveen un mecanismo para hacer obtener resultados provenientes de cualquier
objeto y modificar algún atributo del objeto. (Los métodos de operación modifican solo
atributos del objeto a las que se aplican).
La definición de un método operación requiere:
• FQL: es una consulta cualquiera sobre cualquier clase de objetos.
• idTrgAttrib: es el path XML del atributo a modificar.
• numColumn: es el número de columna en el esquema calculado por el FQL.
• TypeTrg: indica si atributo a actualizar es un valor simple o un conjunto de
valores.
• OnlyInit: seleccionar esta opción si se desea colocar un valor inicial cuando se
está dando de alta un objeto, el cual puede ser editado o no. El valor por
defecto no se tiene en cuenta si ya se tiene un valor. En caso de que ya
contenga un valor.
De esta manera, si el resultado del fql es (v1,…,vn), y se especifica:
idTrgAttrib = “//nomAt/value”
numColumn = x
TypeTrg =value
Entonces luego de la ejecución de la operación se verifica: nomAt=vx
Método Validación
Este método permite realizar validaciones sobre los atributos del objeto al que se aplica
así como los atributos de cualquier otro objeto en el universo.
Una validación verifica que el resultado de una consulta FQL cumpla una cierta condición
y en función de este resultado puede configurarse la lógica del objeto. Para esto, la
configuración de un método validación requiere:
- FQL: es una consulta cualquiera sobre cualquier clase de objetos
- Condición: Es una conjunción de expresiones {c1..cn} donde cada ci es una
comparación entre un valor del resultado del FQL con un valor
constante.
Cada ci se especifica:
• El campo <numColumn> indica el dato que se analizará, mediante el
correspondiente número de columna (en el resultado de la consulta).
• El campo <cmpType> indica el tipo del dato a analizar, pudiendo ser TXT (si es
un dato de tipo string), NUM (si es de tipo numérico) o REC. En el caso de
indicarse REC, se considerará la cantidad de registros del resultado de la
consulta, por lo que se trata como un dato numérico.
• El campo <CMPSign> indica el operador binario de comparación a usar
• El campo <CMPValueNum> indica el valor numérico constante a utilizar en la
comparación. Se utiliza solo si <cmpType>є{NUM,REC}.
• El campo <CMPValueTxt> indica el valor de texto constante a utilizar en la
comparación. Se utiliza solo si <cmpType>=TXT.
De esta manera, la expresión ci a evaluar es:
resultado[<numColumn>] <CMPSign> <CMPValueTxt>, si <cmpType>=TXT
resultado[<numColumn>] <CMPSign> <CMPValueTxt>, si <cmpType>€{NUM,REC}.
El comportamiento de los objetos dependiente del resultado de la evaluación (verdadero

o falso) se configura mediante los campos gotoYES y gotoNO. El valor que pueden
contener estos campos es uno de los siguientes:
• NEXT: Indica que se continúe con la ejecución del siguiente métodos (en el
sentido de OrderNumber) asociado al evento que disparó la validación.
• END: Indica que no se continúe la ejecución de los métodos asociado al evento
que disparó la validación.
• N: Continúa con el método (asociado al evento que disparó la validación) cuyo
ORDERNUMBER se corresponda a N.
Método Macro
M
Los métodos macro permiten ejecutar una secuencia de funciones COM de FlexAB sobre
el resultado de una consulta FQL. Estos métodos permiten llevar a cabo operaciones tales
como modificar las relaciones con otros objetos, bloqueo, versionado y empaquetado de
objetos, entre otras. Estas operaciones permiten modificar atributos del xml de un objeto
que no pueden modificarse desde un método operación. Para esto, el método macro
mantiene un XML de trabajo sobre el cual se llevan a cabo modificaciones intermedias.
El esquema resultante de la consulta FQL debe incluir los campos requeridos en la
primera función que se utilice. Es decir que si la función f tiene una lista de parámetros
(recRes!nom1,…,recRes!nomk) entonces el esquema de la consulta FQL debe incluir al
menos los campos nom1 … nomk.
Las funciones disponibles son:
Nombre de función Descripción Parámetros
actualOBJECTToXML Trae al XML de trabajo, el actual
OBJECTlock Bloquea un objeto recRes!idInternal
OBJECTunlock Desbloquea un objeto recRes!idInternal

objectErase Elimina un objeto recRes!idInternal,
recRes!idFather
objectRevision Crea una revisión de un objeto recRes!idInternal,

recRes!idFather,
recRes!Version,
recRes!Description,
recRes!datemake,
recRes!ExecutedBy,
recRes!CheckedBy,
recRes!ApprovedBy
OBJECTpacking Crea un paquete recRes!idInternal
OBJECTpackingUp Restaura un paquete
OBJECTtoXMLatt Traer el XML de un objeto existente recRes!idInternal,

recRes!idFather
OBJECTtoXMLnew Traer el XML de un objeto nuevo recRes!idInternal,

recRes!idFather
OBJECTtoXMLcopy Traer una copia de un objeto existente recRes!idInternal,

recRes!idFather
SpaceChange Cambia el espacio actual recRes!NewIdSpace
XMLtoOBJECT Guarda el objeto xml
XMLtoXMLadd Agrega objeto incluido recRes!idCLASS,

recRes!idFather
XMLtoXMLdel Elimina objeto incluido recRes!idInternal
XMLtoXMLchgFather Cambia la ubicación de un objeto recRes!idOldFather,

recRes!idNewFather
XMLtoXMLnewLink Crea un nuevo Link a un objeto recRes!idNewFather,

recRes!idnewSpace
Método Mensaje
M
El mensaje ejecuta eventos de objetos de otras clases. Por medio de un mensaje un

objeto puede disparar un evento de otro objeto.
• Se define un método de tipo MSG en la clase A, asociado a un evento e1.
• El FQL asociado debe recuperar un conjunto de IdInternal+IdFather
• Se define una clase B y un evento e2, para indicar que será disparado dicho
evento en los objetos de dicha clase.
• En la clase B se define un método (de cualquier tipo) asociado al evento e2.
MMétodo Programa
El método permite la ejecución de un programa externo.

M
Método
Método Word/Excel/
que permite abrir Project
un archivo Word, Excel o Project y permite cargarle contenido a
los mismos.
- Filtro de Método: Indica el conjunto de restricciones que se deben cumplir para que,
al dispararse el evento asociado, el método pueda ser ejecutado
CLASE REAL (VISTAS)
Clase Real
Reporte HTML Form

Define 0..n Define 1..1
Filtro Reporte
Tiene Filtro 1..1
FORMULARIO DE UNA CLASE REAL
Un formulario define la vista estándar de los objetos de una determinada clase. Esta vista se
divide en dos sub-vistas: el encabezado (Header) y el detalle (Detail). Ambas sub-vistas se
definen utilizando HTML y pueden editarse en modo WYSIWYG (What You See Is What You
Get) o en modo texto.
El encabezado puede mostrar las siguientes propiedades predefinidas:
• IdObject: es un identificador único dentro de la aplicación. Se genera de acuerdo a los
tipos definidos en su clase (ver definición de tipos).
• IdState: es el estado actual del objeto, un estado entre los estados definidos en la
clase (ver definición de estados).
• IdGroup: es uno de los grupos definidos para la clase (ver definición de grupos)
• Tag: (ver definición de tipos).
Para cualquiera de estos datos, en la solapa common del class editor, se permite configurar:
• En que seccion del form se muestra, header o detail (frmPositionField)
• Si es editable o no (frmActive)
• Si es visible o no (frmVisible)
• El texto de la etiqueta correspondiente en el form

• Configurar el orden de visualización (NumListView) en la lista de objetos de la
ventana principal de la SUI. Los atributos que tienen un valor nulo en este
campo no se muestran en dicha lista.
De la misma manera, para los atributos IdState, IdGroup es posible configurar un valor inicial.
Para el campo TAG además es posible especificar:
1. frmControlType: Tipo de entrada en el formulario
2. frmMask: Máscara de entrada de datos (cantidad de caracteres, alfabéticos o
numéricos)
3. frmValidateRule: Regla de validación en término de operaciones de comparación,
conjunción, disyunción y operadores sobre String (Begins, Ends, Contains).
4. frmFormat: ingresar el formato que tendrá el atributo en el formulario
5. List values: En caso que la edición del valor esté restringida a un conjunto de valores,
se puede utilizar control de tipo Combo (frmControlType) cuyo valor será seleccionado
de la lista de valores definida.
En el detalle de un objeto se listan los atributos definidos en esa clase y el detalle de cada
objeto incluido (en caso de haber definido una relación de inclusión).
En base a lo definido en el class editor, el sistema provee un mecanismo de generación
automática de formularios (botón Generate).
REPORTES DE UNA CLASE REAL
Un reporte permite generar vistas alternativas del sistema. Los datos mostrados en el reporte se
obtienen mediante un FQL asociado a cada reporte. A pesar que un reporte está definido en
una clase en particular, la consulta FQL puede recuperar información de objetos de cualquier
clase del sistema, y no solo de los objetos de dicha clase.
La definición de un reporte consiste de:
• idReport: identificador unívoco para el reporte
• idClassFather, idState: Restricciones para ejecutar el reporte (ver Filtros de Reporte).
• Description: texto descriptivo
• FQL: Consulta de la cual se obtienen los datos a mostrar.

CLASE REAL (MISCELÁNEA)
Clase Real
especifica 1..1 Regla de Ayuda especifica 1..1

Seguridad define 0..n define 0..n
utiliza 1..1
Filtro Regla Label

<idLabel> Filtro Ayuda
de Seguridad
Seccion
<idioma,titulo,
define 1..n
contenido>
REGLAS DE SEGURIDAD
Las reglas de seguridad permiten restringir las operaciones aplicables a los objetos mediante un
Filtro de Seguridad. Las operaciones se pueden restringir por medio de los siguientes permisos:
1. deny: implica la negación de todos los otros permisos.
2. new: permite la operación de creación de objetos de esta clase.
3. read: permite la operación de edición de los objetos de esta clase.
4. change:
5. delete: permite la eliminación de los objetos de esta clase
6. del link: permite eliminar un link a un objeto de esta clase
7. copy: permite la copia de un objeto de esta clase
8. cut: permite mover un objeto de esta clase.
9. link, permite crear un link a un objeto de esta clase.
10. print, permite ejecutar reportes (vista previa)
11. version, permite crear una nueva revisión
12. version edit, permite visualizar versiones existentes para el objeto
13. user events, Ejecutar los eventos definidos por el usuario
14. pack, permite crear un paquete de objetos
15. pack up, permite actualizar el sistema con los datos de un paquete
16. import, permite ejecutar la importación/exportación de listas
17. trails, permite trabajar con recorridos
18. full control: implica la validez de los demás permisos (excepto el deny).

CONFIGURACIÓN DE AYUDA
La ayuda de una clase es un texto descriptivo de la clase, que el usuario puede querer mostrar
al pararse sobre un objeto. Dicho texto (denominado Label en FlexAB) está compuesto por una
o mas secciones dependientes de un Filtro de Ayuda.
De esta manera, una clase puede definir distintos Labels para distintas condiciones del objeto
sobre el cual se pide el help.
La definición de un Label requiere:
1. Un texto por cada idioma que se desee configurar. De esta manera, el contenido a
visualizar es relativo al idioma configurado para el usuario actualmente conectado. Los
idiomas disponibles son : Ingles, Español, Frances, Potugues, Aleman e Italiano. El
texto se compone de una o mas secciones de la forma:
<title>unTitulo</title> <section>unTexto</section>
2. Un identificador de la forma:
[HELP] textoDescriptivo
FILTROS
Aplicación FILTRO
clase padre 0..1 (2)
idClassfather
Filtro Filtro especifica 0..1 especifica 0..1 Filtro Filtro Estado Filtro Regla Filtro
Ayuda Método (idApplication) (idApplication) Tipo (Regla) de Seguridad Reporte
espec 0..1
(idApp)
espec 0..1
Aplicación (idApp)
espec 0..1
(idApp)
espec 0..1 espec 0..1

(idSys) (idSys)
Sistema
espec 0..1
espec 0..1
(idAtt)
espec 0..1 (idAtt)
espec 0..1
(idAtt) Atributo
(idAtt)
espec 0..1
espec 0..1 (idGroup)
(idGroup) espec 0..1 espec 0..1
espec 0..1 (idGroup) Grupo de (idGroup)
(idGroup) Grupo
Usuarios
espec 0..1 espec 0..1

(idState) (idState)
especifica 0..1 especifica 0..1
(idState) Estado (idState)

Los filtros permiten especificar restricciones compuestas sobre conceptos de FlexAB. Los filtros
se especifican en términos de campos con valores asociados; un filtro se satisface cuando todos
sus componentes se verifican (es decir, un filtro es la conjunción de todos sus componentes).
En caso de que una componente no sea relevante se puede utilizar el valor * para indicar que
cualquier valor lo satisface (sin restricción).
Existen 6 tipos de filtros:
• Filtro de Ayuda: Especifica bajo que condiciones se muestra la ayuda.
• Filtro de Método: Indica el conjunto de restricciones que se deben cumplir para que,
al dispararse el evento asociado, el método pueda ser ejecutado (ver Métodos).
• Filtro de Tipo: Dado que es posible especificar más de una definición de tipo por clase,
es necesario desambiguar en que caso utilizar cada definición. Para esto se utilizan los
filtros de tipo que deben ser disjuntos.
• Filtro de Estado (Regla): Indica las condiciones que deben cumplirse para llegar a un
determinado estado.
• Filtro de Regla de seguridad: Especifica bajo qué condiciones se aplican las
restricciones de seguridad.
• Filtro de Reporte: Especifica bajo qué condiciones del objeto es posible visualizar el
reporte.
(2) La cardinalidad de los conectores especifica es 0..1 pues al no especificar alguno de los
parámetros (clase padre, estado, grupo de usuarios, atributo o aplicación) no se está
restringiendo los permisos definidos a un valor en particular, es decir que valen para cualquier
valor (lo que en la interfase se especifica con *).
EVENTOS EN FLEXAB
EVENTO
Evento Evento de
Usuario
FlexAB
<nombreEvento>
Los eventos predefinidos por FlexAB para los objetos son:

• New
• BeforeSave
• AfterSave
• Edit
• Delete
• DeleteLink
• Copy-Paste
• Cut-Paste

• Link-Paste
• Print
• FieldChange
• Revision
• Lock
• UNLock
• Parking
• PackingRestore
• BeforeOpenFILE
• AfterOpenFILE
EVENTOS DE USUARIO
Adicionalmente, se provee un mecanismo de definición de eventos de que el usuario puede

disparar explícitamente mediante el menú contextual de un objeto (botón derecho sobre el
objeto desde el árbol).
La definición de un evento de usuario consiste en la construcción de un método con las
siguientes características particulares:
1. En el campo idEvent seleccionar el valor USERevent.
2. En el campo USERevent ingresar un string que será mostrado en el menú contextual de
los objetos de esta clase.
REFERENCIA DE LOS GRAFICOS
CONCEPTO
Describe un Concepto
Elemental en FlexAB
C1 C2
Describe relación ternaria. Es decir, para
relación un determinado valor del concepto C1 y
para un determinado valor del concepto
C2, se define un determinado valor del
concepto C3.
C3
Indica una aclaración importante al

(n) Concepto que se esté describiendo. Es un
hipervínculo al documento correspondiente.
CONCEPTO Representa un Concepto que ya fue

definido en otra pagina.


FlexAB Guia Tecnologica

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

FlexAB Guia Tecnologica

Transféré par

Droits d'auteur :

Formats disponibles

FLLEEXXAB - TG

FlexAB–TG: Guía Tecnológica 2

La Orientación a Objetos es un paradigma, es decir, es un modelo para aclarar algo o para

• entre un objeto y sus atributos (celular > marca, color, modelo);

La metodología de orientación a objetos consiste en:

• Saber el espacio del problema

Esta es la capacidad de FlexAB escalabilidad e integración. Puedo crear aplicaciones

Esta guía esta dirigida al Usuario como al Configurador de aplicaciones de FlexAB,

FlexAB–TG: Guía Tecnológica 3

FlexAB–TG: Guía Tecnológica 4

FlexAB–TG: Guía Tecnológica 5

Las relaciones estructurales se definen dentro de la Aplicación, siendo aplicación un

Podemos definir dos ámbitos para Clase Celular (ESPACIOS):

FlexAB–TG: Guía Tecnológica 6

En función de la vida real, si es un objeto en la vida real seguramente será un objeto

Un tema importante es que los objetos pueden depender estructuralmente de mas de

FlexAB–TG: Guía Tecnológica 7

FlexAB–TG: Guía Tecnológica 8

Toda la tecnología de FlexAB reside en una Base de Datos Relacional-Orientada a Objetos.

¿Qué hace por su estructura?

• Garantiza el acceso y seguridad de la información (datos y archivos) integrada en una

FlexAB–TG: Guía Tecnológica 9

FlexAB–TG: Guía Tecnológica 10

En la actualidad debido a la competitividad del mercado se necesitan herramientas de desarrollo

La idea central de creación de aplicaciones con FlexAB es orientar todo, no solo la

Otro punto importante es que no existe programación. No es necesaria la generación de

Por otro lado, parte de la configuración permite el manejo de mensajes y la ejecución de

FlexAB–TG: Guía Tecnológica 11

Sistema Espacio Grupo de

especifica 1..1 define 1..1

Clase Real Clase Virtual

Un universo es una configuración de trabajo en donde se especifica un Fileserver (para el

Un sistema es un conjunto de clases y relaciones organizadas en espacios. La separación en

FlexAB–TG: Guía Tecnológica 12

Un espacio es un conjunto de definiciones de clases y de relaciones entre éstas. Las relaciones

FlexAB–TG: Guía Tecnológica 13

Deny Negado. Sin acceso

3. IdSpace: Identificación del espacio al que se le concede acceso al grupo de

TIPOS DE CLASES EN FLEXAB

Configuraciones generales (Solapa Class)

Propiedades Comunes (Solapa Common)

FlexAB–TG: Guía Tecnológica 14

FlexAB–TG: Guía Tecnológica 15

Sistema clase componente 1..1 relación componente 0..n

Clase Padre 1..n Clase

TIPOS DE RELACIONES EN FLEXAB

Creación de un objeto componente

Eliminación de contenedores y componentes

Las relaciones estructurales se sub-clasifican en:

Las relaciones funcionales se implementan mediante la definición de atributos relation.

FlexAB–TG: Guía Tecnológica 17

FlexAB–TG: Guía Tecnológica 18

puede pasar a 0..n

Atributo Atributo Atributo Atributo

Expresión a comparar es definido por asigna valor 0..n Parámetro

TIPOS DE ATRIBUTOS EN FLEXAB

FlexAB–TG: Guía Tecnológica 19

Entonces el código de actualización es:

FlexAB–TG: Guía Tecnológica 20

FlexAB–TG: Guía Tecnológica 21

Para la definición de un tipo (regla) se tienen los siguientes campos

• En caso de seleccionar Autokey=autokey, se autogenera la clave IdObject, por lo

FlexAB–TG: Guía Tecnológica 22

FlexAB–TG: Guía Tecnológica 23