MULBRI

Porque MULBRI?

1. Porque en muchos paises hay que utilizar una red de datos costosa para llegar a un nodo de EARN o BITNET, y que entonces era preferable deportar el maximo del proceso en el PC y permitir la compactacion, para bajar sensiblemente la factura.

2. Porque la solucion de archivaje en el nodo no era conveniente para un consultor en constante viaje que necesita mobilizar rapidamente sus datos, documentos y mensajes.

3. A mas largo plazo, para poner en perspectiva el desarollo de un prototipo de interfase usuario de alto nivel deportado en PC, con el objetivo de definir un programa capaz de ofrecer a la region ALC lo que falta en las otras regiones. La idea es de integrar ese trabajo al estudio REDALC de tal manera a integrar el desarollo industrial de ese programa al presupuesto del proyecto.

Porque MULBRI?

Para desarollar un metodo de experimentacion rapido y paralelo al estudio de factibilidad REDALC.

I.II Desarrollos

VERSION I, 6/89

La primera version fue basada en el entorno informatico del nodo EARN que nos aloja, el del CNUSC en Montpellier: nodo IBM/VM con acceso remoto via TRANSPAC a traves del programa SIMPC version XXXX, y del entorno de trabajo de la UL: PC bajo DOS. Todavia MULBRI funciona solamente en ese entorno.

La primera version fue fabricada por Daniel Pimienta a partir de la implementacion (utilizando un mecano de programas existentes y una particion de directorios) de un diseno sencillo que distingua los usuarios siguientes: -Internos Union Latina: los funcionarios de la organizacio, con la distincion de los usuarios "local" (los que comparten el mismo nodo y que necesitan comunicar entre se). Dentro de los usuarios internos aparecio tambien el concepto de operador de grupo de Usuario encargado de la comunicacion para un grupo. -Usuarios redes de investigacion: el mundo "normal" de las redes, que no utiliza MULBRI (el acceso a ese grupo es reservado a los investigadores de la UL).

Desde su principio MULBRI separa dos tipos de comunicacion:

-dentro del mundo MULBRI, con funciones avanzadas de comunicacion mensajes con accentos, documentos o hojas de calculo compactados, cartas encryptadas con llave, archivage implicito por destinacion, administracion de los usuarios facilitada, y mas que todo estructuracion de la comunicacion para permitir un control logico y fiable del flujo.

-con el mundo de la investigacion, con un interfase que esconde el nativo BITNET, con gestion deportada en el PC, de manera a minimizar los tiempos de conexion.

La baja calidad del interfase usuario de esta version se noto rapidamente al mismo tiempo que nuestras limitaciones en personal para seguir un desarollo. Asi se decidio contratar DDA para confecionar algo mas serio (despues de una mala experiencia con otra persona).

Se redactaron dos documentos: -"El uso del complejo "EARN/TELENET", 9/89: documento de 18 paginas destinado a brindar los conceptos basicos a usuarios sin experiencia de telecomunicacion y a demistificar el uso de redes. Ademas el documento aborda consideraciones economica en el uso de diferente metodos de comunicacion. -"MULBRI", 11/89; un docummento de 19 paginas conteniendo elementos de disenhos (formato de los mensajes, flujo de los mensajes, interfases) y consejo de buen uso a los usuarios.

VERSION 2

Fue la replica exacta del disenho inicial y de las funciones, pero con interfases de buena calidad y con una programacion ad hoc. Desde ese nivel, MULBRI comenzo a ofrecer las tecnicas la mas avanzadas de programas en PC ("pop up windows", ayudas contextual). DDA se dio el gusto de fabricar su propio lenguaje "a motor de inferencia" que hacia, siguiendo una programacion descriptiva, ejecutar rutinas escritas en languaje PASCAL. Utilizando el interface SIMPC, MULBRI arrancaba proceduras escritas en el languaje de SIMPC para la transferencia de los mensajes entre el nodo y el PC. Y, dentro del nodo, se arracanban rutinas escritas en REXX bajo VM. MULBRI presentaba desde este nuevo principio una tecnica de compactacion recursiva para automatizar y facilitar el proceso de instalacion.

VERSION 3

El objetivo es de llegar, con el final de esa version, a un nivel donde todas las funcionalides importantes estan satisfechas para el uso interno, y a un nivel de funcion por lo menos igual a EARN por el uso externo a la UL. Hubieron 3 sub-versiones ya, que hizieron un salto funcional importante (3.11 a 3.13 la actual). Las versiones 3 ubiquan MULBRI a un nivel de programa profesional y se puede pensar ahora a extender su uso. El problema crucial del archivaje de los mensajes fue tratado con la version 3, y una seria de funciones de manipulacion de mensajes fuzeron introducidas (copiar, reenviar, importar, exportar). Para lograr eso, DDA tuvo que extender el disenho inicial, manteniendo el control de flujo de manera explicita en bloques de control.

I.III Modo de desarrollo

La originalidad del modo de desarollo es que los propios usuarios expresan sus quejas o requisitos al fabricante quien resolve los problemas urgentes, mandando, por el mismo sistema de comunicacion MULBRI, las soluciones que auto modifican el programa. Ademas se consignan los requisitos para decidir, en reuniones frecuentes, el contenido de la proxima version. Va sin decir que la opinion de los usuarios finales es clave en el proceso.

II MULBRI EN LA ACTUALIDAD

II.I Nivel de calidad

Si bien es que el modo de desarollo aporta los problemas normales de un prototipo (problemas nuevos a cada version que se arreglan poco a poco), el metodo nos permitio llegar a un nivel funcional ya bastante operacional y que reflete los deseos de usuarios non neceseriamente informaticos o especialistas de redes. Desde la version 3.1 MULBRI se planteo como una herramienta brindando los frutos esperados de la inversion para el uso interno. La version actual tiene un nivel funcional bastante impresionante en termino al uso interno, y bien operacional en termino de uso hacia el mundo de las redes. La experiencia del uso del nivel 3 de MULBRI desde varios meses permite ya entrever la version final del nivel 3, resolviendo problemas importantes de coherencia semantica de los MENU, utilizando el multi-linguismo, y afinando el nivel de detalle del propio interfase usuario. Los problemas ya son menos frecuentes, y donde las condiciones de communicacion son suficiente, el uso ya es natural y fluide. La extencion se hace con facilidad en el plan humano (los nuevos usuarios "entran" en el sistema sin problema) y los sindromes de rechazo (frecuente frente a tecnologias avanzadas en el mundo de la oficina, no se han manifestado).

Hemos tenido experiencias de uso de "burotica-fiction" de la valor importante que representaba el envio de documentos. En un caso de gestion administrativa urgente entre Santo-Domingo y Paris via Martinica, donde documentos redactados por un "staff" en un lugar, estaban corregidos por una secretaria en otro lugar, chequeado por el firmante en otro lugar, reenviado para ultima correcion al redactador y luego mandado en un tercero lugar para impresion sobre papel prefirmado y remite. Un exercisio de estilo que permitio arreglar en 1 dia un proceso que hubiera tomado semanas por correo y que hubiera sido imposible sin MULBRI.

II.II Cifras de uso

En la actualidad existen 7 "agencias MULBRI" operacionales (con el uso del nodo del CNUSC), y un trafico quotidiano superior a 15 mensajes o documentos internos. Los dos usuarios los mas goloso del programa son, Silvia Quenan, la operadora de la agencia Arago de la Union Latina (quien gestiona unos 15 usuarios finales) y Daniel Pimienta quien ademas de intercambiar una medida de 4 mensajes diarios con sus coleguas de Union Latina mantiene un intercambio de 6 mensajes diarios con sus coleguas del mundo de la investigacion. A ese nivel el numero de mensajes archivados en su PC pasa los 1000. Las dificultades actuales de extension ya no estan del hecho de MULBRI, sino del inevitable problema de aplicacion a entornos diferentes (agencias con nodo USENET, agencias con nodo BITNET sin SIMPC, etc...).

III FUTURO DE MULBRI

Hay 5 axis de desarollo del prototipo:

*Funcionalidades en uso interno:

• Estabilizacion del programa (coherencia logica y semantica de los menu, rellenar los menu de ayuda, traduccion en frances, portugues y italiano, redaccion de documentos para usuarios, para operadores, y para programadores),
• confeccion de una version de demonstracion adaptada al mundo de la investigacion,
• automatizacion del proceso de personalizacion de las proceduras de conexion, version para aliviar el usuario en entorno de comunicacion dificil ("scheduler" de noche, chequeo finos de la comunicacion, rescheduleo en caso de problema).
• version adaptada al uso de redes locales donde cada usuario final es identificado como destinacion y el proceso de operadora se hace de manera automatica.

*Funcionalidades en el uso hacia el mundo de la investigacion:

• nivelacion funcional hacia EARN (tener por lo meno el mismo nivel funcional que el que ofrece EARN),
• rationalizacion de los flujos de mensajes (el caso de la lista de distribucion sin hacer varios envios del PC al nodo)
• extencion funcional (acceso a banco de datos y gestion de conferencia).

*Soporte de entornos diferentes:

• por el terminal, ademas de PC/DOS: APPLE, PC/UNIX.
• por el programa de comunicacion, ademas de SIMPC: un programa ad-hoc(?), UUPC (?), un programa existante con emulacion mas natural (?), TCP-IP (?).
• por el entorno del nodo: version UUCP, version BITNET/DEC.

*Aspetos normativos: integracion de los conceptos X400, X500.

*Aspetos usuarios: integracion de conceptos de comunicacion estructurada (como Coordinador), funciones de burotica (agenda, organizacion de reunion, guias telefonicas...).

La trampa en la cual no podemos caer con un prototipo es de pretender hacer un desarrollo industrial en varios entornos: los costos de produccion se estuvieran multiplicandose en factores del orden de magnitud de 10 a 100! Tambien tenemos que poner mucho pragmatismo en nuestras seleccion:

• evitar problemas de compatibilidad en permitiendo solamente desarrollos complementarios bajo interfases estrictamente definidos,
• concentrase en soluciones que corresponden a problemas de la region y que demuenstran algo en el tiempo del estudio (que se termina antes del final del anho),
• adquirir experencia en entorno que son o van a ser importante,
• no perder de vista el objetivo global de REDALC de tal manera a integrar de manera convenable el resultado en el documento de proyecto.

El estado de nuestras reflexiones, luego de la reunion con DDA es:

• Primzero MULBRI se consolida para terminar la version 3.

• Luego, el proceso se orienta mas a la problematica REDALC (vs la problematica de la Union Latina).

• Se trata de desarollar entornos en nodos diferente para capitalizar en la parte la mas gruesa del programa (la que esta en el PC), eso implica:
  • Dejar el entorno APPLE por el momento (a lo menos que alguien se proponga) y el entorno PC/UNIX,
    
  • focalizar los entornos UUCP, TCP-IP, X400.

IV PLAN DE DESARROLLO DE MULBRI (TENTATIVO)

1/5/91     6     7     8     9     10    11     12   1/92  2/92 

=================================================================
     ^     ^     ^     ^     ^      ^     ^      ^    ^    ^    ^
     a     b     c     d     e      f     g      h    i    j    k



TAREA                              INDICE PESO   RESPONSABLE



Resolucion de los problemas Ver 3.13    a  2     DDA

Documentacion para programadores        b  3     DDA

Traduccion de la doc en castellano      b  2     Silvia

Resolucion de los menu, definicion      a  2     Patrick/Prado

Resolucion de los menu, realizacion     b  5     DDA

Redaccion de las ayudas de contexto     b  3     Patrick+Silvia

Version frances                         b  2     Patrick

Version portugues                       c  2     Tadao

Version de demonstracion                b  3     Pablo Liendo 

Version UUCP                            i 40     Julian

Version TCP-IP                          j 40     Tadao

Amelioracion proceduras SIM y schedulor c 12     X (RD) 

Version 3 pre final (ver definicion)    c 10     DDA

Version 3 final                         e  8     DDA

Version 4.1 compl. a EARN, definicion   c  1     GRUPO ENTERO

Version 4.1 realizacion                 h 20     DDA

Estudios X400                           ?        ???

Version LAN                             ?  ?     DDA

Version APPLE                           ? mucho  ?

Notas:

• El indice indica la fecha de terminacion de la tarea.
• El peso es una estimacion del numero de dia/persona para cumplir la tarea.
  
• Queremos aprovechar de la venida de DDA en las jornadas REDALC de julio en Santo Domingo para, en grupo, hacer sesiones de trabajo sobre el tema. Eso interesa principalmente Patrick, Pablo, Julian y un eventual representente de Tadao.
• Hay tareas no listadas aqui pero que van a sacar tiempo a los participantes que consisten a introducir nuevas agencias UL.

Definicion de la version 3 pre final:

• integracion de las nuevas definiciones de los menu,
• introduccion del concepto de confirmacion en acciones,
• archivaje abierto (distinccion version operador y version usuario final),
• amelioracion de las proceduras SIM, resolucion del problema del usurario en viaje, scheduler de conexion,
• amelioracion de la presentacion, soporte de "mouse",

V ELEMENTOS DEL DISENHO DE MULBRI

En prealable a la documentacion para programadores que nos va preparar DDA esta capitulo ubiqua una seria minima de clave para entender el programa y sus interfases.

V.I Interfases

VMCDE: procedura que se ejecuta en el nodo que coordona los diferente procesos que se ejecuta en el nodo.

FORSIMPC: proceduras de SIMPC que se ejecuta en el nodo para la transferencia de archivos (ver documentacion SIMPC).

RECIBxx.DWN: archivo de control de recepcion (xx para UL, LO o RI).

MANDAR.RES: archivo de control de envio xxxx.NAM : Archivos de definicion de los destinatarios de mensajes. AGUL, para Agencias UL, VMId para el archivo NAMES de VM, RUSR para los usuarios de RI del tipo "registrado" (permite regrupar en el mismo nombre de recepcion diferente mandatarios), NUSR para los usuarios de RI del tipo "Normal" (el VmId es utilizado para fabricar el nombre del archivo recibido.

V.II Funciones

EXLDR: Cargador de programa
MENCTL: Controldor de comando y de menu,

V.III Archivos de control

MULBRI.GLO mantiene el entorno (se puede borrar en caso de problema), MULBRI.PRO: mantiene las opciones de colores,
MULBRI.MAC: macros compiladas,
MULBRI.LOD: fuentes de macros,
MULBRI.DEF: definicion del usuario

*.HLP: ayudas contextuales (las dos ultimas letras indican el idioma),
*.LAB: contenidos de los menus
*.MNU: acciones asociadas con los menu (paralelo a LAB), *.LST: archivos de configuracion por la mayoria, los siguientes son archivos de control de flujo: ARCHIV, LISTO, PREPAMA, RECIB, RECVM.

V.IV Codigos de control

A= Accion inmediata de una funcion interna, M= Cargar el menu,
C= Ejecutar el comando DOS,
P= Ejecutar el programa .EXE o .COM, F= Ejecuta la macro definida,
D= Define una macro,

@= variable usuario,
%= variable interna.