16 December 2010

UML: mal entendimiento

He visto bastante en la escena productiva un mal entendimiento de UML, poniendo 2 posturas opuestas extremas, tal como:
  1. Los que creen que es la panacea
  2. Los que la odian 

Los del primer grupo creen que a base de la primera creen que al usar tal herramienta el proyecto va ser exitoso y todo funcionara.

Los del segundo grupo creen que es basura (muchas veces teniendo la misma base erronea del primer grupo, que es supuesta panacea), porque no les genero el esquelo completo de su diseño de patrones/clases

Generalmente ocurre lo que no se entiende no gusta, ha sucedido siempre en la historia de la civilización, pero acá podemos rescatar algunas buenas practicas para poder usar esta nomenclatura en vez de seguir neófito.

Lo que NO es:

  1. No es la panacea
  2. Por lo mismo no te entregara todas las clases (si tienen un buen diseñador/analista con experiencia en programación y patrones de diseño puede entregar algo robusto, pero siempre tendrá algo que falta y esas iteraciones deberán hacerla el programador, obviamente todo esto funciona si los requerimientos iniciales se hicieron bien y no se ha cambiado en el tiempo). 
Lo que Si es:

  1. Estandariza la nomenclatura
  2. Explica de forma simple ciertas especificaciones como con casos de uso y de secuencia para todo usuario y programadores respectivamente. 

por otro lado simple hay alguna manera de poder especificar guarismos, es más, Meyer y otros ya lo han hecho, lo malo de UML que es propietario, pero se alineo con OMG asi que es el mejor/último esfuerzo que se ha hecho de tal manera que la documentación sea estándar al contratar a Jacobson e IBM comprar a Rational.

-- (15/10/08).



Después de haber escrito el pasado texto hace ya 2 años, veo que Fowler tiene un punto de vista bastante parecido donde me llama mucho la atención los siguientes párrafos:
Changing the design doesn't necessarily mean changing the diagrams. It's perfectly reasonable to draw diagrams that help you understand the design and then throw the diagrams away. Drawing them helped, and that is enough to make them worthwhile. They don't have to become permanent artifacts. The best UML diagrams are not artifacts.

A lot of XPers use CRC cards. That's not in conflict with UML. I use a mix of CRC and UML all the time, using whichever technique is most useful for the job at hand.
 Bueno lo escribió el 2004 :-)

-- (15/12/10)

13 December 2010

EJB 3.0 Database Persistence with Oracle Fusion Middleware 11g : Review

This is a good book (→tutorial) for any developer that wants to use EJB 3.0 with the most popular Oracle J2EE technologies.

The book starts with a simple introduction of EJB 3.0 and compares that spec to EJB 2.x, overviews new features such as, annotations, JPA and interceptors.

Then it goes into this topic in depth, always tied-up to JDeveloper; for instance, shows how to convert EJB 2.x to 3.0, it's a very good example if the reader comes from that legacy specification or to see explicitly how much effort we are saving coding and not generating deploy descriptors to obtain the same business/architecture JEE feature.

Continuing the Book's Oracle point of view, look into EclipseLink JPA, JDeveloper (as main IDE) and complete chapter of Eclipse OEPE and their details. Chapters dedicated to integration with ADF & JSF separately, EJB relationships, and finishing with Web Services.

A lot of details, clear explanations, source code, screen-shots of step-by-step instructions to avoid any doubt to the reader to get the best of these specs and tools.

Blog Archive

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.