Banda Ancha en Latinoamérica

Un informe de Cisco para América Latina destaca el potencial de crecimiento de la banda ancha en Latinoamérica, pero su bajo desarrollo actual. Comentado en La Nación por Ricardo Quesada, el informe muesta una penetración baja, comparada a la europea (sin hablar de los países más destacados en Asia). El informe es un papel orientado a mejorar los negocios de Cisco en el continente, pero las cifras son considerables:

"América latina tiene una oportunidad enorme. El alto valor de las commodities hace que haya mucha plata en los países de la región. Si se reinvierte en infraestructura y en tecnología de la comunicación, es posible que esta bonanza se convierta en crecimiento duradero", afirmó Jaime Valles, responsable para América latina de Cisco Systems.

Según Valles, la región está frente al crucial desafío de mejorar las condiciones de conectividad y el acceso de la población a la banda ancha, que hoy, en promedio, llega al 3,5%. El país con mayor porcentaje de conexiones es Chile, con un 8,8%, y la Argentina está segundo, con 6,6%, lo que representa más de 2,5 millones de accesos. "Los países más desarrollados tienen cerca de un 20% de penetración de banda ancha. Cisco tiene el reto de mejorar estos números", expresó el ejecutivo.

Más allá de los objetivos de mejora, esa cifra no es buena. Es de destacar también que Brasil continúa por debajo de Chile y Argentina. Las cifras mejoran bastante respecto a informes anteriores (1 y 2), pero en cifras absolutas siguen siendo bajas. Entre otras cosas, ¿cuánto se pierde de interconexión internacional? Cada vez más, cualquier sitio da por supuesto que los usuarios que se acercan a una página, lo hacen a velocidades de banda ancha mínima al menos, lo que permite elaborar contenidos complejos. Si en América Latina el 91,2 % o más de la población no tiene acceso a conexiones rápidas ¿qué alcance existe?

Code Generation 2008 finalizada

A finales de junio se efectuaron las sesiones de Code Generation 2008, anunciada aquí dos o tres veces. Centrada en las distintas variantes de desarrollo basado en modelos, ha continuado progresando en extender su uso, y en debatir el peso y alcance de las distintas vías de construcción de software. Las sesiones predominantemente ocuparon las dos tendencias corrientes en modelado: las distintas variantes del estándar de OMG, Model Driven Architecture, y las distintas ofertas de Domain Specific Languages; dos temas relacionados de particular interés, también tratados, son las relaciones con Lineas de Producto Software, y la aplicación a arquitecturas orientadas a servicios (SOA). Comentarios de algunos de sus participantes, en los blogs de Mark Dalgarno y Pedro Molina. Las presentaciones están disponibles en el sitio de la conferencia. El programa, mencionado en alguna nota anterior, da una idea del alcance de la conferencia.
Steve Cook y Bran Selic estuvieron a cargo de las keynotes. Y un excelente grupo de investigadores tomó a su cargo cada tema.

UML, DSL, y Microsoft, parte 2

En refuerzo de lo dicho antes, encuentro a Tad Anderson, escribiendo en .NET Developer´s Journal, que en septiembre de 2007 habla de las decisiones de Microsoft sobre UML, y su respaldo a DSL, afirmando que en dos años, no tuvo oportunidad ni medios de usar el set incluído en VSTS:
Over the past 2 years I have had the VSTS Architecture version installed and I have not used the DSL tools once on a project
Las razones muestran un camino que hoy parece estar remontándose:

A few years ago Microsoft decided to cut off its nose to spite its face.The war on UML started with the DSL movement.Although Microsoft still claimed to see UML as an essential tool, they stopped trying to compete with the rest of the market and tried to lead us down a new path that did not include UML.
With Rosario around the corner (a very big corner) the emphases is on Application Life-cycle Management (ALM).I think that is great. But the claim that their DSL tools will support the essential design documents is once again WRONG!!!! The DSL tools currently supported are the ones they are going to depend on again in the future.
Over the past 2 years I have had the VSTS Architecture version installed and I have not used the DSL tools once on a project. I have looked at them several times, but I always found SPARX Enterprise Architect (EA) easier to use to make meaningful artifacts. Microsoft did try to save a little face by saying they do support and suggest UML for domain modeling.
But there suggestion was to model in Visio (UML 1.2 or 1.4??), forward engineer the model to code and then open it up in their DSL class modeler. That is just plain dumb when tools like Enterprise Architect exist. Yes, Microsoft is partnering with SPARX now, but the ALM movement just confuses things because it introduces tools that step all over SPARX EA tools that support ALM, except for UML. Go figure.?.?.

Y concluye, tras relacionar el modelado con el marco en que lo usaría:

Microsoft’s ALM push will probably be good for project managers, but Microsoft still does not get that they are continuing to ignore the architect.

No está de más leer su nota completa. Es más contundente que lo que aquí extracto.

UML, DSL, y Microsoft

En junio ya hemos conversado sobre el repentino interés de Microsoft en UML. Anticipado por el propio Bill Gates en su keynote de Microsoft Tech-Ed 2008, la noticia ha hechado a rodar con amplitud, y hará más camino seguramente. Es interesante el párrafo que Gates le dedica al tema:

[Respondiendo a una pregunta sobre UML] we'll have additional support for UML in Visual Studio 10 for the specific modeling tools that are there. Then as we move forward and take the modeling platform to the next layer, we'll get even more ability for you to create your own models.

So, you're absolutely right that the modeling world is fairly disparate today. Even at Microsoft our people who do our business applications have some of their modeling environment. Excel in a sense is a pretty limited modeling type environment.

The thing that we've recognized is that by bringing those things together we can actually enable new things like what you do across the lifetime of an application. And underneath these models we actually use UML.

We think it's very rare -- a very rare person would actually want to look directly at the UML because it's so kind of abstract, but underneath, both in terms of exchange with other people's products and some of the exchange we're doing between our own products, we do have UML based subscriptions of these models.

Jack Vaughan y Michael Meehan han dado su opinión sobre este interés, y algo de sus dichos creo que da en el clavo: luego de alentar DSL versus UML, realmente una herramienta que articule la totalidad de un modelo es necesaria (And underneath these models we actually use UML...). DSL es un concepto positivo y conveniente, pero hacer pasar todo por lenguajes específicos de dominio es inapropiado, probablemente difundido más como una operación comercial que como una realidad. Primero, no todo dominio será expresado en un DSL, y segundo, sigue quedando en pie cuál será el pegamento que englobe conceptualmente el conjunto como un sistema; ¿la factoría de software?, o dicho de otra forma, ¿el Visual Studio Team System?.
Parafraseando a Jacobson, Vaughan dice:

Noted software technologist Ivar Jacobson, one of the original "Three Amigos" responsible for UML, said the problem of transforming representation between specific domains is not trivial.

"With DSLs, the problem is you need to have underlying semantics in common. You have a serious transformation problem across domains," said Jacobson, head of Ivar Jacobson International. "UML has a profile that allows you to have specific language constructs, but it has the same underlying model."

With DSLs, common semantics are very difficult to achieve.

Meehan va en la misma dirección a propósito de SOA; su punto de vista es que no es casual que al intentar poner un pie en SOA, sea necesario un medio de expresar lo que haya en común:

Yet Oslo is Microsoft’s Hail Mary pass over the rest of the SOA market and apparently the company has decided to end its religious differences with UML for the sake of giving Oslo mass appeal. Previously Microsoft had been pushing domain specific languages (DSLs) as an alternative to the general purpose format of UML. Unfortunately for the folks in Redmond, DSLs have failed to gain much traction. Part of the problem is getting the people who form a domain to agree upon a standard syntax. Another part is having that DSL interact with anything outside of its domain. Those things surely will come with the march of time, but the uptake has been painfully slow.

SOA demands some commonality, that everyone stop trying to be so special and idiosyncratic. Microsoft has always understood that on some levels, but it’s got skin in the proprietary software business (actually it’s got skin, blood, muscle, bone, you name it). Its maverick tendencies have often led to it offering users products that do SOA the Microsoft way. That is in stark contrasts to the company’s Web services tooling, which has for the most part embraced open standards and heterogeneous systems (most notably Windows Communication Foundation). This is where I remind some readers out there that, yes, there truly is a difference between SOA and Web services.

In fact, one way to look at Oslo, which supposedly will offer a Community Technical Preview in September, is that this is Microsoft’s flag in the ground for SOA. It emphasizes the importance of modeling, attempting to bring the technology as close as possible to the business. As such, UML represents an excellent choice. It should create interoperability between Oslo projects and those built with rival modeling tools (e.g. IBM Rational). And Eclipse’s Modeling Development Tools Project will have a UML2 component ready by the end of the month.

UML gives Oslo a reach it never would have had if it were based on a proprietary modeling language. The UML foundation means Oslo stands a chance of being truly universal, which is as SOA a concept as you can get.

Así, comenzamos a dejar de ver al UML y su significado básico como bosquejos escritos en servilletas a la hora de conversar...

De pronto, UML, II

El 8 de junio, Dr Dobbs Code Talk publicó una entrada de Christopher Diggins, que reconoce tres elementos que en el último tiempo han sido oscurecidos o cuestionados: que en programación hacen falta modelos, que UML tiene un papel que cumplir, y que existe un intento de crear un modelado que se convierta intrínsicamente en código, basado en UML (xUML, UML ejecutable). Diggins propone una sintaxis para no diagramar, sino escribir los modelos, que luego se ejecutarán (Heron).
Más allá del futuro de su iniciativa, lo motivan algunas objeciones comunmente formuladas a estándar:

Modeling is frequently used in certain software development domains to help verify the design of software, both formally and informally, before implementation starts.

One of the reasons that this approach hasn't caught on in the programming community at large is that it slows down development and increases the overall cost significantly. You have to maintain separate artifacts that contain largely the same information: the source code and the model. Finally models are often ignored after implementation starts.

Diggins reconoce que esta objeción no vale para el "UML ejecutable", que genera código a partir del modelo:

There is however a better solution that already exists: make the code and models synonymous with each other. In other words: make the model the code. This approach is the holy grail of the model-driven architecture (MDA) movement, and only one technology actually offers it today: executable UML (xUML).

Una objeción es acerca del carácter gráfico del modelo:

The problem with xUML is that it is primarily a diagram based formalism (with some unspecfied syntax thrown in). Most of us programmers hate diagrams. They are slow and cumbersome to develop and manipulate. My view, which I am sure is shared by many of you out there, is this: I wish everyone else in the world could supply me with up to date UML models with their source code, but I don't want to be obliged to do so myself.

Otra importante es acerca de la real posibilidad de traducir todos los diagramas a código. O mejor al revés: que todo el código requerido sea manejable con diagramas:

So a question one might ask is: why can't we simply generate models from code? Well the problem is that code is too low-level. Just like you can't generate pretty and elegant source code with meaningful symbol information from assembly code, the same is true of models.

En fin, estas objeciones serían objetables...En OMG existen estándares para manejar información de los modelos por medio de directivas que completen los diagramas. Tampoco es mi experiencia: el modelador que uso (Plex/no UML/si MDD) también es capaz de completar la información con un metalenguaje capaz de expresar lo que haga falta, y lo suficientemente abstracto como para que pueda generar código para distintas plataformas y arquitecturas, basadas en las mismas directivas, configuradas para distintos contextos.
La iniciativa de Diggins va en esa dirección. Nótese que Diggins, ante los puntos no satisfactorios de UML, va por más, no hacia atrás.