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)

La desaparición de Peoplesoft

Finalmente, esta última semana de diciembre, Oracle tomo control formalmente de Peoplesoft. Luego de varios meses de presión sobre los accionistas, Peoplesoft sucumbió tras haber provocado previamente la desaparición de JDEdwards. Así, en un solo año vimos la extinción de dos grandes competidores del mercado de aplicaciones corporativas (ERP), y estuvimos cerca de que ver la compra de SAP por parte de Microsoft.
Luego del estallido de la "burbuja tecnológica" posterior al año 2000, la tendencia es a la consolidación y simplificación del mercado a un nivel sin precedentes, y pareciera que continuará este camino durante el 2005. Podría pasarme un largo rato contando los que estaban y ya no están, pero simplemente enumeraría aquellas empresas con las que tuve o tengo algo que ver: sin hablar de Plex, que tuvo a bien quedar en manos de uno de los grandes competidores (aunque Computer Associates atraviesa también "tormentas huracanadas"), mencionaría a Brío, que irónicamente fue comprada por Hyperion, el dueño de la base de datos que utilizara como "companion" de sus productos OLAP, invirtiendo la relación de fuerzas entre ambos productos. O Netviz, que pasara de ser un interesantísimo concepto de visualización de redes, a ser un apéndice de una compañia dedicada al monitoreo de performace (Concord Communications), estrechando su alcance al interés que el nuevo dueño pueda dedicarle. Techrepublic dedica un breve artículo que toma palabras de Joe Tucci, CEO de EMC, destacando la importancia y el impacto de esta característica dominante. Allí se encomillan las palabras de Dan Farber,
". . .if you don't get big fast, you will be left behind. If you are swift, small and innovative, you'll likely get scooped up by a big fish. Companies in the middle will have the hardest time surviving in the current consolidation phase." El artículo de Techrepublic da una pequeña lista de las adquisiciones del año, que son muchas más, siempre eliminando a un pequeño competidor con alguna virtud brillante, a manos de otro actor con una buena chequera.
No veo esta consolidación como un factor positivo. Más bien parece un corolario de la primera oleada de desapariciones, cuando la innovación y burbujeo producido por el surgimiento de jóvenes empresas se fue acotando a un reducido número de participantes, que tendieron a "enfriar" las nuevas ideas. Desde este punto de vista, vamos hacia las glaciaciones.
Qué conclusiones se pudieran sacar?

• La concentración de los participantes no traerá mejores condiciones de negociación, ni mejores precios o servicios para los compradores de software. No es esa la regla de los monopolios
• La innovación queda en pocas manos. No es un marco para el estímulo de la audacia de pensamiento: If you are swift, small and innovative, you'll likely get scooped up by a big fish.
• Tanto la fuerza creativa de los ahora empleados de alguna corporación gigantesca, que no conoce ni siquiera la cartera de productos que vende, como la confianza de los usuarios de cualquiera de los productos afectados, marchan hacia un estado de desconfianza en el compromiso con su producto. ¿Quién puede creer en la continuidad y soporte de un software, si éste fue tratado como un commodity, y pasó por tres ventas (Por ejemplo, un usuario de JDEdwards)?
• Quisiera mencionar a los perdedores: La caída de Peoplesoft, por caso, no sólo afectará a sus actuales 12.000 empleados, que deben estar buscando trabajo, sino también a sus distribuidores, a las empresas consultoras que invirtieron en costosas certificaciones de capacitación, a las empresas que pagaron centenares de miles de dólares, o millones, por implantar un producto que ahora será descartado, o desalentado.

Sin embargo, Gran Corporación fue muchas veces sinónimo de dinosaurio: éstos son grandes, les cuesta moverse, les afectan los cambios climáticos, y subsisten a condición de comer grandes cantidades de alimentos. Muy probablemente, una nueva generación de pequeños y voraces competidores les presente batalla por la comida.