Estos son los principales elementos que potencian el desarrollo de aplicaciones en Plex, siempre y cuando se los utilice -no conozco una herramienta que no requiera interpretación-. Trataremos que ésta página sirva para explotar mejor Plex, para quien la use. Y para enriquecer e intercambiar distintos "dialectos" en cómo hacerlo. No es mi propósito, al menos por ahora, el entrar en una descripción minuciosa. La ayuda de Plex tiene actualmente excelente información en al menos dos capítulos de la Guia de Usuario acerca del manejo de modelo, administración de configuración, y análisis de impacto. Aquí por ahora los objetivos son más simples: Poner el acento en que estas facilidades existen, y sugerir estrategias para su explotación.
Hay de todas formas un aspecto que se debiera destacar: Los conceptos de SCM (Administración de Configuración del Software), podríamos decir que son ante todo "defensivos", preventivos, y proactivos "sólo", si esto pudiera decirse así, en cuanto a que asegurar calidad y consistencia conduce a mayor productividad en la elaboración del software. Pero la configuración del modelo en Plex significa más que eso: significa planear el software para que éste tenga mayor alcance, permitiendo organizar el soporte de distintas plataformas, arquitecturas y lenguajes. Es decir que, a condición de planear estratégicamente el software, el diseño puede ser conducido a potentes resultados con pasos simples. No son muchos los productos que le permitieran que su aplicación funcionara sin recurrir a un ejército de gurús en un ambiente Iseries, o Linux, o Web, o cliente Windows, con un bajo nivel de especificaciones y poca inversión en conocimiento de cada plataforma
Qué es el manejo de la configuración en Plex? Es la definición, en un momento dado, de un corte del modelo en una Variante, Versión, Nivel, y Lenguajes dados, con el propósito de crear los artefactos de explotación necesarios en una combinación de plataformas determinada, en base al trabajo de interrogación sobre el modelo que realiza el generador utilizado.
| Variante | Define usualmente la plataforma para la que se diseñará el modelo. La interfaz del usuario, la presentación depende de la variante (Paneles, Reportes, Mensajes). Los nombres de implementación pueden declararse vinculados a la variante, como las etiquetas (Labels). La Lógica (Diagrama de acción) puede ser ajustada a la variante, por medio de metaoperaciones que bifurquen el código basado en la variante de configurado del modelo |
| Lenguaje | Define el lenguaje en el que se mostrará la presentación al usuario. Mensajes, etiquetas, dependen del lenguaje, y pueden declararse independientemente en cada uno que se cree. |
| Versión | Representa un conjunto mayor de cambios. La lógica, el diagrama de acción puede variar según la versión. |
| Nivel | Representa un subconjunto menor de cambios. Una versión puede acumular un grupo de Niveles, omitir algunos, o crear uno separado como PTF |
Si usted usa Plex, el capítulo 16 (V.5.0) de la guia de usuario le dará la información suficiente para que su configuración funcione. Si usted recién comienza, o está en busca de una herramienta integral, tome en cuenta este breve resumen.
La definición de la configuración es crítica, y debería planearse por anticipado, y usarse siempre, aunque no se tenga pensado usar una aplicación "cross platform".Configurar el desarrollo debe ser una rutina de trabajo.
Usando un viejo ejemplo, configurar un modelo significa ubicarlo en un espacio tridimensional: El trabajo siempre debería ser la intersección de Variante/Versión-Nivel/Lenguaje. Por ejemplo, al diseñar un panel, es posible tener una presentación distinta si lo configuro en una variante Windows o AS/400 5250. Si definí las dos variantes, diseñar o generar cualquiera de las dos presentaciones es sólo cuestión de posicionarse en la variante adecuada
¿Cómo hago para iniciar un nuevo desarrollo, sin perder la versión corriente, a la que debo mantener?. Aquí interviene la "dimensión" de Versión y Nivel: Es necesario crear una nueva versión, y configurarse en ella para todo lo que se desarrolle para el nuevo proyecto. Cuando sea requerido volver atrás, al trabajo en la versión anterior, para generar parches, sólo hay que cambiar a la dimensión previa. Si usted es un usuario nuevo, puede aprender lo suficiente simmplemente recorriendo las librerías de clases o patterns que dispone con Plex. Haga la prueba de cambiar la configuración, y recorra la lógica y la presentación, para ver las diferencias
¿Qué pasa si hemos decidido cambiar de NT a Linux, o nos fusionamos con una empresa que tiene AS/400?. Esta suele ser la oportunidad para hechar a la basura todo lo que ya nos tenía cansado!. Pero, si nuestro desarrollo es valioso, o irreemplazable, la situación puede ser dramática. En cambio, como Plex trabaja al nivel del modelo abstracto del problema, es posible hacer una transición simple (o mucho más simple que pensar todo de nuevo). En principio, nos hace falta una nueva variante. Tendremos probablemente distintos métodos de acceso a nuestros datos. Dejemos de lado el hecho de que el encapsulamiento y la arquitectura que separa presentación de lógica, y GUI de servicios en servidor, que nos facilita de por sí la transición, y vayamos a la variante: Es posible, con una variante definida, rehacer la presentación de acuerdo a lo que la nueva plataforma permita. Es posible definir nuevas funciones adecuadas a la manipulación de datos; es posible redefinir la lógica según la plataforma requiera para procesar los datos. Existen triples que permiten redefinir la lógica (AD) de acuerdo a la nueva necesidad. Aquí intervienen normalmente las metaoperaciones.
La relación entre Versión y Nivel: Parecería una diferencia no muy significativa, pero debería usarse tal como corresponde en un ambiente reglado por un esquema de manejo de versión; es decir, una versión es un cambio mayor, y los niveles corresponden a una colección de cambios menores.
Se pueden enumerar varios recursos que en conjunto permiten actuar a la configuración:
Desde la versión 5.1, y con mayor amplitud en la versión 5.5, es posible exportar e importar partes del modelo. Esta facilidad debe ser tenida en cuenta también a propósito de la configuración, tanto sea para no cometer errores, como para explotarla. El punto a tener en cuenta es que la exportación o importación con XML se ejecuta de acuerdo a la configuración que el modelo posea en el momento de iniciarse. Es decir, se mueve una fotografía estática del modelo, en las dimensiones en que éste haya sido configurado (Salida desde el modelo), y se aplicará al conjunto de dimensiones que se hayan configurado en el destino (Integración en destino).
Quien provenga de un ambiente de administración de los cambios al código, se encontrará con dificultades para aplicar sus reglas en Plex.
La cuestión principal es cuál es el valor que se debe proteger, y secundariamente también qué hacer para proteger una aplicación en producción.
El valor a proteger es el Modelo de Grupo. Este es el lugar donde se producen los cambios, y donde evoluciona la aplicación.
El código fuente generado es relativamente secundario, ya que puede regenerarse contínuamente a partir de las definiciones del modelo, y las sucesivas versiones pueden reconstruírse de ser necesario en base al manejo de versión y nivel.
La regla número uno es que, cualquiera que sea la política que se adopte respecto al código fuente, deben guardarse los sucesivos cortes requeridos del modelo de grupo.
El código fuente: La arquitectura de Plex apunta a la mantención de un modelo móvil, donde los cortes en su configuración se proponen hacer el seguimiento de grupos consistentes, más o menos estables y grandes de cambios; la entrega de un parche o un release.
Sería muy difícil una política de versiones a nivel de objeto o versión, guardando cambios diarios. Tampoco sería posible restaurar un objeto a un nivel determinado, sin considerar las dependencias de éste con todos aquellos objetos con los que está relacionado.
Precisamente esta integridad monolítica es una de sus ventajas.
Una solución es la que se aplica con Turnover, que inicia el control de cambios a partir del código fuente RPG, con lo que es posible mantener una estructura de versiones "tradicional", a nivle del código fuente.
Esta solución es buena desde el punto de vista de la continuidad de la aplicación en producción, y debe ser siempre considerada: el código fuente de los objetos que se están ejecutando no se puede perder,
sea para rastrear un problema en producción, o sea para recuperar un error en el código, previniendose de que la evolución del modelo no pueda reconstruír el fuente al nivel deseado.
Es decir, un responsable de operaciones debe poder restaurar una versión menor si la versión corriente falla.
Una alternativa dentro del modelo es, en tanto sea posible, abrir una nueva variante de desarrollo con objetos nuevos, sin abandonar los antiguos hasta que la versión nueva esté estable y aprobada, y sólo entonces, descartar los objetos obsoletos.
Finalmente, una cuestión de importancia es mantener también la pista de todos los objetos o instrumentos que integran el ambiente de una versión o release, y para eso es necesaria una política más amplia que la configuración del modelo.
Aquí se debe tener una política basada en una herramienta de administración, o procedimientso claros en su reemplazo.
Esta colección de objetos que integran el ambiente, lo constituyen la documentación de instalación, de manejo del modelo, el nivel de release necesario de los objetos runtime (dlls de sistema, por ejemplo), el numerador de funciones, el archivo con definiciones de generación (bld),
las definiciones aplicadas a .ini, .properties de configuración de la aplicación y de Plex, imágenes (gif, bmp) invocadas, activex y su versión, y todo aquello que en conjunto conforma el ambiente de desarrollo del modelo y el de la aplicación
Para resumir, cómo mantener un esquema de administración de cambios, y configuración de Release
Existe una discusión abierta en EDGE acerca de la administración de los cambios con Plex en un ambiente controlado por un ISeries. Puede verlo en el Foro, y participar si aún está activo para cuando lo consulte. Obtendrá ideas prácticas acerca de cómo y dónde dentro de Plex puede establecer los puntos de control para disparar los "scripts" necesarios para administrar los cambios. Hablando en general, estos puntos están en el momento en que Plex ejecuta al compilador de la plataforma de que se trate: En la discusión se habla de código basado en ISeries: está dicho en otro sitio (tips) que es posible modificar las instrucciones ejecutadas al compilar. Ese sería el punto de inserción de lógica de administración de código fuente. Lo mismo puede decirse aún más claramente en el caso del ambiente Java o WinC, donde los "hooks" se pueden establecer desde la pantalla misma de administración de las instrucciones del "makefile" Esos mismos serían los puntos en que enlazaría Plex con un administrador de cambios, tales como Implementer o Source Integrity.
El manejo de las autorizaciones depende de la actividad conciente de un administrador del/los modelos.
En sentido estricto la autoridad se asigna a los usuarios a nivel de verbos utilizables, niveles permisibles, y propiedad de los objetos.
Es decir, un usuario puede ser circunscripto a determinadas funciones estableciendo a qué grupos de verbos podrá acceder,
facilitando la creación de perfiles de trabajo, si el equipo admitiera una división de responsabilidades.
Lo mismo puede decirse de la autorización de niveles, al permitir disponer de un grupo trabajando en un nivel en explotación,
mientras otro lo hace en una versión futura.
La propiedad de los objetos es determinable permitiendo su actualización por todos (World), o limitándola a nivel de grupo o usuario.
Pero en un sentido amplio, podemos hablar también del uso de submodelos en la extracción de modelos locales, como una parte de este esquema.
Los submodelos permiten acotar el número de objetos que se extraen del modelo grupal, reduciéndolos a aquellos que hagan falta para una actividad específica,
y minimizando el riesgo de conflictos.
Finalmente, es posible marcar los objetos en proceso de modificación por un usuario con object flags,
lo que no impide que otro usuario tome y trabaje sobre ese objeto, pero será advertido de que se producirá un conflicto.
En resumen, tenemos estos elementos para pensar la arquitectura de control que mejor se adapte a nuestra necesidad: