flexab guia tecnologica

FFFLLLEEEXXXAAABBB --- TTTGGG GGGUUUÍÍÍAAA TTTEEECCCNNNOOOLLLÓÓÓGGGIIICCCAAA

FlexAB–TG: Guía Tecnológica v22 – 1_(DOC)TEG.pdf

2

ÍÍÍnnndddiiiccceee IINN TT RR OO DD UU CC CC II OO NN ............................................................................................................3 OO BB JJ EE TT OO SS .......................................................................................................................4 CCLL AA SS EE SS .........................................................................................................................5 OO BB JJ EE TT OO SS FFLL EE XX AABB .........................................................................................................7 RREE LL AA CC II OO NN EE SS EE NN TT RR EE OO BB JJ EE TT OO SS ......................................................................................8 EESS TT RR UU CC TT UU RR AA DD EE FFLL EE XX AABB .............................................................................................9 AA PP LL II CC AA CC II OO NN EE SS CC OO NN FFLL EE XX AABB......................................................................................10 CCRR EE AA CC II ÓÓ NN DD EE AA PP LL II CC AA CC II OO NN EE SS CC OO NN FFLL EE XX AABB ..............................................................11 UUNN II VV EE RR SS OO SS EE NN FFLL EE XX AABB .............................................................................................12

UUNN II VV EE RR SS OO SS ................................................................................................................... 12 SS II SS TT EE MM AA SS ..................................................................................................................... 12 EESS PP AA CC II OO SS ..................................................................................................................... 13 GGRR UU PP OO SS DD EE UUSS UU AA RR II OO SS .................................................................................................. 13 AAPP LL II CC AA CC II OO NN EE SS .............................................................................................................. 13 CCLL AA SS EE SS EE NN FFLL EE XXAABB ....................................................................................................... 14 TTII PP OO SS DD EE CC LL AA SS EE SS EE NN FFLL EE XX AABB ....................................................................................... 14

RREE LL AA CC II ÓÓ NN EE NN FFLL EE XX AABB ...............................................................................................16 TTII PP OO SS DD EE RREE LL AA CC II OO NN EE SS EE NN FFLL EE XX AABB ............................................................................... 16

MMOO DD EE LL OO DD EE CCLL AA SS EE RREE AA LL ............................................................................................19 TT II PP OO SS DD EE AATT RR II BB UU TT OO SS EE NN FFLL EE XXAABB ................................................................................. 19 EESS TT AA DD OO SS EE NN FF LL EE XXAABB .................................................................................................... 21 GGRR UU PP OO SS EE NN FFLL EE XXAABB ...................................................................................................... 21 TTII PP OO SS EE NN FFLL EE XX AABB ......................................................................................................... 22 TT II PP OO SS DD EE II DD EE NN TT II FF II CC AA DD OO RR EE SS EE NN FFLL EE XX AABB ....................................................................... 24 DDEE FF II NN II CC II ÓÓ NN DD EE MMÉÉ TT OO DD OO SS EE NN FFLL EE XXAABB .......................................................................... 24

CCLL AA SS EE RREE AA LL(( VV II SS TT AA SS)) .................................................................................................27 FFOO RR MM UU LL AA RR II OO SS DD EE UU NN AA CCLL AA SS EE RREE AA LL ............................................................................... 27 RREE PP OO RR TT EE SS DD EE UU NN AA CCLL AA SS EE RREE AA LL ..................................................................................... 28

CCLL AA SS EE RREE AA LL(( MMII SS CC EE LL ÁÁ NN EE AA )) .......................................................................................29 RREE GG LL AA SS DD EE SSEE GG UU RR II DD AA DD ................................................................................................. 29 CCOO NN FF II GG UU RR AA CC II ÓÓ NN DD EE AAYY UU DD AA .......................................................................................... 30

FFII LL TT RR OO SS .....................................................................................................................30 EEVV EE NN TT OO SS DD EE FF LL EE XX AABB .................................................................................................31

EEVV EE NN TT OO SS DD EE UUSS UU AA RR II OO .................................................................................................. 32 RREE FF EE RR EE NN CC II AA DD EE LL OO SS GG RR AA FF II CC OO SS .................................................................................32

FlexAB–TG: Guía Tecnológica v22 - 1_(DOC)TEG.pdf

3

IIInnntttrrroooddduuucccccciiióóónnn 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.


4

OOBBJJEETTOOSS 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.


5

CCLLAASSEESS 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


6

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. 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

Inventario 2005

Inventario 2006

Sistema de Inventarios


7

OOBBJJEETTOOSS FFLLEEXXAABB 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.


8

RREELLAACCIIOONNEESS EENNTTRREE OOBBJJEETTOOSS 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


9

EESSTTRRUUCCTTUURRAA DDEE FFLLEEXXAABB 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.


10

AAPPLLIICCAACCIIOONNEESS CCOONN FFLLEEXXAABB 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.


11

CCRREEAACCIIÓÓNN DDEE AAPPLLIICCAACCIIOONNEESS CCOONN FFLLEEXXAABB 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.


12

UUNNIIVVEERRSSOOSS EENN FFLLEEXXAABB

UUNN IIVV EE RRSS OO SS EENN FFLL EE XXAABB

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.

SSIISS TT EEMM AASS

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.

Universo<DBName, LoginType,

FSServerName>

Espacio Grupo de Usuarios

Aplicación

Clase

Clase Real Clase Virtual

especifica permisos define

FQL es definida por

Sistema

0..n

1..n tiene 1..n

1..1 1..1

tiene 1 n

define 0..n

tiene 1..n tiene 1..n


13

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.

EESS PPAACC IIOO SS

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.

GGRRUU PPOO SS DD EE UUSS UU AA RRIIOO SS

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.

AAPPLL IICC AACC IIOO NN EESS

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:


14

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.

CCLL AASS EESS EENN FFLL EEXXAABB 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.

TT II PP OO SS DD EE CC LL AA SS EE SS EE NN FFLL EE XX AABB

C 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):

Clases Reales


15

• 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 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.

Clases Virtuales


16

RREELLAACCIIOONNEESS EENN FFLLEEXXAABB

TT II PP OO SS DD EE RREE LL AA CC II OO NN EE SS EE NN FFLL EE XX AABB

R

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).

Relación de Inclusión

Relación Padre 1..n

Relación Estructural

relationType={object, link,..}

Relación

Clase

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

Clase destino 1..n

Clase Padre 1..n Relación Funcional 0..n

Espacio

Sistema

vale en 1..1

vale en 1..1

Relación Inclusión

relationType={1-1, 1-N}

Atributo Relation

Definida por 1..1 Relación

Funcional {1-1}

(1)


17

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.

R 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.

R

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:

Relación Estructural


18

• 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.


19

MMOODDEELLOO DDEE CCLLAASSEE RREEAALL

TT II PP OO SS DD EE AA TT RR II BB UU TT OO SS EE NN FFLL EE XX AABB 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.

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

gotoYes

gotoNo método invocado 1..1

calcula

es definido por

aplica 1..n

es disparado por

puede pasar a 0..n

es definido por es definido por

Estado

Grupo

TipoAtributo Virtual

Atributo Relación

Atributo Visual

Atributo Real

Atributo

Método

Validación Programa Excel / Word / Project Macro Mensaje Operación

FQL

FunciónCOM

Parámetro

define de 1..n

define 0..n

define 0..n Clase Real

define 0..n

depende de

tiene 0..n

Evento

FQL

es definido por Expresión a comparar

es definido por

puede cargar

especifica 0..n

asigna valor 0..n

Filtro Tipo

Filtro Método

Filtro Estado (regla)

tiene filtro 1..1

tiene regla 0..n

tiene filtro 1..1

Real


20

• · autonumber

• · single

• · double

• · char

• · text

• · date

• · time

• · datetime

• · timestamp

• · numtext

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).

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

Virtual

Relation


21

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

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

EESS TT AA DD OO SS EE NN FFLL EE XX AABB

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.

GG RR UU PP OO SS EE NN FFLL EE XX AABB 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)

Visual


22

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. TT II PP OO SS EE NN FFLL EE XX AABB

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])


23

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.



• [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.



• [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.



• [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.



• [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.



• [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.



• [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.


24

TT II PP OO SS DD EE IIDD EE NN TT II FF II CC AA DD OO RR EE SS EE NN FFLL EE XX AABB

Identificador universal, es el identificador único del objeto en el universo.

Identificador del objeto, se genera de acuerdo a los tipos definidos para la clase, es un identificador único dentro de la aplicación.

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.

DD EE FF II NN II CC II ÓÓ NN DD EE MM ÉÉ TT OO DD OO SS EE NN FFLL EE XX AABB

M 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 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

Método Operación

Método Validación

IIDD II NN TT EE RR NN AA LL

IIDD OO BB JJ EE CC TT

TT AA GG


25

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 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

Método Macro


26

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 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.

M El método permite la ejecución de un programa externo.

Método Mensaje

Método Programa


27

M Método que permite abrir 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

CCLLAASSEE RREEAALL ((VVIISSTTAASS))

FFOO RR MM UU LL AA RR II OO DD EE UU NN AA CCLL AA SS EE RREE AA LL 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

Método Word/Excel/ Project

Clase Real

Filtro Reporte

HTML Form Reporte

Tiene Filtro 1..1

Define 0..n Define 1..1


28

• 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).

RREE PP OO RR TT EE SS DD EE UU NN AA CCLL AA SS EE RREE AA LL 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.


29

CCLLAASSEE RREEAALL ((MMIISSCCEELLÁÁNNEEAA))

RREE GG LL AA SS DD EE SS EE GG UU RR II DD AA DD 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).

Clase Real

Filtro Ayuda

Ayuda Regla de Seguridad define 0..n

especifica 1..1 define 0..n

Label<idLabel>

Filtro Regla de Seguridad

especifica 1..1

Seccion <idioma,titulo,

contenido>

utiliza 1..1

define 1..n


30

CCOO NN FF II GG UU RR AA CC II ÓÓ NN DD EE AA YY UU DD AA 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

FFIILLTTRROOSS

Filtro Tipo

Filtro Estado (Regla)

Filtro Regla de Seguridad

Filtro Reporte

FILTRO (2)

Filtro Ayuda

Filtro Método

Aplicación

Sistema

Atributo

Grupo

Estado

Grupo de Usuarios

Aplicación clase padre 0..1 idClassfather

especifica 0..1 (idApplication)

especifica 0..1(idApplication)

espec 0..1 (idApp)

espec 0..1 (idApp)

espec 0..1 (idApp)

espec 0..1 (idSys)

espec 0..1 (idSys)

espec 0..1 (idAtt)

espec 0..1 (idAtt)

espec 0..1 (idAtt)

espec 0..1 (idAtt)

espec 0..1 (idGroup)

espec 0..1 (idGroup) espec 0..1

(idGroup)



espec 0..1 (idState)

especifica 0..1 (idState)

espec 0..1 (idState)

especifica 0..1 (idState)


31

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 *). EEVVEENNTTOOSS EENN FFLLEEXXAABB Los eventos predefinidos por FlexAB para los objetos son:

• New

• BeforeSave

• AfterSave

• Edit

• Delete

• DeleteLink

• Copy-Paste

• Cut-Paste

Evento de Usuario

<nombreEvento>

EVENTO

Evento FlexAB


32

• Link-Paste

• Print

• FieldChange

• Revision

• Lock

• UNLock

• Parking

• PackingRestore

• BeforeOpenFILE

• AfterOpenFILE

EEVV EE NN TT OO SS DD EE UU SS UU AA RR II OO 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.

RREEFFEERREE NNCCII AA DDEE LLOO SS GGRR AAFF IICCOO SS

Describe relación ternaria. Es decir, para un determinado valor del concepto C1 y para un determinado valor del concepto C2, se define un determinado valor del concepto C3.

CONCEPTO Describe un Concepto Elemental en FlexAB

relación

C1 C2

C3

CONCEPTO Representa un Concepto que ya fue definido en otra pagina.

(n) Indica una aclaración importante al Concepto que se esté describiendo. Es un hipervínculo al documento correspondiente.

flexab guia tecnologica

Documents