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)