lunes, 12 de septiembre de 2011

UML y sus badenes en la autopista del Diseño de Software #chile #uml


Para poder diseñar un sistema de información, existen diversos lenguajes de modelamiento, uno de ellos es UML, que a ciencia cierta partió en los 90's.

Cierto es que si uno se pone a revisar la literatura, como es el caso de UML distilled primera edicion del autor Martin Flower, y luego se compara la con el autor Alistair Cockburn, se observa un debate.


Veamos el texto original:

"Uses and Extends


In addition to the links among actors and use cases, there are two other types of links in Figure 3-1. These represent the uses and extends relationships among use cases, These represent the uses and extends relationships among use cases. There are often the source of confusion for people who get the purposes of these two verbs confused, so take a moment to understand them.


You can use the extends relationship when you have one use case that is similar to another use case but does a bit more."

Pero por otra parte, si leemos el libro del autor Alistair Cockburn, señala lo siguiente:

"A critique of UML's "extends" relation 

The circumstance that caused "extends" to be invented in the first place was the business
practice of never touching the requirements file of a previous system release. Since Ericsson was building telephony systems, and in telephony the business is to add asynchronous services (see When to use extension use cases), the extends relation was both practical and applicable. The new team could, without touching a line of the original system requirements, build on the old, safely locked requirements document, adding the requirements for a new, asynchronous service at whatever point in the base use case was appropriate.

I am sad to sat that the UML 1.3 standard violates the original purpose of extends and violates basic principles of document management. In UML 1.3, you are supposed to name, in the base use case, those places at which extensions are permitted! These are called "extension points".

The first violation of document management is given by the extends relation in its original form - that you have to name the place in the base use case where the extension occurs. Once the base use case is edited, that location may move. The saving grace, in Ericsson's case, was that the requirements document was locked, and so the sentences were guaranteed not to move around. This is, by the way, a valid criticism of the numbered-step use case form. It is one more reason to discourage the use of extension use cases. I suspect that extension points were introduced to deal with this violation.

The more serious violation is that now, you must go back and modify the base use case whenever you write an extension use case that needs a new extension point! The original purpose of this exercise was to avoid having to modify the base use case when new, asynchronous services get added, but now we have to type into both the old and the new Type Spell Check use case! With that much intrusion, you would be better off using the simpler "includes" relation in the first place.

There is an additional violation. You are permitted (in some textbooks actually "encouraged") to expose the extension points in the use case diagram. This causes two problems on its own. First, you are actually publishing the internal parts of the use case into the global view offered by the use case diagram. Secondly, the extensions take up most of the space in the ellipse, obscuring the much more important goal name.

Finally, and this is not specific to the "extends" relation, UML 1.3 does not show different
In the end, I have come to view "extension points" as a mistake in UML 1.3.
So, first of all, don't use extension use cases, unless you have a really good reason. If you do use them, absolutely don't expose the extension points in the use case diagram.
Follow the advice of the section, Reminder: Use Includes."

Desgraciadamente, hasta hoy en día, continua el debate sobre <<extends>>

Por otra parte, revisando la web, me encontré con una carta, un tanto irónica del autor de Eiffel, Bertrand Meyer, donde critica a UML, puede leerse en su versión en inglés o traducida al español.


Ahora, que pasa en la realidad Chilena?, pues bien hasta donde me he topado con los documentos de diseño de sistemas de información, estos presentan leves pinceladas de lo que se debe construir, generalmente sucede esta poda, ya que las empresas (en su gran mayoría) estan enfocadas a facturar lo más pronto posible, mientras que su contraparte (el Cliente) esta orientado a que las máquinas emitan vapor de sus turbinas, una manera artística de señalar que desean que todo funcione bien y a la primera.


Pero The Chilean way, y quizas otras Naciones Ways podan el UML para poder llegar a trabajar con lo que sea importante, para luego partir con la generación de código.


Lo que también es cierto, que aquellos que llevan años de circo diseñando sistemas de información y sobreviviendo a los cambios y/o mejoras del UML, notarán la necesidad de contar con un lenguaje de diseño más robusto y que sea directa su interpretación.


Es interesante leer al colega Argentino que hace sus descargos contra UML, quizá ya sea tiempo de cambiar a un nuevo lenguaje que sea más preciso en la difícil arena del desarrollo de sistemas de información.








jueves, 31 de marzo de 2011

Ética en las certificaciones TI

Tiempo atrás escribí un breve artículo sobre mitos y realidades de las certificaciones TI, donde expresamente  algunos colegas sienten la obligación de certificarse ya sea por un tema de empleabilidad o para aumentar sus ingresos y mostrarse al mercado o al interior de las organizaciones como profesionales altamente capacitados o como también suele suceder las mismas empresas para ser más competitivas suelen certificar a los empleados en el dominio de alguna tecnología para competir de mejor manera en el mercado, me llamó la atención un joven Mexicano que simplemente veía a las certificaciones mucho más importante que estudiar una carrera, tema que no comparto para nada.

Cierto es, que con el tiempo siguen los cuestionamientos a prácticas para nada éticas, donde al momento de rendir un examen, se consiguen Braindumps o exámenes con las preguntas que dieron otros colegas en el mundo por un determinado producto o servicio.

Volviendo a buscar en Internet, me encuentro con un breve artículo de CEO sobre la ética en las certificaciones TI, es interesante que a pesar del tiempo que ha pasado desde que publiqué en el blog este ruido empieza a generar dudas en el mundo TI, se siga con las mismas prácticas en desmedro de los profesionales que si se preparan y cuentan con la experiencia para rendir los exámenes conforme a su dominio, aunque los avances de la tecnología van mucho más rápido que el mismo dominio.