Microsoft y MDA-MDD - Segunda aproximación

Yendo adelante con la nota anterior, quisiera entrar un poco más en la visión de Microsoft.
Debo aclarar que tengo un prejuicio, y es que la insistencia de MS en desechar, desvalorar o desacreditar los dos estándares de OMG relacionados (MDA y UML) tiene una simple razón comercial. El mejor resultado de desentrañar su iniciativa, sería determinar los valores positivos que la estrategia de modelado de MS pueda aportar.
También debo decir que yo mismo, por mi experiencia personal con Plex, puedo coincidir en que no necesariamente se debe construír un producto por medio de transformaciones de un modelo generado a partir de un esquema UML. Aunque creo que entre los propios constructores del estándar, aceptan que pueden existir otras vías de pasar desde un modelo hacia una aplicación.
Salvado esto, quisiera enfocar el punto más valioso de la estrategia MS:

In our opinion, a single PIM and a single PSM per target platform, all developed using a general purpose modeling language, as prescribed by MDA, are insufficient to support the significantly greater levels of automation promised by model-driven development.

De acuerdo. Tratar de elevar el diseño orientado por modelos a un esquema que soporte en forma amplia el ciclo de vida completo de una aplicación, es una consecuencia natural de la construcción evolutiva de un modelo.
Cómo se ejemplifica en el documento de MS:

Rich automation of the software life cycle requires many additional types of models, such as models that:

• Capture, analyze, and manage requirements; identifying trace relationships between requirements, architectural design and implementation constructs, enabling validation that requirements have been implemented, and supporting impact analysis when requirements change.
• Define software architecture in a way that supports security, performance and reliability analysis, and other forms of evaluation; and in a way that enables predictable assembly of systems from components, and efficient and reversible step-by-step transformations from requirements and deployment,
• Define how the executable components of a system are packaged, identifying the types of resources in the deployment environment required by each component, and binding the components to specific instances of those resource types,
• Define test cases, test data sets, test harnesses, and other artifacts, making it easier to evaluate the quality of software developed using models, and to manage and display the test results
• Identify traceability relationships between models and other artifacts, making it easier to support business impact analysis when systems go down, configure systems to satisfy requirements, and enforce constraints during system configuration,
• Define configurations of source artifacts used to build executables, making it easier to version those configurations, and to associate defect reports and feature change requests with specific versions.

Dejando de lado que algunos de estos casos debieran ser contemplados hoy día por un esquema UML (seguramente el ítem 3), hay aquí un conjunto de escenarios que requerirían conducción, trazabilidad, interconexión o integración, automatización, y que cubren un paso más que lo que hoy una transformación PIM => PSM puede alcanzar. Muchos de ellos pudieran ser encarados encauzando el uso de un modelo dentro de una herramienta de manejo de configuración, que hoy cubren casi todos los ítems, al menos en una forma secuencial histórica. Pero mucho mejor sería que el mismo modelo articulara todos estos aspectos.
MS habla de "many additional types of models" para referirse al modo en que estos aspectos serían expresados, planteando el problema como una colección de modelos. Me conforma más la idea de OMG que habla de visiones encaradas por distintos diagramas. La idea de colección de modelos me hace pensar que la integración de ellos se lograría por medio de la IDE en la que se describieran y recolectaran, con lo que deja un grado de subjetivismo en cómo serán interpretados o aplicados. Más aún, cuando la IDE en que están incluídos es una parte del Visual Studio mismo, en donde la construcción de código tiene de automático aquello que pueda ser derivado de un wizard, una clase heredada, un header, o un patrón aplicado. Sobre esta característica retornaré en otro momento.
En resumen, la idea de extender, y las áreas propuestas de extensión, son de real interés, y creo que son valiosos generadores de ideas. El cuánto sea esto logrado en esta iniciativa, es algo que debe verse bajando más cerca de cada una de las herramientas concretas con las que se lo intenta. En cambio, el hecho de manejar estos recursos como una colección, sugiere que la idea no está acabada, y que en estos términos puede ser incluso peligrosa, excepto que se tenga una buena disciplina para su utilización. El desarrollo basado en modelos justamente se propuso atacar la complejidad del diseño, facilitando la visión arquitectónica, yendo hacia la abstracción, y poniendo bajo control la complejidad de las decisiones de detalle. De un modo en que la cascada de consecuencias que se derivan de las definiciones en el modelo abstracto, estén bajo control. No veo en el esquema propuesto por MS facilidades amplias de este tipo. Pudiera convertirse en lo contrario.
Volveremos sobre esto avanzando un poco...

Microsoft explica su posición sobre MDA-MDD

El 1 de junio Paul Ballard publica una breve nota en The Server Side presentando el documento oficial de Microsoft donde se explicita en mayor detalle su posición sobre el desarrollo basado en modelos. Quince páginas (ver el artículo en el enlace del título de esta nota) para describir el concepto de Software Factory, los puntos de contacto y las diferencias con UML y MDA:

Customers and partners are keen to understand Microsoft's strategy for model-driven development and its support in Visual Studio Team System. When we explain our strategy to them, they frequently express interest in some of the same topics, and raise some of the same concerns. In this document we set out our strategy for model-driven development as a series of questions and responses that address these topics and concerns. The first five questions deal with the main pillars of our strategy, which we have described with detailed answers and explanations.

En los próximos días trataré de sacar lo mejor del documento...

Si los programadores fueran albañiles...

Casi de casualidad, me encontré con este artículo sin autor declarado, en la bibliografía del curso de Ingeniería de Software I del Politécnico de Albacete.

Uno de Enero

Hoy me han llevado al solar por primera vez. La situación es perfecta: tiene el Metro a dos pasos y una cafetería enfrente donde sirven menú del día. El viejo bloque de pisos, al que va a sustituir nuestra nueva construcción, lleva un año al borde de la ruina. Mi propia empresa ha colocado varios puntales que, por el momento, han ido evitando que el caduco edificio reviente por sus múltiples grietas. La construcción de este megalito de ladrillo dió comienzo hace cinco años, y aunque los pisos superiores nunca llegaron a recibir el agua, la electricidad y el enfoscado de las paredes, en diez meses los cimientos ya se habían desplazado peligrosamente y las vigas presentaban peligrosas fisuras. La cansada torre de viviendas ya ha cumplido su propósito y ahora nosotros la conduciremos a una muerte dulce. Por supuesto, el viejo edificio no será demolido hasta despues de construir y probar el nuevo, lo que nos deja poco espacio de maniobra; pero no vamos a dejar a todas esas familias en la calle durante la construcción. De cualquier modo, los vecinos de la vieja y decadente estructura nos miran con recelo. Saben que el nuevo edificio tendrá viviendas mas cómodas, pero algunos de los residentes no podrán costearlas. Ni se qué va a ser de esta gente, ni es asunto mío. Llegan los primeros camiones de ladrillos.

Dos de enero

Me han presentado a Alberto, la persona a quien "voy a reportar". No me han dicho si es el capataz, el jefe de obra, el aparejador, o el arquitecto; sólo me han dicho que todo lo que tenga que "reportar", se lo "reporte" a él. Así que, por donde él diga, yo zaca-zaca, como una locomotora. Esa es la definición que me han dado de nuestra metodología. He buscado "reportar" en el diccionario, y no aparece.

Seis de febrero

En algo más de un mes, hemos cavado medio metro de cimientos. Ayer Alberto nos dijo que empezáramos a poner ladrillos, porque el tiempo designado para la cimentación se había agotado hace dos semanas. No acepto nuestras excusas de que las prometidas excavadoras aun no habían llegado y que nos habíamos visto obligados a cavar con las paletas de enyesar. Un compañero se trajo una pala de cavar que guardaba de una obra anterior y casi le echan por razones deontológicas. Según Alberto, lo que pasa es que frecuentamos demasiado la cafetería. El asunto se ha zanjado con un «hale, a levantar paredes y luego que cada palo aguante su vela». El trabajo sin planos es dificultoso. Los cimientos tienen una forma algo pintoresca. He pedido una plomada para que las paredes queden verticales y he recibido improperios poniendo en duda mi masculinidad. Ya sé que Alberto no es el arquitecto, porque el arquitecto es un tal Ignacio. Pasó a supervisar la obra el otro día, aunque aun no había nada que ver. Me han llegado rumores, aunque no son muy dignos de crédito, de que existen fotocopias de planos.

Doce de mayo

Anoche estuvimos hasta las siete de la mañana cubriendo con tablas y enmoquetando el espacio que algún día ocupara el despacho de la sexta planta, aunque el edificio no es aun mas que una maraña de vigas de todos los tamaños y algunas paredes que habrá que tirar más tarde porque están en el sitio equivocado. Hemos traído baterías para los fluorescentes y unos muebles de caoba preciosos. Por suerte, todo estuvo a punto para la demo. Izamos al cliente con la grúa hasta su futuro despacho y pudo contemplar la vista que se disfrutaría desde el emplazamiento. El viento hizo que la pared oeste, que dos de mis compañeros sujetaban con la espalda, se derrumbara con gran estruendo sobre la mesa de caoba en el peor momento. Gracias a Dios, el cliente fue comprensivo: esto pasa siempre en las demos, y él está curado de espanto, dijo mientras le sacudíamos el polvo del traje. Dice que el lunes que viene vendrá a probar las instalaciones sanitarias. Supliremos con cubos la inexistencia de tuberías.

Veintitrés de febrero

Han transcurrido casi catorce meses. Llevamos ya siete de retraso y el edificio no acaba de superar el estado de "casi terminado". Soy de los pocos albañiles que no ha cambiado de obra en este tiempo. Alberto esta consumido por la zozobra y se pasa el día en la cafetería trasegando Soberanos. El arquitecto no ha vuelto a pasar por aquí. Los rumores dicen que existieron unos planos, pero no eran de un bloque de pisos, sino de un polideportivo. Por lo visto, en las reuniones del comité de construcción se dijo que la filosofía era la misma y que sólo harían falta modificaciones mínimas. Ahora comprendo por qué nos hicieron instalar aros de baloncesto en el hueco del ascensor. Siempre dije que acabaríamos teniendo que quitarlos o aquello no era un hueco de ascensor, que era cuestión de lógica. Alberto siempre me contestaba que no le viniera con tecnicismos. Estoy perdiendo la vocación de albañil. He decidido apuntarme por las tardes a un curso de informática, a ver si puedo cambiar de vida. Este oficio mío no es serio

* Publicado en la sección "Cartas del iluso" de la revista Solo Programadores, número 19, Marzo 1996.

Copyright © 1994-1998, ATI, Asociación de Técnicos de Informática.

¿Abarca y Devora III? - Un comentario posiblemente muy a propósito...

Publicado el 16 de abril de este año en WillyDev.Net, el artículo indicado en el enlace del título tuvo la virtud de molestarme, dejándome con el disgusto de no poder discutir sus afirmaciones, no sólo con el prologuista o el traductor, sino al menos con sus soportes en WillyDev, quienes lo consideraron excelente. No leí, y es improbable que lo haga, el libro que motiva el prólogo de Joel Spolsky (En busca de la estupidez, de Rick Chapman), que puede o no -seguramente sí- ahondar en la línea del prologuista, pero es lo que éste dice lo que en principio me desagrada.
En primer lugar, el tono del escrito, que pareciera preparado por un fan adolescente de Microsoft (mal iría a leer un libro de análisis de tendencias presentado por un fan adolescente). Su visión del "ñoño-opositor-linuxero" me temo que muy bien le pudiera caber a él mismo. Una persona que piensa que los problemas de competencia comercial que se dirimieron en el período que ejemplifica, pudieran reducirse a una guerra de fans, desconoce probablemente el impacto que esas guerras comerciales dejaron. O se trata de un documento destinado a captar el entusiasmo de los nerds del bando propio...
En segundo lugar, una de sus dos afirmaciones centrales: "Microsoft es la única empresa de la lista (de grandes compañias de software) que no ha cometido un error garrafal e insensato". Quizá sea de interés estudiar los errores de sus competidores caídos, pero pensar que ese punto explica el predominio de Microsoft, es ignorar u ocultar otro elemento fundamental de su predominio: la utilización a destajo de su posición dominante, que está expresada en una cadena interminable de juicios por monopolio (Windows Media Player, Netscape, por sólo mencionar dos bien conocidos, no son reflejos de errores estratégicos del competidor, sino de abuso de posición monopólica, y es revulsivo escuchar al prologuista explicar la caída de Netscape por el plan de reescritura del código, ignorando la demanda sustentada a través de varios años, acerca de la inclusión forzosa de IE dentro de Windows). Más aún, seremos expectadores privilegiados de la historia, ya que ahora va por Google, y veremos allí cómo se aplica la doctrina de "no cometer errores garrafales": MSN Search también estará incluída en todo lo que fuera Windows, y, si usted es usuario de Messenger, podrá notar que es forzado a actualizarse a la nueva versión 7.0 incondicionalmente, y cuasi forzado a aceptar el MSN Search incluído en la actualización; al menos a mí, me resulta ultrajante que no pueda abrir mi versión 6.x si no acepto la 7.0 (algo parecido con XP). Las discusiones en la Unión Europea y China acerca de las reglas de conducta del gigante, creo que eximen de comentarios.
Spolsky supone un segundo argumento justificativo del predominio de MS, y es que está a su frente un programador. Creo que le hace muy poco mérito a Gates...

Abarca y Devora II - Descripción del invento

Data Structure Mappings: Un esquema Relacional a un esquema Orientado a Objetos; cómo es cubierto por la patente apuntada en la nota anterior.
Lo que sigue es la lista de Claims de la patente:
What is claimed is:

1. A system that facilitates mapping arbitrary data models, comprising a mapping component that receives respective metadata from at least two arbitrary data models, and maps expressions between the data models.

2. The system of claim 1, the data models are query languages.

3. The system of claim 1, the data models are data access languages.

4. The system of claim 1, the data models are data manipulation languages.

5. The system of claim 1, the data models are data definition languages.

6. The system of claim 1, the data models include at least an object model and at least one relational model where the object model is mapped to at least one of the relational models.

7. The system of claim 1, the data models include object models where one of the object models is mapped to at least one of the other object models.

8. The system of claim 1, the data models include an XML model and at least one relational model where the XML model is mapped to at least one of the relational models.

9. The system of claim 1, the data models are XML models where one of the XML models is mapped to at least one of the other XML models.

10. The system of claim 1, the data models include an XML model and at least one object model where the XML model is mapped to at least one of the object models.

11. The system of claim 1, the data models are relational models where one relational model is mapped to at least one of the other relational models.

12. The system of claim 1, the data models include an XML model and an object model where the object model is mapped to at least one of the XML models.

13. The system of claim 1, the data models are of the same structure.

14. The system of claim 1, the mapping component receives topology data that is derived from the metadata.

15. The system of claim 1, the data models are read-only.

16. The system of claim 1, the data models are mapped without modifying the metadata or structure of the data models themselves.

17. The system of claim 1, the expressions comprise at least one of a structure, field, and relationship.

18. The system of claim 17, the expressions mapped between the data models are at least one of the same, different, and a combination of the same and different.

19. The system of claim 1, the mapping component creates structural transformations on the data of a data model by at least one of creating or collapsing hierarchies, moving attributes from one element to another, and introducing new relationships.

20. The system of claim 1, the mapping component relates and connects the same mappable concepts between the data models.

21. The system of claim 1, the mapping between the data models is directional.

22. The system of claim 1, the data models include a source domain and a target domain, such that a structure and field of the target domain can be mapped at least once.

23. The system of claim 1, the data models include a source domain and a target domain, such that a structure and field of the source domain can be mapped multiple times.

24. The system of claim 1, the data models include a source domain and a target domain such that the mapping component allows a user to operate on the data models through a query language of the target domain.

25. The system of claim 1, the data models include a source domain and a target domain such that the source domain is the persistent location of the data.

26. The system of claim 1, the data models include a source domain and a target domain such that mapping translates a query written in a query language of the target domain into a query language of the source domain.

27. The system of claim 1, the mapping component facilitates automatically synchronizing updates made in a target data model to a source data model.

28. The system of claim 1, the mapping component includes a mapping file that maps like concepts of the respective metadata.

29. A computer executing the system of claim 1.

30. A system that facilitates mapping arbitrary data models, comprising: source metadata that represents source concepts of a source data source; target metadata that represents target concepts of at least one target data source; and a mapping component that receives the source metadata and the target metadata and maps the concepts from the source data source to the target metadata associated with one or more of the target data sources.

31. The system of claim 30, the mapped concepts are at least one of the same, different, and a combination of the same and different.

32. The system of claim 30, the data sources are of the same structure.

33. The system of claim 30, the source concepts and the target concepts are the same in both of the data sources.

34. The system of claim 30, the mapping component relates and maps the same concepts between the data sources.

35. The system of claim 30, the source and target concepts include a relationship element that is a link and association between two structures in the same data source.

36. The system of claim 35, the relationship element defines how a first structure relates to a second structure in the same data source.

37. The system of claim 30, the source data source and the target data source are disposed on a network remote from the mapping component.

38. The system of claim 30, the mapping component is local to at least one of the source data source and the target data source.

39. A method of mapping data between data models, comprising: receiving respective metadata from at least two arbitrary data models; and mapping expressions between at least two of the data models based upon the metadata.

40. The method of claim 39, the expressions mapped between the two data models are the same expressions.

41. The method of claim 39, further comprising defining a source data schema and a target data schema and information missing in the schemas.

42. The method of claim 39, further comprising transforming data during a mapping of a source data model to a target data model using a function.

43. The method of claim 39, further comprising synchronizing changes made in a target data model with a source data model.

44. A method for mapping arbitrary data models, comprising: receiving source metadata that represents source concepts of a source data source and target metadata that represents target concepts of a target data source; and mapping the concepts between the source and target data sources based upon the source metadata and the target metadata.

45. The method of claim 44, the data sources are of the same structure.

46. The method of claim 44, further comprising, creating a variable in a source domain; restricting the variable with conditions; and mapping the variable to the target concept.

47. The method of claim 46, the variable is created at least one of implicitly and explicitly.

48. The method of claim 46, the variable represents an empty result set.

49. The method of claim 44, the mapping is stackable between the source and target data via one or more intermediate mapping stages.

50. The method of claim 44, further comprising selecting an optimal path for mapping between the source and the target.

51. The method of claim 50, the optimal path is selected with a central control entity based on at least one of available bandwidth and interruptions in the path.

52. The method of claim 44, further comprising accessing a mapping algorithm in response to selecting an optimal path between a plurality of the data sources and plurality of the data targets.

53. The method of claim 52, the mapping algorithm is associated with a structure of the source data and the target data.

54. A system that facilitates mapping data between arbitrary data models, comprising: means for receiving source metadata that represents source concepts of a source data source and target metadata that represents target concepts of a target data source; and means for mapping the concepts between the source and target data sources based upon the source metadata and the target metadata.

55. The system of claim 54, the means for mapping includes a mapping means that relates and maps the same concepts between the data sources.

Mel Brooks: "Abarca y Devora"

Una noticia de los últimos días: un grupo de desarrolladores patentó el mapeo entre estructuras de datos. Extractado por The Server Side:

The patent is A data mapping architecture for mapping between two or more data sources without modifying the metadata or structure of the data sources themselves. Data mapping also supports updates. The architecture also supports at least the case where data sources that are being mapped, are given, their schemas predefined, and cannot be changed.

En la lista de propietarios de la patente aparece un número importante de personas vinculadas a Microsoft. La voz común es considerar que es Microsoft mismo quien avanza sobre una idea que fue ampliamente aplicada a través de muchos años por muchas empresas, que puede incluír distintos perfiles de problemas, pero que es señalada especialmente como amenaza a los diseños existentes en OR mapping (mapeo de relacional a objeto y viceversa).
Primer contacto con la noticia, una advertencia temprana de Jack Herrington en CGN-Talk, desde donde se puede leer el contenido completo de la patente aprobada, y los nombres de sus propietarios. Luego, la nota en The Server Side apuntada en el título de éste artículo, aribuyendo a Microsoft la acción, y, fundamentalmente, las consecuencias. Como en la discusión de The Server Side se dice, una patente no es definitiva, sino controversial; pero implica un avance definido hacia un objetivo restrictivo: poner una idea que en varios aspectos es de dominio público y académico, en manos de un grupo de beneficiarios de futuros reclamos de propiedad intelectual.
Aunque es temprano para atribuirle un padre, los "indicios vehementes" señalan uno, y uno acostumbrado a moverse con estos valores.
La siguiente es la introducción descriptiva del invento:

[0004] The present invention disclosed and claimed herein, in one aspect thereof, comprises a mapping format designed to support a scenario where two (or more) data sources need to map to each other, without modifying the metadata or structure of the data sources themselves. Mapping is provided, for example, between an Object space and a relational database, Object space and XML data model, an XML data model and a Relational data model, or mapping could be provided between any other possible data model to XML, relational data model, or any other data model. The mapping format supports updates, and also supports the case where both data sources being mapped are given, their schemas are predefined, and cannot be changed (i.e., read-only). An approach that was previously used to map, for example, XML data to a relational database required making changes to the XML schema definition (XSD) file in order to add annotations. The mapping format of the present invention works as if the XSD file is owned by an external entity and cannot be changed. It also allows reuse of the same XSD file, without editing, for multiple mappings to different data sources (databases, etc.).

[0005] Each data model exposes at least one of three concepts (or expressions) to mapping: structure, field, and relationship. All of these concepts can be mapped between the data models. It is possible that one data model may have only one or two of the expressions to be mapped into another data model that has three expressions. The mapping structure is the base component of the mapping schema and serves as a container for related mapping fields. A field is a data model concept that holds typed data. Relationship is the link and association between two structures in the same data model, and describes how structures in the same domain relate to each other. The relationship is established through common fields of the two structures and/or a containment/reference where a structure contains another structure. These are just examples of relationships, since other relationships can be established (e.g., siblings, functions, . . . ). The present invention allows establishing arbitrary relationships. A member of a data model can be exposed as a different mapping concept depending on the mapping context.

[0006] Semantically, mapping is equivalent to a view (and a view is actually a query) with additional metadata, including reversibility hints and additional information about the two mapped domains. When one data source is mapped to another, what is really being requested is that it is desired that the Target schema is to be a view of the Source schema. Mapping is a view represented in one data domain on top of another data domain, and defines the view transformation itself. Mapping can create complex views with structural transformations on the data, which transformations create or collapse hierarchies, move attributes from one element to another, and introduce new relationships.

[0007] Mapping relates and connects the same mappable concepts between two or more mapped models. Mapping is also directional. Thus, one domain is classified as a Source and the other is classified as a Target. The directionality of mapping is important for mapping implementation and semantics, in that, a model that is mapped as a Source has different characteristics then a model that is mapped as a Target. The Target holds the view of the source model, where the mapping is materialized using the query language of the target domain. The Source is the persistent location of the data, and mapping translates the query written in the target domain query language to the source domain query language. One difference between Source and Target is that a structure or field from the Source or Target model has some restrictions regarding the number of mappings that can apply for structures and fields. In the target domain, a structure and a field can only be mapped once, whereas in the Source domain, a structure and a field can be mapped multiple times. For example, a Customers table can be mapped to a BuyingCustomer element and a ReferringCustomer element in the Target domain. However, a local element or local class can be mapped only once. Another difference that stems for the directional attribute of mapping is that mapping allows users to operate on the mapped models through the query language of the target domain (e.g., using XQuery for mapping a Relational model to an XML model, and OPath, for mapping a Relational model to an Object model).

[0008] Another important attribute of the mapping architecture is that of being updateable. In the past, developers had to write code to propagate and synchronize changes between the domains. However, in accordance with the present invention, the mapping engine now performs these tasks. That is, when the user creates, deletes, or modifies a structure in the target domain, these changes are automatically synchronized (persisted) to the source domain by the target API and mapping engine.

[0009] In another aspect thereof, the mapping architecture is stackable where multiple stages of mappings may occur from a source to a target.

Quisiera destacar el último párrafo de la introducción:

[0010] To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

...

El compromiso europeo con MDA

Dos muestras del notable interés comprometido en Europa con la consolidación de un estándar MDD: Modelware y UMT-QTV
Modelware en su presentación en dos palabras:

There is a growing gap between the demands of the end-users and the solutions the currently used methods of software development achieve. A paradigm to close this gap consists of the use of models for the construction of software. Model Driven Development (MDD) puts this concept on the critical path of the software development. The ultimate goal of the project MODELWARE is the large-scale deployment of Model Driven Development.

MODELWARE has three major objectives:

Objective A: To develop a solution to enable a 15-20% productivity increase of software systems development. This solution will be based on MDD. Objective B: To lead the industrialisation of the solution. Objective C: To ensure the successful adoption of that solution by industry.

Based on the exploitation of higher levels of abstractions in the specification and design of software systems, MODELWARE provides a rigorous and coherent framework bringing major improvements in engineering processes. The framework automates the production of most software artefacts (tests, documentation, code, etc) and allows better capitalisation of know-how.

MODELWARE establishes the missing link between advanced formal approaches proposed by the academic communities and more traditional industry driven engineering solutions.

MODELWARE defines and develops the complete infrastructure required for large scale deployment of Model Driven Development strategies and validates it in several business areas. MODELWARE combines innovations in modelling technologies, tool development (both generic and domain specific), standardization, experimentations, change management, and users-suppliers relationships.

Entre otros colaboradores destacables, tales como France Telecom, el Fraunhofer Gesellschaft de Alemania, e IBM UK, quisiera destacar a la Universidad Politécnica de Madrid, y a Jean Bézivin, por el Institut National de Recherche en Informatique et en Automatique de Francia.


UMT-QTV en su parca presentación:

UMT-QVT is a tool for model transformation and code generation of UML/XMI models. UMT-QVT provides an environment in which new generators can be plugged in. The tool environment is implemented in Java. Generators are implemented in either XSLT or Java.

UMT-QVT is the 'Sourceforge' name for the UMT tool, which is short for UML Model Transformation Tool. It is not, as you may or may not assume, an implementation of the forthcoming OMG QVT (Query, View, Transformation) standard. However, it might migrate towards that eventually.....

Jon Oldevik, de Noruega, ofrece más información en su sitio ModelBased.

Extreme Programming revisitado

Timothy Fisher publica en su blog soportado por Sys-Con, un artículo comentando pros y contras de XP. Probablemente, como dice el artículo, dando una visión imparcial del alcance y valía de su práctica. Recuerdo haberme interesado en XP hace alrededor de cuatro años, inicialmente con entusiasmo por algunos de sus principios, y luego con mayor moderación en cuanto conocía más el conjunto de reglas que recomendara, y en tanto conocía mejor las opiniones y actitudes de sus mentores. Con el tiempo, tomé el camino de adoptarlo como un conjunto de prácticas, algunas de las cuales me parecen excelentes, y otras que dejo para sus integristas, que parece que los tiene. Adhiero casi por completo al balance de Timothy, y quizá le pusiera el acento a algún otro elemento, especialmente a su visión de los proyectos como "historias sin fin", y a su desapego al modelado del proyecto (dos puntos vinculados sin duda).
Los "pros"de Timothy:

Testeo

Unit testing has certainly been around for many, many years, but it's certainly not unreasonable to say that we owe a great deal of today's increased emphasis on unit testing to XP. Unit testing was promoted as one of XP's core practices. Along with the recognition of unit testing as a powerful aid to developers came the methodology of test-driven development. This is a development style in which unit tests are always written prior to the code which they are testing.

Plan de trabajo

What XP refers to as the "planning game", is another good practice that can be carried over into other methodologies. XP does a very good job in maintaining schedules, plans, and keeping the plan very current. The iteration and build strategies advocated by XP are very good strategies for any project. Amongst these strategies, XP advocates frequent releases, short and well defined development iterations, frequent builds, and emphasis on build automation. Whether you choose to practice XP or not, these are strategies that add value to any methodology.

En este caso, el plan es referido al corto plazo. En este terreno, XP es muy interesante, y quisiera aplicar tanto como pudiera especialmente el objetivo de releases cortos: Ciclo corto de desarrollo tanto como se pueda.

...
Otros aspectos en pro no son mencionados, sino brevemente agrupados en el punto anterior. Quisiera agregar un "pro" apenas indicado al comienzo de su artículo: la propiedad común, o quizá mejor comunitaria, del código. Seguramente no llevado al extremo de la rotación diaria en la escritura de código, pero la rotación en la construcción del código es un elemento fuerte para lograr un mejor dominio del producto en el que se trabaja. Todo lo contario a la práctica usual, donde cada participante de un proyecto suele estar especializado en una actividad. En realidad, Timothy critica como uno de los "cons" de XP este concepto:

XP also does not believe in the need for "experts". Their philosophy is that all programmers should be well balanced on all technologies employed by the application. While this sounds admirable as a goal, the reality of this is that you kill the enthusiasm of an expert, and encourage a mediocre understand of all technologies in all your programmers. It is simply not realistic for all programmers to become experts in all of a project's technologies. Individuals who want to gain expertise in a specific technology, such as security, GUI design, databases, etc. are discouraged.

Creo que aquí coexisten dos aspectos: uno, que también veo, es el poco acento puesto en el análisis global o de largo plazo, dando primordial importancia a la escritura de código. El otro aspecto es la rotación en la elaboración del trabajo: Es cierto que un especialista no debe ser reemplazado, y que su trabajo tiene su cualidad propia, pero, en primer lugar, rotar entre pares es posible y recomendable, para mejorar el conocimiento global del producto en construcción, al menos lo suficiente para que un área no dependa de una sola persona. Adicionalmente, la visión global cohesiona y posibilita incluso la mejora a través de la observación del par.

Los "cons" de Timothy (the not so good):

El cliente en el equipo

Another core practice of XP asks you to keep a customer representative onsite with your development team so that you are able to quickly work out requirements confusion, get answers to questions, and get feedback on your progress. This sounds great, but it’s the practice I usually refer to as the fantasy practice. We'd all love to have James Gosling onsite also in case we run into any Java problems, but it's simply not realistic, just as having an onsite customer is not realistic in most cases. When you are able to achieve this, absolutely go for it. It's a grand idea, but not one that a software development methodology should rely on as a core practice.

Hacer las cosas simples

XP also tends to be full of short catch phrases summarizing its core principles. One of those is "Do the Simplest thing Possible." Here they are advocating that you should always implement the simplest, least complicated solution to the task at hand. They specifically warn against coding for anticipated future extensibility and add-ons that may or may not actually happen. While in general, this may not be bad advice, I think making this a core principle of XP is going too far with this attitude. Often, it does make a great deal of sense to spend the time to implement something that, while not necessarily the simplest solution, is a smarter and better solution. Remember this; the simplest solution is not always the best solution. This tenet seems to be born out of programmers who are adverse to strategic design, analysis, and modeling and simply want to code.(El subrayado es mío)

Aquí adhiero en tanto la simplicidad tenga relación con la oposición a un desarrollo de visión estratégica. Por lo demás, la simplicidad es recomendable.

Programación de a pares:

En este punto adhiero por completo a su criterio, al que remito. Sólo le agrego una especialización "local". Quisiera saber cuántos equipos de trabajo de Latinoamérica podrían disponer equipos de pares para escribir código en una máquina...

El código es toda la documentación:

While not an official XP practice, it is a common belief in the XP community that source code alone can serve as the developer documentation for a project. This may be fine for the developers currently working on the project, but have you ever tried joining a project in progress with a large code base and being told that the only documentation for what they've created so far is the source code? Believe it or not, many XPers would say that is perfectly fine, and this is how they document their projects. Again here, we have a failure to consider the future and what is strategically best for the organization as a whole.

En resumen...

The best way to view XP is as a collection of principles which may be applied to your software development project individually or in sets. You should not be dogmatic in your views about XP and believe that it is an all or nothing methodology. I'd go a step further even and refer to XP as a methodology toolbox, rather than a methodology

De acuerdo, Timothy. La mejor actitud sería tener una cartilla de XP a mano, y releerlas para reconsiderar el trabajo de la próxima semana, pero como auxiliar de tu método predefinido de trabajo...

Las herramientas de configuración y el ciclo de vida del software

La administración de cambios: Lo que inicialmente tuvo un alcance limitado al manejo del código fuente, con un ciclo corto de administración entre un repositorio de código y los objetos en producción, evoluciona y se ajusta más cada año a principios industriales (ingeniería de software) para la construcción de software. El artículo de Michel Sayko enlazado en el título de la nota quizá no diga algo muy nuevo, pero tiene la virtud de exponer en cierto modo el estado actual del manejo de la configuración del software (SCM), al presentar la disciplina como una parte central del manejo del ciclo de vida, y destacar la capacidad de definir procesos de trabajo a través de los cuales se aplique el control de cambios. En sus palabras:

Early configuration management tools provided version control for source code files. By versioning source code files, changes made by one developer to one file could be preserved. Other developers could take these versions, modify them, and create new versions. The ability to version files became a prerequisite for team development. Over time, SCM tools offered integrated defect tracking since testing during the software development lifecycle identified bugs that needed to be fixed. Next came workflow automation. Tool vendors added process models and workflow engines to their SCM tools so that an organization could model and execute its software development process. Process items could model the activities that are at the core of software development lifecycle, such as gathering requirements, specifying features and functionality, designing, coding, and testing. A workflow engine could move each process item though a sequence of states as the activity modeled by the process item progressed. Over time, process modeling capabilities in the tools evolved. Today, SCM tools can model complex development processes. SCM tool users have come to expect flexible and extensible process models that can be adapted easily as an organization’s processes change. In addition, SCM tools users now look for an integration between requirements management and core SCM features. The need to ensure that a software system satisfies an evolving set of requirements is what drives this integration. Customer expectations and government regulations now make traceability from requirements to source code files a requirement for the software development lifecycle.

El modelo asincrónico: un artículo en Developer.com

Durante décadas el modelo generalizado y frecuente de construír software fue sincrónico: pudiera ser distribuído, pero en cierto modo todo actuaba como si un supremo director condujera armoniosamente todos los hilos. Qué lo cuestionó primero, es asunto de revisión de fechas. Pero dos elementos ofrecieron otras posibilidades: las colas de datos (o mensajes), y los componentes distribuídos abiertos, especialmente lo que CORBA inició. Hoy SOA es un elemento a punto de integrarse a nuestro trabajo por largo tiempo. Aquí hay una hojeada a características y problemas de nueva generación.

La evolución tecnológica está basada en criterios científicos?

Mr X (no puedo averiguar ahora quién es) escribe en el artículo que se puede enlazar desde el título de este comentario, ideas que seguramente alguna vez también se le ocurrieron: ¿hay que estar siempre en la última ola?. Cuántas veces la aparición de un nuevo concepto se debe simplemente a la necesidad de una compañía de salir a competir y tomar control de un segmento de mercado? Cuántas veces nos hemos visto obligados a adoptar una tecnología determinada simplemente porque devino la única disponible? Cuántas veces, por el lado contrario, una idea brillante quedó en un cajón porque una compañía mayor la compró y envió a vía muerta? Cuántas buenas ideas no son compradas?
Mr X apunta a OO en su crítica, dedicándole un artículo en particular, pero el criterio es ampliamente aplicable. No estamos ante un proceso de evolución racional, científica, sino ante un proceso de evolución darwinista, en el que la calidad de una idea es solo parte del asunto, y otra parte no menor es el tamaño del capital que respalde un concepto. Escrito en 2001, el contenido es aún más aplicable hoy, en que la aguda concentración del mercado de IT lleva a una situación en que la tecnología es casi totalmente empresa-dependiente. Por ejemplo, qué hace tan distinto al concepto de Software Factory, que no le permita actuar en común con MDA?...o más aún,
serían tan ácidas las críticas de Greenfield, Short y otros, en un escenario distinto?
En palabras de Mr X:

Some may suggest that the chaotic fluctuations are necessary for progress. Since the merit of ideas cannot be readily quantifiable, the only remaining choices are stagnation or trial-and-error to find the better products or technologies. Given that stagnation is not the way of America, the remaining choice is trial-and-error.

I don't fully agree with that. In my opinion, the merit of new concepts, languages, and paradigms should be required to be exposed to tough and open scrutiny before it could be heavily promoted as an improvement. Of course, this cannot easily be enacted into law.

Thus, the only solution may be education about the hype process. If people realized that they are being bamboozled to forever ride the tech-hype treadmill, then people may be less likely to be suckered in. I should point out that it is not any evil plot by one group, just a side-effect of active capitalism. Rather than throw the baby out with the bath water, let's clean up the bath water a bit.

Popkin pasa a ser parte de Telelogic

Continuando la concentración mundial de empresas dedicadas al software, ahora le tocó el turno a Popkin, la compañia que desarrolló System Architect. ¿De qué manera verlo? Desde un punto de vista positivo, implica el reconocimiento y nuevas oportunidades al diseño basado en modelos, en manos de Telelogic, una empresa dedicada a la integración de aplicaciones (EAI). Desde otro punto de vista, es otro esfuerzo basado en el entusiasmo y el convencimiento que es absorbido.
...Algunos días después...(30 de mayo)
El comentario de www.methodsandtools.com supone que Popkin alcanzó un socio...

Telelogic in Acquisition Mood The Swedish company Telelogic has announced the acquisition of Popkin Software, the US based editor of System Architect for $ 45 million in cash. Popkin's revenues for 2004 were $ 19.1 million and it had currently 108 employees. Telelogic has also launched a bid to buy Focal Software. With 26 employees, Focal Software develops and sells web-based solutions for decision support in product development and project portfolio analysis. Founded in 1983, Telelogic has currently more than 750 employees. Its main products are DOOR, a tool for requirements management, TAU dedicated to design, implementation & tests and SYNERGY for configuration management. With these acquisitions, Telelogic completes its product portfolio and expand its market opportunities. In this relatively good year for software development tools vendors, you can expect other acquisitions or mergers. In this case, Jan Popkin has found for his company a partner that will allow him to develop its product.

Las raíces de la Orientación a Objetos

H.S. Lahman dedica en su Weblog, algunos interesantes párrafos a las raíces que condujeron a la visión Orientada a Objetos, y a las etapas de evolución de la construcción del software. No es la primera vez que menciono a Lahman, uno de los constructores de MDA, pero sólo ahora caigo en la cuenta de que es un verdadero pionero (primera aplicación en 1957!). Por lo tanto, participante de toda la evolución del desarrollo de software, y voz competente para hacer una mirada de valoración. Lahman destaca las ventajas, y lo revolucionario que resultó, la aparición del paradigma de análisis, diseño y programación estructurada:

The first systemmatic attempt to eliminate hackers appeared in the form of Structured Programming that provided a collection of good practices for writing 3GL code. That was quickly followed by Structured Design and Structured Analysis, both of which introduced more abstract graphical representations of programs. The dominant design technique became top-down functional decomposition where the solution was started with a very simple and general statement of the problem solution and then one successively decomposed that solution into more detailed levels. Each statement of functionality was collected as a node in an inverted "tree" whose lowest leaves were logically indivisible.

The impact of SA/SD/SP was enormous. Defect rates dropped from 150/KLOC to 5/KLOC. In addition, productivity for large projects where multiple programmers had to coordiante efforts improved greatly. Instead of 1000 programmers working for 10 years to produce 1 MLOC, 200 programmers could do the same job in 2-5 years

Lahman describe a la vez cuáles fueron los puntos débiles del diseño estructurado, indicando especialmente dos, vinculados al mantenimiento del código estructurado: la modificación de variables de estado en puntos no determinados del código, y las dependencias jerárquicas:

There were a lot of problems that led to the Maintainability Gap but they could be broadly categorized as having two root causes: uncontrolled access to state variables and hierarchical implementation dependencies. State variable access was primarily a defect problem as data was modified in unexpected ways at unexpected times during execution. That resulted in additional test and repair cycle time when one modified existing code because it was difficult to predict how changes would affect untouched code that happened to access the same data.

Hierarchical implementation dependencies resulted in the legnedary "spaghetti code". That was because the leaf nodes in the functional decpomposition tree were at a very fine level of abstraction -- essentially arithmetic or logical operators in the 3GL. It was simply too tedious to cobble together lengthy sequences of such atomic operations to do complex tasks. However, the higher-level nodes in the functional decomposition tree quite conveniently captured such sequences as descendants. Since this nodes were systemmatically derived they had defined functional semantics. That allowed them to be reused (i.e., accessed by "clients" in different parts of the application that happened to need the same sequence of leaf oeprations).

That sort of reuse through accessing higher-level functions was a boon to developers and led to the notion of "procedural development" because it made excellent use of the core characteristic of 3GLs, block structuring around procedures. The problem, though, was that the functional decomposition "tree" now became a lattice where each node potentially had multiple ancestors (clients) as well as multiple descendants. It was that fanout of dependency that led to spaghetti code.

The dependencies existed because in top-down functional decomposition the lower-level functions are extensions of their parent higher-level function. That is, the specification of the higher-level function included the specifcation of the lower-level functions. Thus any contract between the client and the higher-level function dependend upon the specification of the entire descedant tree of functions. So if one changed the specification of a lower-level function, the specification of all of its higher-level ancestors was also changed.

That was no problem so long as the access structure was a pure tree. That's because the change was probably triggered by a need to change the specification of a higher-level function and implementing the fix in the lower-level function was simply the easiest place to do it. However, when one has a lattice, the higher-level functions have multiple clients. If only one client wants the change, the other clients may be broken by the change. Worse, there can be a client at any level of ancestry in the tree, so the change may break clients that are not even direct clients of the original higher-level function. The result was a disaster for maintainability because every change for one client could potentially break a host of other clients. Fixing things to keep all clients happy often resulted in major surgery to the tree or very complex parameterization that complicated the functions.

Podríamos decir que aún hoy estas observaciones son ampliamente verificables, sin hablar de que (lo puedo decir por Argentina y Chile) podemos encontrar con cierta frecuencia sistemas construídos bajo éste paradigma, o documentados con el método. Si me extendiera un poco más, encontraría que existen centros de estudio que aún lo enseñan como método a aplicar...

Veintiseis años con nosotros

Veintiseis años con nosotros. Casi toda una vida. Casi todos nuestros recuerdos, y el estímulo del pensamiento. Le debo su visión del matrimonio, y todos los argentinos le debemos dos guerras menos. No está su presencia por primera vez, y ahora me resulta difícil escuchar su voz grabada.

Luc Alex Florent Gabi, Ndje: Patrones de Diseño y Componentes

Buscando materiales de Componentes y Patrones de Diseño, encontré el sitio de Ndje...Un colega camerunés con referencias a ambos temas, y mucho más. Es un descubrimiento, que tendré que ir investigando en las próximas semanas. En el tema de componentes, le pasa lo que que sucede con Cetus: curiosamente, Componentes, una arquitectura que fue el tema de discusión obligado hasta hace no más de tres o cuatro años atrás, desarrolló una nube de papeles describiendo sus virtudes por parte de los mayores competidores del mercado, pero hoy, no menos de la mitad de ellos son inhallables. Incluso, algunas de las empresas que los sustentaron. Otras empresas de pronto mudaron su arquitectura, y en muchos casos hoy sostienen J2EE o Servicios Web, lo que en definitiva es una continuidad lógica de los componentes. Bien, el asunto es que a Ndje le pasa lo que a Cetus: la mitad de los enlaces a documentos que pudieran ser de sumo interés, ya no apuntan a donde se espera. Si se tiene paciencia, muchos de esos papeles se pueden encontrar todavía, recurriendo a los Archivos del sitio.
Sin embargo, no deje de visitar Componentes, Patrones (con un manual de OOD incluído) , y Lenguajes

SOA y MDA

Si le interesa SOA (Service Oriented Architecture), puede encontrar algunas presentaciones de interés en la Conferencia de IDC UK 2005. Particularmente, una presentación estudiando cómo MDA puede servir en un entorno de arquitectura de servicios. (Tomado originalmente del grupo Soa en Yahoo ).

OO: el desafío de "Muchos a Muchos"

Costin Cozianu trae a discusión un desafío del SQL y las bases de datos relacionales hecho al mundo de Orientación a Objetos: resolver en forma sintética algunas acciones sobre una relacion de muchos a muchos (en el ejemplo, usuarios asociados a grupos -un usuario en más de un grupo-). El enlace al problema en el título de esta nota.
El desafío:

• Model the relationship between Users and Groups (many to many)
• For all domain objects (Users and Groups), handle:
  • creation of new objects
  • updating of existing objects
  • deleting of existing objects (including cascading: if a group is deleted, any relationships are invalidated)
• Querying for a set of objects which match a simple but arbitrary condition
• Creating a relationship between any two instances
• Removing a relationship between any two instances (including deletion as a result of deleting a member of the relationship)
• Navigating the relationship both ways in better than linear time
• If solution is not SQL, supply the entire implementation.
• Make it thread safe and deadlock safe (this is functionality provided out of the box by SQL DBMSes).

El objetivo: "demostrar que SQL mantiene funcionalidad que no está rápidamente disponible, ni trivialmente implementable" en ambientes OO:

The challenge was intended to demonstrate that SQL has useful functionality that is not readily available, nor trivially implementable in OO environments. This is in contrast to claims of OO developers (DbasGoneBad, PrevalenceLayer, etc) that if we could only get SQL databases out of the picture then we'd have all milk and honey. Since many books on OO talk quite a lot and quite without substance about OO "relationships" (aggregation, composition, ownership, directionality, etc), and since I know from experience that managing OO relationships is a frequent source of bugs in OO programs, I put this challenge with the intent to make some OoWeenie?s out there painfully aware of the limitations of their own tools. In particular this page debunks a pervasive misconception (see quotes in ObjectRelationalPsychologicalMismatch) that RelationalModel is not as good at representing "relationships" as object models. Which claim should be judged ridiculous on the face of it, but it is amusing how many "important names" in the OO camp make it.

Java y C++, errores históricos?

El 3 de mayo de 1997, Bertrand Meyer escribió en un grupo Google:

Ten years ago or so, when object technology first captured the industry's attention, projects moved en masse to C++. This was not the right decision. Not that everything was bad with C++ (then it would not have attracted so many
people); it was simply not appropriate for serious software engineering. C++ was a transition technology, useful to make C developers and their managers object-aware, but not appropriate for the development of durable, high-quality software systems. Interestingly enough, this was clear to many people; virtually
every object-oriented expert would privately concede that C++ was an inadequate solution - but carefully refrain from saying so in public, for fear of appearing to go against the tide.
This is happening again with Java. Once again we have an approach that has some major contributions to make but is hyped as the solution to everything - and is not. (sigue...)

Con estas revulsivas ideas se inició una discusión valiosa, con decenas y decenas de participantes, algunos de ellos fundamentales, como Bjarne Stroustrup o el mismo Bertrand Meyer con sólidos argumentos, que, cualquiera sea la posición de cada uno, sirve para aprender. Estamos en 2005, y la línea de discusión sigue: C++ y Java siguen en foco, sus puntos débiles son conocidos, y Eiffel también sigue en un segundo plano de adopción...
Si le interesa seguir la línea de discusión, o aportar su criterio...
http://groups-beta.google.com/group/comp.object/browse_frm/thread/2c6139ce13be9980/649217656063dab8

Un problema de arquitectura?

Un artículo de Builder.com (link en el título de esta nota), recoje la crítica de James Gosling, de Sun, sobre la decisión de Microsoft de soportar C y C++ en el esquema de ejecución de .NET . Gosling, "padre del lenguaje Java", dijo en Sydney en la primera semana de febrero, que esto crea un agujero de seguridad, y que éste es "one of the biggest and most offensive mistakes that they could have made", uno de los más ofensivos errores que hubieran podido cometer. ¿Por qué?:

(...) the security hole is based upon the fact that several features of the older languages are ambivalent with regards to security: "C++ allowed you to do arbitrary casting, arbitrary adding of images and pointers, and converting them back and forth between pointers in a very, very unstructured way.
(...) Gosling is concerned about "unsafe" code, which is produced by traditional languages like C and C++. Unsafe code is old code that does not strictly follow the rules of type safety that .NET defines, and this sort of code requires additional permissions to execute.
(...) An important point is that the so-called unsafe code does have the potential to run faster than "managed" code due to some languages' ability to include machine-specific features that may sacrifice platform portability for speed.

Charles Sterling, del lado de Microsoft, sostiene que .NET define distintas clases de código, dentro de las cuales el "código manejado" o "administrado", corre bajo el control de .NET y sus reglas de seguridad. Sterling reconoce que el código "inseguro" tiene la ventaja de estar adecuado a la plataforma, por lo que puede correr más rápido en una plataforma específica. Así, la decisión de usar código seguro o inseguro, es una decisión de cuánto riesgo se quiera aceptar:

the choice between the two platforms is all about risk: if developers are willing to "accept the risk" of unsafe code then they may gain access to "the best performance system on the planet."

Más sobre educación primaria: reportaje a Juan Carlos Tedesco

La Nación publica un reportaje a Juan Carlos Tedesco, especialista en educación, que refirma y describe en mayor detalle el empobrecimiento de la educación básica en Argentina, apuntando al desinterés de los dirigentes, y la importancia del soporte de la familia y la sociedad. Frente a la indolencia y la confianza en que "ya se solucionará", es importante su opinión sobre qué es tocar fondo:

-¿En América latina hay que tocar fondo para advertir que un área necesita ser fortalecida?

-Ojalá fuera así. A veces ni siquiera tocando fondo se ha hecho. Si no, no estaríamos donde estamos. Porque uno podría decir que aquí hemos tocado fondo varias veces. ¿Qué significa tocar fondo? Cuando volvió la democracia, después de tantos años de dictadura, desaparecidos, uno pensaba que habíamos tocado fondo. La experiencia demostró que no. Tuvimos que sufrir otra crisis profunda, la de 2001, igual que en otros países de América latina. Esto tiene que ver con el umbral de tolerancia que tenemos. Y nuestros umbrales de tolerancia han descendido mucho. Uno podría haber dicho hace muchos años que la Argentina no iba a tolerar un índice de desempleo mayor del siete por ciento.
Llegamos al 20 por ciento y se lo toleró. ¿Podemos tolerar tener el 50 por
ciento de la población por debajo de la línea de pobreza? ¿Cuál es el fondo?
América latina y la Argentina tienen que entender que tenemos que levantar mucho los umbrales. Hay que reaccionar antes de que sucedan estas cosas.

La educación básica es el futuro (hay que decirlo todavía?)

La revista América Economía , (número 293) trae en su portada un artículo sobre la educación básica en América Latina, con observaciones a un informe de la OCDE, que muestra muy pobres resultados de la enseñanza en general:

Los bochornos se sucedieron en diciembre cuando se publicaron los resultados de las dos pruebas internacionales más importantes de calidad educativa. El primero fue cuando la Organización para la Cooperación y Desarrollo Económico (OCDE) publicó los últimos resultados del Programme for Internacional Student Assessment. Conocido como el Pisa, el programa consiste en la aplicación de exámenes de conocimiento a entre 4.500 y 10.000 alumnos de 15 años de cada país participante. En total, 415.000 niños fueron evaluados por sus aptitudes en matemáticas, capacidad de lectura, ciencias y resolución de problemas. En su última versión, participaron los 30 países de la OCDE y 11 países voluntarios. México tomó parte como miembro de la alianza. Brasil y Uruguay, como voluntarios. El resultado no pudo haber sido peor para nuestros representantes regionales: los tres pelearon los peores lugares del ranking. Y en todas las variables estudiadas.

Es un déjà vu de lo sucedido con el Pisa 2000. Entonces, los cinco países latinoamericanos evaluados (Argentina, México, Chile, Brasil y Perú) se repartieron consecutivamente los últimos lugares, junto a Macedonia. En el informe presentado entonces por la OCDE, los países latinoamericanos destacaron por su mínima comprensión de lectura, alto nivel de repitencia y la enorme disparidad entre la capacidad de lectura de los estudiantes de familias pobres y con recursos. Los mismos puntos se destacan este año.
(...)
De la tendencia tampoco escapa Chile, el país de la región que ha puesto más esfuerzos para llevar a cabo una reforma educativa desde los 90. En diciembre se publicó el Estudio Internacional de Tendencias en Matemáticas y Ciencias 2003 (TIMSS, su sigla en inglés), otra prueba internacional que evalúa la calidad de enseñanza. Chile, el único país latinoamericano examinado, obtuvo magros resultados. No sólo alcanzó la posición 39 entre los 46 países participantes: lo preocupante es que el nivel de progreso fue mínimo frente a los resultados obtenidos en la versión anterior del TIMSS, de 1999.

Qué se afirma en el artículo:

• Aumenta la masa de estudiantes en nivel primario y medio en todo el continente, pero no aumentan los recursos dedicados, ni el nivel curricular.
• En las comparaciones mencionadas, los países que más avanzan, son los que tenían ya antes mejor nivel educativo, con lo que se ensancha la distancia entre los casos americanos y el resto.
• En muchos casos los estudiantes no entienden lo que leen, y se confunden con nociones básicas de matemáticas.
• Aumenta la diferencia de resultados entre alumnos de bajos recursos y de altos o medianos.
• La enseñanza está divorciada de los requerimientos de la vida real, en particular del trabajo y las empresas.
• En muchos casos, los recursos se orientan hacia la enseñanza privada, en lugar de ir a la pública (se menciona a Brasil), creando mayor diferencia entre la enseñanza pública y la privada.
• La desigualdad es aún mayor entre grupos raciales y étnicos.
• Los educadores se ven como empleados públicos, y adoptan los vicios de la burocracia.
• A los distritos pobres nadie quiere ir a trabajar, por lo que los alumnos quedan en manos de los menos experimentados o capacitados, por descarte.
• No es posible establecer un consenso de continuidad de un plan de mejora de la educación, y los planes cambian cada vez que los gobiernos cambian.

Una anécdota contada al inicio da la real dimensión del problema:

Un empresario de Rio Grande do Sul, Brasil, estaba a punto de estampar la firma que cambiaría de nivel su negocio de calderas. Había convencido a una empresa estadounidense para invertir dinero en su planta. No obstante, el inversionista extranjero le puso una condición inesperada: antes de poner un dólar, todos los empleados de la fábrica debían tener educación secundaria completa. El empresario gaúcho no sólo no lo podía creer. Tampoco lo podía cumplir: muchos de sus empleados tenían apenas entre cuatro y cinco años de escolaridad. Al ver cómo el negocio del año se escapaba de sus manos, no le quedó más que rendirse ante la evidencia: sin educación no hay competitividad.

Puedo enumerar decenas de síntomas avalando este diagnóstico, sólo acudiendo a la memoria de hechos de Argentina; otros podrán hablar de sus países: por ejemplo, las reformas educativas. Desde que recuerdo, Argentina va de reforma en reforma, al menos una por cada cambio "filosófico" de gobierno (la dictadura militar de Onganía, el gobierno peronista de 1973, la nueva dictadura posterior, el gobierno radical, y el nuevo gobierno peronista) cada uno su reforma educativa, en donde los maestros deben aprender un nuevo sistema de enseñanza, y los estudiantes en transición pasan de un sistema de aprendizaje al otro durante su ciclo en curso. Y, debiera decirse, cada vez, un sistema más degradado.
En fin, Latinoamérica no parece querer comprender el problema. Contrariamente a lo que podemos observar en los países asiáticos, que potenciaron su educación básica con el aval y respaldo de sus comunidades completas, ya sea la familia que sigue la educación de sus hijos, el Estado que actúa con continuidad a pesar de los cambios de administraciones, los maestros que son competentes, o las empresas que apoyan la capacitación.
Seguimos participando de comunidades disociadas, que, al anteponer el interés particular o de grupo al colectivo, están conduciéndose indolentemente hacia el mayor suicidio posible: la degradación social.

Global Tester: SQA, Metodos de manejo de la Calidad

Jeff Nyman sostiene Global Tester, un sitio dedicado al manejo de calidad en la construcción de software, con énfasis en el testeo. Qué dice sobre el concepto:

GlobalTester is a repository of open content information regarding subjects related to Quality Assurance, Quality Control, and Quality Testing. To state what GlobalTester is, it is helpful to consider its goals. One goal of GlobalTester is to provide a wide variety of information about various aspects of a quality initiative that can be used in a variety of organizations that act to bring a product to market, whether that product is hardware, software, Web sites, or anything else within the domain of the Information Technology (IT) industry. On a practical side, a goal of GlobalTester is to be two things simultaneously: (1) a diverse toolbox and repository of methodologies, methods, and practices for a robust quality initiative, and (2) a testing solution framework that emphasizes a broad view of testing to include non-exectuable and executable elements of a development lifecycle and that seeks to promote ways of thinking as well as ways of doing. Another goal of GlobalTester is to be as independent as possible of different management structures, specific tools and software, and staffing realities so as to present a large selection of topics that one can pick and choose from based on relevance and interest.

Qué dice sobre sí mismo Jeff:

Any time a site like this pops up it is logical and prudent to ask what makes the author of the site (and its contents) claim to be an expert in the field that they are talking about. In my case the answer is: absolutely nothing. In general, there is nowhere that I will claim to be an "expert", whatever that truly might be in the context of Quality Assurance. In fact, like everyone else in the industry, I am in a constant state of learning. Thus, even when I learn something there is always the corollary that tells me I have a lot more to learn. The only claim I will categorically make is that I am an individual that is committed to Quality Assurance in my professional life (and even my personal one to a large extent) and that I am committed to disseminating as much information as I can about Quality Assurance to the widest possible audience. I also make the claim that anything I present on this site has had the potential to save me a lot of time and effort at various organizations with which I have been employed. Perhaps more importantly, anything I present on this site has led to improvements in the overall quality efforts and initiatives of which I have been a part.

Adhiero a su punto de vista...( también puedo decir, "especialista en nada, e interesado en todo")

Un Blog de Arquitectura de Software

IASA (International Association of Sofware Architects) mantiene un blog más o menos institucional, que puede servir como enlace rápido a sus novedades. IASA es un reciente emprendimiento destinado a discutir conceptos de la arquitectura, de un modo abierto y no sujeto a posiciones tomadas. No dejar de visitarlo...
(El blog, enlazado en el título de esta nota, como en general sucede)

Un texto para mantener siempre a mano

Cómo ser un programador...Por si no lo conocía, debiera leerlo y tenerlo a mano. Un breve escrito, "How to be a programmer" desarrolla recomendaciones acerca de cómo escribir código, documentarlo, estimar tiempos, manejar un equipo y participar en él, testear, y , en general, las actividades diarias del trabajo de una persona y un equipo dedicados al desarrollo de código.
Robert Read, su autor, lo presenta así:

To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible.
In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one. This is very subjective and, therefore, this essay is doomed to be personal and somewhat opinionated. I confine myself to problems that a programmer is very likely to have to face in her work. Many of these problems and their solutions are so general to the human condition that I will probably seem preachy. I hope in spite of this that this essay will be useful

DSDM: Un sitio excelente en castellano sobre MDA

Este no será un verano con vacaciones...Tengo una pila tan grande de asuntos pendientes, que lo convierten en la época del año de actividad más intensa. Así, pasé por alto un correo enviado por la lista del grupo de trabajo MDD-MDA donde anuncian la nueva página creada para soportar la iniciativa en nuestra lengua. Correo del 30 de noviembre del año pasado! Con la disculpa por el tiempo transcurrido, quiero recomendar la página como la mejor sistematización de materiales, investigadores, organizaciones y cualquier otra clase de recursos que ayuden a comprender y avanzar en el estándar del desarrollo de software dirigido por modelos. Como señalé en otra nota, quisiera destacar la fuerte presencia de las universidades españolas en el estudio de MDA, así como en servicios Web.

Otro enfoque sobre la construcción de Software

Programación orientada a Lenguajes (LOP), defendido por Sergey Dmitriev, de JetBrains, explica otro paradigma para construír software. Una concepción cercana a la propuesta por Charles Simonyi: Programación Intencional.
Dice Dmitriev:

The motivation behind LOP goes something like this: I want to be able to work in terms of the concepts and notions of the problem I am trying to solve, instead of being forced to translate my ideas into the notions that a general-purpose language is able to understand (e.g. classes, methods, loops, conditionals, etc.). To achieve this, I need to use domain-specific languages. How do I get them? I create them.

I have begun development of a universal platform (the Meta Programming System) for designing domain-specific languages along with their supporting tools and environments. It will allow programmers to define languages as easily as they can write programs today. The platform will fully support LOP, giving programmers the freedom to use the most suitable language for each part of their programs, rather than tying them down to one fixed general-purpose programming language.

For me, the most serious problem is that there is a very long gap between when I know exactly how to solve a problem and when I have successfully communicated this solution to the computer as a program. I can explain the problem and solution to another programmer in a matter of hours, but encoding this solution into the computer takes much longer. This is because with a programmer I can use natural language which is very rich, but for the computer, I must use a general-purpose programming language which is much less expressive. Programming languages today have only tens of notions that can be expressed. A natural language has tens of thousands of notions which can be expressed succinctly. So, to explain a program to another programmer, I can just express very high-level ideas, but for the computer, I must express every single step and every detail. In mainstream programming, most of the time spent ‘programming’ is really just finding ways to express natural language concepts in terms of programming level abstractions, which is difficult, not very creative, and more or less a waste of time.

Una definición rápida del concepto de programación orientada a lenguajes, en el papel de M.P.Ward:

The approach starts by developing a formally specied, domain-oriented, very high-level language which is designed to be well-suited to developing this kind of program. The development process then splits into two independent stages: (1) Implement the system using this middle level language, and (2) Implement a compiler or translator or interpreter for the language, using existing technology. The approach is claimed to have advantages for domain analysis, rapid prototyping, maintenance, portability, user-enhanceable systems, reuseof development work, while also providing high development productivity.

Una crítica a LOP, que entrega más visión de contexto, en el Blog de Chris Nelson. Apuntada por el mismo Dmitriev.

Software Factory versus MDA

En TheServerSide.net existe una discusión en curso de interés sobre el valor del estándar de Arquitectura conducida por Modelado (MDA). Sólo en varios días podré acotar opiniones sobre el conjunto de la discusión, particularmente en cuanto al "versus", la factoría. Por el momento, quisiera solamente remarcar algunos aspectos señalados por Jack Greenfield, como puntos débiles del estándar. Jack no avala en general MDA, aportando argumentos que en mi criterio no veo como opuestos. Prometo releer varias veces sus razones, hasta encontrar por qué algunos de sus puntos pudieran considerarse "contradictorios". Por ejemplo, Jack cuestiona la idea de independencia de la plataforma:

The primary stated goal of MDA is platform independence. While some insulation from platform technology changes is no doubt achievable, I do not believe it is feasible to produce secure, usable, reliable, performing and supportable software from specifications that take no platform dependencies of any kind into account

Sin embargo, esta afirmación parece ignorar la existencia de dos niveles de modelado, el Platform Independent Model (PIM), y el Platform Specific Model (PSM). Creo que es cuestión de tiempo el que un PSM pueda generar código suficientemente específico para una plataforma dada, como para satisfacer los reclamos de Greenfield acerca de la necesidad de especificar el código. Pero, por si lo leí mal, lo releeré diez veces en estos días...
De todas formas, más allá de estas críticas, que releeré, están sus observaciones, que podrían tomarse como una lista de tareas a realizar:
Relacionado con el ciclo de vida:

• MDA says nothing about how models should be integrated with requirements, architecture, frameworks, patterns, code, configuration files, and other key development artifacts in the context of a development process. Surely, the failures of CASE in the 80s and 90s should tell us that genuinely seamless integration between code and models is an absolute requirement for success in model driven development. Any methodology that claims to explain how models should be used to develop software must prescribe robust solutions at the critical interfaces between models and other mediums of specification and implementation.
• MDA says nothing about how models or metadata derived from models should be used to automate specific tasks across the software life cycle, such as debugging, testing, deployment, version control and configuration management, operations and maintenance. Surely, these activities are as important, if not more so, than generating implementations? To be effective, a model driven development methodology should describe a holistic approach to automating the rest of the software life cycle.

Sobre el UML:

According to the OMG's official definition of MDA, MDA is a way to develop applications in UML. (There are two other competing but unofficial definitions of MDA, as described in a blog posting by Steve Cook, one that advocates the use of MOF based languages, not UML, as the medium of model driven development, and one that advocates the use of UML as a first class programming language that is compiled directly into executables. Of the three definitions, the MOF based one is the closest to the approach that we have taken with software factories and DSLs.). This is a large topic that I will take up in subsequent blog postings, even though it is already covered at length in the book. The point, for those who can’t wait, is that as a methodology for developing software in UML, the effectiveness of MDA is limited to the effectiveness of the UML as a language for model driven development, a task it was not designed to support.

Este asunto continuará...

En dos palabras, una declaración de principios

A propósito de una pregunta circunstancial, Christopher Smith define, en poco más de dos párrafos, la razón por la que los generadores de código devendrán la forma predominante de construír software. Frente a la nube de desarrolladores y dirigentes de IT que prefieren la construcción de código basados en su escritura directa ("handcoding"), la diferencia la hace la productividad:

I'm a Plex true believer. I was on vacation last week and I ran into a guy that works for Red Hat as a kernel developer. We had a discussion about system vs. application programming. He was rather dismissive of code generators. This also seems to be true of most Java developers.

(the following applies to experienced Plex developers) If you can tolerate 10 times more time to develop your application, fewer features, less consistency, 10 times more bugs due to lazy coding and you just absolutely need the source code to do it your way, you can squeeze 5% to maybe 10% more efficiency out of your application. Big Fat Deal.

The learning curve is steep and long but the payoff is big.

You need fewer SMART developers. Most shops try to just have fewer CHEAP developers and never realize any benefits.

Dicho en EDGE, el foro de usuarios de Allfusion Plex.

En el límite: una discusión entre RDBMS y OODBMS

El 4 de enero, en comp.object, Frebe lanza una pregunta que abrió una discusión acalorada que no terminará rápidamente:

In the OO world, there has been talking about OO databases for about 15 years now. But to me it is still not clear what a OO database actually is?

Sometimes people talk about OO databases as "a database that can do everything a relational database can, plus extra OO things". Sometimes they seem not to support the relational model and seem to be very closeto the network model. Sometimes hierarchial databases (like XML databases) are referred as "OO databases".

My question is: Which are the most popular OODBMS and what are their main features in comparison to relational databases? Does they have a query language and in that case, how does it work?

Sometimes I read that OO databases have a "seamless" integration with the programming language. Does this mean that the separation of database access logic into a persistence layer is not more necessary, or?

Fredrick desató vientos furiosos, pero muy útiles para navegar en el límite de las vías para manejar datos, objetos, o "persistencia", para decirlo de una manera que promedie lo que se puede obtener en el modelo relacional y en el de objetos. Me inclino a compartir la opinión de aquellos que consideran a las bases de datos orientadas a objeto "una mala idea cuyo tiempo nunca llega" (Daniel Parker). Así como Simon Williams puntualiza flancos débiles de las bases de datos relacionales, esta discusión pone sobre la mesa las fronteras donde el procesamiento de la persistencia y de la volatilidad no encuentra un medio consistente de representarlo o manejarlo.
Sin embargo, las observaciones de las dificultade de las OODB expresadas por sus propios usuarios o abogados más o menos defensores, parecen confirmar que esta vía está casi muerta:

The main advantage is that they provide very convenient syntax for accessing objects and they automate a lot of access details so the developer never really has to think very much about persistence. The downside is that the database boilerplate is ubiquitous in the application; typically even the 'new' operator is overridden to provide housekeeping infrastructure for the OODB activities. So the application code is tightly married to the specific DB vendor. Another disadvantage is that if one needs to access the same data from different applications, the stored data must be a one-size-fits-all representation of the object model, which is rarely very practical for complex OO applications. (H.S.Lahman)

Considering how much time and code programmers spend trying to figure out how best to store their data, and OODBMS' ability to make memory seem infinite and remove the burden of how persistence is achieved from the programmer is a goodthing. The estimates of 25% of application code dealing with database stuffs is about right. When we converted our application from RDB to OODBMS we saw a 22% reduction in code.

The greatest drawback is the lack of a query language and perhaps the impossibility of creating one to query data graphs (which is what OODBMS seem to be). Though our core application saw a 22% reduction in code 75% of any
system is typically queries and reports. Having to write them in the OODBMS'
language is a great way to slow development to a crawl. Adhoc queries is something SQL excels at, not to mention all the available report writers that simply don't exist for OODBMS. (Thomas Gagne)

La defensa más consistente de las OODB proviene de AndyW:

In an OODB you dont have database access logic, there is no need for it - and thats a mechanism provided by OO itself, rather than a database.

An OODB stores the instance of an object along with all the code needed to work with that instance. The location of the object is irrelevant to its usage - wether its on disk, in memory or on amachine in a different country is not important.

Objects have what is called an Object ID or OID for short. Think of it like a name tag for the object and it must be unique - just like an object is in the real world. Just like your coffee cup is unique. Also objects may have many OIDs - just like your cup can have manynames.

Objects are complex entities and can be made up of smaller simpler or complex objects themselves. When you deal with a complex object you also automatically deal with its individual parts thru the power of polymorphism and encapsulation. This is why OODBs are very good when used for diagramatic parts catalogs and telephone exchanges (phonecall info is very complex containing many dynamic sub parts).

Referencing an object automatically creates an instance if none exists and most OODBs will load the persistant form into transient space automatically, likewise they will persist automatically (hence no access code). Persisntance and transience mean slightly different things in OODBs as they do in normal programming, it also happens to be mostly irrelevant to the application program.

Andy fue replicado con dureza y sarcasmo...En el debate participan actores de proyectos de implantación de sistemas apoyados en OODB, que fueron abandonados por imposibilidad de concretarlos.

Modeling Maturity Levels

Siguiendo la orientación del Modelo de Madurez de Capacidades (CMM o CMMI), Anneke Kleppe y Jos Warmer hablan de un Modelo de Madurez de Modelado (MML, por Model Maturity Level) , estableciendo cinco niveles de elaboración de un modelo de un problema, siendo los niveles tratados los siguientes

• 0, No especificación
• 1, Especificación textual
• 2, Texto aclarado o completado con un Modelo Gráfico
  
• 3, Modelos visuales completados con texto
• 4, Modelos Precisos, en los que el modelo visual puede enlazarse en forma precisa al código ejecutable
• 5, Solo Modelos, es decir, un modelo que puede llevarse a código ejecutable sin intervención manual. Esto es MDA .

Respecto al nivel 5, los autores dicen:

At MML 5 the models are precise and detailed enough to allow complete code generation. The code generators at this level have become as trustworthy as compilers, therefore no developer needs to even look at the generated code. It is as invisible as assembler code is today. In other words, the MML 5 is the modeling Valhalla.

Unfortunately, there are no modeling languages in which we can write MML 5 models. We cannot work at this level—yet. Currently we still need to hand code a lot of nitty gritty details. This is the reason why we do not give an example here. Only within specific and limited application domains there are languages and tools that can achieve this. Most notably different vendors selling their versions of 'Executable UML' provide solutions in the realtime domain.

En este punto, mi experiencia difiere, pero la primera diferencia proviene de qué consideremos un modelo, y qué consideremos "hand coded"
Estoy acostumbrado a utilizar un concepto de modelo que integra aspectos gráficos, en el marco de una descripción narrativa (mejor debiera decirse lógica, en el sentido de los predicados lógicos de la lógica simbólica) que vertebra un repositorio, el que es íntegro casi en un 95 %, dejando para ingresar código manual sólo por medio de fragmentos estrictamente mapeados a "diagramas de acción", los que pudieran ser también considerados "hand coded", pero sólo si usted está dispuesto a conceder que un diagrama de actividades de UML es "código manual".
Pero, bueno, lo aquí interesante es la definición de niveles de madurez en el modelado.
Y usted, en qué nivel de madurez se ubica?...

Código autodocumentado

Una wiki dedicada a las reglas de escritura de código: La mejor forma de escribir comentarios es que el código sea el comentario...

Thoughts on Software

Thoughts on Software
...De Shayne Wissler, quien también ofrece una herramienta de administración de cambios en Ouray Sofware. Uso libre a cambio de información de testeo.

OOD no resuelve todo...(por lo menos los servicios Web)

Usualmente se considera al diseño orientado a objetos como el paradigma dominante, o como la visión natural del diseño. Aunque a veces sucede, en foros o grupos de estudiantes y profesionales argentinos o latinoamericanos, que aún OOA, OOD, OOP suenan como cosas extrañas (pero esto merece un libro completo de apuntes sobre las características de la educación y la capacitación profesional en nuestros países).
Pues bien, para aquellos que tiemblan cuando les dicen que deberán aplicar UML, existe una vuelta de tuerca más: Crecientemente se dice que las Arquitecturas Orientadas a Servicio, y su operador relacionado, los Servicios Web, "no se ajustan bien a la Orientación a Objetos". Para quien se interese en examinar este nuevo aspecto, un artículo conciso y claro de Geoffrey Slinker, le puede servir de aproximación.
(Gracias a la referencia en el grupo SOA sostenido por Gervas Douglas, en Yahoo)