Uml y acciones

los que no son miembros de su cofradía”. Se estaba refiriendo, por supuesto, a términos
tales como el ocultamiento de información, el encapsulado, la herencia y el polimorfismo. Sin embargo,
Page-Jones también nos prevenía que, independientemente de lo obscuro que nos parecieran, los
conceptos abarcados por estos términos iban a impactar de ahí en adelante nuestra forma de trabajo
porque laorientación a objetos no iba a ser sólo una moda pasajera.
El presente artículo no pretende sobajar a quienes no estén versados en orientación a objetos, y
espero que los lectores disculpen la inclusión de uno de estos espantos polisilábicos (el metamodelo)
en el título. En las líneas siguientes vamos a tratar de explicar qué hay detrás del amplio consenso que
ha impulsado al nuevo lenguaje,que sirve para crear modelos de análisis y diseño. La importancia del
tema estriba en que tenemos ante nosotros un estándar que va a afectar, tarde o temprano, la forma de
realizar el desarrollo o implantación de sistemas.
El Object Management Group (OMG, conocido por sus esfuerzos de estandarización en el área de
orientación a objetos) abrió un concurso en 1996 para que las empresas interesadaspropusieran un
lenguaje estándar de modelado de sistemas. En respuesta, el nivel 1.1 del Unified Modeling Language
(UML) fue presentado y propuesto por una lista muy significativa de empresas: Hewlett-Packard, i-
Logix, IBM, ICON Computing, Intellicorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum
Technology, Ptech, Rational Software, Reich Technologies, Sterling Software, Softeam,Taskon y
Unisys. En noviembre de ese año, como era de esperarse, la propuesta fue adoptada por el OMG.
Cabe aclarar que Rational Software ya había producido versiones anteriores del UML, aunque no
gozaron del grado de aceptación que tiene este último nivel.
Una de las ventajas que se pretenden lograr mediante un lenguaje unificado es permitir el intercambio
de diagramas y de formas derepresentación de sistemas entre diversas herramientas. Por ejemplo, si
un grupo de desarrolladores utilizara una herramienta CASE (Computer Aided Software Engineering) o
una herramienta de modelado visual, debiera existir la facilidad de transportarla a otra herramienta,
independientemente del proveedor o fabricante de cada una de ellas.
Pero el problema de estandarización no tiene que ver sólo conla transportabilidad de los diagramas
de una herramienta de software a otra. Para mediados de los noventa las llamadas “metodologías”
habían proliferado de tal forma que los proyectos y equipos de trabajo se topaban constantemente con
dificultades para seleccionar un método de análisis y diseño. Los métodos propuestos por Grady Booch,
Ivar Jacobson, James Martin, James Odell, Edward Yourdon,y muchos más, tenían asociadas sus
-- Converted from Word to PDF for free by Fast PDF -- www.fastpdf.com --
2
formas peculiares de diagramación. En otras palabras, cada uno de estos métodos contaba con su
propio lenguaje de modelado. Esta falta de estandarización impedía la reutilización de soluciones de
un proyecto a otro, y muchas veces inhibía la inversión en capacitación de personal y enherramientas
para diagramar. A lo anterior debemos añadir el esfuerzo y los riesgos inherentes a la curva de
aprendizaje de estos métodos de análisis y diseño.
Un paso para salir de la crisis
UML no va a ser la panacea para el desarrollo de sistemas, pero ciertamente va a contribuir a la
solución de algunos de los problemas más agudos, especialmente en proyectos grandes o complejos.
En eldesarrollo de software los modelos juegan el mismo papel que los planos y las especificaciones
en la industria de la construcción: primero, porque representan la forma de ir plasmando las
aproximaciones e ideas necesarias para resolver los requerimientos del cliente; segundo, porque los
modelos son esenciales para la comunicación entre los distintos equipos de trabajo y entre las distintas...