Un afilado comentario sobre el estado del uso de modelos

Scott Finnie publica a finales de Septiembre un acertado comentario (a mi juicio por lo menos) crítico sobre el estado y evolución del uso de modelado en la vida real, en sus distintas vertientes actuales. Finnie encuentra que algunas de las tendencias en modelado han evolucionado mal, y prácticamente no encuentra alguna via conceptual o herramienta aplicada que sea totalmente satisfactoria.
Finnie comienza dedicando un párrafo breve a los métodos más formales, que considera en general inaplicables por sus exigencias:

Formal methods can definitely contribute to the “better software” imperative. Any impact on “faster” is a second order effect however: the models have to be translated into working software by hand. And the learning curve can be steep, requiring a solid foundation in the theory and notation of one or more mathematical disciplines (predicate logic, sets, graphs).

En segundo lugar, Finnie se ocupa de los lenguajes específicos de dominio (DSLs) sobre los que señala sus límites de adopción en la dificultad que representa sumir la creación de lenguajes adecuados a una diversidad de problemas por parte de equipos de empresa. Sólo los ve aceptables en nichos de empresas cuyo producto es el software, en general:

Domain-specific approaches can directly address both “better” and “faster”. But they are not without hurdles, both technical and organisational. On the technical front it’s the challenges of language design. Textual approaches (e.g. Spoofax, Xtext, MPS, Rascal) require the designer to understand compiler construction: parsing, linking, semantic analysis, type systems and so on. Graphical approaches such as MetaEdit+ perhaps simplify that. But there’s still the question of designing a language.
The organisational barriers are at least as significant – and independent of the textual/graphical debate. Getting traction for a DSL depends heavily on the organisation’s approach to software. It’s possible in companies building software products, especially those offering related product families. The cost of investing in language design and tooling is justified through repeatability and hence efficiency. But not all software falls into the “product family” bucket. Even when it does, some organisations – and many developers – are nervous about building a proprietary language. Maintainability, recruitment and CV curation can be powerful adversarial forces.

Finalmente, se enfoca en los lenguajes de modelado de propósito general, de los que espera más, pero encuentra grandes dificultades. La principal objeción a este tipo de modelado, enfocándose fundamentalmente en UML, es la incapacidad de casi todas las variantes desarrolladas de pasar de un esquema más o menos definido, a código ejecutable, o como suele decirse, a modelos ejecutables:

The vast majority of UML models are mere sketches. Sketches aren’t working software.
Sketches need lots of human endeavour to translate them into working software. Which isn’t to say they’re bad: a quick diagram on the whiteboard can be invaluable. But it’s a long way from working software. At the height of its hype curve, the UML wasn’t capable of describing precise, executable models(²). Without those, it’s impossible to automate software generation. Without automation, we don’t get better software quicker.
This is the fundamental mistake with MDA:

1. An incomplete language intended for sketches is not a viable basis for precise, executable models.
2. Without precise models,
   1. no formal checking can take place. So the impact on “better” is marginal;
   2. no process automation can take place. So the impact on “faster” is at best nil.

Summing up: MDA didn’t deliver better software quicker. It had the hype and the backing of large organisations. It didn’t stick because, brutally, it didn’t work.
So – in the context of general purpose modelling – let’s be clear about this: as long as a manually intensive process sits between a model and working software, the model is no more valuable than a sketch.

Finnie sostiene que hoy están dadas las condiciones para reparar estas faltas. Enumera una lista de asuntos por ajustar y resolver, con final abierto:

• whilst there are a plethora of tools for building models, few of them support executable models. Of that few, far fewer still are actually rewarding to use.
• we’re missing the pre-existing models that serve as exemplars. Models that are demonstrably translated into real, working software. Models that can be adapted or reused to meet different requirements.
• we’re missing the translators that turn those models into working software. Automatically, quickly and repeatably. We have the tools to write those translators: we don’t have the translators themselves. At least not robust, industrial quality translators that produce robust, industrial quality software. That can be used by real users or sold to real customers. Results that looks as good as, and function as well as, ‘hand written’ alternatives. Crucially, those translators need to be open for adaptation.
• we’re missing the cohesive environments that make it easy. Environments that don’t need weird hacks or obtuse incantations to make them work. Tools that “just work”. Tools that combine the constituent parts for modelling and translation into a consistent, seamless, industrial-quality experience.
• we’re missing eco-systems that pull these things together to forge communities. Communities that generate interest because they’re doing cool stuff.

Ante esta discusión, que creo que sigue siendo de interés fundamental, desde nuestra comunidad de usuarios de Plex...¿cuántas oportunidades se han perdido  en este camino para lograr una mayor abstracción y alcance?
Nota: si lee el artículo de Finnie, no deje de leer también los comentarios posteriores.

Una guía de trabajo con Plex

George Jeffcock, en su sitio relacionado con sus Stella Tools, dedica algunos párrafos a recomendar buenas prácticas en el uso de Plex. Coincidiendo con las guías de enseñanza usuales en Plex, George recomienda:

STOP Coding - Start Architecting
Plex development is essentially a three-step process involving Data Modeling, Pattern Matching and Customization. There are no shortcuts, each step must be adhered to achieve the goals. Missing a step may seemingly achieve a short term solution but in the medium and long term the solution will surely decay far quicker than it should have. The mindset required to use plex effectively is one of:

• Object oriented approach to application design to eliminate the need to code repeatable elements of applications
• Working at a level of abstraction rather than at the ‘nuts and bolts’ level, probably just saying the first point again but this can’t be over stressed the importance to think this way instead of coding procedural code line after line
• Model-based and pattern-based approach to increased application quality and flexibility
• Multiple inheritance is a key part of the way applications are developed in CA Plex therefore leveraging the full value of a site’s existing patterns
• Encapsulation so that function interfaces contain only the attributes pertinent to the use of the function
• An application should be separated into separate layers/tiers, Functionality should be strictly separated into data access, business logic and presentation logic, as this promotes the consistency of the application as well as the possibilities to reuse functionality.

La primera regla que un nuevo desarrollador en Plex debe asumir, es que debe escribir la menor cantidad de código posible: olvidarse de escribir líneas de código, y pensar, pensar el modelo de datos y relaciones, luego estudiar cómo abstraer y explotar patrones existentes, y sólo luego escribir código, sólo lo que es estrictamente necesario. "Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it"

Evolución o desajuste: un asunto crítico

De interés para usuarios de Plex; en el último tiempo, varias discusiones importantes se han desarrollado en la comunidad de usuarios en CA. Discusiones que van en dos direcciones: prometedores nuevos desarrollos, y retrasos lamentables en el soporte de nuevas tecnologías. Esta dualidad refleja probablemente la situación del producto: un gran capital en una herramienta robusta que no pierde utilidad, y una respuesta errática a los cambios tecnológicos. Puntualizo algunas de las discusiones, e invito a revisarlas, y en el caso de las ideas propuestas, a votarlas si les parecen adecuadas. Las menciono por su título:
Outlook question: la discusión abierta es acerca del soporte de WinApi, ObMapi, es decir, el sistema de mensajería, para Outlook 2013 (también se menciona Outlook 2010). El problema reside en que el API está soportado para 64 bits, pero no para 32 bits, y Plex es generado para 32 bits. Esta es la respuesta del soporte de Plex:

There is a compatibility issue between the 64-bit versions of Microsoft Outlook and other 32-bit applications. Since Plex generates 32-bit application, you will need to use the 32-bit versions of Outlook.  (remite a la explicación de Microsoft). So, if you are using the OBMAPI or WINAPI Souce Code mail APIs, then you will not be able to use the 64-bit version of Outlook 2013 with these APIs.

La solución ofrecida es usar la versión de Office de 32 bits, o usar otro código, o solicitar al equipo de desarrollo que estas APIs soporten 64 bits. El propio soporte recomienda esta última opción, que conduce a  una solicitud existente desde julio de 2014.
Sobre este asunto del atraso en el soporte de productos u opciones respecto a la evolución tecnológica actual, hay otra discusión que afecta a 2E, no Plex, pero donde valen las opiniones de los participantes, ya que podrían asociarse sin mucha dificultad también a Plex: la complejidad de plataformas y tecnologías que deberían abarcarse hace difícil mantener el paso. En el caso de Office, el problema resulta aún más claro: los cambios de arquitectura ensayados por Microsoft son capaces de hundir a cientos de proveedores de servicios que trabajan para su plataforma (partners), como sucediera con el mercado de Silverlight, y seguramente con los incipientes desarrollos orietados al cuasi difunto Metro.
Otras discusiones de importancia vienen de la sección de Ideas, por ejemplo la postulación de la generación de servicios REST sobre el System i (discusión especialmente interesante), o las dos o tres referencias a la actalización del soporte de SQL en el System i (1, 2). O incluso las postulaciones a mejoras en el soporte de RPG ILE. Todos ellos hablan de un retraso de soporte a la evolución de las distintas plataformas, que resulta prioritario resolver. Hoy la evolución tecnológica es rápida y diversa, y resulta muy difícil abarcar el espectro completo de arquitecturas, tecnologías y paradigmas. Aún para el paradigma de diseño basado en modelos, resulta difícil seguir el paso para elaborar transformaciones adecuadas a cada caso y sus interrelaciones. ¿Qué camino es más aconsejable en éste caso, el de Plex?
Desde hace años, la solución de las transformaciones para atender nuevas áreas en Plex han estado a cargo de terceros; sea socios de negocios, como en el caso de los desarrollos web, telefonía móvil, e incipientemente cloud por parte de SoftDesign (Websydian) y CM First (WebClient), o los desarrollos para XML de Simon Jasperse, o los minipatterns debidos a Peter Fabel y Luwdig Hirth, o Stella Tools de George Jeffcock. Probablemente este sea el mejor modo de poder atender, especialmente sin un elevado presupuesto de investigación, la avasalladora ola de cambios en que nos movemos.
También desde hace años, el equipo de desarrollo de Plex expone crecientemente el API que permite la interrogación y operación del modelo, sus objetos y sus métodos. Es gracias a ésto que herramientas como Stella Tools puede trabajar. Probablemente esta vía sea la mejor para el desarrollo del modelador y sus generadores. Sería muy positivo que el trabajo del laboratorio de desarrollo de Plex se concentrara en éste aspecto: los modos para extender el modelador, para extender la inclusión de nuevos generadores que puedan ser elaborados por terceros. Estos terceros podrían ser empresas interesadas en extender la generación de código final a un nuevo área, o empresas  interesadas en adecuar una extensión a sus propias necesidades. Al modo en que Xtext trabaja hoy como DSL. Creo que ésta es la salida viable de Plex en éste momento, y allí deberían centrarse los esfuerzos.

Diez reglas para recordar (y seguir...)

Firmado por Javin Paul, un artículo que recuerda diez reglas importantes de orientación a objetos en el diseño con Java (10 Object Oriented Design Principles Java Programmer should know), que podríamos extender fácilmente a otros campos (y estoy pensando en Plex). Un pequeño decálogo, tan escueto que podríamos pegarlo en una pizarra frente a nuestros ojos, y que deberíamos repasar todos los días.

 DRY (Don't repeat yourself)
Our first object oriented design principle is DRY, as name suggest DRY (don't repeat yourself) means don't write duplicate code, instead use Abstraction to abstract common things in one place. If you have block of code in more than two place consider making it a separate method, or if you use a hard-coded value more than one time make them public final constant. Benefit of this Object oriented design principle is in maintenance. It's important  not to abuse it, duplication is not for code, but for functionality . It means, if you used common code to validate OrderID and SSN it doesn’t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format , your SSN validation code will break. So beware of such coupling and just don’t combine anything which uses similar code but are not related.

Encapsulate What Changes
Only one thing is constant in software field and that is "Change", So encapsulate the code you expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to test and maintain proper encapsulated code. If you are coding in Java then follow principle of making variable and methods private by default and increasing access step by step e.g. from private to protected and not public. Several of design pattern in Java uses Encapsulation, Factory design pattern is one example of Encapsulation which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code.

Open Closed Design Principle
Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful SOLID design principle, which prevents some-one from changing already tried and tested code. Ideally if you are adding new functionality only than your code should be tested and that's the goal of Open Closed Design principle. By the way, Open Closed principle is "O" from SOLID acronym.

Single Responsibility Principle (SRP)
Single Responsibility Principle is another SOLID design principle, and represent  "S" on SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality. If you put more than one functionality in one Class in Java  it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality,  which require another round of testing to avoid any surprise on production environment.

Dependency Injection or Inversion principle
Don't ask for dependency it will be provided to you by framework. This has been very well implemented in Spring framework, beauty of this design principle is that any class which is injected by DI framework is easy to test with mock object and easier to maintain because object creation code is centralized in framework and client code is not littered with that.There are multiple ways to  implemented Dependency injection like using  byte code instrumentation which some AOP (Aspect Oriented programming) framework like AspectJ does or by using proxies just like used in Spring. See this example of IOC and DI design pattern to learn more about this SOLID design principle. It represent "D" on SOLID acronym.

Favor Composition over Inheritance
Always favor composition over inheritance ,if possible. Some of you may argue this, but I found that Composition is lot more flexible than Inheritance. Composition allows to change behavior of a class at runtime by setting property during runtime and by using Interfaces to compose a class we use polymorphism which provides flexibility of to replace with better implementation any time. Even Effective Java advise to favor composition over inheritance.

Liskov Substitution Principle (LSP)
According to Liskov Substitution Principle, Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work with object of sub class without any issue". LSP is closely related to Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality ,and does violated LSP. In order to follow LSP SOLID design principle, derived class or sub class must enhance functionality, but not reduce them. LSP represent  "L" on SOLID acronym.

Interface Segregation principle (ISP)
Interface Segregation Principle stats that, a client should not implement an interface, if it doesn't use that. This happens mostly when one interface contains more than one functionality, and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this design principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement.

Programming for Interface not implementation
Always program for interface and not for implementation this will lead to flexible code which can work with any new implementation of interface. So use interface type on variables, return types of method or argument type of methods in Java. This has been advised by many Java programmer including in Effective Java and head first design pattern book.

Delegation principle
Don't do all stuff  by yourself,  delegate it to respective class. Classical example of delegation design principle is equals() and hashCode() method in Java. In order to compare two object for equality we ask class itself to do comparison instead of Client class doing that check. Benefit of this design principle is no duplication of code and pretty easy to modify behavior.

Y volviendo sobre la idea de su aplicabilidad en Plex, sin duda lo es. En algunos casos fácilmente entendible, (Favor Composition over Inheritance, Encapsulate What Changes, DRY,  Favor Composition over Inheritance) y en otros casos, después de luchar contra la vía fácil de hacer las cosas (Programming for Interface not implementation). Solo veo difícil implementar Dependency Injection. Y cuando me refiero a aplicabilidad, lo hago a nivel del modelo, no a nivel del código generado, donde su aplicabilidad está asegurada.
Plex, como otros productos, admite distintas interpretaciones, distintas formas de desarrollar. Aplicar principios de OOD permite explotarlo en forma más productiva, potenciando sus características. Luchar por no usar una hoja de ruta rutinaria favorece resultados consistentes y duraderos.

Una wiki de Plex oficial

Desde hace ya ocho años aproximadamente, la comunidad de usuarios de Plex sostiene y ha hecho crecer una wiki que se proponía difundir el producto, y reforzarlo con artículos enfocados en aspectos difíciles de entender, o la descripción de variantes novedosas de uso del producto. Un gran esfuerzo sostenido especialmente por la gente de Desynit, pero acompañado por muchos otros, que dejaron un producto robusto, aunque difícil de navegar. No es la única que existe (también puede mencionarse más enfocada a la que AllAbout sostiene), pero es la más completa y profunda en sus contenidos.
Ahora, hace un par de días, CA, aparentemente en el marco de una política de "wikificar" todos sus productos, acaba de lanzar su versión oficial de una wiki para Plex. Contrariamente a la primera existente, esta no parece ser modificable por la comunidad de usuarios, sino sólo por la propia empresa. Por ahora, la invitación es a leerla y sugerir correcciones o ideas. Valga, no sería el único caso y tiene sentido defender la integridad de su contenido. La "antigua" wiki ha tenido que ir cerrando la participación de colaboradores externos después de ser blanco de centenares o miles de ataques de spammers, hasta el punto en que la participación es por referencias y conocimiento seguro de los participantes interesados.
Su contenido apunta bien, y digamos que CA tiene lo necesario para que esta wiki se convierta en una referencia primaria de Plex, especialmente considerando su carácter abierto, es decir, consultable por cualquiera que la acceda. Algo que no es tan simple si alguien desea abordar su documentación (bookshelves) conservada en el área de Producto de la web de CA. Un aspecto importante es que la wiki completa es descargable como pdf o epub (como pdf deja un documento de más de trescientas páginas).
Esta wiki está en sus comienzos, enfocada en la versión 7.1. No dudo que a través de sugerencias y críticas se irá puliendo y enriqueciendo, hasta convertirse en una referencia primaria para quienes quieran conocer el modelador y generador, y para nuevos desarrolladores que quieran entender cómo usarlo.
Por ahora, todavía un poco parco, y con algunas inperfecciones, como considerar la explicación del uso del diagrama de acción y el manejo de entidades relacionales como parte de los componentes de System i. De todas formas, muy recomendable, especialmente esperando su enriquecimiento futuro, que eso es lo que está en la esencia de cualquier wiki.

Tendencias: IOT

El 6 de junio de 2012 se produjo el Lanzamiento Mundial de IPv6, inicio explícito del nuevo y reformulado protocolo de Internet. "IPv6" no se trató simplemente de atender la explosión social de Internet, sino que fue un paso necesario para atender a otra explosión: la perspectiva ya inmediata de extender la red de internet potencialmente a cualquier recurso susceptible de aplicarle inteligencia. Esto es, la Internet de las cosas (IOT), es decir, la posibilidad de que enormes cantidades de objetos puedan disponer algún grado de inteligencia, una dirección propia para comunicarse, y posibilidades inagotables de interrelacionarse con el mundo circundante. Sumémosle el mundo ya lanzado de la movilidad, y tendremos un universo de recursos de potencialidad sin límite. Ian Skerrett, de la Fundación Eclipse, expuso ayer mismo en pocas líneas su visión sobre el alcance de IOT. Creo que vale la pena reproducirlo, por su claridad, profundidad y síntesis:

How to categorize the Internet of Things

I was recently asked how to categorize the Internet of Things. IoT is so broad and multi-dimensional that I am not sure if there is one easy answer or set of categories. However, here is my current thinking…

1. IoT Hardware

A lot of the excitement in IoT and the maker community starts with the cheap, easily accessible hardware. Arduino, Raspberry Pi, BeagleBone are the poster kids in the space. Now there are a ton of new hardware solutions be made available, ex Parallela (16 cores for $99) , Galileo from Intel

2. IoT Standards and Protocols

There is a lot of talk about IoT protocols and which one will win. It is too early and I agree not any one protocol will win. One thing I do know is that closed proprietary solutions are not going to win. We do need to work on having a common set of standards like CoAP, MQTT, Alljoyn, SensorML, etc  Of course, we also need to make sure that we have open source implementations for these standards and protocols. That is why Eclipse IoT is so important for an Open IoT.
There will also be a lot of vertical standards that will be developed for IoT, like OneM2M, Continua, etc.

3. IoT Gateway Software

The typical IoT solution architecture will have some type of gateway solution that connect the sensors and actuators to the Internet. Eclipse Kura and Mihini are good examples of this but there are certainly others.

4. IoT Middleware

Companies like IBM, Axeda, Sierra Wireless, 2lemetry, ClearBlade, Microsoft, Eurotech, Thingworx, Litmus Automation and others are providing IoT platforms/middleware solutions. This is definitely an emerging space where all platforms are not equal. I expect to see a lot more startups and the big enterprise middleware vendors driving the innovation for IoT middleware.

 5. IoT Databases

The amount of data generated by IoT solutions has the potential to be Huge Data, not just big data. AS pointed out by Matt Asay, the exists a massive opportunity in analyzing IoT data.  Splunk seems to be the leader in this space but I expect a lot of innovation in this space.

6. IoT Solutions: IoT & Humans vs Industrial Internet

There are also a lot of  industry specific and user-case specific IoT solutions. Tim O’Reilly wrote a recent article titled ‘The Internet of Things and Humans‘ which does a very nice job summarizing the human impact of IoT. In fact a lot of the hype for IoT is around wearables and home automation.  Nest is the poster-child for IoT&H but you can’t go a week without finding another home automation solution being launched on kickstarter.
There is no doubt the human side of IoT will be important but I find the Industrial side to be a lot more compelling. SCADA systems like the London Tube system , Nespresso providing remote management of coffee machine, the work GE is doing for hospitals, aircrafts, etc. are the things  are fascinating and exciting opportunities. This is also where a lot of the profits in IoT will be made.

In the last 6 months the activity/hype around IoT has exploded. It will be fun to watch how these categories emerge and merge in the next 1-2 years. Of course an Open IoT is what is needed for all this to be successful. Eclipse IoT will be an important part of the solution.

Es hora de adelantar(se) en este escenario; ¿nuestras herramientas serán capaces de operar sobre este conjunto? ¿conocemos los recursos, infraestructura, estándares, proveedores, con los que habrá que interactuar? ¿tenemos la comprensión adecuada para transmitirla a quienes serán sus beneficiarios? Creo que sin duda, esta es la hora de los DSLs y de los modeladores y generadores de código, y comparto la expectativa de Skerrett en el papel que Eclipse pueda cumplir, por su flexibilidad y la extensión de su comunidad de usuarios y proveedores.

A propósito de una API de c++

Hace algunos días me pidieron que estudiara alguna manera de validar que una fotografía cumplía con ciertos requisitos de densidad y medida en pixeles: un requerimiento simple, que exige acceder a metadatos de la imagen. Desde el punto de vista de nuestros modelos de Plex, esto significa usar un API, ya que no existen dentro del conjunto de funciones propias del producto, ni tampoco en ninguno de sus patrones de tecnología, alguna función preelaborada que permita obtener esa información.
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para  .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.

Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el Windows Imaging Component, o el objeto PropertyItem (en System.Drawing.Imaging Namespace) , ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (1, 2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...

DSLs en su lugar

Una "vieja" entrada del blog de Bertrand Meyer, necesaria de recordar cuando se habla de DSLs (Domain Specific Languages) con alguna liberalidad: en ocasiones se los propone para resolver problemas específicos  que parecen condenados a bufurcar el camino de trabajo. La posición de Meyer es radical: ¿cuándo crear un lenguaje de dominio? Nunca:
El contexto:

It is a common occurrence in software development. Someone says: “We should design a language”. The usual context is that some part of the development requires a rich functionality set, and it appears appropriate to provide a flexible solution through a specialized language.

La objeción de Meyer:

Designing a language in such a context is almost always a bad idea (and I am not sure why I wrote “almost”). Languages are endless objects of discussion, usually on the least important aspects, which are also the most visible and those on which everyone has a strong opinion: concrete syntactic properties. People might pretend otherwise (“let’s not get bogged down on syntax, this is just one possible form”) but syntax is what the discussions will get bogged down to — keywords or symbols, this order or that order of operands, one instruction with several variants vs. several instructions… — at the expense of discussing the fundamental issues of functionality.
Worse yet, even if a language will be part of the solution it is usually just one facet to the solution.As was already explained in detail in [1], any useful functionality set will naturally be useful through several interfaces: a textual notation with concrete syntax may be one of them, but other possible ones include an API (Abstract Program Interface) for use from other software elements, a Graphical User Interface, a web user interface, yet another for web services (typically WSDL or some other XML or JSON format).
In such cases, starting with a concrete textual language is pretty silly, since it cannot yield the others directly (it would have to be parsed and further analyzed, which does not make sense). Of all the kinds of interface listed, the most fundamental one is the API: it describes the raw functionality, excluding any choice of syntax but including, thanks to contracts, elements of semantics.

Conclusión:

One of the key rules for successful software construction — as for many other ventures of course, especially in science and technology — is to distinguish the essential from the auxiliary, and consequently to devote proper attention to the essential issues while avoiding disputations of auxiliary issues. To define functionality, API is essential; language is auxiliary.
So when should you design a language? Never. Well, hardly ever.

 Si computaramos el tiempo de trabajo para definir el DSL y asegurar que funcione, en tales contextos, la adhesión a la posición de Meyer es segura...

UML en la ICSE 2013

Anteúltimo día de ICSE 2013 (International Conference on Software Engineering) , que muestra un gran número de trabajos de interés y participantes. A esta hora, destaco el que Timothy Lethbridge comenta, aunque por razones diversas: la presentación de Marian Petre "UML in practice", que resume su investigación sobre una muestra de desarrolladores de software, respecto a su uso o no de UML. En el resúmen de Timothy

She conducted an excellent interview-based study of 50 software developers in a wide variety of industries and geographical locations. Her key question was, "Do you use UML".

She found that only 15 out of 50 use it in some way, and none use it wholeheartedly.

A total of 11 use it selectively, adapting it as necessary depending on the audience. Of this group use of diagram types was: Class diagrams: 7, sequence diagrams: 6, activity diagrams: 6, state diagrams: 2 and use case diagrams: 1.

Only 3 used it for code generation; these were generally in the context of product lines and embedded software. Such users, however, tended not to use it for early phases of design, only for generation.

One used it in what she called 'retrofit' mode, i.e. "Not unless the client demands it for some reason".

That leaves the 35 software developers who do not use it (70%). Some reported historical use, and some of these did in fact model using their own notation.

The main complaints were that it is unnecessarily complex, lacks and ability to represent the whole system, and has difficulties when it comes to synchronization of artifacts. There were also comments about certain diagram types, such as state machines being only used as an aid to thinking. In general, diagram types were seen as not working well together.

She did comment on the fact that UML is widely taught in educational programs.

Como Tijs van der Storm comenta, quizá Marian esté martillando los últimos clavos en el ataúd de UML...

También coinciden en sus comentarios James Noble,  Alex Nederlof, y Leif Singer, entre otros. Éste último apunta al uso de UML en educación registrado por Marian, como muchas veces, y en muchos aspectos, corriendo detrás de la situación real.

Silverlight: Crónica de una muerte anunciada

Tim Anderson,  (¿ex?) entusiasta de Silverlight, informa que el sitio oficial del producto (Silverlight.net), ha desaparecido, y que ahora redirecciona a MSDN. La degradación (en términos militares) del producto queda evidente en que, si a grandes rasgos los contenidos principales fueron migrados, muchos contenidos dependientes y relacionados ahora conducen a enlaces perdidos ("shattered into a million broken urls"). Tim piensa en términos condicionales acerca de lo que Silverlight hubiera podido ser pero no fue. Algunos lectores apuntan otros casos de discontinuidad. Una vez más, para mí esta declinación planificada (¿obsolescencia programada?) refuerza la idea de que el software debe construírse a salvo de los proveedores de productos o plataformas, a nivel de modelo, de tal forma que sea capaz de sobreponerse a las conveniencias ajenas. Dejemos hablar a Tim:

There has been some Twitter chatter about the closure of silverlight.net, Microsoft’s official site for its lightweight .NET client platform. multimedia player and browser plug-in.
I am not sure when it happened, but it is true. Silverlight.net now redirects to a page on MSDN. Some but not all of the content has been migrated to MSDN, but Microsoft has not bothered to redirect the URLs, so most of the links out there to resources and discussions on Silverlight will dump you to the aforementioned generic page.
One of the things this demonstrates is how short-sighted it is to create these mini-sites with their own top-level domain. It illustrates how fractured Microsoft is, with individual teams doing their own thing regardless. Microsoft has dozens of these sites, such as windowsazure.com, windowsphone.com, asp.net, and so on; there is little consistency of style, and when someone decides to fold one of these back to the main site, all the links die.
What about Silverlight though? It was always going to be a struggle against Flash, but Silverlight was a great technical achievement and I see it as client-side .NET done right, lightweight, secure, and powerful. It is easy to find flaws. Microsoft should have retained the cross-platform vision it started with; it should have worked wholeheartedly with the Mono team for Linux-based platforms; it should have retained parity between Windows and Mac; it should never have compromised Silverlight with the COM support that arrived in Silverlight 4.
The reasons for the absence of Silverlight in the Windows Runtime on Windows 8, and in both Metro and desktop environments in Windows RT, are likely political. The ability to run Silverlight apps on Surface RT would enhance the platform, and if COM support were removed, without compromising security.
XAML and .NET in the Windows Runtime is akin to Silverlight, but with enough differences to make porting difficult. There is an argument that supporting Silverlight there would confuse matters, though since Silverlight is still the development platform for Windows Phone 8 it is already confusing. Silverlight is a mature platform and if Microsoft had supported it in the Windows Runtime, we would have had a better set of apps at launch as well as more developer engagement.
I posted that Microsoft’s Silverlight dream is over in October 2010, during Microsoft’s final Professional Developers Conference, which is when the end of Silverlight became obvious. It lives on in Windows Phone, but I would guess that Windows Phone 8.5 or 9.0 will deprecate Silverlight in favour of the Windows Runtime. A shame, though of course it will be supported on the x86 Windows desktop and in x86 Internet Explorer for years to come.

Buena presentación sobre MDE

Jordi Cabot publica hoy en Slideshare una muy interesante presentación sobre MDE/MDD, que, si bien hace una introducción general al tema, le dedica lo fundamental a las líneas de investigación y a los puntos problemáticos para lo que define como versión 2.0 de MDE. Dentro de las líneas de trabajo presente y futuro dos aspectos que veo particularmente interesantes son la actividad relacionada con  ingeniería reversa dirigida por modelos (mención especial de MoDisco), y el  manejo de muy grandes modelos, que parece ser un asunto de difícil solución en el marco de las premisas actuales de MDE/MDD.
La presentación es suficientemente detallada y amplia como para que pueda despertar la inquietud de aquellos que todavía dudan del valor de MDD/MDE, y más aún para quienes ya están embarcados en alguna forma de desarrollo basado en modelos. El camino es ancho y abierto...
No lo voy a reproducir: cualquiera puede ver la presentación en Slideshare.

Una presentación: Plex + Webclient

Una presentación publicada hoy por CM First, sobre PLex + Webclient. Para quienes no conocen Plex, una vista estimulante de sus posibilidades. Para quienes usan Plex y evalúan mover sus aplicaciones a nuevas arquitecturas, una idea de cómo mover aplicaciones a web + /o cloud +/o dispositivos móviles. Para quienes no conozcan Plex, es importante tener en cuenta la flexibilidad disponible en cuanto a arquitecturas.

Developing App with CA Plex + CM WebClient from CM First Technologies

En mi caso, este mes, testeando Plex + Android. Quizá agregue algunas líneas sobre sus resultados.

MDD: Una polémica en castellano

Javier Garzas ha tenido la muy buena idea de transcribir en su blog una discusión que sostuviera poco antes en Twitter con otros colegas españoles, acerca del alcance y validez del desarrollo basado en modelos, y de su confrontación y validez frente al concepto "el diseño es el código". La discusión refleja entre sus lectores un gran interés en el tema, pero también un persistente desconocimiento, y además algo de desconfianza y rechazo acerca de la idea del desarrollo guiado por modelos. No tengo tiempo hoy para otra cosa que no sea recomendar su lectura y, para quienes lo crean necesario, participar en la discusión. Espero tener tiempo el fin de semana para hacer algo más que recomendar su artículo, y la lectura de los comentarios de sus lectores. Entretanto, gracias especialmente a Javier y Pedro por su gran discusión.

Stella Tools, actualización

Acabo de releer el artículo que le dedicara a Stella Tools, y creo que merece una actualización. Ya lo he hecho en el propio artículo, pero, para quienes no lleguen a el directamente, va este recordatorio: George Jeffcock, su autor, ha seguido trabajando en Stella, con gran aceptación de sus usuarios. Pero, lo más importante, ha creado una entrada en la Wiki de Plex, que puede constituír un buen punto de entrada para su uso y su entendimiento. Como se ha dicho antes, Stella es uno de los mejores ejemplos publicados y aprovechables de la potencia que ofrece el API del modelo de Plex. Nuevamente,  estoy convencido de que, a partir del API del modelo, es posible extender Plex en amplios frentes.
Sobre este punto, Lee Dare ha escrito una introducción, y una descripción algo más amplia.

Un tutorial sobre OCL

Jordi Cabot acaba de publicar una presentación sobre OCL (Object Constraint Language) que constituye un excelente tutorial sobre el metalenguaje. Creo que de lo que recuerdo, es el mejor. OCL es un conocido de todos cuantos hayan trabajado con UML en MDD, apreciado y criticado...El tutorial es muy útil para quienes estén tratando de ver el alcance del desarrollo por modelos, y ayuda claramente a entender cómo se pasa de un modelo visual a un cuerpo capaz de convertirse en código.
Desde el punto de vista de Plex, se puede decir sin dudas que el OCL tiene muchos puntos de contacto con el metalenguaje (metaoperaciones) que se puede utilizar en Plex para abstraer y extender el alcance de los modelos que se describan con la herramienta. Una mirada al tutorial, en nuestro caso, también es motivadora. Para recordar la potencia de las metaoperaciones.

Plex => WebClient => Ipad

Para usuarios de Plex, o interesados en mover un modelo a aplicaciones móviles: una pequeña presentación de WebClient adelanta bastante información acerca del proceso de creación de una aplicación desarrollada para Ipad con Plex. No es posible entrar en detalles sin la documentación esperada para la versión 1.8, pero da una idea de los pasos a seguir, básicamente en la misma vía que lo necesario para construír una aplicación web estándar de Webclient, pero en una Mac: Plex [en una máquina virtual]=> Eclipse [Indigo en este caso] => [PhoneGap] => Código listo. Brevemente se explica también la variante Android.

A propósito de la década de Eclipse

Jean Bezivin comparte hoy en Google+ una nota de Ian Skerrett, de la Fundación Eclipse, que puntualiza algunos de sus logros en diez años de existencia. En lo esencial:

As I have written, Eclipse is celebrating 10 years of open source and community during the month of November.   There have been a number of milestones that have shaped the Eclipse community but what have been the major accomplishments?  What has Eclipse done to actually change the software industry?  Here are what I see as some of the key accomplishments for Eclipse.
1.  Dominant Java IDE.  Eclipse started out as being a really great Java IDE and continues today to be the market leader for Java IDEs.  If you think back to the late 1990′s and early 2000′s the Java IDE market was a dog-fight between Borland JBuilder, Visual Cafe, IBM VisualAge for Java.   Eclipse is now the clear leader and has approximately 65% market share in the Java IDE market.
2. De-facto Solution for C/C++ Tools.  If you are building a tooling solution for C/C++ developers there is a very good chance you are using Eclipse CDT as the platform.   In the realtime operating system and embedded development market, Eclipse CDT has become the de-facto standard.  There at least 50 companies that are building their developer tools solution based on CDT.
3. A large and innovative modeling community.  I am not sure how to quantify it but I believe the Eclipse modeling community has grown to become one of the largest and innovative communities at Eclipse.  If you are doing modeling, chances are you are using Eclipse Modeling Framework (EMF).  However, EMF is just the core that has created a really amazing community of innovation and diversity that happens at Eclipse Modeling.   There are over 70 modeling projects at Eclipse and I know a lot more not hosted at Eclipse.   It is a great success.
4. Integrating ALM Tools.  The Mylyn project has grown into becoming the industry hub for integrating tools across the application lifecycle.   There are now over 70 different Mylyn connectors that integrate different projects into the developer desktop.
5. Modular runtimes.  Equinox and the EclipseRT projects demonstrate how modularity can work on a large scale.  Everything at Eclipse is based on Equinox, since it is the OSGi runtime.  However, Equinox and the EclipseRT top-level project has spawned an industry around Eclipse RCP and server-side OSGi.  The range of applications being built on RCP is impressive, including NASA Mars Rover, financial institutions, aircraft design, genome decoding, etc, etc.   On the server side, Equinox is used by most enterprise Java application servers and Virgo is emerging as a new Equinox based platform.
6. Eclipse Release Train.  The Eclipse release trains have demonstrated open source communities can be predictable and scale to large distributed teams.   This is incredibly important as large more conservative companies become involved in open source.  Very few other organizations can claim a track record of predictability and scale that compares to the Eclipse community.
7. Eclipse Ecosystem.  Eclipse has become one of the two major development tools platform in the industry; MS Visual Studio being the other.   No matter what language you are using there is most likely an Eclipse IDE for you.  No matter what developer tool you are using, there is probably an Eclipse plugin.   No other platform has been able to create such a diverse and large ecosystem.  It has actually made building and integrating developer tools a lot easier!

De esto algo conocemos en la comunidad de Plex: al menos dos emprendimientos vinculan extensiones de Plex con las posibilidades de Eclipse: Webclient, creando una variante web ajax a partir de la generación de código Plex java, y el trabajo de Christopher Smith, mejorando el proceso de implementación de un modelo Plex. Dos sugerencias que abren un panorama más que positivo para el futuro.

SPLC 2011

Con programa preliminar a partir de este domingo, el lunes y martes próximo se desarrollará en Munich la 15ª conferencia de Lineas de Producto Software (SPL, Software Product Lines). Un concepto fundamental en la construcción de software, una fuente de ideas para quienes lo construyen, tanto sea en grandes unidades económicas, donde sus conceptos deberían ser  irremplazables, como para unidades menores, donde deberían motivar líneas de investigación y trabajo más racionales.
Aunque hemos conversado más de una vez sobre su significado, la descripción de uno de sus tutoriales explica razonablemente su meta:

Product Line Engineering is a common approach to address a business with a family of related software products. Instead of having separated development projects for each product in the family, products are built using a shared set of core assets, such as reference architectures and common infrastructure and domain-specific components. Key drivers for PLE are the potential cost savings due to shared core assets, as well as new business opportunities by, for instance, supporting tight integration and improved interworking among members of the product family. 

 Estoy persuadido de que SPL y MDD recorren caminos convergentes y retroalimentados. Uno de los tutoriales que se desarrollarán, toca esta característica: "Leveraging Model Driven Engineering in Software Product Lines", desarrollado por  Bruce Trask and Angel Roman:

Model Driven Engineering (MDE) is a promising recent innovation in the software industry that has proven to work synergistically with Software Product Line Architectures (SPLA). It can provide the tools necessary to fully harness the power of Software Product Lines. The major players in the software industry including commercial companies such as IBM, Microsoft, standards bodies including the Object Management Group and leading Universities such as the ISIS group at Vanderbilt University are embracing this MDE/SPLA combination fully. IBM is spearheading the Eclipse Foundation including its MDE tools like the Eclipse Modeling Framework (EMF) and the Graphical Modeling Framework. Microsoft has also launched their Software Factories and DSL Toolkit into the MDE space. Top software groups such as the ISIS group at Vanderbilt are using these MDE techniques in combination with SPLAs for very complex systems. The Object Management Group is working on standardizing the various facets of MDE. All of these groups are capitalizing on the perfect storm of critical innovations today that allow such an approach to finally be viable. To further emphasize the timeliness of this technology is the complexity ceiling the software industry find itself facing wherein the platform technologies have increased far in advance of the language tools necessary to deal with them. This complexity ceiling is evident in today’s Software Product Lines.

 Invito a seguir sus sesiones, a solicitar sus presentaciones, y a tomar contacto con sus participantes. Estas conferencias anuales acercan el mejor material sobre el tema.

Información y seguimiento en el sitio de la conferencia.

Webclient mobile es ahora open source

La newletter de CM First publicada hoy comunica que la elaboración de las nuevas plantillas destinadas al soporte de aplicaciones móviles se convierte en un proyecto open source. Es decir, abierta fundamentalmente a la comunidad de usuarios y desarrolladores de Plex/Webclient, porque de todas formas trabajar con ellas exige disponer de una licencia. Sin embargo, esta decisión representa otro paso destinado a abrir el desarrollo de patrones, semejante al que diera AllAbout hace un par de años abriendo el desarrollo de su desarrollo sobre XML. La arquitectura de Plex en su basamento en patrones y el desarrollo creciente de su API están permitiendo abrir sus posibilidades y extender su alcance. Los patrones para dispositivos móviles (teléfonos y tablets) se han iniciado con una base importante, y se potenciarán con participación abierta. Hay muchos otros campos donde aplicar este concepto.
El nuevo proyecto, en Google.Code.

Sugerencias que da un proyecto

Bob Fields, de Walt Disney World, comenta en The Model Driven Software Network, la  estrategia de la compañía para el desarrollo de sus aplicaciones usando Java, Eclipse, Rational, Maven. Una experiencia que recién comienza a describir, pero que ya presenta aspectos de interés si la sobrevolamos un poco, sea en general como medio de articular una línea de trabajo con MDD, o, siendo más específico, desde el punto de vista de Plex. Dice Bob:

(...) My main passion as an architect is in finding ways to improve the software development process through automation. I have championed the adoption of Apache Maven at WDPR, but much work remains before we have full adoption and integration over all phases of the lifecycle.(...) I led the effort to adopt an MDA tool several years ago. After investigating a number of alternatives (two no longer exist: OptimalJ and ArcStyler), we settled on the open source tool AndroMDA because of the maven implementation plus the mature output capabilities using velocity templates: Java, Spring, Hibernate, EJB, EJB3/JPA, Struts, JSF, WebServices, jBPM/Drools, dotNet NSpring/NHibernate/ASP.

 Es decir, articular una herramienta MDD con el mayor espectro posible de salidas, incluyendo todo en algún tipo de herramientas que permita articular y automatizar cuanto sea posible del ciclo de vida del sofware. En el caso de Plex, muchas sugerencias para extender y abrir el desarrollo, adelantándose a lo que en un momento determinado sea posible hacer con la IDE. Lo que iniciara Webclient (puente con Eclipse + Web), ampliado.