RobotDocIRS
Documento Interno de DocIRS
Abril 2003

José Enrique González Cornejo

.

 
----Ver video con breve explicación de RobotDocIRS---

Resumen

El artículo intenta formalizar la máquina RobotDocIRS, herramienta que constituye la síntesis de nuestra experiencia en la programación  de aplicaciones. RobotDocIRS es un generador de código en plataforma Web, que aprende de acuerdo a un conjunto de reglas de sintácticas y semánticas. La idea central de esta herramienta interna de la compañía, es sistematizar y complementar el ciclo metodológico en el puente diseño-desarrollo , con un prototipo que cumpla con los estándares de calidad y estilo en la programación de la aplicación. Así mismo, que el prototipo represente una maqueta compleja y dinámica que aproxime al máximo los requerimientos del cliente y pueda ser mejorada en línea conjuntamente con el cliente

En sus inicios RobotDocIRS comenzó como una aplicación  generadora de código en programación modular,  la cual permitía tener el prototipo básico. Su construcción se realizó a partir de la experiencia y nuestras propias librerías ( programas, funciones, scripts y objetos), utilizados a lo largo de varios años, para el desarrollo de aplicaciones. Sin embargo, en  un proceso de mejoramiento empírico e investigativo,  se fue descubriendo  que era posible adicionar componentes y clases en cada una de las capas que forman el sistema, reemplazando el trabajo humano de un programador.

 

Abstract

The article, written in Spanish,  attempts to formalize the RobotDocIRS machine tool, which is the synthesis of our experience in programming applications. RobotDocIRS code generator is a Web platform that learns according to a set of syntactic and semantic rules. The thrust of this internal tool company, is to systematize and complement the methodological cycle on the bridge design-development, with a prototype that meets the standards of quality and style of application programming. Also, the prototype model represents a complex and dynamic approaches to maximize the customer's requirements and can be improved in conjunction with the Customer line.

In the beginning RobotDocIRS began as a code generator application in modular programming, which have allowed the basic prototype. It was built from the experience and our own libraries (programs, functions, scripts and objects), used over several years to develop applications. However, in a process of improving empirical, investigative, it was discovered that it was possible to add components and classes in each of the layers that make up the system, replacing the human work of a programmer.

 

Robot Computacional

Robot es un dispositivo, que desempeña tareas automáticamente, ya sea de acuerdo a supervisión humana directa, a través de un programa predefinido o siguiendo un conjunto de reglas generales, utilizando técnicas de inteligencia artificial. Generalmente estas tareas reemplazan, asemejan o extienden el trabajo humano.

Un robot debe tener como mínimo dos propiedades a saber:

i) Sustituir mano de obra.
ii) Un modo (estructuras sintáctica y semántica) para ir aprendiendo.

RobotDocIRS

RobotDocIRS es un sistema computacional que cumple las condiciones antes descritas, con el objetivo general de contribuir al Negocio del Cliente, a través del modelamiento. En otros términos, RobotDocIRS es una herramienta tecnológica para el Levantamiento de Procesos, Diseño y Rediseño Funcional.

diagrama robot

Su forma de complementar el ciclo metodológico, se realiza   construyendo en corto tiempo la 'Obra Gruesa' de una Aplicación que opera sobre IIS y SQL Server. RobotDocIRS es un maquina con capacidad de realizar funciones que requieren de inteligencia, emulando la conducta de un programador, no sólo generando código, sino que interpretando fielmente lo solicitado desde el Levantamiento de Procesos.

codigo.jpg (105036 bytes)

 

RobotDocIRS logra este objetivo, al configurar y construir, un prototipo orientado al cliente, mediante la generación de los los códigos de múltiples páginas ASP(Active Server Pages de Microsoft), con su navegación correspondiente, con una Base de Datos nativa sobre XML, motor de búsqueda indexado y la documentación de ayudas en línea de las páginas respectivas. Todo esto, a partir de una Capa de Insumos que contiene un Léxico, una Sintaxis y una Semántica.

Para generar y editar los archivos de insumo, RobotDocIRS está dotado de una simple interfaz que facilita el trabajo y estructura los múltiples insumos de acuerdo a la sintaxis requerida.

Estos insumos, son localizados en carpetas únicas, de donde son leídos e introducidos por el Robot hacia la Capa de Proceso.

Es decir, una vez arriba el Insumo, se activa la orden de ejecución de RobotDocIRS y comienza el proceso automático de validación, búsqueda de analogías, mejoramiento de errores humanos, ajustes de código, ensamblaje, sincronización de objetos, asociación rutinas y scripts, mejoramiento de. etiquetas, construcción de páginas, etc.. para finalmente producir el Resultado en una carpeta especial que funciona sobre Internet, con una URL definida. Esta resultante corre sobre los servicios de Internet Information Server (IIS) tanto en Intra como en Extranet

RobotDocIRS es un intento por sintetizar la experiencia de años de DocIRS en el desarrollo de aplicaciones, permitiendo sustituir a un programador en el 80% de su trabajo, pero en forma aún más sistemática, ordenada, verificada y sin errores.

La interacción que se genera entre Levantamiento y el prototipo, permite un diseño funcional robusto que asegura un manejo eficiente de los datos, eliminar la variabilidad, reducir los tiempos de ciclo, costos más bajos para el cliente y efectos positivos en el desempeño financiero de DocIRS.

Herramienta Interna

 

ciclo robot uml.

bruno_levantamiento

Bruno Maggio en Levantamiento

Ahorro para todos

Partí jugando en una cancha de futbol,
de pronto el cliente me  cambió las reglas a una cancha de beisbol,
para finalmente dejarme jugando waterpolo..
José

Con métodos convencionales, hay un largo retraso antes de que el cliente consiga ver cualquier resultado. Así mismo el desarrollo puede durar tanto tiempo que las reglas del negocio del cliente podrían haber cambiado, lo que en la mayoría de los casos, lo obliga a intentar cambiar los requerimientos como parte del contrato. La solución DocIRS basada íntegramente en su experiencia,  logra con un 20% de los recursos lo que convencionalmente se produce con un 80% de los recursos en la construcción de software, porque:

1. La especificación documentada de los requerimientos del cliente para el constructor es certera. Esto significa, que no existe un área de incertidumbre que induzca a nuevos pedidos, a  re-construir requerimientos, a generar mal entendidos para reformular el proyecto.

2. El prototipo entregado contiene el 80% de lo que es una construcción de aplicaciones sobre plataforma Internet. En efecto, el prototipo DocIRS, junto a la documentación entregada son equivalentes a un plano, su descripción y maqueta aceptada 100% por el cliente.

3. El prototipo hace converger, en corto muy tiempo, hacia un diseño aceptable por el cliente y factible de construir a los desarrolladores, limitando a un mínimo los cambios de reglas, ahorrando tiempo de desarrollo, sin exponer la calidad, el costo del producto y malos entendidos entre las partes.

Ecuación dago+ pepe = Metodología DocIRS satisfaccion4.jpg (13962 bytes)

RobotDocIRS hace rentable el Levantamiento de Procesos porque permite:

  • Visibilidad rápida

  • Mayor flexibilidad (porque RobotDocIRS reajustar a voluntad)

  • Cero codificación manual

  • Participación creciente del usuario

  • Defectos tienden a Cero

  • Costo reducido (reutilización de rutinas)

  • Ciclos de desarrollo más cortos

  • Visión y prácticas estandardizadas

Caso de Uso Genérico

Estar LISTO es tener el producto completo e impecable, con cero fallas y aprobado 100% por el cliente.
Dago.

   
     

Ahorro significativo para el Constructor

El prototipo representa un gran ahorro, particularmente para quien construye la aplicación

El prototipo construido por RobotDocIRS es más que un programa de prueba. Es prácticamente la aplicación preliminar o versión beta de la aplicación requerida, pero sin las conexiones a bases de datos, sin los listados e informes que derivan de estos datos.

Efectivamente, el prototipo RobotDocIRS pone a disposición de los constructores el diseño funcional convertido en sistema, con al menos el 90% de todo el código fuente de los formularios o páginas completas, las validaciones por campo, por objeto y globales, la navegación por menús y viñetas e incluso los diversos estilos del proyecto.

Cuando se entrega el prototipo de RobotDocIRS, es porque ya pasó por las etapas de aprendizaje del proceso, las funcionalidades, y porque ya se descubrieron y analizaron los puntos sensibles de sistema que se desarrollará.

El prototipo RobotDocIRS ahorra también un considerable tiempo al desarrollador, no sólo en términos de la comunicación, y claras especificaciones de los requerimientos, sino que especialmente le ahorra un gran número de Horas Hombres de programación, dado que ya está construida eficientemente la interfaz de presentación con la aprobación del cliente.

Este hecho, lo demuestra la aplicación en desarrollo del Comité Electrónico de la Plataforma Pequeña Empresa de BancoEstado. En efecto, el proveedor seleccionado por BancoEstado para construir el modulo Comité Electrónico, la interfaz de su Entregable es casi en su totalidad, - sin cambios -,el mismo prototipo generado por RobotDocIRS. Es decir, este constructor hasta el momento, se montó 100% sobre los códigos del prototipo de RobotDocIRS aplicándole sólo la conexión a bases de datos y   otros detalles de reglas de negocio que RobotDocIRS no abarca.


Ver matemática acerca de la Isocuanta

Ventaja

RobotDocIRS permite a DocIRS adquirir una enorme ventaja , porque la competencia llega sólo hasta la etapa de Levantamiento tradicional y no llega a entregar  como  valor agregado, un completo prototipo (con pantallas, formularios, campos, detalles, validaciones, su correspondiente navegación y documentación completa de cada formulario o pantalla y un mapa de navegación) que funcione con rapidez y exactitud, minutos después de solicitado el cambio, haciéndolo visible en un sitio Internet exclusivo del cliente.

Es decir, para que las empresas puedan competir con DocIRS, deberían alcanzar a nivelar el Entregable dentro de este ámbito, incorporando un alto numero de Horas Hombres de programadores de primer nivel. Estas varias semanas de desarrollo que deberían trabajar, a fin de lograr este nivel de producción del RoboDocIRS, tiene un impacto significativo en el precio y en los tiempos de entrega.

curva_produccion

La ventaja de DocIRS, - dentro de este ámbito-  es claramente más competitiva que comparativa , dado que las fuentes de las ventajas comparativas se basan en  factores productivos: capital, recursos, "contactos"  e inversión tecnológica (proyectos asegurados, fierros y recursos humanos). Es decir, estos factores sobran en    decenas de empresas del rubro informático que operan en el mercado, pero no así la  investigación permanente y creatividad tecnológica (diferenciación de los servicios, entrega rápida, formalidad ingenieril, soporte bitácora y capacitación), que ha permitido a DocIRS alcanzar un alto nivel en inteligencia tecnológica versus un bajo nivel de costo en recursos humanos (Esto mediante un pequeño equipo de ingenieros altamente calificados, especializados y comprometidos)

¿Qué entendemos por Diseño Funcional?

Entendemos como Diseño Funcional la interpretación modular de las metas requeridas en un proceso de negocio del cliente. Metas que deberán tomar forma y automatizarse en un sistema computacional orientado al objeto, de modo de minimizar los efectos secundarios en las partes del sistema.  Esto Implica las siguientes etapas:

  • Fragmentación de la información, partición en formularios o páginas

  • Definición de las relaciones entre las particiones de información (entre los formularios o páginas)

  • Definición de los enlaces, nodos o hipervínculos que establecerán los recorridos potenciales del cliente a través del sistema.

A lo largo del diseño funcional hay que tener en cuenta los siguientes aspectos:

-Criterios funcionales.
-Niveles de interactividad.
-Aspectos relativos a la navegación.

Bosquejo de un Diseño --> Formulario
Ejemplo de Bosquejo inicial vs. Formulario en la aplicación

Dentro de la metodología objeto orientado para el Diseño Funcional, que ha desarrollado DociRS, cada función es fácil de modificarse, porque cada una de ellas cumple tareas bién definidas y acotadas. El diseño funcional es modulado, documentado y derivado directamente desde los procesos existentes o requeridos por el cliente. De este modo el diseño se desarrolla con:

  • conocimiento exacto de lo que se desea construir,

  • calidad asegurada de lo que exactamente se debe revisar, y

  • que el cliente sepa exactamente qué desea obtener y

  • concatenándose sin dificultades con RobotDocIRS hacia  la construcción del software.

Las especificaciones del diseño funcional se expresan en un documento con notación   UML y en un prototipo que representa la fase del pre-desarrollo. El documento incluye una lista organizada de los requisitos que se utilizan para el desarrollo, junto a la aprobación firmada del cliente.

Prototipo: Onda Transversal del Levantamiento

En efecto, el prototipo instantáneo es como una  una onda transversal a todas las fases del proyecto de automatización,  lo que transforma una metodología plana y lineal de documentación UML, en un método experimental que deja exactamente documentado, comunicado y especificado el sistema para los constructores (Ver página ¿Cuáles son las características que debe tener una herramienta UML?).

Las múltiples versiones del prototipo que produce el RobotDocIRS, van modificando  los diagramas (de Flujo de Procesos, de Actividades, de Casos de Uso, de Secuencia, de Clases) y  la definición y alcances del modelo de datos, sus conclusiones  e inteligencia de negocios.

fases.jpg (3430 bytes)

UML Tareas Ingeniero DocIRS

En síntesis, RobotDocIRS es ideal para la construcción de maquetas y prototipos, logrando tiempos record de respuesta, para la interacción con el Cliente en la etapa del Levantamiento de Procesos. Dado que en los diferentes momentos  del proceso , se van eliminando problemas que se detectan en el análisis de las pantallas y documentación, y se van agregando mejoramientos que van asegurando mayor  rapidez y solidez en el producto.

Satisfacer los requerimientos del cliente

Según nuestra experiencia, bajo esta concepción de prototipo es más susceptible de encontrar formas de incorporación de los resultados y reglas de negocio más optimas, puesto que los usuarios participan directamente en la experiencia de análisis y diseño, evaluando y comparando ellos mismos el diseño y la información generada por el sistema.

El prototipo se inicia como modelo de simulación que va evolucionando con su uso, para llegar  a  minimizar los defectos. En efecto, los usuarios evalúan el diseño y la información generada por el modelo inicial  y proponen cambios en la medida que es utilizado, de modo que los requerimientos funcionen no solo en el papel, sino que transforma e implementa los mejoramientos en forma concreta. 

Es decir, el prototipo es fundamental para comprender e interpretar exacta y rápidamente los requerimientos del cliente. El  equipos de DocIRS  y el Cliente, trabaja en ciclos sucesivos Insumo-Resultado, hasta llegar a los límites de perfección con el mínimo de defectos observables.

RobotDocIRS opera sobre capas

  • Capa Insumo: está organizada en un conjunto de archivos con una relación de orden:

Modulo-->Formulario-->Objetos -->Documentación

Diagrama_Insumo

Interfaz_Insumo
Panel de Insumos

El insumo es preparado por los Ingenieros Industriales de DocIRS, responsables del levantamiento de Usuarios y Proceso. Ese insumo se organiza a través de una interfaz especial que permite construir en forma sencilla y eficiente los insumos tales como módulos, formularios, campos asociados a cada formulario, documentación por formulario y campo, objetos y valores introducidos en las celdas de las tablas etc... Los archivos insumos internamente en RobotDocIRS están relacionados biyectivamente. Esta aplicación opera remotamente sobre un VPN especial de DocIRS.

icono_editor_insumo

vpn.jpg (33813 bytes)

 

  • Capa Proceso: El motor del robot opera serialmente con cada entrada, construyendo en el mismo orden o secuencia en que está dispuesto las entradas InsumoRobot e InsumoTextos (con este ultimo el RobotDocIRS construye la Ayuda en Línea). El motor del robot cuenta con librerías de objetos, scripts y memoria de casos.  RobotDocIRS permite continuar infinitamente agregando elementos o componentes para el  proceso de construcción del Resultado.

panel_robot_docirs.jpg (216717 bytes)
Panel RoboDocIRS

Nótese que los objetos pueden ser archivos de textos simples o con sus scripts asociados y que los parámetros a sustitur en la construcción son /1\/2\,... Por ejemplo:

Objeto Número de Cédula de Indetidad (RUT)
<input type='text'
id='/1\'
name='/1\'
maxlength='10' size='12'
onKeyPress="vbscript:SubCampoKeyPress('0-9 .-kK')"
onKeyDown="vbscript:SubKeyEnter"
OnBlur="vbscript:ValidaRut(me)"
onMouseover="showfloatie('*texto*', event)"
onMouseout="hidefloatie()"

value=""

style="text-align: right">

<script language='VBScript'><!--
function ValidaRUT(obj)

sRut=obj.value
sRut=trim(sRut)
sRut=replace(sRut,".","")
sRut=replace(sRut,"-","")

if len(sRut)>0 then
Verificador=right(sRut,1)
Cuerpo=left(sRut,len(sRut)-1)

if not subVerificaRUT(Verificador, Cuerpo) then
MsgBox "Rut Invalido",vbExclamation,"Mensaje de Validacion"
obj.Value=""
obj.focus
else
obj.Value=FormatNumber(Cuerpo,0) & "-" & Verificador
end if
end if
end function
-->
</script>
  • Capa Resultado: Una aplicación de formularios o páginas ASP, que opera sobre una base SQL Server. Constituida por dos tablas "universales" cuyos campos principales son textos XML. Los objetos que constituyen cada formulario son extraídos pertinentemente por RobotDocIRS desde una librería de objetos que incluye sus correspondientes scripts de validación. Así mismo, RobotDocIRS está dotado de un conjunto de Javascripts genéricos par efectos de validaciones, efectos visuales y optimización del código.

Ejemplo de Resultado, es el prototipo de una plataforma completa entregada en enero 2007 para BancoEstado, cuenta con 68.000 líneas de código ASP, 1200 objetos, 70 formularios, ayuda enlínea, navegación a través de viñetas, pull-down menús y links. Esta aplicación completa, como unidad toda, RobotDocIRS la genera en forma perfecta sólo en 45 segundos.

resultado
Formulario o Pagina construida por RobotDocIRS en la Plataforma Pequeña Empresa de BancoEstado. Cuando ingrese al ejemplo de prototipo, utilice el RUT 1-9 para comenzar a navegar en el prototipo.


Mapa de Navegación con documentación en línea

Mapa de Navegación del Sistema Construido sobre la Ayuda por RoboDocIRS"


¿Qué debemos evitar hacer con esta herramienta interna?

Debemos evitar la modificación manual de las páginas generadas por RobotDocIRS. Porque estas intervenciones, posteriormente impiden generar todos los códigos, dado que el Robot genera la aplicación completa como una unidad toda (índices, rutinas, ayudas, rótulos, viñetas, menú, enlaces, etc,) cada vez que se ejecuta.

Es decir, al intervenir páginas modificando y realizando arreglos manuales, implica necesariamente continuar trabajando con el método de desarrollo convencional (no más con el robot) y bajar los tiempos del ciclo, aumentar los defectos, costos y sacar al cliente de las normas y marco de la tecnología. Es decir, hacer cambios y mejoramientos en forma aislada, atenta contra la variabilidad.

Este concepto de no intervención de los resultados del RobotDocIRS, ha sido difícil implantarlo con los ingenieros de la empresa responsables del Levantamiento Procesos y Diseño Funcional, dado que ellos pueden y saben desarrollar códigos (como ASP, Java, VBscript, HTML,...) y desean agregarle, - por su cuenta - detallitos y "pirotecnia" (fundamentalmente de diseño), a las páginas construidas por el RobotDocIRS. Pero, justamente la experiencia ha demostrado que haber realizado estos cambios en forma manual sobre varias páginas de la aplicación, se transformó posteriormente en un problema, que jugó en contra, especialmente en la detección de fallas a lo largo y ancho de la aplicación. (Es decir, se perdió tiempo significativo y más encima se hecho a perder la calidad del prototipo. Nótese que sólo en revisar y arreglar los problemas se gastaron más de 5 Horas Hombre, en consecuencia que RobotDocIRS demora sólo 55 segundos en hacer todo de nuevo, validado y bién).

Intrevención manual que aumenta la variabilidad

Hoy estos ingenieros, dada la experiencia, prefieren agregar nuevos objetos y bloques, perfeccionar la versatilidad, solicitando que todas las nuevas variantes se produzcan, en lo posible, sólo desde el RobotDocIRS, dado que los Insumos que ellos mismos configuran, constituyen la materia prima de donde RobotDocIRS construye toda la aplicación como una unidad toda. Es decir, hoy en el equipo de Levantamiento de Procesos y Diseño, se está implementando   creativamente la política de fortalecer RobotDocIRS.

La fortaleza del RobotDocIRS es justamente que construye la aplicación con un conjunto de conocidos de objetos, en forma sistemática y ordenada. Este hecho, de configurar la aplicación con piezas o legos permite que el usuario aprenda en forma estándar y dentro de un marco determinado a realizar sus requerimientos e ideas.

Este lego no es cerrado, es decir puede continuar infinitamente aumentando sus piezas simples y compuestas, y es una herramienta que permite formar usuarios (o contraparte técnica del cliente). A quienes es necesario inculcarles una medición común, normas o reglas comunes de construcción y estándares de visualización de sus requerimientos.

Variabilidad Controlada

La calidad del producto es un función directa de la calidad del proceso. De ahí que, es un un objetivo fundamental en el mejoramiento del resultado R, controlar y reducir la variabilidad, de forma que los procesos relacionados a RobotDocIRS sean estables, consistentes y predecibles.

En nuestro caso, tanto el creador de RobotDocIRS y como su equipo, conocen con exactitud cómo cada variable del proceso afecta cada característica del prototipo, con la permanente posibilidad de intervenir y ajustar estas variables dentro del sistema, de modo que siempre el servicio de RobotDocIRS responda a las necesidades del cliente.

e ---------> 0        t ---------> Min[tiempo]

RobotDocIRS está diseñado bajo el supuesto que el resultado queda determinado por las condiciones bajo los cuales se realiza. Esto significa que en el proceso de construcción del producto, no existe variabilidad aleatoria, dado que el modelo es determinístico.

En la gráfica se ilustra que en no más de 10 ejecuciones de RobotDocIRS, se logra el objetivo (satisfaccón del cliente, prototipo interpreta al cliente), con una desviación estándar muy pequeña. La razón es simple: la transformación que aplica RobotDocIRS depende del diseño de Insumo, y no de sus operaciones internas.

Con un n<=10 se logra el objetivo

Es decir, se ingresa un conjunto finito y ordenado de variables seleccionadas desde un léxico predeterminado, según el Levantamiento de Proceso y RobotDocIRS produce exactamente lo que debe resultar según su programación.

Supongamos el resultado entregado, no satisface (al propio ingeniero DocIRS o) al cliente. Entonces, implica que el resultado carece de algún objeto y/o no presenta un distribución apropiada de ellos. Esta falta puede ocurrir por una de las siguientes causas:

i) La combinación de variables de entrada no fue seleccionada como debía ser. Es decir, existen los objetos y también su combinación o relación, pero no fueron incluidos en la función.

ii) No existe el o los objetos que permitan lograr el resultado esperado.

Las respectivas soluciones son:

i) Se reformulan las variables de entrada y se prepara nuevamente el Insumo de RobotDocIRS. Esta operación debiera ocurrir en minutos.

ii) Se estudia y diseña el o los objetos que deben incorporarse a la librería de RoboDocIRS, para anexarlos al Léxico y desde allí ser utilizados como variables de entrada. Esta operación debiera ocurrir en minutos u horas.

Otra fuente de error de muy menor ocurrencia, que no es considerada para medir la variabilidad de este proceso, podría darse porque las validación de uno o más argumentos de un objeto, no están completamente validadas en la aplicación que prepara la Capa Insumo y/o que tampoco son capturadas y corregidas durante el Proceso. RobotDocIRS, cuenta también con un conjunto de validaciones que detecta y corrige automáticamente errores menores, tales como duplicación de variables, caracteres no aceptados para identificar objetos, ortografías, etc..). Esta fuente de error dice relación con verificar bien el objeto, antes de ser incluido en el modelo.

En síntesis, el proceso es constante y la variabilidad está controlada en ambos casos.(Dentro del ámbito del contenido no del diseño)

 

Algebra de RobotDocIRS

- Léxico

Sea L el conjunto numerable de n objetos que constituyen la librería de RobotDocIRS

 

L = {O1, O2, O3,…On}

Más específicamente L = {Xi / C(Xi) = True con i=1,2,3,…n}. Donde cada objeto Xi se define como un conjunto complejo de datos que posee estructura y fue previamente construido como parte del sistema Insumo de RobotDocIRS.

 

C(X): Representa las condiciones funcionales que debe cumplir cada objeto de L . Los objetos pertenecientes a L son, en general, rutinas de códigos ASP paramétricos localizados en la librería o también funciones directamente construidas, dentro de la aplicación computacional que genera el Resultado, ambas formas cumplen con una definición de nombre único, una sintaxis predefinida y estar declarados en la Lista de Objetos de RobotDocIRS. Además L cumple con las siguientes propiedades:

 

i) fÎL

ii) OjÎL => Ojc = L –{ ÈOi } con i¹j

El léxico L, permite contener objetos simples y complejos. Los objetos complejos están compuesto por objetos simples de L, pero son tratados y procesados como objetos independientes dentro del sistema.

 

Se define L como un conjunto que admite agregar un objeto cuando sea requerido.

L = L È {On+1},

El objeto On+1 puede ser agregado a L, siempre y cuando el objeto cumpla con la condiciones de pertenencia C(x) que exige RobotDocIRS, para constituir un objeto del conjunto L.

- Estructura Insumo

Ahora, se define el sistema de insumos S sobre L como una clase con estructura de arbol: S É M É F ÉO

S: Sistema o conjunto de todos los insumos de RobotDocIRS.

M: Módulos o clasificaciones para los formularios.

F: Formularios o páginas constituidas por objetos

O: Objetos seleccionados de L son el último elemento del árbol.

 

 

Sea S= {M1, M2, M3,…,Mn1} , el conjunto formado por los módulos definidos en el Levantamiento y Diseño que se sintetizan en el Insumo robot completo, donde los Mj ¹ Mi , cuando "i¹j

 

Mj = {Fj1, Fj2, Fj3,…,Fjn2} , es el insumo correspondiente a un modulo Mj, conformado por n2 Formularios. Donde los Fji ¹ Fjk , " i ¹k

 

Para cada formulario Fjk Î Mj, se tiene que Fjk ={Ojk1, Ojk2, Ojk3,…, Ojkn3} es un conjunto ordenado (≤) que admite el uso del mismo objeto, pero con notación diferente en su asignación o etiqueta. El orden definido, corresponde a la secuencia de construcción y posición del objeto en el Resultado.

 

Es decir, Fjk es el conjunto de los n3 objetos seleccionados de L, que conforman un formulario definido Fjk, perteneciente al modulo Mj del sistema S.

Fjk =È Ojki . Un formulario admite la unión del mismo objeto (no confundir con L)

 


El conjunto de los n3 objetos seleccionados de L, que constituyen un formulario están definido bajo una relación de orden.

Es decir, Ojk1 ≤ Ojk2 ≤ Ojk3 Ojkn3, " Ojki

 

Este orden secuencial de los objetos es definido por diseño, dado que en ese mismo orden RobotDocIRS irá construyendo y localizando los objetos en el formulario o página Fjk.

 

Nótese que los objetos traen información de su formulario, así mismo el formulario identifica su Modulo.

 

- Proceso

Sea P(S)=R la función que define el proceso de RobotDocIRS para transformar el insumo S en el resultado R.

 

 

diagrama_funcion

diagrama_vista

RobotDocIRS está dotado de una forma análoga de Transformaciones Lineales, o dicho de otra manera de una serie de operadores lineales u homomorfismo de S sobre R.

El proceso P, que define RobotDocIRS una vez capturado el Insumo S, corresponde a un conjunto de estados y a un esquema de componentes fijas que constituyen el resultado R.

Recordemos que el Resultado R está preconcebido por los diseñadores. Es decir, lo que hace RobotDocIRS en la Capa de Procesos P, es primero configurar una lista de los problemas para los cuales existe una solución en P.

Una vez definida la lista de problemas a resolver por RobotDocIRS, entonces mediante la Matriz de Estados, se realiza de manera totalmente mecánica los procesos, que normalmente llevaría a cabo un programador ordenado, de acuerdo a un algoritmo con reglas lógicas definidas, para obtener el resultado R. Expresado en otros terminos, " si Î S $ri Î R ó $ una Transición Ti={e1,e2,..,en} en la Matriz de Estados tal que P(si) = ri , (donde R = È ri )

Diagrama de Flujo Agregado del Proceso

El pilar central de este proceso, corresponde a la Matriz de Estados de RobotDocIRS, la cual se monta sobre un Algoritmo Mayor y varios algoritmos menores, que en la medida que se va realizando la transición, ellos van complementado, ajustando y afinando los resultados parciales de cada estado, como así mismo la resultante y sus relaciones respectivas en R.

Todas las entradas posibles a la Matriz de Estados están numeradas a través de las columnas de la Matriz. Todos los estados posibles están enumerados a través de las filas.

Desde la Matriz de Estados se controla la transición Tj a Tj+1, indicándole al algoritmo su siguiente bifurcación.

El proceso o función P interpreta el insumo S en forma inequívoca, de la siguiente forma:

i) Lectura y carga en respectivos arreglos de las componentes {M,F,O} de S

ii) Validación de la existencia, sintaxis y argumentos de cada variable de insumo localizada en los elementos de cada arreglo de carga que Estos arreglos constituyen las entradas de la máquina o algoritmo mayor de RobotDociRS.

iii) Construcción del marco global divisiones del formulario o página.

iv) Inclusión de uno por uno de los objetos (según la relación de orden establecida en el Insumo S) hacia Matriz de Estados que va operando y cuyos resultados parciales transitando por los estados respectivos.

ESTADOS E1 E2 .. En
T1        
T2  

Ay/Tj

 

   
...    

Ax/Ti

 
Tn

Az/Tk

     

v) Cada objeto es previamente identificado por la librería de soluciones de RobotDocIRS, para después ser   introducido en la Matriz de Estados.

vi) De acuerdo a la identificación del objeto, se establece la fila de estados por la que irá transitando el elemento constructivo.

vii) El elemento constructivo se finaliza con la localización del objeto con todos sus atributos en el área de la página resultante.

viii) El proceso de elementos constructivos se repite tantas veces como objetos contenga cada formulario, multiplicado por el numero de formularios que tiene el insumo S.

ix) Finalmente se ejecutan una serie de algoritmos menores tanto sobre los formularios individualmente como para robustecer sus relaciones.

- Resultado

El resultado R es un conjunto de archivos de diferentes formatos. Donde los archivos centrales son las paginas o formularios de visualización ASP y los complementarios que son componentes ASP, Java Script ,Visual Script, HTML, DOM, DHTML, CSS, AJAX y otros archivos de texto incluidos. Este conjunto de archivos, está coherentemente articulado y conforma un sistema que opera sobre IIS, al cual el usuario puede acceder, visualizar y navegar con Microsoft Internet Explorer.

El prototipo o resultado R, está orientado al cliente. Por tanto, siempre la página de entrada del prototipo es para ingresar la identificación o RUT del Cliente. Es a partir de este parámetro, que se inicia la navegación por las diferentes páginas con la información relacionada a este cliente específico.

Paso de parametro RUT del Cliente a través de la aplicación
Prototipo Orientado al Cliente












Dagoberto Cereceda González José Enrique González Cornejo

Junto con nuestros clientes, en un sólo equipo, esperamos seguir mejorando en el esfuerzo...

abril 2007

Cristian: constructor de la Interfaz Insumo

Artículos Relacionados