|
*01
Q: ¿ Porqué la tecnología básica elegida es .NET y no otra ?
A: El proyecto M&P comenzó a mediados de 1970. En ese momento mi
contexto computaciónal era un Mainframe IBM/360 con 32 KB de memoria
real (la memoria virtual recién apareció en el modelo /370 algún tiempo
después). El sistema operativo era IBM-DOS/360 y el procesamiento 100% batch.
La programación se hacia en COBOL y Assembler/360.
En ese contexto parte de mi trabajo era hacer simulaciones de procesos
usando el sistema IBM/GPSS (General Purpose Simulation System).
El lenguaje GPSS sigue vigente hoy en día y prácticamente no ha sufrido
cambios en su funciónalidad "core".
GPSS define un conjunto de BLOCKS con el que se puede modelizar un
amplísimo espectro de sistemas reales y los modelos son directamente
ejecutables (previa compilación en 1970).
Con menos de 40 tipos de BLOCKS podía simular sistemas reales muy
complejos con gran exactitud y predecir su comportamiento en situaciones
distintas a las habituales.
Por supuesto al poco tiempo me surgió el interrogante: No es posible
crear un conjunto de bloques para modelizar y ejecutar aplicaciones de
negocio ? Inmediatamente mi respuesta fue: Porque no ?.
A partir de ese momento el tema se constituyo en el telón de fondo de mi
actividad informática.
Mis avances fueron muy lentos inicialmente, era muy difícil conseguir
información localmente y por ese motivo viajaba a EEUU periódicamente.
Cuando apareció Java yo estaba trabajando con C/C++, y a primera
vista Java parecía ser el sucesor/reemplazante de C++ y además proveía "Reflection".
Así es que prácticamente todos los que trabajábamos con C++ decidimos saltar
a Java.
La gran mayoría pudo hacerlo pero una gran minoría no pudimos porque
(increíblemente) Java no manejaba "pointers a funciones" (algo que
hasta VB tenia). Los pointers a funciones resulta(ba)n muy convenientes
(indispensables) para la implementación de aplicaciones "high-end"
(intérpretes, compiladores, manejadores de bases de datos, sistemas
operaivoss, etc.) en los que la performance debe ser la maxima posible.
Vino entonces el planteo a Sun/Gosling de incorporar pointers a funciones
(o "referencias a métodos") en Java. La negativa de Sun/Gosling fue
terminante con el argumento de que lo mismo se podía hacer en Java usando
clases e interfaces.
Probamos esta alternativa y encontramos que la cantidad de código
requerido era 10x-20x veces mayor y por consiguiente los tiempos de
compilación y de ejecución eran inaceptablemente elevados para nuestras
necesidades (además de que la ejecución en la JVM era interpretativa).
A pesar de las evidencias Sun/Gosling mantuvieron su posición.
En ese momento MS tenia muy avanzado su proyecto "New Generation" (que se
transformo finalmente en ".NET"). El objetivo de este proyecto era crear un
"Common Language Runtime" (CLR) que cubriese las necesidades de todos los
lenguajes que comercializaba, así como de lenguajes comercializados por
terceros. El CLR definía una familia extensa de tipos de datos y uno de
ellos era "referencia a función". Este tipo de dato luego recibió el nombre
de "delegate".
MS vio la reacción de los programadores C++ respecto de Java (su
bienvenida y su frustración) y decidió lanzar el J++ una versión de
Java con delegates. Así es que todos los frustrados saltamos inmediatamente
al J++ y permanecimos allí hasta la aparición de C# y la discontinuación del
J++ (en mi caso casi tres años).
En la evolución de MS los delegates se trasformaron en la columna
vertebral de .NET (que hoy debería llamarse ".Delegates").
Actualmente Java sigue emulando los "pointers a funciones" en software.
Ahora los delelgates son también la columna vertebral del procesamiento
paralelo de MS (resultan ideales en el entorno multicore, manycore y
hyperthreading).
Luego basándose en el CLR MS incorporo el lenguaje XAML que
facilita la "composición" declarativa de aplicaciones y tiene un
Engine de databinding de muy alta performance (basado en Delegates,
por supuesto).
En síntesis la respuesta a la pregunta "Porque la tecnología básica
elegida es .NET y no otra ?" es: "Porque .NET tiene Delegates y un Engine
XAML de muy alta performance".
| M&P TBW es el primer sistema que utiliza
Composición Declarativa para desarrollar todos los
aspectos de las aplicaciones. [10-feb-2011] 
|
Q: ¿ En qué se diferencia y en qué se parece la propuesta de (M&P)
BLOCKS a otras ?
A: M&P define una arquitectura basada en componentes e interfaces
similar a las antiguas arquitecturas MS/COM/ActiveX, OMG/CORBA, IBM/SOM y Java/EJB
pero M&P opera en un nivel muy superior de abstracción que lo hace muy fácil
de usar.
En M&P la "composición" de una aplicación se realiza en forma declarativa
mediante el lenguaje XAML (basado en XML) lo que facilita la
visualización y edición de la red de componentes.
XAML permite crear fácilmente "Components-inside-Components" (CIC)
sin limite de profundidad. Esta facilidad permite implementar
múltiples niveles de abstracción (tantos como resulte conveniente) y
navegar por la estructura XML de la aplicación rápidamente.
XAML provee además un engine de "databinding" para la conexión/interoperación
de los componentes.
Visual Studio Express (free) provee los tools para la edición de los
archivos XAML y el databinding de los componentes.
La Plataforma BLOCKS extiende las facilidades nativas de databinding de
XAML, define un protocolo de arranque estándar para la red de
componentes e introduce facilidades de "auto-adaptación al contexto" en los
BLOCKS.
En M&P los componentes son Plug-and-Play en run-time y por default
son Multithreaded (resolviendo automaticamente las operaciones cross-thread).
Ver M&P TBW comparado con MS Prism y MEF.
*03
Q: Si tengo módulos desarrollados en otros lenguajes, se han pensado
maneras de hacer recorridas parcialmente automatizadas de los códigos fuente
de mis módulos para que puedan quedar pre-implementados (a pulir) en M&P ?
A: No, por varias razones:
1. Habría que desarrollar parsers y analizadores para los diferentes
lenguajes.
2. Dentro de un mismo lenguaje los estilos de programación y/o librerías
utilizadas pueden ser muy diversos.
3. También dentro de una misma aplicación los estilos de programación y/o
librerías utilizadas pueden ser muy diversos. Aun en aplicaciones bien
estructuradas es frecuente encontrar "islas" de código "spaghetti".
Existen en el mercado programas especializados tales como Analizadores
estáticos de código que ayudan a resolver el problema. Sin embargo los
análisis son básicamente "sintácticos" y estadísticos y no tienen capacidad
(por falta de información) de contemplar la semántica inmersa en el código.
En general la (re)modularización requiere un "refactoring" inteligente
(semántico) cuyo alcance depende de las circunstancias.
Si el lenguaje fuente es un lenguaje .NET el refactoring puede hacerse
gradualmente sin que la aplicación deje de funciónar. Se comienza creando un
BLOCK que contiene toda la aplicación que luego se va modularizando.
*04
Q: ¿ Qué herramientas están disponibles para "ver" un mapa de 10
módulos interoperantes ? ¿ y de 100 ? ¿ y de 1000 ? ¿ y de 10000 ? ¿ puedo
"editar los módulos, sus definiciones, o sus propiedades, desde esas
"vistas", o debo ir a buscarlas en listas encarpetadas ?
A: En la MP_FAQ *02 menciónamos que en M&P la
"composición" de una aplicación se realiza en forma declarativa mediante el
lenguaje XAML (basado en XML) lo que facilita la visualización y
edición de la red de componentes. También menciónamos que XAML permite crear
fácilmente "Components-inside-Components" (CIC) sin limite de profundidad.
Esta facilidad permite implementar múltiples niveles de abstracción (en
diferentes archivos XAML) y navegar por la estructura XML de la aplicación
rápidamente.
Las facilidades de visualización y edición de XAML del Visual Studio Express
(free) permiten expandir y colapsar fácilmente partes del archivo XAML
facilitando la focalización para el análisis y la edición del código XAML.
La función Find permite realizar búsquedas sobre uno o varios archivos XAML
y la función Replace realizar reemplazos.
La edición de los archivos puede hacerse manualmente o automáticamente en
forma directa (in-place).
En general la complejidad aparente de una aplicación M&P "bien modularizada"
crece linealmente con la cantidad de componentes interoperantes a diferencia
del crecimiento exponencial (por explosión combinatoria) que se percibe en
la mayoría de las aplicaciones no modularizadas.
*05
Q: Es tremendamente atractivo la idea de modularización "Divide and
Conquer". Sin embargo, las cosas en el mundo real siempre se complican, y
las cosas también se "convierten" en "bottom up". ¿ Cómo aborda M&P esta
inevitable reintegración de la partición ? ¿Me permite ir para atrás y para
adelante, tanto en términos de reimplementación de interfases entre módulos,
como de "vistas" de análisis y apreciación de lo ya hecho e implementado, en
perspectiva con lo aún por hacer e implementar ?
A: En M&P no existe una dirección preferencial "top-down" o "bottom-up".
El diseñador puede elegir la estrategia que le resulte mas útil/cómoda y
cambiarla cada vez que sea necesario.
En general cuando se migra una aplicación existente no modularizada a M&P la
estrategia es top-down por descomposiciones sucesivas. También suele ser la
estrategia habitual para desarrollos base-cero. En este caso normalmente se
definen inicialmente un conjunto de componentes dummy al efecto de delinear
la estructura de la aplicación para soportar la funciónalidad requerida (The
"Form follows fumction" Principle).
M&P en la actualidad no provee mecanismos especiales para la apreciación de
lo ya hecho e implementado, en perspectiva con lo aún por hacer e
implementar. La técnica que usamos normalmente es introducir keywords (que
denotan el estado de avance) en comentarios en el código C# en que se define
el "behavior" del BLOCK. De esta manera mediante la función Find se obtiene
una lista de los BLOCKS que están en un determinado estado.
Es posible también incorporar comentarios similares en el código XAML.
*06
Q: Me interesan algunos ejemplos: en particular estoy interesado en
la intercambiabilidad de interfases Web con interfases no Web.
A: Prácticamente todos los BLOCKS M&P (nativos y custom) pueden ser
usados tanto en los desktop Windows, como en los Browsers y en los
dispositivos móviles basados en WP7.
El look-and-feel y el código de las aplicaciones M&P es prácticamente
idéntico en estas plataformas.
Cada plataforma por supuesto tiene requerimientos particulares que requieren
BLOCKS especializados.
*07
Q: ¿ Como varia la productividad a medida que se desarrolla la
aplicación ? ¿ Es creciente, constante, decreciente ? ¿ Cual es la "curva" ?
¿ Cómo afecta a la productividad la dimensión de la aplicación a desarrollar
? ¿ y si esa dimensión es pequeña al principio, pero crece con el paso del
tiempo ? ¿ Cual es la productividad en el desarrollo de BLOCKS custom ?
A: Hasta este momento no hemos recolectado suficiente información
cuantitativa como para responder con precisión numérica a estos
interrogantes. Los siguientes comentarios surgen de las observaciones
realizadas.
En general la productividad de desarrollo depende mas de la experiencia del
diseñador que de M&P.
Si el diseñador tiene gran experiencia en modularización puede sintetizar
rápidamente la solución final.
Si el diseñador tiene poca experiencia la síntesis de la solución es por
aproximaciones (refactorizaciones) sucesivas. En este caso la productividad
mejora significativamente a medida de que se avanza (curva de rendimiento
creciente).
Para un diseñador con experiencia, la productividad es independiente de la
dimensión de la aplicación, es constante a lo largo del proyecto.
En cuanto al desarrollo la modularización permite el desarrollo en paralelo
de los módulos.
Además de los BLOCKS nativos M&P provee mas de 30 aplicaciones demo/ejemplo
que contienen BLOCKS custom que pueden ser utilizados en forma directa o
modificados para adaptarlos a los requerimientos de la aplicación.
Para la creación de BLOCKS custom M&P provee un conjunto de microgeneradores de
código que producen los distintos elementos de código requeridos por el BLOCK custom. Esto permite al desarrollador concentrarse en la lógica del
comportamiento (behavior) del BLOCK.
Para una nueva aplicación existe un microgenerador que crea la
infraestructura básica completa para el diseño y desarrollo.
*08
Q: El creador de código al vuelo, ¿ siempre crea el código necesario
? ¿ o lo hace en función de ciertas condiciones de actualización ? Si es
así, ¿ cuáles son las condiciones ? El código creado, es a su vez compilado
por la plataforma subyacente: ¿ cómo incide este paso en la performance
general ?
A: Varios componentes del M&P Runtime (MPR) generan código al vuelo (en
run-time).
Algunos generan código MSIL (Microsoft Intermediate Language) que es
el lenguaje de programación que emiten, en forma interna, los compiladores
de lenguajes .NET. Este código es ejecutado directamente por el run-time (CLR)
de .NET.
Otros generan BScript eXpressions (BSX) que son interpretadas por el
procesador BScript del MPR.
En todos los casos la generación es muy directa y eficiente y no impacta
negativamente sobre la performance.
Mientras que los generadores de código MSIL son utilizados internamente por
el MPR y no son accesibles para el desarrollador, la generación de BSX es
utilizable por el desarrollador mediante un API muy simple y directa.
La generación de código MSIL se usa por ejemplo en el Browser para crear
dinámicamente "DataProviders" locales a partir de descriptores muy simples
enviados desde el Server usando BSXs (generadas al vuelo por un generador
BSX). Estos DataProviders locales son proxies de los DataProviders que
residen en el Server, que también son creados al vuelo a partir de la
información residente en los DModels (Data Models) de M&P. De esta manera
los cambios en los DModels se propagan automáticamente e inmediatamente a
las aplicaciones.
La generación de código MSIL también se usa para crear nuevas Clases (por lo
general transitorias) que pueden ser luego instanciadas en memoria.
Para optimizar la performance los códigos generados pueden ser almacenados
en caches en el caso de que se prevea una generación muy repetida, pero por
lo general el proceso de generación es muy rápido y eficiente y no hace
falta el uso de caches.
*09
Q: ¿ Surge de esta modularización y de sus definiciones ,
propiedades, e interacciones modulares una manera "reversible" de "exportar"
la documentación del sistema, para por un lado los desarrolladores
colaboradores, y para -por otro lado- los usuarios ? ¿ Qué limitantes se han
encontrado en este proceso al que seguramente M&P se ha enfrentado, qué se
ha aprendido de su posible abordaje, y qué se espera razonablemente poder
hacer al respecto de futuro ?
A: En M&P la "composición" de una aplicación se realiza en forma
declarativa mediante el lenguaje XAML (basado en XML) lo que facilita la
visualización y edición de la red de componentes.
La estructura de BLOCKS de una aplicación M&P se describe en archivos XAML (XML).
El contenido de los archivos XAML de M&P es muy fácil de leer y de
interpretar (tanto por humanos como por el computador).
El contenido de los archivos puede ser visualizado y analizado por los
usuarios mediante visualizadores/editores XML comunes (free) con una minima
capacitación. Los archivos pueden ser tratados como documentos de texto,
enviados por mail, impresos, etc.
Los archivos XAML han demostrado ser un excelente medio para facilitar la
colaboración entre diseñadores, usuarios y desarrolladores. Permite que los
usuarios participen activamente en la "composición" de una aplicación.
Hasta el momento no han surgido problemas que nos hagan pensar en introducir
cambios en esta modalidad de trabajo en el futuro.
*10
Q: ¿ Cuando se considera que una aplicación esta "bien modularizada"
? ¿ Como se logra una aplicación "bien modularizada" en M&P ?
A: Cuando la complejidad aparente (la percibida por los humanos) de la
aplicación es suficientemente baja como para permitir su actualización y
extensión con comodidad, rapidez y total confiabilidad.
Se aplican algunos principios de diseño, patterns y "best-practices"
recomendadas. Se definen también un conjunto
de "Formas Normales" análogas a las definidas para las Bases de Datos
Relaciónales para prevenir "anormalidades" en la actualización y extensión
de la red de bloques (Base de BLOCKS, por analogía) de una aplicación.
*11
Q: ¿ Existe alguna forma para determinar rápidamente si una
aplicación aparentemente bien estructurada con orientación a objetos esta
(implícitamente) "bien modularizada" ?
A: Una manera rápida y efectiva es analizar (preferiblemente tracear) su
protocolo (secuencia) de arranque, es decir el orden y la forma en que los
objetos son creados e inicializados. Si el protocolo es modular es alta la
probabilidad de que la aplicación este (implícitamente) "bien modularizada".
En M&P el Parser XAML es quien instancia los BLOCKS y existe
un Protocolo de Arranque "estándar".
Ver también
|
